Splunk4Rookies - Observability Cloud

2分 著者Robert Castley & Pieter Hagen

このワークショップでは、Splunk Observability Cloud が提供する、フロントエンドアプリケーションからバックエンドサービスまで、ユーザーエクスペリエンスを即時に可視化する能力について紹介します。これを通じて、Splunk Observability Cloud の最も魅力的な製品機能と差別化要因のいくつかを体験できます。

  • インフラ監視(Infrastructure Monitoring)
  • 完全で忠実な Real User Monitoring(RUM)
  • Application Performance Monitoring(APM)による End to End の NoSample™ で完全忠実なトレースの可視性
  • コード入力を必要としないログクエリ
  • 外形監視・合成監視(Synthetic Monitoring)
  • タグ分析とエラースタックを使用した根本原因の特定
  • Related Contents(関連する機能や製品に関するテレメトリーデータへのコンテンツへのリンク)

Splunk Observability Cloud が最も重視しているのは、テレメトリデータを統合することで、エンドユーザーエクスペリエンスとあなたのアプリケーションスタックとを1つの画面で完全に理解できるようにすることです。

このワークショップでは、AWS EC2 インスタンスに展開されたマイクロサービスベースのアプリケーションを使用します。このアプリケーションは、ユーザーが製品を閲覧し、カートに追加し、チェックアウトすることができるシンプルなeコマースアプリケーションです。このアプリケーションは OpenTelemetry で計装されています。


OpenTelemetry は、テレメトリデータ(メトリクス、トレース、およびログ)を計装・生成・収集・エクスポートするためのツール、API、およびソフトウェア開発キット(SDK)のコレクションです。これにより、ソフトウェアのパフォーマンスと動作を分析できます。

OpenTelemetry コミュニティは成長を続けています。Splunk、Google、Microsoft、Amazonなど多くの組織が協力したプロジェクトで、現在、Kubernetes の次に多くの貢献者を有するプロジェクトとなっています。

Full Stack Full Stack

Last Modified 2024/04/05

Splunk4Rookies - Observability Cloudのサブセクション

ワークショップの概要

2分

イントロダクション

このワークショップのゴールは、ある問題を体験し、Splunk Observability Cloud を使用してトラブルシューティングを行い、根本原因を特定することです。これを実現するために、私たちは Kubernetes で動作する完全なマイクロサービスベースのアプリケーションを提供し、それが Splunk Observability Cloud にメトリクス、トレース、ログを送信するように計装しています。

参加対象者は?

Splunk Observability をハンズオンの環境で理解したいと考えている方。このワークショップは、ほとんど、または、まったく Splunk Observability の経験がない人向けに設計されています。

必要なものは何ですか?

皆様自身の参加と、パソコン、外部のウェブサイトにアクセスできるブラウザがあれば十分です。私たちはこれらのワークショップを対面、または、Zoom で実施しています。あなたのデバイスに Zoom クライアントがない場合でも、ウェブブラウザを通じてワークショップ環境にアクセスすることができます。

このワークショップで何がカバーされていますか?

この3時間のセッションでは、ハンズオンの環境でストリーミング分析NoSample™ で完全忠実な分散トレーシングを備えた唯一の可観測性プラットフォームである Splunk Observability の基本を学びます。

OpenTelemetry

なぜ OpenTelemetry が必要なのか、そして、それが可観測性にとってなぜ重要なのかについて簡単に紹介します。

Splunk Observability ユーザーインターフェースのツアー

Splunk Observability Cloud のさまざまなコンポーネントを渡り歩きながら、5つの主要なコンポーネント(APM、RUM、Log Observer、Synthetics、Infrastructure)を操作する方法を紹介します。

リアルユーザーデータの生成

オンラインブティックというウェブサイトを使用してお買い物を楽しみます。ブラウザ、モバイル、タブレットを使用し、架空の通貨で買い物を行っていただきます。これを通じて、 メトリクス(問題があるのか?)トレース(問題はどこにあるのか?)ログ(問題は何か?) を送信します。

Splunk Real User Monitoring (RUM)

すべての参加者のブラウザセッションから受信するテレメトリーデータに基づいて実際のユーザーのデータを調査します。ここでのゴールは、パフォーマンスが悪かったブラウザ、モバイル、タブレットのセッションを見つけて、トラブルシューティングのプロセスを開始することです。

Splunk Application Performance Monitoring (APM)

RUM トレース(フロントエンド)から APM トレース(バックエンド)へとジャンプすることで、End to End 全体を可視化する能力を理解しましょう。すべてのサービスはテレメトリー(トレースとスパン)を送信しており、Splunk Observability Cloud はそれを可視化・分析し、異常やエラーを検出するために使用することができます。

Splunk Log Observer (LO)

Related Content の強力な機能を使うと、あるコンポーネントから別のコンポーネントにジャンプすることが可能になります。ここでは、私たちは APM トレースから、そのトレースに関連するログにジャンプします。

Splunk Synthetics

私たちのアプリケーションを24時間365日で監視し、問題が発生したときにアラートを受け取ることができたら素晴らしいことではないでしょうか? これが Synthetics の役割です。オンラインブティックサイトでの典型的なユーザージャーニーのパフォーマンスと可用性を1分ごとにチェックするシンプルなテストをご紹介します。

Last Modified 2024/04/05

OpenTelemetry とは何か、なぜ注目するべきなのか?

2分

OpenTelemetry

クラウドコンピューティングやマイクロサービスアーキテクチャ、更に、ますます複雑になりつつあるビジネス要件の台頭により、可観測性へのニーズはこれまで以上に高まっています。可観測性とは、システムの内部状態をその出力を調べることで理解する能力のことです。ソフトウェアの文脈では、メトリクストレース、およびログを含むテレメトリーデータに基づいてシステムの内部状態を理解する能力を意味します。

システムを観測可能にするためには、計装が必要です。つまり、コードはトレース、メトリクス、およびログを出力する必要があります。その上で、計装によって出力されたデータが、Splunk Observability Cloud などの可観測性バックエンドに送信される必要があります。

メトリクストレースログ
問題があるのか?問題はどこにあるのか?問題は何か?

OpenTelemetry は2つの重要な側面を持ちます。

  • プロプライエタリなデータ形式やツールに縛られることなく、自分が生成するデータを自分のものとすることを可能にします。
  • 単一の API と規約を学ぶことを可能にします

この2つが組み合わさることで、チームや組織は今日の現代的なコンピューティングの世界で必要な柔軟性を得ることができます。

可観測性に取りかかるときに考慮すべきことはたくさんありますが、その中でも重要な質問は 「どのようにして可観測性ツールにデータを取り込むのか?」 というものです。OpenTelemetry の業界全体での採用により、これまで以上に簡単に、この質問に答えることができるようになっています。

なぜ注目するべきなのか?

OpenTelemetry は完全にオープンソースで、無料で使用することができます。過去には、監視および可観測性ツールはプロプライエタリなエージェントに大きく依存していました。つまり、追加のツールを設定・変更するために、インフラストラクチャレベルからアプリケーションレベルに至るまで、システム全体で大量の変更が必要になってしまうということです。

OpenTelemetry はベンダーニュートラルであり、可観測性に関わる多くの業界のリーダーによってサポートされています。そのため、利用者はいつでも、わずかな計装に対する変更だけで、サポートされている可観測性ツールを切り替えることができます。これは、どの OpenTelemetry のディストリビューションが使用されているかを問わず真実です。Linux と同様に、さまざまなディストリビューションがあり、設定とアドオンがバンドルされていますが、根本的に、これらはすべてコミュニティ主導の OpenTelemetry プロジェクトに基づいているものなのです。

Splunk は OpenTelemetry に完全にコミットしています。これにより、お客様は、いかなるタイプ、いかなるアーキテクチャ、いかなるソース、いかなる規模感であっても、すべてのデータをリアルタイムに収集し活用することができます。OpenTelemetry は監視のありかたを根本的に変えつつあり、IT チームと DevOps チームがあらゆる疑問やあらゆるアクションに対してデータを活用することを可能にしています。このワークショップ中に、こういった特徴について体験することができるはずです。

OpenTelemetryのロゴ OpenTelemetryのロゴ

Last Modified 2024/04/05

UI - クイックツアー 🚌

まずは、Splunk Observability Cloud のさまざまなコンポーネントをウォークスルーしていきましょう。UI に慣れてもらうことが目的です。

  1. Splunk Observability Cloud へのサインイン
  2. リアルユーザーモニタリング (RUM)
  3. アプリケーションパフォーマンスモニタリング (APM)
  4. Log Observer
  5. Synthetics
  6. Infrastructure Monitoring
Tip

