はじめに

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

Splunkが主催するワークショップの場合、Workshop Orgに招待するメールを受け取っているはずです。このメールは下のスクリーンショットのようになっています。見つからない場合は、迷惑メールフォルダを確認するか、インストラクターにお知らせください。また、ログイン FAQで他の解決策を確認することもできます。

進めるには、Join Now（参加する）ボタンをクリックするか、メールに記載されているリンクをクリックしてください。

登録プロセスをすでに完了している場合は、残りの手順をスキップして直接Splunk Observability Cloudにログインできます

• https://app.eu0.signalfx.com (EMEA)
• https://app.us1.signalfx.com (APAC/AMER)

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

• 8文字から32文字の間である
• 少なくとも1つの大文字を含む
• 少なくとも1つの数字を含む
• 少なくとも1つの記号（例：!@#$%^&*()_+）を含む

利用規約に同意するためのチェックボックスをクリックし、SIGN IN NOW（今すぐサインイン）ボタンをクリックします。

Real User Monitoring概要

Splunk RUMは業界で唯一のエンドツーエンドのNoSample（サンプリングなし）RUMソリューションで、すべてのWebおよびモバイルセッションの完全なユーザーエクスペリエンスに関する可視性を提供し、発生時にすべてのフロントエンドトレースとバックエンドのメトリクス、トレース、ログを独自に組み合わせます。ITオペレーションとエンジニアリングチームは、エラーの範囲を迅速に特定し、優先順位を付け、分離し、パフォーマンスが実際のユーザーにどのように影響するかを測定し、すべてのユーザー操作のビデオ再構築とともにパフォーマンスメトリクスを相関させることでエンドユーザーエクスペリエンスを最適化できます。

完全なユーザーセッション分析： ストリーミング分析により、シングルページおよびマルチページアプリからの完全なユーザーセッションをキャプチャし、すべてのリソース、画像、ルート変更、APIコールの顧客への影響を測定します。
問題をより迅速に関連付ける： 無限のカーディナリティと完全なトランザクション分析により、複雑な分散システム全体で問題をより迅速に特定し関連付けることができます。
レイテンシーとエラーの分離： 各コード変更とデプロイメントに対するレイテンシー、エラー、パフォーマンスの低下を簡単に特定します。コンテンツ、画像、サードパーティの依存関係がお客様にどのように影響するかを測定します。
ページパフォーマンスのベンチマークと改善： コアウェブバイタルを活用して、ページ読み込み体験、インタラクティビティ、視覚的安定性を測定し改善します。影響力のあるJavaScriptエラーを見つけて修正し、最初に改善すべきページを簡単に理解します。
意味のあるメトリクスの探索： 特定のワークフロー、カスタムタグ、未インデックス化タグの自動提案に関するメトリクスを使用して、顧客への影響を即座に視覚化し、問題の根本原因をすばやく見つけます。
エンドユーザーエクスペリエンスの最適化： すべてのユーザー操作のビデオ再構築とともにパフォーマンスメトリクスを相関させて、エンドユーザーエクスペリエンスを最適化します。

Application Performance Monitoring概要

Splunk APMは、モノリスとマイクロサービス全体で問題をより迅速に解決するために、すべてのサービスとその依存関係のNoSample（サンプリングなし）エンドツーエンドの可視性を提供します。チームは新しいデプロイメントからの問題をすぐに検出し、問題の原因の範囲を特定して分離することで自信を持ってトラブルシューティングを行い、バックエンドサービスがエンドユーザーとビジネスワークフローにどのように影響するかを理解することでサービスのパフォーマンスを最適化できます。