このワークショップでは、以下の方法で簡単に操作できます

  • このページの右上にある左矢印(< | >
  • キーボードの左(◀️)および右(▶️)のカーソルキー
Last Modified 2024/04/05

3. UI - クイックツアーのサブセクション

はじめに

2分

1. Splunk Observability Cloud にサインインする

Splunk からワークショップの組織への招待メールが届くはずです。下のスクリーンショットのようなメールです。もし見つけられない場合は、スパム/ごみ箱フォルダを確認するか、講師に知らせてください。また、ログイン - よくある質問で他の解決策を確認いただくことも可能です。

Join Now ボタンをクリックするか、メールに記載されているリンクをクリックして、次に進んでください。

すでに登録プロセスを完了している場合は、残りをスキップして直接 Splunk Observability Cloud に進み、ログインすることができます。

email email

Splunk Observability Cloud を初めて使用する場合は、登録フォームが表示されます。あなたのフルネームと希望のパスワードを入力してください。パスワードの要件は以下の通りです

  • 必須 8文字から32文字の間でなければなりません
  • 必須 少なくとも1つの大文字を含む必要があります
  • 必須 少なくとも1つの数字を含む必要があります
  • 必須 少なくとも1つの記号を含む必要があります(例:!@#$%^&*()_+)

利用規約に同意するためのチェックボックスをクリックし、SIGN IN NOW ボタンをクリックしてください。

User-Setup User-Setup

Last Modified 2024/04/05

1. はじめにのサブセクション

ホームページ

5分

Splunk Observability Cloud に登録しログインすると、ホーム画面であるランディングページに移動します。ここでは、使用開始にあたって役に立つ機能を確認できます。

ホームページ ホームページ

  1. “Explorer your data” : 有効になっているインテグレーションを表示しています。管理者であればさらにインテグレーションを追加できます。
  2. “Documentation” : Splunk Observability Cloud に取り組み始める際に利用できるトレーニングビデオやドキュメンテーションへのリンクです。
  3. “Recents” : 最近作成・使用したダッシュボードや Detector にすぐにアクセスすることができます。
  4. メインメニュー: Splunk Observability Cloud の各機能に移動できます。
  5. 組織(Org)切り替え: 組織間を簡単に切り替えることができます(複数の組織のメンバーである場合)。
  6. メインメニューの展開/縮小: 画面サイズに応じて、メインメニューを展開 » / 縮小 « できます。

最初の Exercise に取り組んでみましょう。

Exercise
  • メインメニューを展開し、Settings をクリックします。
  • 組織切り替えで、複数の組織にアクセスできるかどうかを確認します。
Hint

これまでに Splunk Observability を使用したことがある場合、以前使用した組織のページを開いている可能性があります。正しいワークショップの組織にいることを確認してください。複数の組織にアクセスできる場合は、講師に確認してください。

Exercise
  • Onboarding Guidance をクリックします(ここでは、オンボーディングパネルの表示を切り替えることができます。これは、製品を十分に理解していて、より多くの情報を表示できるようにスペースを使用したい場合に便利です)。
  • Home Page のオンボーディングコンテンツを非表示にします。
  • メニューの下部で、好みの外観を選択します。LightDark、または Auto モードが選択できます。
  • Sign Out ボタンが表示されていることに気付きましたか? でも、押さないでくださいね!😊
  • メインメニューに戻るために < をクリックします。

次に、Splunk Real User Monitoring (RUM) をチェックしましょう。

Last Modified 2024/04/05

RUMの概要

5分

Splunk RUM は業界唯一の End to End の, NoSample™ RUM ソリューションです。すべての Web およびモバイルセッションに関するユーザーエクスペリエンス全体を可視化し、フロントエンドの全てのトレースをバックエンドのメトリクス、トレース、ログと一意に組み合わせることができます。IT 運用チームとエンジニアリングチームは、迅速にエラー範囲の特定、対処の優先度付け、他の問題との切り分け、実際のユーザーに対する影響の測定を行うことができます。また、すべてのユーザー操作をビデオでリプレイしながらパフォーマンス指標と相関させることでエンドユーザー体験を最適化することができます。

全てのユーザーセッションを分析する: ストリーミング分析によって、シングルページおよびマルチページアプリまで、全てのユーザーセッションをキャプチャし、すべてのリソース、画像、ルート変更、API 呼び出しが与える顧客への影響を測定します。

問題をより迅速に関連付ける: 無限のカーディナリティと完全なトランザクション分析により、複雑な分散システム全体で問題をより迅速に特定し、相関付けることができます。

遅延とエラーを特定する: それぞれのコード変更やデプロイに対して遅延、エラー、パフォーマンスが悪い状態を簡単に特定します。コンテンツ、画像、およびサードパーティの依存関係が顧客にどのような影響を与えるかを測定します。

ページパフォーマンスを取得し改善する: Core Web Vitals を活用してページロード体験、対話性、視覚的安定性を測定し、改善します。影響を及ぼす JavaScript エラーを見つけて修正し、最初に改善すべきページを簡単に理解できます。

意味のあるメトリクスを探索する: 特定のワークフロー、カスタムタグ、およびインデックス化されていないタグに関する自動提案に基づいたメトリクスによって、顧客への影響を即座に視覚化し、問題の根本原因を迅速に特定します。

エンドユーザー体験を最適化する: すべてのユーザーインタラクションをビデオリプレイで確認しながらパフォーマンスメトリクスと関連付け、エンドユーザー体験を最適化することができます。

アーキテクチャの概要 アーキテクチャの概要

Last Modified 2024/04/05

2. RUMの概要のサブセクション

RUM ホームページ

メインメニューで RUM をクリックすると、RUM のメインとなるホーム画面、ランディングページに移動します。このページでは、選択したすべての RUM アプリケーション全体のステータスを一目で確認できることに主眼が置かれています。フルサイズ、あるいは、コンパクトビューのいずれかの形式で表示することができます。

ステータスダッシュボードの表示タイプがいずれの場合でも、RUM ホームページは3つのセクションで構成されています。

RUM ページ RUM ページ

  1. オンボーディングパネル: Splunk RUM を始めるためのトレーニングビデオとドキュメンテーションへのリンク(画面のスペースが必要な場合は、このパネルを非表示にできます)
  2. フィルターパネル: 時間枠、環境、アプリケーション、ソースタイプでフィルタリングすることができます
  3. アプリケーションサマリーパネル: RUM データを送信するすべてのアプリケーションのサマリーが表示されます
RUM における 環境(Environment),アプリケーション(App),ソースタイプ(Source)
  • Splunk Observability は、RUM トレースの一部として送信される Environment タグを使用して、“Production” や “Development” などの異なる環境からのデータを区分します。
  • さらに App タグによる区分も可能です。これにより、同じ環境で動作する別々のブラウザ/モバイルアプリケーションを区別することができます。
  • Splunk RUM はブラウザとモバイルアプリケーションの両方で利用可能であり、Source を使用してそれらを区別することができます。このワークショップでは、ブラウザベースの RUM のみを使用します。
Exercise
  • 時間枠が -15m に設定されていることを確認してください
  • ドロップダウンボックスからワークショップの Environment を選択してください。命名規則は [ワークショップの名前]-workshop です(これを選択すると、ワークショップの RUM アプリケーションが表示されるはずです)
  • App を選択します。命名規則は [ワークショップの名前]-store です。SourceAll に設定したままにしてください。
  • JavaScript Errors タイルで Cannot read properties of undefined (reading ‘Prcie’) と表示される TypeError エントリをクリックし、詳細を確認してください。エラーが発生したウェブサイトのどの部分か、すぐに見つけることができるはずです。これにより迅速に問題を修正することができます。
  • パネルを閉じます。
  • 3列目のタイルには Web Vitals が表示されています。これはユーザーエクスペリエンスの3つの重要な側面であるページのローディング対話性、および視覚的安定性に焦点を当てたメトリックです。

Web Vitals メトリクスに基づいて、現在のウェブサイトのパフォーマンスをどのように評価しますか?

Web Vitals メトリクスによれば、サイトの初期ロードはOKで、良好 と評価できます

  • 最後のタイル、Most recent detectors タイルは、アプリケーションでトリガーされたアラートがあるかどうかを表示します。
  • アプリケーション名の前の下向き 矢印をクリックして、ビューをコンパクトスタイルに切り替えます。このビューでも主要な情報がすべて利用可能です。コンパクトビューの任意の場所をクリックしてフルビューに戻ります。
Additional Exercise

RUM ホームページではフロントエンドの概要をシンプルに確認することができますが、詳細なステータス確認や問題調査が必要になるケースもあるはずです。

フロントエンドの問題特定・原因調査を行う方法は、5. Splunk RUM を見てみましょう。

お時間がある方は、更にいくつかの機能を確認してみましょう。

  • [ワークショップの名前]-store をクリックします。詳細なダッシュボードビューが表示されます。
  • UX Metrics, Front-end Health, Back-end Health, Custom Events というメニュータブをそれぞれ開いてみましょう。
    • それぞれのページで、どんなメトリクスが表示されているか確認してみてください
  • Custom Events をクリックします。
    • Custom Events は、特定の操作(例:カートに商品を追加するボタンを押す、商品詳細ページを開く、など)をイベントとして記録し、集計したものです。

RUM Dashboard RUM Dashboard

Custom Events として記録された処理で、1分あたりのリクエスト回数が最も多い処理は何ですか?

AddToCartです

  • Custom Event Requests のすぐ下の see all をクリックします
  • Tag Spotlight というビューが表示されたはずです
    • Tag Spotlight は取得したテレメトリーデータに含まれるタグ情報ごとの傾向を表示・分析する機能です

RUM Tag Spotlight RUM Tag Spotlight

  • Custom Event Name というタイルの中で AddToCart という項目を探します。みつけたらクリックして Add to filter をクリックしてください
    • これにより、AddToCart 処理だけに注目をして、分析を行うことができます。RUM Tag Filtering RUM Tag Filtering

このアプリケーションに対してアクセス元として最も多い国はどこですか? またそれはどのタイルから分かりますか?

アメリカ (US) です。Countryタイルから分かります

  • User Sessions をクリックします
  • Duration をクリックして、処理時間が長い順に並べ替えます
    • AddToCart に該当する処理を実施したユーザーのセッションを確認することができます
  • 最も処理時間が長いユーザーセッションの Session ID をクリックします RUM User Sessions RUM User Sessions
  • 画面右上にある Replay ボタンを押してみたり、各処理の時間やタグ情報を確認したり、APM というリンクにカーソルを当ててみたりしましょう RUM Waterfall RUM Waterfall

次に、Splunk Application Performance Monitoring (APM) をチェックしましょう。

Last Modified 2024/04/05

APMの概要

5分

Splunk APM は、NoSample™ で End to End ですべてのアプリケーションやその依存性に関する可視性を提供し、モノリシックアプリ、マイクロサービスの両方で問題をより迅速に解決することに寄与します。チームは新しいアプリケーションをデプロイした際にもすぐに問題に気づくことができます。また、問題の発生源を絞り込み、切り分けることでトラブルシューティングに自信を持って取り組むことができます。バックエンドサービスがエンドユーザーとビジネスワークフローに与える影響を理解することを通じて、サービスのパフォーマンスを最適化することができます。

リアルタイムモニタリングとアラート: Splunk は、すぐに利用可能なサービスダッシュボードを提供します。急激な変化があると RED メトリクス(処理量、エラー、遅延)に基づいて自動的に問題を検出・アラートを発します。

動的なテレメトリーマップ: モダンなプロダクション環境でのサービスパフォーマンスをリアルタイムで簡単に視覚化します。インフラストラクチャ、アプリケーション、エンドユーザー、およびすべての依存関係からサービスパフォーマンスをエンドツーエンドで可視化することで、新しい問題を迅速に絞り込み、より効果的にトラブルシューティングを行うことができるようになります。

インテリジェントなタグ付けと分析: ビジネス、インフラストラクチャ、アプリケーションからのすべてのタグを一か所で表示し、特定のタグに対して遅延やエラーに関する新しい傾向を簡単に比較・理解することができます。

AI を活用したトラブルシューティングによる最も影響の大きい問題を特定: 個々のダッシュボードを手間をかけて掘り下げる必要はありません。問題をより効率的に切り分けることができます。サービスと顧客に最も影響を与える異常とエラーの原因を自動的に特定します。

すべてのトランザクションに対する完全な分散トレーシング分析: クラウドネイティブ環境の問題をより効果的に特定します。Splunk の分散トレーシングは、インフラストラクチャ、ビジネスワークフロー、アプリケーションの特徴を踏まえた上で、バックエンドとフロントエンドからのすべてのトランザクションを視覚化し、その関係性を明らかにします。

フルスタックでの相関性の可視化: Splunk Observability 内で、APM はトレース、メトリクス、ログ、プロファイリングをすべてリンクさせ、スタック全体における各コンポーネントの依存関係やパフォーマンスを簡単に理解できるようにします。

データベースクエリパフォーマンスの監視: SQL および NoSQL データベースからの遅いクエリや高頻度に実行されるクエリが、サービス、エンドポイント、およびビジネスワークフローにどのような影響を与えるかを簡単に特定できるようにします。計装は必要ありません。

アーキテクチャの概要 アーキテクチャの概要

Last Modified 2024/04/05

3. APMの概要のサブセクション

APM ホームページ

メインメニューで APM をクリックすると、APM ホームページが表示されます。このページは3つのセクションで構成されています。

APMページ APMページ

  1. オンボーディングパネル: Splunk APM を始める際に参考になるトレーニングビデオとドキュメンテーションへのリンク
  2. APM Overview: 最もエラー率やレイテンシーが高いサービスとビジネスワークフローのリアルタイムメトリクス
  3. 機能パネル: サービス、タグ、トレース、データベースクエリパフォーマンス、コードプロファイリングの詳細分析を行う際に使用するリンク

APM Overview パネルは、アプリケーションのヘルスステータスに関する概要を示します。これにはアプリケーションのサービス、レイテンシー、エラーのサマリーが含まれています。また、エラーレートが最も高いサービスとビジネスワークフローのリストも含まれています(ビジネスワークフローは、特定の活動やトランザクションに関連する一連のトレースの集合で、エンドツーエンドの KPI を監視し、根本原因とボトルネック特定することができるようになります)。

環境(Environment)について

複数のアプリケーションを簡単に区別するために、Splunk は Environment を使用します。ワークショップ環境の命名規則は [ワークショップの名前]-workshop です。インストラクターが正しい名前を案内します。

Exercise
  • 表示されている画面上の時間枠が過去15分(-15m)に設定されていることを確認してください。
  • ドロップダウンボックスからワークショップの Environment を選択してください。そのワークショップ環境名のみが選択されていることを確認してください。

エラーレートが最も高いサービスに関するチャートから、どんなことが分かりますか?

paymentservice が高いエラーレートを持っています

概要ページを下にスクロールすると、一部のサービスに Inferred Service が表示されることに気づくでしょう。

Splunk APM は、リモートサービスを呼び出すスパンに含まれる情報から、存在が推論されるサービス、つまり、Inferred Service を検出することができます。Inferred Service として検出されるサービスの例としては、データベース、HTTPエンドポイント、メッセージキューなどがあります。Inferred Service は計装されていませんが、サービスマップとサービスリストに表示されます。

Additional Exercise

もうすこし詳細に確認してみましょう。

バックエンドアプリケーションでの問題特定・原因調査を行う方法は、6. Splunk APM で取り組んでいただくことが可能です。

お時間がある方は、更にいくつかの機能を確認してみましょう。

  • Service Map をクリックします。
  • あわせて Show Legend を開いてみましょう。この Service Map に表示されている内容の凡例です。
    • Service Map は、アプリケーションの相関性を表すマップです。APM エージェントを利用すると、アプリケーション間での連携やリクエストから自動的に生成されます。
    • 点線の四角や丸のオブジェクトは、Inferred Service です。これらは計装されていませんが、計装済みのアプリケーションが連携先として利用していると推定されたため、サービスマップ上にも表示されています。

APM Service Map APM Service Map

  1. エラー率が高いと、サービスマップ上ではどのように表示されますか?
  2. このシステムでは、どのようなDBを使用していますか?
    • ヒント: DBは Inferred Service として、四角のオブジェクトで表示されます
  1. アプリケーションが赤くハイライトされます
  2. MySQLとRedisを使用しています
  • Legend を開いている場合は閉じてください。
  • エラーが頻発している paymentservice をクリックしてみましょう。
  • 画面右側のメニューの表示が少し変わったはずです。paymentservice に関するメトリクスやメニューが表示されるようになりました。
  • Breakdown をクリックし、version を探して、クリックしてみましょう。

APM Breakdown APM Breakdown

  • Service Map の表示が変わり、paymentservice がアプリケーションのバージョンごとに表示されるようになったはずです。
  • Splunk APM では、タグ情報に基づいてサービスマップ自体を変化させて分析することができます。非常に視覚的なので、このシステムに詳しくない人でも探索できそうですね!

APM Breakdown - Version APM Breakdown - Version

paymentservice を version ごとに分析すると、どういうことが分かりますか?

v350.10バージョンの方がエラー率が高いことが分かります

  • v350.10 をクリックして、メニューのTraceを開いてみましょう。
  • 画面右上に Switch to TraceAnalyzer というボタンがある場合は、これをクリックしてください。
    • アプリケーションに対するリクエストが、どのように処理されたかをトレースし、エラーやボトルネックを特定したり、その処理の詳細を分析することができます
    • この画面では、トレースの一覧が表示されます
  • Errors Only のトグルを有効化してください。また、Duration をクリックして処理時間が長い順に並べ替えてください。

APM Trace APM Trace

  • 最も処理時間が長いトレースの Trace ID をクリックします。
  • このトランザクションがどのように処理されたかを確認しましょう。

APM Trace Detail APM Trace Detail

  • 各行の処理を スパン(Span)、スパン全体を トレース(Trace) と呼びます。
  • 赤とピンクの ! マークアイコンを見つけられますか? これはそれぞれ、一連のトランザクションの中でエラーを発生させたスパン(Root Cause Error)と、その影響で発生したエラーになったスパンとを区別して表示しています。
    • 選択されたトレースによっては、ピンクの ! は表示されないかもしれません。
  • いずれかのスパンをクリックすると、そのスパンに関連するタグ情報を確認することができます。
  • 同じ処理が繰り返されている場合、スパンの左に x6 のように反復回数が表示されることがあります。
  1. 根本原因のエラーが発生しているサービスは何ですか?そのエラーメッセージは何ですか?
  2. このトレース処理に時間がかかっている原因として、どういったことが考えられますか?
  1. paymentserviceです。エラーメッセージは Invalid request を記録しています
  2. checkoutserviceとpaymentserviceでエラーが発生し、何度もリトライされていることで全体の処理時間が長くなっています
  • 画面の最下部には InfrastructureLogs というボタンが表示されているはずです。これらは、この処理と関連するシステムのコンポーネントやログの存在を教えてくれます。
  • Logs をクリックし、Logs for trace … から始まる箇所をクリックしてみましょう。

APM Related Log APM Related Log

  • Log Observer の画面が表示されます。この画面では、先ほどのトレースに関連するログのみを自動で抽出して提示してくれています。
  • Log Observer の使い方は、次のワークショップコースの中で扱います。

APM Log from Trace APM Log from Trace

次に、Splunk Log Observer (LO) をチェックしましょう。

Last Modified 2024/04/05

Log Observerの概要

5 minutes

Log Observer Connect は、Splunk Platform 上に取得されたログデータを直感的かつノーコードのインターフェースにシームレスに取り込むことが可能で、素早く問題を見つけて修正できるよう設計されています。ログベースの分析を簡単に実行でき、Splunk Infrastructure Monitoring のリアルタイムメトリクスや Splunk APM のトレースを1つの画面でシームレスに関連付けて確認することができます。

End to End の可視性: Splunk Platform の強力なログ機能を Splunk Observability Cloud のトレースとリアルタイムメトリクスと組み合わせることで、ハイブリッド環境のより深い洞察とコンテキストを提供します。

迅速かつ簡単なログベースの調査: Splunk Cloud Platform または Enterprise に既に取り込まれているログを Splunk Observability Cloud の簡素で直感的なインターフェースで再利用することができます。カスタマイズできて、すぐに使えるダッシュボードも活用できます(SPL の知識は不要です!)

大規模組織での利用が可能で、操作効率も向上: ログ管理をチームをまたいで一元化することで、データとチームの障壁を取り払い、システム全体に対するサポートを向上させます。

Logo graph Logo graph

Last Modified 2024/04/05

4. Log Observerの概要のサブセクション

Log Observer ホームページ

メインメニューで Log Observer をクリックしてみましょう。Log Observer ホームページは4つのセクションで構成されます。

Lo Page Lo Page

  1. オンボーディングパネル: Splunk Log Observer を始めるためのトレーニングビデオとドキュメンテーションへのリンク。
  2. フィルターパネル: 時間枠、index、および Field に基づいてログをフィルタリングすることができます。また、事前に保存しておいたクエリを利用することもできます。
  3. Log table: 現在のフィルタ条件に一致するログエントリーのリスト。
  4. Fields: 現在選択されている index で使用可能なフィールドのリスト。
Splunk index

一般的に、Splunk では「index」はデータが保存される指定された場所を指します。これはデータを格納するフォルダまたはコンテナのようなものです。 Splunk index 内のデータは検索と分析が容易になるように整理され構造化されています。異なるインデックスを作成して特定のタイプのデータを格納することができます。たとえば、Web サーバーログ用に1つの index、アプリケーションログ用に別の index を作成しておくようなことが可能です。

Tip

これまでに Splunk Enterprise または Splunk Cloud を使用したことがある場合、おそらくログから調査を開始することに慣れているでしょう。このあとの Exercise でも同じように取り組むことは可能ですが、このワークショップでは調査にあたってすべての OpenTelemetry シグナルを使用していきます。

さて、簡単なログ検索の演習を行いましょう。

Exercise

まず、visa を使用した注文を検索してみます。

  • 時間枠を -15分 に設定してください

  • Filter で Add Filter をクリックし、次にダイアログで Fields をクリックしてください。

  • cardType と入力して選択してください

  • Top values の下にある visa をクリックし、その後 = をクリックしてフィルターに追加しましょう。

    logo search logo search

  • ログテーブル内のログエントリの1つをクリックして、そのエントリに cardType: "visa" が含まれていることを確認してください。

今度は出荷されたすべての注文を探してみましょう。

  • Filter で Clear All をクリックして前のフィルターを削除してください。
  • 再度 Filter で Add Filter をクリックし、次に Keyword を選択します。次に Enter Keyword… ボックスに order: と入力してエンターキーを押してください。
  • これで order: という単語を含むログ行しか表示されなくなります。まだ多くのログ行がありますので、さらにフィルタリングしていきましょう。
  • 別のフィルターを追加します。今度は Fields ボックスを選択し、Find a field… と表示されている検索ボックスに severity と入力して選択してください。 severity severity
  • ダイアログボックスの下部にある Exclude all logs with this fields をクリックしてください。注文ログ行には severity が割り当てられていないため、これにより不要なログ行を除外することができます。
  • 画面上部にオンボーディングコンテンツが表示されている場合は、Exclude all logs with this fields ボタンを押すためにページをスクロールする必要があるかもしれません。
  • これで過去15分間に販売された注文のリストが表示されたはずです。

次に、Splunk Synthetics を確認しましょう。

Last Modified 2024/04/05

Syntheticsの概要

5 minutes

Splunk Synthetic Monitoring は、URL、API、および重要な Web サービス全体に対する可視性を提供しており、問題の解決をより迅速に行うことができるようになります。IT 運用およびエンジニアリングチームは、簡単に問題を検出してアラートを発報したり、問題を優先順位づけすることができます。複数のステップから構成されるユーザージャーニーをシミュレーションしたり、新しいコードのデプロイがビジネスにどのような影響を与えるか測定したり、Web のパフォーマンスを最適化することも可能です。ステップバイステップのガイドにより、より良いデジタルエクスペリエンスを担保することにもつながります。

可用性の確認: ブラウザテストによって、ユーザーエクスペリエンスを構成する多段階のワークフローをシミュレートすることができます。これにより、重要なサービス、URL、および API のヘルスステータスや可用性を監視、アラートすることができます。

パフォーマンス指標の改善: Core Web Vitals およびモダンなパフォーマンスメトリクスを活用することで、すべてのパフォーマンスに関する問題点を1つの画面上で確認することができます。ページパフォーマンスを改善するために必要となるページの読み込み、対話性、視覚的な安定性に関するメトリクスを測定・改善したり、JavaScript エラーを見つけて修正したりすることができます。

フロントエンドからバックエンドまで: Splunk APM、Infrastructure Monitoring、On-Call、および ITSI との統合により、チームはバックエンドサービスやこれを支えるインフラストラクチャの状況、インシデント対応状況を踏まえたエンドポイントの稼働状態を確認することができ、環境全体を横断的に捉えてトラブルシュートを行うことができます。

問題の検知とアラート: エンドユーザーエクスペリエンスを監視およびシミュレートすることで、顧客に影響を与える前に API やサービスエンドポイント、重要なビジネストランザクションに対する問題を検知、アラートし、解決することができます。

ビジネスパフォーマンス: 主要なビジネストランザクションのために多段階のユーザーフローを簡単に定め、レコーディングすることで、数分でクリティカルなユーザージャーニーに関するテストを開始することができます。アップタイムやパフォーマンスに関わる SLA および SLO をトラックし、通知してくれます。

表示画面の記録とビデオ再生: 録画した画面や操作の再生、スクリーンショットの取得を行うことが可能で、現代でよく用いられるパフォーマンススコア、比較用のベンチマーク指標、エンドユーザーの体感を数値化したメトリクスとともに確認することができます。ビジュアルコンテンツの配信速度を最適化し、ページの安定性や対話性を向上させることで、より良いデジタルエクスペリエンスを展開することができます

Synthetics overview Synthetics overview

Last Modified 2024/04/05

5. Syntheticsの概要のサブセクション

Syntheticsホームページ

Synthetics をメインメニューでクリックしてみましょう。Synthetics ホームページに移動したはずです。このページには、役立つ情報を確認したり、Synthetic テストを選択または作成する3つのセクションがあります。

Synthetic main Synthetic main

  1. オンボーディングパネル: Splunk Synthetics を始めるためのトレーニングビデオとドキュメンテーションへのリンク。
  2. テストパネル: 設定されているすべてのテストのリスト(BrowserAPI、および Uptime
  3. Add new test: 新しい Synthetic テストを作成するためのドロップダウン。
Info

ワークショップの一環として、実行中のアプリケーションに対するブラウザーテストを用意しています。テストパネル(2)で見つけることができるはずです。テストの名前は Workshop Browser Test for のあとにワークショップの名前を続けたものとなります(講師が名前をご連絡いたします)。

ツアーを続けましょう。ワークショップ用の Browser Test の結果を見てみます。

Exercise
  • テストパネルで、ワークショップの名前が含まれている行をクリックします。以下のように表示されるはずです。

Synthetics-overview Synthetics-overview

  • Synthetic Tests ページでは、最後の1日、8日、および30日の間にサイトのパフォーマンスが表示されます。上のスクリーンショットに示されているように、テストがその期間より前に開始されていれば、対応するチャートにデータが表示されます。テストが作成された時点によっては、一部のデータが表示されない場合があります。
  • Performance KPI のドロップダウンで、デフォルトの last 4 hours から last 1 hour に時間を変更してください。

テストはどれくらいの頻度で実行され、どこから実行されていますか?

テストはフランクフルト、ロンドン、およびパリから、1分間隔のラウンドロビンで実行されます

Additional Exercise

テスト結果に基づいて問題調査を行ったり、監視設定を行う方法は、8. Splunk Synthetics で取り組んでいただくことが可能です。

実行したテストの詳細をもうすこし確認してみましょう。

  • 画面下部に、Recent run results という欄があるはずです。Failed になっている最新のテストをクリックしましょう
  • テスト結果の詳細画面が表示されます。

Synthetics-detail Synthetics-detail

  • 画面最上部に赤くエラーが表示されていることを確認しましょう

Synthetics-error Synthetics-error

  • 1秒間隔のスクリーンショットが横並びに表示されています。Every 1s というプルダウンを変えると、スクリーンショットの表示間隔を変更できます
  • また、その右側には、録画再生ウィンドウがあるはずです。再生してみましょう
  • 録画再生ウィンドウの下部には、この処理に関するパフォーマンス情報が表示されます。Web Vitalなどに基づいてパフォーマンスが可視化されています
  • Business Transaction は、テストで確認したい処理をグループ化して定義したものです。また、Pages は、テストの中で開かれた Web ページの URL を示しています
  • それぞれクリックしてみると、それに該当する処理が画面下部に表示されます。どのような処理が順番に実施されたか、処理状況が示されています。
  • APM というリンクが表示されているはずです
    • バックエンドアプリケーションを APM で計装している場合、Synthetic テストと APM のトレースを紐づけることができます

このテストはなぜ Failed と判断されましたか

Place Order 処理の後に “Order Confirmation ID” が表示されるまでに時間がかかり、タイムアウトしてしまった

次に、Splunk Infrastructure Monitoring (IM) を使用してアプリケーションが実行されているインフラストラクチャを調査しましょう。

Last Modified 2024/04/05

Infrastructureの概要

5 minutes

Splunk Infrastructure Monitoring (IM) は、ハイブリッドクラウド環境向けモニタリングおよびオブザビリティサービスとして市場でも高い評価を得ています。Splunk IM は特許取得済みのストリーミングアーキテクチャに基づいて構成されており、従来のソリューションよりも短時間かつ高精度で、インフラストラクチャ、サービス、およびアプリケーションのパフォーマンスを視覚化・分析できるリアルタイムソリューションを提供しています。

OpenTelemetry 標準化: あなたのデータを完全にコントロールすることができます。ベンダーロックインから解放され、独自エージェントの導入が不要になります。

Splunk の OTel Collector: シームレスなインストールとダイナミックな構成が可能で、ほんのわずかな時間ですべてのスタックに対して自動検出を行うことができます。これによりクラウド、サービス、およびシステム全体を横断的に可視化することができます。

300 以上の簡単に使用できる OOTB コンテンツ: Navigator と Dashboard が事前に用意されており、あなたの環境全体をすぐに可視化できます。すべてのデータをリアルタイムに扱うことが可能です。

Kubernetes ナビゲータ: すぐに利用できるプリセットのビューによって、ノード、Pod、およびコンテナの状態を包括的かつ構造的に理解できます。わかりやすく、インタラクティブなクラスターマップによって、初心者でも簡単に Kubernetes を理解できるでしょう。

アラートの自動検出と Detector: メトリクス取得を行いはじめるとすぐに、重要なメトリクスを自動的に判別し、detector(アラート)の条件が生成されます。テレメトリデータが取り込まれた直後から正確なアラートを行うことができ、ほんのわずかな時間で重要なアラート通知をリアルタイムに受け取ることができます。

ダッシュボード内のログ参照: ログメッセージとリアルタイムメトリクスを 1 ページで組み合わせて表示することができます。共通のフィルタ条件や時間制御により、共通のコンテキストに基づいて迅速にトラブルシューティングを行うことができます。

メトリクスパイプラインの管理: データ取り込み時点でメトリクスのボリュームを制御することができます。Instrumentation(計装)を変更することなく、必要なデータのみを保存・分析できるようにデータ集約や破棄を設定できます。メトリクスのボリュームを削減し、オブザービリティに対する支出を最適化することができるはずです。

Infrastructure Overview Infrastructure Overview

Last Modified 2024/04/05

6. Infrastructureの概要のサブセクション

Infrastructure Navigators

Infrastructure をメインメニューでクリックします。Infrastructure ホームページは4つの異なるセクションで構成されています。

Infra main Infra main

  1. オンボーディングパネル: Splunk Infrastructure Monitoring を始める際に参照するトレーニングビデオとドキュメンテーションへのリンク。
  2. 時間とフィルタパネル: 時間ウィンドウ(一覧画面上では設定変更できません)
  3. Integration パネル: Splunk Observability Cloud にメトリクスを送信しているすべてのテクノロジのリスト。
  4. タイルパネル: Integration によって監視されているサービスの合計数(Integration 別に表示)

Infrastructure パネルを使用して、興味のあるインフラストラクチャ/テクノロジーを選択できます。やってみましょう。

Exercise
  • Integration パネルの Containers セクション(3)にある、Kubernetes を調査対象のテクノロジーとして選択します。

  • K8s NodesK8s Workloads の2つのタイルが表示されるはずです。

  • 各タイルの下部には過去の推移を表すグラフがあり、上部には現在発生しているアラートの数が表示されます。これらの追加情報は全てのタイルに表示されており、インフラストラクチャの健全性を概要として確認するのに役立つはずです。

  • K8s Nodes タイルをクリックします。

  • Kubernetes クラスターが1つ以上の表示されます。

  • 次に Add filters ボタンをクリックします。 k8s.cluster.name と入力し、検索結果をクリックします。

  • リストから [WORKSHOPの名前]-k3s-cluster を選択し、Apply Filter ボタンをクリックします。

    cluster cluster

  • Kubernetes Navigator では、健全性を色で示します。ご覧の通り、2つの Pod またはサービスが健全ではなく、Failed 状態にあります(1)。残りは問題なく動いています。これは共用の Kubernetes 環境では一般的に発生することがあるもので、ワークショップではこれを再現しています。

  • サイドにあるタイルに注目してください。Nodes dependencies2)の下に、MySQL と Redis のタイルが表示されています。これらは我々のeコマースアプリケーションで使用されている2つのデータベースです。

Node Dependencies

OpenTelemetry Collector によるモニタリングが構成されている場合、選択したノードで実行されているサービスが UI 上に表示されます。

Exercise
  • Redis タイルをクリックすると、Redis instances ナビゲータに移動します。REDIS INSTANCE の下で redis-[WORKSHOPの名前] をクリックします。
  • これにより、Redis instance に移動します。このナビゲータは、我々のeコマースサイトのアクティブな Redis インスタンスからのメトリクスデータを含むチャートを表示します。 redis redis

このビューでの Instance dependencies タイルの名前を挙げられますか?

はい、Kubernetes に関するタイルです。

  • タイルをクリックすると、Redis サービスを実行する Pod が表示される Pod レベルでの Kubernetes Navigator に移動します。
  • クラスターレベルに戻るには、画面の上部にある Cluster1)のリンクをクリックします。

node node

これで Splunk Observability Cloud のツアーが完了しました。

さて、eコマースサイト「Online Boutique」にアクセスし、仮想のクレジット💶を使ってショッピングをしてみましょう。

Last Modified 2024/04/05

Let's go shopping 💶

5 分
ペルソナ

あなたは都会に暮らす、流行に敏感な人です。有名なオンラインブティックショップで次の新しいアイテムを買いたくてウズウズしています。オンラインブティックは、あらゆる流行の最先端を求める人のニーズを満たす場所であると聞いています。

この演習の目的は、オンラインブティックのウェブアプリケーションとやり取りすることです。これは Splunk Observability Cloud の機能をデモンストレーションするために使用されるサンプルアプリケーションで、アイテムを閲覧し、カートに追加してからチェックアウトすることができるシンプルなeコマースサイトです。

アプリケーションは既に展開されており、インストラクターからオンラインブティックのウェブサイトへのリンクが提供されます。

Exercise - ショッピングを始めましょう
  • オンラインブティックへのリンクが手に入ったら、いくつかのアイテムを見て、カートに追加して、最後にチェックアウトしてみてください。
  • この演習を数回繰り返し、可能であれば異なるブラウザ、モバイルデバイス、またはタブレットを使用してください。これにより、調査のために利用するより多くのデータを生成することができます。
Hint

ページの読み込みを待っている間に、マウスカーソルをページ上で動かしてください。これにより、後でこのワークショップで調査を行うためのさらに多くのデータが生成されます。

Exercise(続き)
  • チェックアウト処理で何か気づきませんか? 完了までに時間がかかったように見えましたが、最終的には完了しましたか? こういったことが発生した場合は、注文確認 ID (Order Confirmation ID) をコピーして、後で使用できるようにローカルに保存してください。
  • ショッピングに使用したブラウザセッションを閉じてください。

ユーザーエクスペリエンスが悪いと感じるかもしれません。これは顧客満足度に影響を与える潜在的な問題なので、これを解決するために手を打ってみましょう。

Online Boutique Online Boutique

では、Splunk RUM でデータがどのように見えるか、確認してみましょう。

Last Modified 2024/04/05

Splunk RUM

15 分
ペルソナ

あなたはフロントエンドエンジニアまたは SRE で、パフォーマンスの問題について最初のトリアージを実行するように指示されています。オンラインブティックアプリケーションに関する潜在的な顧客満足度の問題を調査するように求められています。

私たちは、すべての参加者のブラウザセッションから受信したテレメトリによって提供された実際のユーザーデータを調査します。目標は、パフォーマンスが低い可能性のあるブラウザ、モバイル、またはタブレットセッションを見つけ、トラブルシューティングプロセスを開始することです。

Last Modified 2024/02/05

5. Splunk RUMのサブセクション

1. RUM ダッシュボード

Splunk Observability Cloud のメインメニューから RUM をクリックします。RUM ホームページに移動しますが、このビューは以前の短い紹介で既に見たことがあるでしょう。

multiple apps multiple apps

Exercise
  • あなたのワークショップ環境が選択されていることを確かめるために、次のようにドロップダウンが設定/選択されていることを確認してください。
    • 時間枠-15m に設定されています。
    • Environment[NAME OF WORKSHOP]-workshop が選択されています。
    • App[NAME OF WORKSHOP]-store が選択されています。
    • SourceAll に設定されています。
  • 次に、Page Views / JavaScript Errors チャートの上にある [NAME OF WORKSHOP]-store をクリックします。
  • これにより、新しいダッシュボードビューが表示され、メトリクスが UX MetricsFront-end HealthBack-end HealthCustom Events に分解され、それらを過去のメトリクスと比較します(デフォルトでは1時間)。

RUM Dashboard RUM Dashboard

  • UX Metrics: ページビュー、ページ読み込み、Web Vitals メトリクス。
  • Front-end Health: Javascript エラーおよび Long Task の期間と回数の分解。
  • Back-end Health: ネットワークエラーおよびリクエスト、Time to First Byte。
  • Custom Events: カスタムイベントの RED メトリクス(Rate、Error&Duration)。
Exercise
  • 各タブ(UX MetricsFront-end HealthBack-end HealthCustom Events)をクリックしてデータを調査してください。

Custom Events タブのチャートを調査した場合、処理時間の急激な増加を分かりやすく示しているチャートはどれですか?

Custom Event Latency チャートです。

Last Modified 2024/04/05

2. Tag Spotlight

Exercise
  • Custom Events タブが選択されていることを確認してください。

  • Custom Event Latency チャートを見てください。ここで表示されるメトリクスは、アプリケーションのレイテンシを示しています。横に表示されている比較メトリクスは、1時間前と比較したレイテンシを示しています(これは上部のフィルターバーで選択されています)。

  • チャートタイトルの下にある see all リンクをクリックします。

RUM Tag Spotlight RUM Tag Spotlight

このダッシュボードビューでは、RUM データに関連付けられたすべてのタグが表示されます。タグは、データを識別するために使用されるキーと値のペアです。この場合、タグは OpenTelemetry の計装によって自動的に生成されます。これらのタグはデータをフィルタリングし、チャートやテーブルを作成するために使用されます。Tag Spotlight ビューを使用することで、ユーザーセッションに関するドリルダウンができます。

Exercise
  • タイムフレームを Last 1 hour に変更します。
  • Add Filters をクリックし、OS Version を選択し、!= をクリックして Synthetics および RUMLoadGen を選択し、Apply Filter ボタンをクリックします。
  • Custom Event Name チャートを見つけ、リストで PlaceOrder を見つけてクリックし、Add to filter を選択します。
  • グラフ上の大きなスパイクに注意してください。
  • User Sessions タブをクリックします。
  • 表の上で Duration 見出しを2回クリックして、セッションを持続時間の降順でソートします。
  • テーブルの上にあるをクリックし、Sf Geo City を追加の列のリストから選択して、Save をクリックします。

これで、最長の処理時間から降順に並べられ、サイトで買い物をしているすべてのユーザーの都市を含むユーザーセッションテーブルができました。さらにデータを絞り込むために、OSバージョン、ブラウザバージョンなどを適用できます。

RUM Tag Spotlight RUM Tag Spotlight

Last Modified 2024/02/16

3. Session Replay

セッション

セッションとはトレースの集合で、あるユーザーがアプリケーションを操作するときに実行されるアクションに対応しています。 デフォルトでは、セッションは、セッション内でキャプチャされた最後のイベントから 15 分が経過するまで継続します。 セッションの最大継続時間は 4 時間です。

Exercise
  • User Sessions テーブルで、最長の Duration(20秒以上)を持つトップの Session ID をクリックします。これにより、RUM セッションビューに移動します。

RUM Session RUM Session

Exercise
  • RUM セッションリプレイ Replay ボタンをクリックします。RUM セッションリプレイを使用すると、ユーザーセッションを再生して表示できます。これはユーザーが実際にどのような体験をしたかを正確に確認できる素晴らしい方法です。
  • リプレイを開始するために再生ボタンをクリックします。

RUM Session RUM Session

RUM セッションリプレイでは、デフォルトでテキストがマスキングされますが、画像もマスキングできます(このワークショップの例ではマスキングされています)。これは、セッションに機密情報が含まれている場合に役立ちます。再生速度を変更したり、リプレイを一時停止したりすることもできます。

Tip

セッションを再生する際に、マウスの動きがどのようにキャプチャされるかに注目してください。これは、ユーザーがどこに注意を集中しているかを確認するのに役立ちます。

Last Modified 2024/04/05

4. User Sessions

Exercise
  • RUM Session Replay 右上の X をクリックして閉じます。前回の演習で PlaceOrder にフィルターを設定していました。この演習でも選択されているはずです。以下のスクリーンショット(1)に示されています。
  • スパンの長さに注意してください。これは注文を完了するのにかかった時間です。良くありません!
  • ページを下にスクロールすると、Tags メタデータ(Tag Spotlight で使用される)が表示されます。タグの後には、読み込まれたページオブジェクトが表示されます(HTML、CSS、画像、JavaScriptなど)。
  • ページを下にスクロールして、青い APM リンク(URLの末尾に /cart/checkout が含まれているもの)にカーソルを合わせます。

RUM Session RUM Session

これにより、APM パフォーマンスサマリーが表示されます。これはトラブルシューティング時に非常に役立つ End to End(RUM から APM への)ビューです。

Exercise
  • paymentservice2)と checkoutservice3)がエラー状態であることがスクリーンショットで確認できます。
  • Workflow Name の下にある front-end:/cart/checkout をクリックすると、APM Service Map が表示されます。

RUM to APM RUM to APM

Last Modified 2024/02/16

Splunk APM

20 minutes
ペルソナ

あなたはバックエンドの開発者で、SRE によって発見された問題の調査を支援するように呼ばれました。SRE はユーザーエクスペリエンスが悪いと特定し、その問題の調査をお願いしています。

RUM トレース(フロントエンド)から APM トレース(バックエンド)にジャンプすることで、完全な End to End の可視性の力を理解できるでしょう。すべてのサービスが Splunk Observability Cloud によって視覚化、分析、異常およびエラーの検出が可能となるテレメトリ(トレースやスパン)を送信しています。

RUM と APM は同じコインの両側面です。RUM はアプリケーションのクライアント側のビューであり、APM はサーバー側のビューです。このセクションでは、APM を使用してどこに問題が潜んでいるかドリルダウンし、特定します。

Last Modified 2024/04/05

6. Splunk APMのサブセクション

1. APM Explore

APM サービスマップは、APM で計装されたサービス、および、存在が推測されるサービス間の依存関係とつながりを表示します。このマップは、時間範囲、環境、ワークフロー、サービス、およびタグのフィルタで選択した内容に基づいて動的に生成されます。

RUM ウォーターフォールで APM リンクをクリックすると、サービスマップビューに自動的にフィルタが追加され、その Workflow Namefrontend:/cart/checkout)に関与したサービスが表示されます。