リアルタイム監視とアラート： Splunkは標準でサービスダッシュボードを提供し、急激な変化があった場合にREDメトリクス（レート、エラー、期間）を自動的に検出してアラートを発します。 動的テレメトリマップ： 現代の本番環境でのサービスパフォーマンスをリアルタイムで簡単に視覚化できます。インフラストラクチャ、アプリケーション、エンドユーザー、およびすべての依存関係からのサービスパフォーマンスのエンドツーエンドの可視性により、新しい問題の範囲をすばやく特定し、より効果的にトラブルシューティングを行うことができます。
インテリジェントなタグ付けと分析： ビジネス、インフラストラクチャ、アプリケーションからのすべてのタグを1か所で表示し、レイテンシーやエラーの新しい傾向を特定のタグ値と簡単に比較できます。
AI によるトラブルシューティングが最も影響の大きい問題を特定： 個々のダッシュボードを手動で掘り下げる代わりに、より効率的に問題を分離します。サービスと顧客に最も影響を与える異常とエラーの原因を自動的に特定します。
完全な分散トレースがすべてのトランザクションを分析： クラウドネイティブ環境の問題をより効果的に特定します。Splunk分散トレースは、バックエンドとフロントエンドからのすべてのトランザクションをインフラストラクチャ、ビジネスワークフロー、アプリケーションのコンテキストで視覚化し相関付けます。
フルスタック相関： Splunk Observability内では、APMがトレース、メトリクス、ログ、プロファイリングをリンクし、スタック全体のすべてのコンポーネントとその依存関係のパフォーマンスを簡単に理解できるようにします。
データベースクエリパフォーマンスの監視： SQLおよびNoSQLデータベースからの遅いクエリと高実行クエリがサービス、エンドポイント、ビジネスワークフローにどのように影響するかを簡単に特定できます — 計装は不要です。

Log Observer概要

Log Observer Connectを使用すると、Splunkプラットフォームからの同じログデータをシームレスに直感的でコード不要のインターフェースに取り込み、問題を迅速に見つけて修正するのに役立ちます。ログベースの分析を簡単に実行し、Splunk Infrastructure MonitoringのリアルタイムメトリクスとSplunk APMトレースを1か所でシームレスに関連付けることができます。

エンドツーエンドの可視性： Splunkプラットフォームの強力なロギング機能とSplunk Observability Cloudのトレースおよびリアルタイムメトリクスを組み合わせることで、ハイブリッド環境のより深い洞察とより多くのコンテキストを得ることができます。
迅速かつ簡単なログベースの調査を実行： すでにSplunk Cloud PlatformまたはEnterpriseに取り込まれているログを、シンプルで直感的なインターフェース（SPLを知る必要はありません！）でカスタマイズ可能な標準搭載のダッシュボードとともに再利用することによって実現します。
より高いスケールの経済性と運用効率を実現： チーム間でログ管理を一元化し、データとチームのサイロを壊し、全体的により良いサポートを得ることによって実現します。

Synthetics概要

Splunk Synthetic Monitoringは、URL、API、重要なWebサービス全体に可視性を提供し、問題をより迅速に解決します。ITオペレーションとエンジニアリングチームは、問題の検出、アラート、優先順位付けを簡単に行い、複数ステップのユーザージャーニーをシミュレートし、新しいコードデプロイメントからのビジネスへの影響を測定し、ステップバイステップのガイド付き推奨事項を使用してWebパフォーマンスを最適化し、より良いデジタルエクスペリエンスを確保できます。

可用性の確保： ユーザーエクスペリエンスを構成する複数ステップのワークフローをシミュレートするカスタマイズ可能なブラウザテストで、重要なサービス、URL、APIの健全性と可用性を事前に監視し、アラートを出します。
メトリクスの改善： コアウェブバイタルとモダンパフォーマンスメトリクスにより、ユーザーはすべてのパフォーマンス欠陥を1か所で表示し、ページ読み込み、インタラクティビティ、視覚的安定性を測定して改善し、JavaScriptエラーを見つけて修正してページパフォーマンスを向上させることができます。
フロントエンドからバックエンドまで： Splunk APM、Infrastructure Monitoring、On-Call、ITSIとの統合により、チームはエンドポイントの稼働時間をバックエンドサービス、基盤となるインフラストラクチャ、およびインシデント対応の調整との関連で表示し、単一のUI内で環境全体をトラブルシューティングできます。
検出とアラート： エンドユーザー体験を監視してシミュレートし、顧客に影響を与える前にAPI、サービスエンドポイント、重要なビジネストランザクションの問題を検出、通信、解決します。
ビジネスパフォーマンス： 主要なビジネストランザクションの複数ステップのユーザーフローを簡単に定義し、数分で重要なユーザージャーニーの記録とテストを開始します。稼働時間とパフォーマンスのSLAとSLOを追跡・報告します。
フィルムストリップとビデオ再生： 画面録画、フィルムストリップ、スクリーンショットを、最新のパフォーマンススコア、競合ベンチマーキング、メトリクスとともに表示して、人工的なエンドユーザー体験を視覚化します。ビジュアルコンテンツを配信する速度を最適化し、ページの安定性とインタラクティビティを向上させて、より良いデジタルエクスペリエンスをデプロイします。

インフラストラクチャ概要