Service Map でワークフローに関係するサービスが表示されます。画面右側の Business Workflow の下には、選択したワークフローのチャートが表示されます。Service MapBusiness Workflow のチャートは同期されています。Service Map 内であるサービスを選択すると、Business Workflow ペインのチャートが更新され、選択したサービスのメトリクスが表示されます。

APM Business Workflow APM Business Workflow

Exercise
  • paymentservice を Service Map でクリックしてください。

APM Explore APM Explore

Splunk APM は、発生している問題をリアルタイムに確認し、特定のサービス、特定のエンドポイント、またはこれらを支えるインフラストラクチャに関連しているかどうかを迅速に判断するために利用できる、メトリクスをチャートとして可視化する一連の組み込みダッシュボードを提供しています。これを詳しく見てみましょう。

Exercise
  • paymentservice パネルの右上にある View Dashboard をクリックしてください。
Last Modified 2024/02/05

2. APM Service Dashboard

Service Dashboard

APM サービスダッシュボードは、サービス、エンドポイント、および Business Workflow のエンドポイントスパンから生成されたモニタリングメトリクセットに基づいて、リクエスト、エラー、および所要時間(RED)メトリクスを提供します。ダッシュボードを下にスクロールすると、基盤や Kubernetes に関連するメトリクスも表示され、インフラストラクチャに問題があるかどうかを判断するのに役立ちます。

Service Dashboard Service Dashboard

Exercise
  • Time の枠 (1) を確認してください。ダッシュボードには、選択したアプリケーションの APM トレースによって取得された、処理にかかった時間に関するデータのみが表示されています(チャートは静的です)。
  • Time の枠に -1h と入力し、Enter キーを押します。
  • Request rateRequest latency (p90)Error rate の Single Value チャートは 10 秒ごとに更新されており、引き続き多くのエラーが発生していることを示しています。
  • これらのチャートはパフォーマンスの問題を迅速に特定するのに非常に役立ちます。このダッシュボードを使用してサービスのヘルスステータスを監視したり、ダッシュボードを作成・構成する際のベースとして利用することができます。
  • これらのチャートをいくつか、後の演習で使用したいと思います。
    • Request rate Single Value チャート(2)で をクリックし、Copy を選択します。これにより、ページの右上(3)の部分に 1 が表示され、クリップボードにコピーされたチャートがあることを示しています。
    • Request rate の折れ線グラフ(4)では、Add to clipboard アイコンをクリックしてクリップボードに追加するか、 を使用して Add to clipboard を選択します。
  • ページの右上(3)の部分に2が表示されていることを確認してください。
  • それでは、エクスプロービューに戻りましょう。ブラウザの “戻る” ボタンをクリックしてください。