Splunk Infrastructure Monitoring（IM）は、ハイブリッドクラウド環境向けの市場をリードする監視および可観測性サービスです。特許取得済みのストリーミングアーキテクチャに基づいて構築されており、従来のソリューションよりもはるかに短時間で、より高い精度でインフラストラクチャ、サービス、アプリケーション全体のパフォーマンスを視覚化および分析するためのリアルタイムソリューションをエンジニアリングチームに提供します。

OpenTelemetry 標準化： データの完全な制御を提供し、ベンダーロックインから解放し、独自のエージェントの実装から解放します。
Splunk の OTel コレクター： シームレスなインストールと動的な構成により、スタック全体を数秒で自動検出し、クラウド、サービス、システム全体の可視性を提供します。
300 以上の使いやすい標準コンテンツ： 事前構築されたナビゲーターとダッシュボードにより、環境全体の即時の視覚化を提供し、すべてのデータとリアルタイムで対話できます。
Kubernetes ナビゲーター： ノード、ポッド、コンテナの包括的な標準的な階層ビューを即座に提供します。わかりやすいインタラクティブなクラスターマップで、最も初心者のKubernetesユーザーでもすぐに使いこなせます。
AutoDetect アラートとディテクター： 最も重要なメトリクスを標準で自動的に識別し、テレメトリデータが取り込まれた瞬間から正確にアラートを出すディテクターのアラート条件を作成し、重要な通知のために数秒でリアルタイムのアラート機能を使用します。
ダッシュボード内のログビュー： 共通のフィルターと時間制御を使用して、ログメッセージとリアルタイムメトリクスを1ページに組み合わせ、より迅速なコンテキスト内トラブルシューティングを実現します。
メトリクスパイプライン管理： 再計装なしに取り込み時点でメトリクスの量を制御し、必要なデータのみを保存して分析するための集約およびデータ削除ルールのセットを使用します。メトリクスの量を削減し、可観測性のコストを最適化します。

1. RUMダッシュボード

Splunk Observability Cloudのメインメニューから、RUMをクリックします。RUMホームページに到着します。このビューについては、先ほどの短い紹介ですでに説明しました。

• UX Metrics: ページビュー、ページロード、Webバイタルメトリクス。
• Front-end Health: JavaScriptエラーとロングタスクの期間と数の内訳。
• Back-end Health: ネットワークエラー、リクエスト、最初のバイトまでの時間。
• Custom Events: Custom EventsのREDメトリクス（レート、エラー、期間）。

2. Tag Spotlight

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

これで、最も長い期間の降順でソートされたユーザーセッションテーブルができました。このテーブルには、サイトでショッピングしたすべてのユーザーの都市も含まれています。OSバージョン、ブラウザバージョンなど、さらにフィルターを適用してデータを絞り込むこともできます。

3. セッションリプレイ

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

4. ユーザーセッション

これによりAPMパフォーマンスサマリーが表示されます。このエンドツーエンド（RUMからAPM）のビューは、問題のトラブルシューティングを行う際に非常に便利です。

1. APM探索

APMサービスマップは、APMで計装された（インストルメンテーション）サービスと推測されるサービスの間の依存関係と接続を表示します。このマップは、時間範囲、環境、ワークフロー、サービス、タグフィルターでの選択に基づいて動的に生成されます。

RUMウォーターフォールでAPMリンクをクリックすると、そのワークフロー名（frontend:/cart/checkout）に関連するサービスを表示するために、サービスマップビューに自動的にフィルターが追加されました。

ワークフローに関連するサービスはService Mapで確認できます。サイドペインのBusiness Workflowの下には、選択したワークフローのチャートが表示されています。Service Mapとビジネスワークフローチャートは同期しています。Service Mapでサービスを選択すると、Business Workflowペインのチャートが更新され、選択したサービスのメトリクスが表示されます。

Splunk APMはまた、リアルタイムで発生している問題を確認し、問題がサービス、特定のエンドポイント、または基盤となるインフラストラクチャに関連しているかどうかを迅速に判断するのに役立つ組み込みの Service Centric View(サービス中心ビュー) も提供しています。より詳しく見てみましょう。

2. APMサービスビュー

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

3. APM Tag Spotlight

Tag Spotlightのビューは、チャートとカードの両方で設定可能です。デフォルトではリクエストとエラーに設定されています。

また、カードに表示されるタグメトリクスを設定することも可能です。以下の任意の組み合わせを選択できます

• Requests
• Errors
• Root Cause errors
• P50 Latency
• P90 Latency
• P99 Latency

改めて、フィルターアイコンからShow tags with no valuesチェックボックスがオフになっていることを確認してください。

paymentserviceの問題を引き起こしているバージョンを特定したので、エラーについてさらに詳しい情報が見つかるか確認してみましょう。ページ上部の ← Tag Spotlight をクリックして、サービスマップに戻ります。

4. APMサービスブレイクダウン

これでpaymentserviceがgold、silver、bronzeの3つのサービスに分解されているのが確認できます。各テナントは2つのサービスに分解されており、それぞれのバージョン（v350.10 と v350.9）に対応しています。

次に、何が起きているかを確認するためにトレースを詳しく調べる必要があります。

5. APMトレースアナライザー

Splunk APMはすべてのサービスのNoSample（サンプリングなし）エンドツーエンドの可視性を提供するため、Splunk APMはすべてのトレースをキャプチャします。このワークショップでは、Order Confirmation IDがタグとして利用可能です。これは、ワークショップの前半で遭遇した不良なユーザー体験の正確なトレースを検索するためにこれを使用できることを意味します。

Trace & Error countビューは、積み上げ棒グラフで合計トレース数とエラーのあるトレース数を表示します。マウスを使用して、利用可能な時間枠内の特定の期間を選択できます。

Trace Durationビューは、期間ごとのトレースのヒートマップを表示します。ヒートマップは3次元のデータを表しています

• x軸の時間
• y軸のトレース期間
• ヒートマップの色合いで表される1秒あたりのトレース（またはリクエスト）数

マウスを使ってヒートマップ上の領域を選択し、特定の時間帯とトレース期間の範囲にフォーカスすることができます。

これで、非常に長いチェックアウト待ちという不良なユーザーエクスペリエンスに遭遇した正確なトレースまでフィルタリングできました。

このトレースを表示することの二次的な利点は、トレースが最大13か月間アクセス可能であることです。これにより、開発者は後の段階でこの問題に戻り、このトレースを引き続き表示することができます。

次に、トレースウォーターフォールを確認していきます。

6. APMウォーターフォール

トレースアナライザーからトレースウォーターフォールに到達しました。トレースは同じトレースIDを共有するスパンの集まりで、アプリケーションとその構成サービスによって処理される一意のトランザクションを表します。

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

関連コンテンツ(Related Contents)は、APM、インフラストラクチャモニタリング、およびLog Observerが可観測性クラウド全体でフィルターを渡すことを可能にする特定のメタデータに依存しています。関連ログが機能するためには、ログに以下のメタデータが必要です

• service.name
• deployment.environment
• host.name
• trace_id
• span_id

次に、ログのエラーについてさらに詳しく調べてみましょう。

1. ログフィルタリング

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

これの利点は、RUMとAPM間のリンクと同様に、以前のアクションのコンテキスト内でログを見ていることです。この場合、コンテキストはトレースの時間枠（1）とtrace_idに設定されたフィルター（2）です。

このビューには、エンドユーザーとオンラインブティックのやり取りによって開始されたバックエンドトランザクションに参加したすべてのアプリケーションまたはサービスからのすべてのログ行が含まれます。

私たちのオンラインブティックのような小さなアプリケーションでさえ、見つかるログの膨大な量により、調査している実際のインシデントに関連する特定のログ行を見つけることが難しくなる場合があります。

次に、ログエントリの詳細を見ていきます。

2. ログエントリの表示

特定のログ行を見る前に、これまでに行ったことと、可観測性の3本柱に基づいてなぜここにいるのかを簡単に振り返ってみましょう

• メトリクスを使用して、アプリケーションに問題があることを特定しました。これはサービスダッシュボードのエラー率が、あるべき値よりも高かったことから明らかでした。
• トレースとスパンタグを使用して、問題がどこにあるかを見つけました。paymentserviceには v350.9 と v350.10 の2つのバージョンがあり、v350.10 のエラー率は 100% でした。
• paymentserviceの v350.10 からのこのエラーが、複数の再試行とオンラインブティックのチェックアウトからの応答の長い遅延を引き起こしたことを確認しました。
• トレースから、関連コンテンツの力を使用して、失敗したpaymentserviceバージョンのログエントリに到達しました。これで、問題が何であるかを特定できます。

ワークショップの次のパートでは、問題発見モードから緩和、防止、プロセス改善モードに移行します。

次は、カスタムダッシュボードでのログチャートの作成です。

3. ログタイムラインチャート