APM Explore APM Explore

Exercise

サービスマップで paymentservice の上にカーソルを合わせてください。ポップアップして表示されたサービスに関するチャートからどんなことがわかりますか?

エラー率が非常に高いです。

APM Service Chart APM Service Chart

このエラー率にパターンがあるかどうかを理解する必要があります。そのためには、Tag Spotlight が便利です。

Last Modified 2024/04/05

3. APM Tag Spotlight

Exercise
  • paymentservice のタグを表示するには、paymentservice をクリックし、右側のメニューパネルで Tag Spotlight をクリックします(画面解像度によってはスクロールが必要な場合があります)。
  • Tag Spotlight に移動したら、Show tags with no values のトグルスイッチがオフになっていることを確認してください。

APM Tag Spotlight APM Tag Spotlight

Tag Spotlight には、2つの表示モードがあります。デフォルトは Request/Errors で、もう1つは Latency です。

Request/Error チャートでは、リクエストの合計数、エラーの合計数、および根本原因のエラーが表示されます。Latency チャートでは、p50、p90、および p99 のレイテンシが表示されます。これらの値は、Splunk APM がインデックス化された各スパンタグに対して生成する Troubleshooting MetricSets(TMS)に基づいています。これらは RED メトリクス(リクエスト、エラー、および所要時間)として知られています。

Exercise

どのチャートが問題を特定するタグでしょうか?

version チャートです。v350.10 に対するリクエストの数はエラーの数と一致しています。

  • これで、問題を引き起こしている paymentservice のバージョンを特定したので、エラーに関する詳細情報を見つけることができるかどうかを確認してみましょう。ページの上部にある ← Tag Spotlight をクリックして Service Map に戻ります。
Last Modified 2024/04/05

4. APM Service Breakdown

Exercise
  • 右側のペインで Breakdown をクリックします。
  • リストから tenant.level を選択します。これは顧客のステータスを表すタグであり、顧客のステータスに関連するトレンドを見るのに役立ちます。
  • Service Map で gold をクリックして選択します。
  • さらに Breakdown をクリックし、version を選択します。これはサービスのバージョンを示すタグです。
  • silverbronze についても同様の手順を繰り返します。

確認できた内容から、どんな結論を得ることができますか?

すべてのテナントがバージョン v350.10 による影響を受けている

paymentservicegoldsilverbronze の3つのサービスに分けて表示されていることが分かるでしょう。各テナントはバージョン (v350.10v350.9) ごとのサービスに分けられています。

APM サービスのBreakdown APM サービスのBreakdown

Exercise
  • 3つの赤い円を囲む外側のメインボックスをクリックします。ボックスがハイライト表示されます。
スパンのタグ

スパンに付与されるタグに基づいてサービスの分析は非常に強力な機能です。これにより、異なる顧客、異なるバージョン、異なる地域などに対するサービスのパフォーマンスを確認できます。この演習では、paymentservicev350.10 がすべての顧客に問題を引き起こしていることが判明しました。

次に、トレースを詳細に調査して問題の原因を見つける必要があります。

Last Modified 2024/04/05

5. APM Trace Analyzer

Splunk APM では、NoSample™ の End to End の可視性が提供され、すべてのサービスのトレースがキャプチャされます。このワークショップでは、Order Confirmation ID がタグとして利用可能です。これにより、ワークショップの前半で遭遇したユーザーエクスペリエンスの問題のトレースを正確に検索できます。

Trace Analyzer

Splunk Observability Cloud は、アプリケーションモニタリングデータを探索するための複数のツールを提供しています。Trace Analyzer は、未知の問題や新しい問題を調査するために高カーディナリティで粒度の細かなデータを検索・探索するシナリオに適しています。

Exercise
  • paymentservice の外側のボックスを選択した状態で、右側のペインで Traces をクリックします。
  • Trace Analyzer を使用していることを確認するために、Switch to Classic View が表示されていることを確認します。表示されていない場合は、Switch to Trace Analyzer をクリックします。

APM Trace Analyzer APM Trace Analyzer

Exercise
  • 表示する時間枠として Last 1 hour を選択します。
  • ほとんどのトレースがエラー(赤)であり、エラーのない(青の)トレースは限られています。
  • Sample Ratio1:10 ではなく 1:1 に設定されていることを確認します。
  • Add filters をクリックし、orderId を入力し、リストから orderId を選択します。
  • ワークショップの前半でショッピングを行った際の Order Confirmation ID を貼り付けて Enter キーを押します。入力する ID が分からない場合は、インストラクターにお問い合わせください。 Traces by Duration Traces by Duration

これで、あなたが体験した、チェックアウト処理で長時間待たされユーザーエクスペリエンスを損ねていた処理のトレースを絞り込むことができました。このトレースは最大13ヶ月間アクセスすることができます。そのため、例えば、開発者は後日この問題に再び取り組む際にも、このトレースを確認できるでしょう。

Exercise
  • リスト内のトレースをクリックします。

次に、トレースのウォーターフォールを見ていきましょう。

Last Modified 2024/02/15

6. APM Waterfall

Trace Analyzer から Trace Waterfall に移動しました。トレースは、同じトレース ID を共有するスパンの集合であり、アプリケーションとその構成サービスによって処理される一意のトランザクションを表します。

Splunk APM の各スパンは、単一の操作をキャプチャします。Splunk APM は、スパンに記録された操作がエラーとなった場合、スパンをエラースパンと見なします。

Trace Waterfall Trace Waterfall

Exercise
  • ウォーターフォール内の paymentservice:grpc.hipstershop.PaymentService/Charge スパンの隣にある ! をクリックします。

スパンのメタデータに記録されているエラーメッセージとバージョンは何ですか?

Invalid Requestv350.10 です。

問題を引き起こしている paymentservice のバージョンを既に特定しているので、エラーに関してより詳細な情報を見つけられるか、やってみましょう。ここで Related logs が役立ちます。

Related Logs Related Logs

関連するコンテンツは、特定のメタデータによって実現されており、これにより、APM, Infrastructure Monitoring, Log Observer が Splunk Observability Cloud 内でフィルター条件を共有することで可能になっています。Related Logs が機能するには、ログに次のメタデータが必要です。

  • service.name
  • deployment.environment
  • host.name
  • trace_id
  • span_id
Exercise
  • Trace Waterfall の一番下で Logs (1) と書かれた部分をクリックします。これにより、このトレースに紐づく Related Logs があることが分かります。
  • ポップアップ内の Logs for trace XXX エントリをクリックすると、トレース全体と関係のあるログが Log Observer で表示されます。
Last Modified 2024/04/05

Splunk Log Observer

20 分
ペルソナ

引き続き バックエンド開発者 の役割で、アプリケーションのログを調査して問題の原因を特定する必要があります。

APM トレースに関連するコンテンツ(ログ)を使用して、Splunk Log Observer を使用して問題を正確に理解するために、深掘りをしていきます。

Related Content は、1つのコンポーネントから別のコンポーネントにジャンプするための強力な機能で、メトリクストレース、および ログ に対して利用できます。

Last Modified 2024/02/15

7. Splunk Log Observerのサブセクション

1. Log Filtering

Log Observer (LO) は複数の方法で使用できます。クイックツアーでは、LO ノーコードインターフェース を使用してログの特定のエントリを検索しました。ただし、このセクションでは、APM のトレースから LO に移動したと想定しています。

RUM と APM の間のリンクと同じように、前のアクションのコンテキストを引き継いでログを調査することができるのは一つの利点です。今回の場合、時間枠(1)を見てみると、これはトレースが取得された時間帯と一致しています。また、Filter(2)にも、trace_id の情報が既に設定されています。

Trace Logs Trace Logs

このビューには、オンラインブティックでエンドユーザーが実施した操作によって実行されたバックエンドのトランザクションに関わる すべての アプリケーションまたはサービスの すべての ログ行が含まれます。

オンラインブティックのような小さなアプリケーションでも、膨大な量のログが検出され、調査対象となる実際のインシデントに関わる特定のログを見つけ出すのが難しくなる場合があります。

Exercise

ログに含まれるエラーメッセージだけにフォーカスする必要があります。

  • Group By ドロップダウンボックスをクリックして、Severity を検索します。
  • 選択したら、Apply ボタンをクリックします(チャートの凡例が、debug、error、info に変化します)。 legend legend
  • エラーログだけを選択するには、凡例の中の error(1)をクリックして、Add to filter を選択します。
  • 複数のサービスに対するエラーログがある場合は、フィルタにサービス名 sf_service=paymentservice を追加することもできます。今回の場合は不要です。 Error Logs Error Logs

次に、詳細なログエントリを見ていきましょう。

Last Modified 2024/04/05

2. ログエントリの参照

特定のログ行を見る前に、これまでに何を行ってきたかと、オブザーバビリティの3本柱に基づいて、なぜここに辿り着いたのかを簡単に振り返りましょう。

MetricsTracesLogs
問題があるか?問題はどこにあるか?問題は何か?
  • メトリクスを使用して、アプリケーションに問題があることが判明しました。これは、サービスダッシュボードのエラーレートが本来の状態よりも高かったことから明らかです。
  • トレースとスパンタグを使用して、問題がどこにあるかを見つけました。 paymentservicev350.9v350.10 の2つのバージョンで構成されており、 v350.10 に対するエラーレートは 100% でした。
  • バージョン v350.10paymentservice から生成されるエラーがオンラインブティックのチェックアウト処理の応答において、複数回の再試行と長時間の遅延を引き起こしていたことを確認しました。
  • トレースから Related Content の強力な機能を使用して、失敗した paymentservice バージョンのログエントリに到達しました。これにより、問題が 何であるか を特定できるようになりました。
Exercise
  • Logs tables のエラーエントリをクリックします(異なるサービスからのまれなエラーがある場合は、エントリに hostname: "paymentservice-xxxx" と表示されていることを確認してください)。

メッセージを踏まえ、問題を解決するためには開発チームに何を伝える必要がありますか?

開発チームは、有効なAPIトークンを使用してコンテナを再構築およびデプロイするか、 v350.9 にロールバックする必要があります。

Log Message Log Message

  • ログメッセージペインの X をクリックして閉じます。
おめでとうございます

Splunk Observability Cloud を使用することで、オンラインブティックでのショッピング中にユーザーエクスペリエンスが悪かった原因を理解することができました。オブザーバビリティの3本柱である メトリクストレースログ に基づいて、RUM、APM、およびログを利用することで、サービス全体で何が起こっており、その後、その根底にある原因を見つけることができました。

また、Splunkが提供する、アプリケーションの振る舞いのパターンを検出する Tag Spotlight によるインテリジェントなタグ付けと分析の機能や、問題のコンテキストを維持しながら異なるコンポーネント間を素早く移動する Related Contents によりスタック全体を相関させる機能についても、その使い方を理解したはずです。

ワークショップの次のパートでは、問題の特定から緩和予防、およびプロセスの改善に進んでいきます。

次に、カスタムダッシュボードでログチャートを作成します。

Last Modified 2024/04/05

3. Log Timeline Chart

Log Observer である固定のビューを持っておくと、ダッシュボードの中でそのビューを活用し、将来的に問題の検出と解決にかかる時間を削減することができるでしょう。ワークショップの一環として、これらのチャートを使用するカスタムダッシュボードの例を作成します。

まず、Log Timeline チャートの作成を見てみましょう。Log Timeline チャートは、時間の経過とともにログメッセージを表示するために使用されます。これはログメッセージの頻度を確認し、パターンを識別するのに適した表現方法です。また、環境全体でのログメッセージの出力傾向を確認するのにも適しています。これらのチャートはカスタムダッシュボードに保存できます。

Exercise

まず、表示するログの列を必要なものに絞り込みます。

  • Logs table 上の Configure Table アイコンをクリックして Table Settings を開きます。 _raw のチェックを外し、k8s.pod_name, message, version のフィールドが選択されていることを確認します。 Log Table Settings Log Table Settings
  • 固定の時間が入っている時間枠の設定を外し、 Last 15 minutes を設定します。
  • すべてのトレースに対してログ参照ができるように、フィルタ設定から trace_id を削除し、 sf_service=paymentservice および sf_environment=[WORKSHOPNAME] フィールドを追加します。
  • Save をクリックし、Save to Dashboard を選択します。 save it save it
  • チャート作成に関するダイアログが表示されます。Chart nameLog Timeline を入力します。
  • 次に、Select Dashboard をクリックします。ダッシュボード選択のダイアログでは New dashboard をクリックします。
  • New dashboard ダイアログで、新しいダッシュボードの名前を入力します(Description 欄は入力不要です)。名前には以下を使用します: <受講者のイニシャル> - Service Health Dashboard と入力し、 Save をクリックします。
  • 新しいダッシュボードがリストでハイライト表示されていることを確認し(1)、 OK をクリックします(2)。 Save dashboard Save dashboard
  • Chart Type として Log Timeline が選択されていることを確認します。 log timeline log timeline
  • 最後に Save ボタンをクリックします(この時点で Save and goto dashboard をクリックしないでください)。

次に、Log View チャートを作成します。

Last Modified 2024/04/05

4. Log View Chart

次に、ログに関するチャートタイプである Log View チャートタイプを見ていきます。このチャートを使用すると、事前に定義しておいたフィルタに基づいてログメッセージを表示できます。

前の Log Timeline チャートと同様に、Log View のチャートを Customer Health Service Dashboard に追加します。

Exercise
  • 前の演習完了後、Log Observer 画面が表示されていることを確認してください。
  • フィルタ設定は前の演習と同じです。表示する時間枠を Last 15 minutes に設定し、severity=errorsf_service=paymentservice および sf_environment=[WORKSHOPNAME] でフィルタリングしているはずです。
  • Log Views のヘッダーについても、前の演習で設定したフィールドのみが選択されていることを確認してください。
  • 再び Save をクリックしてから Save to Dashboard をクリックします。
  • これにより、改めて、チャート作成ダイアログが提供されます。
  • Chart nameLog View を入力します。
  • 今回は Select Dashboard をクリックし、前回の演習で作成したダッシュボードを検索します。検索ボックスにご自身のイニシャルを入力することで見つけることができるでしょう。(1)。 search dashboard search dashboard
  • ダッシュボード名をクリックしてハイライト表示し(2)、 OK をクリックします(3)。
  • これで、チャート作成ダイアログに戻ります。
  • Chart Type として Log View が選択されていることを確認してください。 log view log view
  • 次に、Save and go to dashboard をクリックしてダッシュボードを表示します。
  • 結果的に、以下のようなダッシュボードが表示されるはずです。 Custom Dashboard Custom Dashboard
  • この演習の最後のステップとして、ダッシュボードをワークショップのチームページに追加しましょう。ワークショップ中に後からダッシュボードを探すのが簡単になるはずです。
  • ページの上部で、ダッシュボード名の左にある をクリックします(1)。 linking linking
  • ドロップダウンから Link to teams を選択します(2)。
  • 次に表示される Link to teams ダイアログで、インストラクターが提供したワークショップのチームを見つけ、 Done をクリックします。

次のセッションでは、Splunk Synthetics を見て、Web ベースのアプリケーションのテストを自動化する方法を見ていきます。

Last Modified 2024/02/15

Splunk Synthetics

15分
ペルソナ

あなたは SRE の帽子をかぶり、Online Boutique のモニタリングを設定するように求められました。アプリケーションが24時間365日利用可能で、パフォーマンスが良好であることを確認する必要があります。

アプリケーションのモニタリングを24時間365日行い、問題が発生したときにアラートを受け取ることができたら素晴らしいですよね?それが Synthetics の役割です。ここでは、Online Boutique での典型的なユーザージャーニーが問題なく、良好なパフォーマンスで利用できることを確認する、1分おきに実行されるシンプルなテストをご紹介します。

Last Modified 2024/02/15

8. Splunk Syntheticsのサブセクション

1. Synthetics Dashboard

Splunk Observability Cloud のメインメニューから Synthetics をクリックします。All または Browser tests をクリックして、アクティブなテストの一覧を表示します。

RUM セクションでの調査中、Place Order トランザクションに問題があることを見つけました。Synthetics テストでもこれを確認できるかどうか見てみましょう。テストの4番目のページ、つまり Place Order ステップのメトリック First byte time を使用します。

Exercise
  • Search ボックスに [WORKSHOP NAME] を入力し、ワークショップに対応するテストを選択します(インストラクターから指示します)。
  • Performance KPIs の下部にある時間枠を -30m に設定し、Enter キーを押します。
  • Location と表示されている箇所をクリックし、ドロップダウンから Page を選択します。隣の Filter 欄にはテストに含まれるページが表示されます。
  • Duration と表示されている箇所をクリックして Duration の選択を解除し、First byte time を選択します。 Transaction Filter Transaction Filter
  • 凡例を確認し、First byte time - Page 4 の色に着目しましょう。
  • First byte time - Page 4 の値が最も大きくなるデータポイントを選択します。
  • 右から新しいペインが表示されます。ペインの上部にある所要時間を確認してください。リスト内でこの所要時間が表示されている行を見つけ、クリックします。最も時間がかかったテスト結果を見つけられました。 Multiple Runs Multiple Runs

この特定のテスト実行に関して、Run results に移動して見てみましょう。

Last Modified 2024/02/15

2. Synthetics Test Detail

現在、ある1つの Synthetic Browser Test の結果を見ています。このテストは Business Transactions として分けられています。これは、1つまたは複数の論理的に関連する操作の集合であり、ビジネスクリティカルなユーザーフローを表すものと考えてください。

Info

以下のスクリーンショットにはエラーが含まれていませんが、みなさんのテスト結果にはエラーが含まれている場合があります。テスト実行は時折失敗する場合があるため、これは想定通りの挙動であり、ワークショップにも影響ありません。

waterfall waterfall

  1. Filmstrip: サイトのパフォーマンスを一連のスクリーンショットで表示し、ページのリアルタイムな応答を確認できます。
  2. Video: テスト実行元デバイスや地理的な場所からテスト対象のサイトを読み込むユーザーがどのような体験をするかを確認できます。
  3. Browser test metrics: ウェブサイトのパフォーマンスの概要を確認することができます。
  4. Synthetic transactions: ユーザーとサイト間での通信や操作からなる Synthetic トランザクションをリスト表示しています。
  5. Waterfall chart: テスト実行元とテスト対象サイト間での通信や操作に関する一連の様子を視覚的に表現しています。

デフォルトでは、Splunk Syntheticsはテストのスクリーンショットとビデオのキャプチャを提供します。これは問題のデバッグに役立ちます。たとえば、大きな画像の遅い読み込み、ページの遅い描画などが確認できます。

Exercise
  • マウスを使ってフィルムストリップを左右にスクロールし、テスト実行中、どのようにサイトが表示されていたかを確認します。
  • ビデオペインでは、再生ボタン を押して録画を再生できます。再生画面右下の をクリックすると、再生速度を変更したり、Picture in Picture で表示したり、ビデオを Download したりできます。
  • Synthetic Transaction ペインで、Business Transactions のヘッダーの下に表示されている最初のボタン Home をクリックします。
  • 以下のウォーターフォールでは、ページを構成するオブジェクトがすべて表示されます。最初の行は HTML ページそのものです。次の行はページを構成するオブジェクト(HTML、CSS、JavaScript、画像、フォントなど)です。
  • ウォーターフォールで GET splunk-otel-web.js の行を見つけます。
  • > ボタンをクリックして、メタデータセクションを開き、リクエスト/レスポンスヘッダー情報を確認します。
  • Synthetic Transaction ペインで、2番目の Business Transaction Shop をクリックします。フィルムストリップが調整され、新しいトランザクションの先頭に移動します。
  • 他のトランザクションについても同様に繰り返し、最後に PlaceOrder トランザクションを選択します。
Last Modified 2024/02/15

3. Synthetics to APM

さきほどの演習を通じて、以下のような画面が表示されているはずです。

Place Order Place Order

Exercise
  • ウォーターフォールの中から POST checkout で始まるエントリを見つけます。
  • その前にある > ボタンをクリックして、メタデータセクションを展開します。収集されているメタデータを観察してみてください。また、Server-Timing ヘッダーに着目してみましょう。このヘッダーにより、テスト実行の情報とバックエンドのトレースを関連付けることができます。
  • ウォーターフォールの中の POST checkout 行の前にある青い APM リンクをクリックします。

APM trace APM trace

Exercise
  • paymentservice に1つ以上のエラーが表示されることを確認してください(1)。
  • 同じエラーであることを確認するには、Logs の Related Contents をクリックします(2)。
  • 以前の演習と同様に、エラーのみに絞り込むための手順を繰り返します。
  • エラーログを表示して、無効なトークンによって支払い処理が失敗したことを検証しましょう。
Last Modified 2024/02/15

4. Synthetics Detector

これらのテストは24時間365日実行できます。そのため、テストが失敗したり所定のSLAよりも処理時間がかかるようになりつつある場合に早期に警告を受けることができる理想的なツールです。ソーシャルメディアやウェブサイトの稼働チェックサイトなどから状態を通知されるような事態を防ぐことができます。

Social media Social media

それでは、テストが1.1分以上かかる場合にエラーを検出しましょう。