Log Observerで特定のビューを持った後、そのビューをダッシュボードで使用できると、将来的に問題の検出や解決にかかる時間を短縮するのに非常に役立ちます。ワークショップの一環として、これらのチャートを使用する例示的なカスタムダッシュボードを作成します。

ログタイムラインチャートの作成を見ていきましょう。ログタイムラインチャートは、時間経過に伴うログメッセージを視覚化するために使用されます。ログメッセージの頻度を確認し、パターンを特定するための優れた方法です。また、環境全体でのログメッセージの分布を確認するための素晴らしい方法でもあります。これらのチャートはカスタムダッシュボードに保存できます。

次に、ログビューチャートを作成します。

4. ログビューチャート

ログで使用できる次のチャートタイプはログビューチャートタイプです。このチャートでは、事前定義されたフィルターに基づいてログメッセージを確認できます。

前回のログタイムラインチャートと同様に、このチャートのバージョンをカスタマーヘルスサービスダッシュボードに追加します

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

1. Syntheticsダッシュボード

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

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

2. Syntheticsテスト詳細

現在、単一のSynthetic Browserテストの結果を見ています。このテストはビジネストランザクションに分割されています。これは、ビジネス上重要なユーザーフローを表す、論理的に関連する1つ以上の操作のグループと考えてください。

1. フィルムストリップ： サイトのパフォーマンスのスクリーンショットのセットを提供し、ページがリアルタイムでどのように応答するかを確認できます。
2. ビデオ： 特定のテスト実行の場所とデバイスからあなたのサイトを読み込もうとするユーザーが体験する内容を正確に確認できます。
3. ブラウザテストメトリクス： ウェブサイトのパフォーマンスの全体像を提供するビューです。
4. Synthetic トランザクション： サイトとの対話を構成するSyntheticトランザクションのリスト
5. ウォーターフォールチャート ウォーターフォールチャートは、テストランナーとテスト対象サイトの間の対話を視覚的に表現したものです。

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

3. SyntheticsからAPMへ

今、以下のような表示が見えているはずです。

4. Synthetics Detector

これらのテストを24時間365日実行できるため、テストが失敗したり、合意したSLAよりも長く実行され始めた場合に、ソーシャルメディアやアップタイムウェブサイトから通知される前に、早期に警告を受けるための理想的なツールです。

そのような事態を防ぐために、テストが1.1分以上かかっているかどうかを検知しましょう。

ダッシュボードの強化

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

これは**支払いサービス**のためのカスタムヘルスダッシュボードです。
ログのエラーに注意してください。
詳細については[リンク](https://https://www.splunk.com/en_us/products/observability.html)をご覧ください。

これは素晴らしいですね。引き続き、より意味のあるチャートを追加していきましょう。

カスタムチャートの追加

ワークショップのこのパートでは、ダッシュボードに追加するチャートを作成し、また以前に構築したディテクターにリンクします。これにより、テストの動作を確認し、1つ以上のテスト実行がSLAを違反した場合にアラートを受け取ることができます。

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

主要なポイント

このワークショップを通じて、Splunk Observability CloudとOpenTelemetryシグナル（メトリクス、トレース、ログ）の組み合わせが、検出までの平均時間（MTTD）と解決までの平均時間（MTTR）をどのように短縮できるかを見てきました。

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

• ユーザーが何を体験しているかを理解し、RUMとAPMを使用して特に長いページ読み込みのトラブルシューティングを行いました。フロントエンドとバックエンド全体でトレースをたどり、ログエントリーまで追跡しました。 RUMのセッション再生とAPMの依存関係マップを使用し、ブレークダウン機能を使って問題の原因を発見しました

• RUMとAPMの両方でTag Spotlightを使用して、影響範囲を理解し、パフォーマンス問題とエラーのトレンドやコンテキストを検出しました。APMのトレースウォーターフォールでスパンを詳しく調べ、サービスがどのように相互作用し、エラーを見つけました

• 関連コンテンツ機能を使用して、トレースからトレースに関連するログへの直接のリンクをたどり、フィルターを使用して問題の正確な原因まで掘り下げました。

• 次に、WebとモバイルトラフィックをシミュレートできるSyntheticsを調べ、利用可能なSyntheticsテストを使用して、まずRUM/APMとLog Observerでの発見を確認し、次にテストの実行時間がSLAを超えた場合にアラートを受け取るためのディテクターを作成しました。

• 最後の演習では、開発者とSREのためにTVスクリーンで継続的に表示するヘルスダッシュボードを作成しました