Exercise
  • 左のメニューから Synthetics のホームページに戻ります。

  • ワークショップのテストをもう一度選択し、ページの上部の Create Detector ボタンをクリックします。 synth detector synth detector

  • New Synthetics Detector (1) と表示されているテキストを編集し、<受講者のイニシャル> - [WORKSHOPNAME] に置き換えます。

  • 次に、Run durationStatic threshold が選択されていることを確認します。

  • Trigger threshold2)を 65,000 から 68,000 程度に設定し、Enter キーを押してグラフを更新します。上記のように、しきい値を超えるスパイクが複数あることを確認してください(実際の処理時間に合わせてしきい値を調整する必要があるかもしれません)。

  • それ以外はデフォルトのままにします。

  • これで、スパイクの下に赤と白の三角形の列が表示されるようになります(3)。赤い三角形は、テストが指定されたしきい値を超過したことを示し、白い三角形は指定されたしきい値以下に戻ったことを示します。赤い三角形ごとにアラートがトリガーされます。

  • アラートの重大度(4)やアラートの方法を変更できます。 アラート受信者は追加しないでください。大量のアラート通知にさらされる可能性があります!

  • Detector を有効化するために、Activate をクリックします。

  • 作成した Detector を表示するには、Edit Test ボタンをクリックします。

  • ページの一番下にアクティブな Detector のリストがあります。

    list of detectors list of detectors

  • 自分のものが見つからない場合は、New Synthetic Detector という名前のものが表示され、名前が正しく保存されていない可能性があります。New Synthetic Detector リンクをクリックして、名前を再度変更してください。

  • 編集モードを終了するには Close ボタンをクリックします。

Last Modified 2024/04/05

カスタム サービスヘルスダッシュボード 🏥

15 分
ペルソナ

SRE の役割はあなたにぴったりです。そのため paymentservice 用のカスタムサービスヘルスダッシュボードを作り上げてほしいと求められています。要件は、RED メトリクス、ログ、および Synthetic テストの所要時間の結果を表示することです。

一般的に、開発チームやSREチームがアプリケーションやサービスのヘルスステータスの概要を必要とします。壁掛けのテレビ画面にこういった情報を常時表示しておくこともよくあります。Splunk Observability Cloud は、カスタムダッシュボードを作成することで、こういった要望に完璧に応えることができます。

このセクションでは、チームのモニターやテレビに表示するため、サービスヘルスダッシュボードを構築します。

Last Modified 2024/04/05

9. Service Health Dashboardのサブセクション

ダッシュボードの拡張

すでに Log Observer の演習でダッシュボードに便利なログチャートを保存していますので、そのダッシュボードを拡張します。

Wall mounted Wall mounted

Exercise
  • 2つのログチャートが含まれたダッシュボードに戻るために、メインメニューから Dashboards をクリックし、Team Dashboard ビューに移動します。Dashboards の下にある Search dashboards をクリックして、Service Health Dashboard グループを検索します。
  • 名前をクリックすると、以前に保存したダッシュボードが表示されます。 log list log list
  • ログ情報は役に立ちますが、これが何かをチームメンバーが理解できるようにするには、もう少し情報が必要です。
  • まず最初のステップとして、ダッシュボードに説明チャートを追加してみましょう。New text note をクリックし、ノートのテキストを次のテキストに置き換えます。その後 Save and close ボタンをクリックし、チャートに Instructions という名前を付けます。
Text note に使用する情報

これは Payment service 用のカスタムヘルスダッシュボードです。
ログに含まれるエラーに注意してください。
詳細については、リンクを参照してください。

  • チャートの順序があまりよくないので、役立つように順序を入れ替えてみましょう。
  • マウスを Instructions チャートの上端に移動させると、マウスポインタが に変わります。あなたはダッシュボード内でチャートをドラッグして移動することができます。Instructions チャートを左上の場所に移動させましょう。さらに、チャートの右端をドラッグしてページの 1/3 にサイズを変更しましょう。
  • Log Timeline view チャートを Instruction チャートの横にドラッグして移動させ、ページの残りの 2/3 を埋めるようにサイズを変更します。
  • 次に、Log lines チャートをページの幅にリサイズし、少なくとも2倍の長さにリサイズします。
  • 以下のダッシュボードのようになったはずです。 Initial Dashboard Initial Dashboard

見栄えが良くなりました。さらに続けて、役立ちそうなチャートを追加していきましょう。

Last Modified 2024/04/05

コピーしたチャートの追加

このセクションでは、コピー&ペーストの機能を使用してダッシュボードを拡張します。以前、APMサービスダッシュボードのセクションでチャートをコピーしました。これらのチャートをカスタムダッシュボードに追加します。

Exercise
  • ページの上部にある 2+ を選択し、Paste charts を選択します。カスタムダッシュボードにチャートを作成することができます。
  • チャートは現在、すべての Environments および Services のデータを表示しています。したがって、環境名と paymentservice にフィルタする設定を追加しましょう。
  • Request Rate の単一の値が表示されているチャートの右上にある (3つのドット)をクリックします。すると、このチャートが編集モードで開かれます。
  • 新しい画面で、画面の中央にあるsf_environment:* x ボタン(1)の x をクリックして閉じます。
  • 次に、+をクリックして新しいフィルタを追加します。sf_environment を選択して、ドロップダウンから [WORKSHOPNAME] を選択して Apply をクリックします。ボタンは sf_environment:[WORKSHOPNAME] に変わります。
  • 同様の操作を sf_service ボタン(2)に対して行います。 一度今の設定を削除して、sf_service に関するフィルタ設定を作成します。フィルタの対象として、paymentservice を指定します。 edit chart edit chart
  • 設定が完了したら、Save and close ボタン(3)をクリックします。
  • Request Rate の数値を表示しているチャートについても、前述の4つの手順を繰り返します。
  • 2つのチャートを更新したら、Save をクリックします。
  • 新しく貼り付けられたチャートはダッシュボードの一番下に表示されたため、再びダッシュボードを並べ替える必要があります。
  • 既に学んだドラッグアンドドロップおよびサイズ変更を行い、ダッシュボードを以下の画像のように整えます。 New dashboard look New dashboard look

次に、実行中の Synthetic テストに基づいたカスタムチャートを作成します。

Last Modified 2024/04/05

カスタムチャートの追加

ワークショップのこのセクションでは、ダッシュボードに追加するチャートを作成し、以前に構築した Detector と紐づけします。これにより、テスト時の振る舞いを確認し、テストによって SLA 違反が発生した場合にアラートを受け取ることができます。

Exercise
  • ダッシュボードの上部で + をクリックし、Chart を選択します。 new chart screen new chart screen
  • まず、Untitled chart の入力フィールドを使用して、チャートの名前を Overall Test Duration にします。
  • このエクササイズでは、棒グラフまたはカラムグラフを使いたいので、チャートオプションの3番目のアイコン をクリックします。
  • Plot editor で、Signal の入力欄に synthetics.run.duration.time.ms(これはテストの実行の所要時間を表します)を入力し Enter キーを押します。
  • 現時点では、異なる色の棒が表示されます。これはテスト実行元の地域ごとに色分けされたものです。ですが、これは不要なので、いくつかの解析ルールを追加してこの表示を変更できます。
  • では Add analytics ボタンをクリックします。
  • ドロップダウンから Mean オプションを選択し、mean:aggregation を選択してダイアログの外側をクリックします。メトリクスが統合され、チャートが単一の色に変わることに着目してください。
  • x 軸は現在、時間を表していません。これを変更するには、プロットラインの末尾にある設定 アイコンをクリックします。次のダイアログが表示されるはずです。 signal setup signal setup
  • Display units2)を None から Time (autoscaling)/Milliseconds(ms) に変更します。ドロップダウンが Millisecond に変わり、チャートの x 軸がテストの実行時間を表すようになります。
  • 設定 アイコンまたはcloseボタンをクリックし、ダイアログを閉じます。
  • Detector を追加するには、Link Detector ボタンをクリックして、以前に作成した Detector の名前を入力します。
  • Detector の名前をクリックして選択します。
  • チャートの周りにカラーの枠が表示されることに着目しましょう。これは、アラートの状態を示しています。ダッシュボードの上部にあるベルアイコンについても同様です。以下の画像のように見えるはずです。 detector added detector added
  • 完了したら、Save and close ボタンをクリックします。
  • ダッシュボードで、チャートを以下のスクリーンショットのように移動させます。 Service Health Dashboard Service Health Dashboard
  • 最後に、ページの上部の三点リーダー Event Overlay の横)をクリックし、View fullscreen をクリックします。これで壁に取り付けられたTVモニターで表示するのにも利用できます(戻るにはEscキーを押します)。
Tip

時間がある場合には、RUM メトリクスを使用してダッシュボードに別のカスタムチャートを追加してみてください。事前に用意・提供されている RUM applications ダッシュボードグループからチャートをコピーするか、rum.client_error.count を使用してアプリケーションのクライアントエラーの数を表示するチャートを作成できます。

最後に、ワークショップの締めくくりを行います。

Last Modified 2024/02/15

ワークショップのまとめ 🎁

10 分

おめでとうございます! Splunk4Rookies - Observability Cloud Workshop を完了しました。これで、あなたは Splunk Observability Cloud をどのように活用してアプリケーションとインフラストラクチャを監視すればよいか理解することができました。

この証明書を LinkedIn プロフィールに追加して、あなたの成し遂げたことをお祝いしましょう。

学んだことと、次にできることを振り返ってみましょう。

Champagne Champagne

Last Modified 2024/02/15

10. ワークショップのまとめのサブセクション

主なポイント

ワークショップでは、Splunk Observability Cloud と OpenTelemetry シグナル(メトリクストレースログ)を組み合わせることで、平均検出時間(MTTD)の短縮、平均解決時間(MTTR)の短縮にどれほど寄与するかを見てきました。

  • 主なユーザーインターフェースとそのコンポーネント、ランディングページ、Infrastructure、APM、RUM、Synthetics、ダッシュボードページ および 設定ページの理解を深めました。
  • 時間の許す限り、Infrastructure の演習で Kubernetes ナビゲーターで使用される メトリクス を見て、Kubernetes クラスターで見つかった関連するサービスを確認しました。

Kubernetes Kubernetes

  • ユーザーが経験していることを理解し、RUM および APM を使用して特に時間のかかるページ読み込みをトラブルシュートしました。その際には、そのトレースをフロントエンドからバックエンドまで追跡し、ログエントリまで確認しました。 また、RUM Session Replay および APM Dependency mapBreakdown などのツールを使用して、問題の原因を発見しました。

rum and apm rum and apm

  • RUM および APM の両方で Tag Spotlight を使用して問題の影響範囲やパフォーマンス問題とエラーの傾向とコンテキストを理解しました。 APM Trace waterfallSpan を掘り下げて、サービスがどのように相互作用ているかを確認し、エラーを見つけました。

tag and waterfall tag and waterfall

  • Related content 機能を使用して、Trace からその Trace に関連する Logs へのリンクを辿り、フィルターを使用して問題の正確な原因まで掘り下げました。

logs logs

  • さらに、Synthetics を確認し、ここでウェブおよびモバイルトラフィックをシミュレートしました。 Synthetics テストを活用し、RUM / APM および Log Observer から見つけた内容を確認するとともに、テスト実行での所要時間が SLA を超えた場合に警告を受けられるように Detector を作成しました。

  • 最後の演習では、開発者とSREがTVスクリーンで状態をチェックし続けられるように、ヘルスダッシュボードを作成しました。

synth and TV synth and TV