はじめに

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

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

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 ボタンをクリックしてください。

RUMの概要

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

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

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

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

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

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

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

APMの概要

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

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

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

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

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

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

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

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

Log Observerの概要

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 の知識は不要です！）

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

Syntheticsの概要

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 をトラックし、通知してくれます。

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

Infrastructureの概要

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

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

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

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

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

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

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

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

1. RUM ダッシュボード

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

• UX Metrics: ページビュー、ページ読み込み、Web Vitals メトリクス。
• Front-end Health: Javascript エラーおよび Long Task の期間と回数の分解。
• Back-end Health: ネットワークエラーおよびリクエスト、Time to First Byte。
• Custom Events: カスタムイベントの RED メトリクス（Rate、Error＆Duration）。

2. Tag Spotlight

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

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

3. Session Replay

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

4. User Sessions

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

1. APM Explore

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

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

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

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

2. APM Service Dashboard

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

3. APM Tag Spotlight

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

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

4. APM Service Breakdown

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

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

5. APM Trace Analyzer

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

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

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

6. APM Waterfall

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

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

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

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

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

1. Log Filtering

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

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

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

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

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

2. ログエントリの参照

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

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

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

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

3. Log Timeline Chart

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

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

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

4. Log View Chart

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

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

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

1. Synthetics Dashboard

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

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

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

2. Synthetics Test Detail

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

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

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

3. Synthetics to APM

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

4. Synthetics Detector

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

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

ダッシュボードの拡張

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

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

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

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

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

カスタムチャートの追加

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

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

主なポイント

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

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

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

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

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

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

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

K3s に NGINX をデプロイする

• NGINX ReplicaSet を K3s クラスタにデプロイし、NGINX デプロイメントのディスカバリーを確認します。
• 負荷テストを実行してメトリクスを作成し、Splunk Observability Cloudにストリーミングすることを確認します！

1. NGINX の起動

Splunk UI で WORKLOADS タブを選択して、実行中の Pod の数を確認します。これにより、クラスタ上のワークロードの概要がわかるはずです。

デフォルトの Kubernetes Pod のうち、ノードごとに実行されている単一のエージェントコンテナに注目してください。この1つのコンテナが、このノードにデプロイされているすべての Pod とサービスを監視します！

次に、MAP タブを選択してデフォルトのクラスタノードビューに戻し、再度クラスタを選択します。

Multipass または AWS/EC2 のシェルセッションで、nginx ディレクトリに移動します。

cd ~/workshop/k3s/nginx

2. NGINXのデプロイメント作成

NGINX の ConfigMap¹ を nginx.conf ファイルを使って作成します。

kubectl create configmap nginxconfig --from-file=nginx.conf

configmap/nginxconfig created

続いて、デプロイメントを作成します。

kubectl create -f nginx-deployment.yaml

次に、NGINXに対する負荷テストを作成するため、 Locust² をデプロイします。

kubectl create -f locust-deployment.yaml

deployment.apps/nginx-loadgenerator created
service/nginx-loadgenerator created

デプロイメントが成功し、Locust と NGINX Pod が動作していることを確認しましょう。

Splunk UI を開いていれば、新しい Pod が起動し、コンテナがデプロイされているのがわかるはずです。

Pod が実行状態に移行するまでには 20 秒程度しかかかりません。Splunk UIでは、以下のようなクラスタが表示されます。

もう一度 WORKLOADS タブを選択すると、新しい ReplicaSet と NGINX 用のデプロイメントが追加されていることがわかります。

これをシェルでも検証してみましょう。

kubectl get pods

NAME                                                          READY   STATUS    RESTARTS   AGE
splunk-otel-collector-k8s-cluster-receiver-77784c659c-ttmpk   1/1     Running   0          9m19s
splunk-otel-collector-agent-249rd                             1/1     Running   0          9m19s
svclb-nginx-vtnzg                                             1/1     Running   0          5m57s
nginx-7b95fb6b6b-7sb9x                                        1/1     Running   0          5m57s
nginx-7b95fb6b6b-lnzsq                                        1/1     Running   0          5m57s
nginx-7b95fb6b6b-hlx27                                        1/1     Running   0          5m57s
nginx-7b95fb6b6b-zwns9                                        1/1     Running   0          5m57s
svclb-nginx-loadgenerator-nscx4                               1/1     Running   0          2m20s
nginx-loadgenerator-755c8f7ff6-x957q                          1/1     Running   0          2m20s

3. Locust の負荷テストの実行

Locust はオープンソースの負荷テストツールで、EC2 インスタンスの IP アドレスの8083番ポートで Locust が利用できるようになりました。Webブラウザで新しいタブを開き、http://{==EC2-IP==}:8083/にアクセスすると、Locust が動作しているのが確認できます。

Spawn rate を 2 に設定し、Start Swarming をクリックします。

これにより、アプリケーションに緩やかな連続した負荷がかかるようになります。

上記のスクリーンショットからわかるように、ほとんどのコールは失敗を報告しています。これはアプリケーションをまだデプロイしていないため予想されることですが、NGINXはアクセス試行を報告しており、これらのメトリックも見ることができます。

サイドメニューから Dashboards → Built-in Dashboard Groups → NGINX → NGINX Servers を選択して、UIにメトリクスが表示されていることを確認します。さらに Overrides フィルターを適用して、 k8s.cluster.name: に、ターミナルの echo $(hostname)-k3s-cluster で返されるクラスタの名前を見つけます。

チャートを編集する

1. チャートの編集

Sample Data ダッシュボードにある Latency histogram チャートの3点 ... をクリックして、Open をクリックします（または、チャートの名前をクリックしてください、ここでは Latency histogram です）。

チャートエディターのUIには、Latency histogram チャートのプロットオプション、カレントプロット、シグナル（メトリック）が表示されます。

Plot Editor タブの Signal には、現在プロットしている demo.trans.latency というメトリックが表示されます。

いくつかの Line プロットが表示されます。18 ts という数字は、18個の時系列メトリックをチャートにプロットしていることを示しています。

異なるチャートタイプのアイコンをクリックして、それぞれの表示を確認してください。スワイプしながらその名前を確認してください。例えば、ヒートマップのアイコンをクリックします。

チャートがヒートマップに変わります。

チャートタイプの Line をクリックすると、線グラフが表示されます。

2. タイムウィンドウの変更

また、Time ドロップダウンから Past 15 minutes に変更することで、チャートの時間枠を変更することができます。

3. データテーブルの表示

Data Table タブをクリックします。

18行が表示され、それぞれがいくつかの列を持つ時系列メトリックを表しています。これらの列は、メトリックのディメンションを表しています。demo.trans.latency のディメンジョンは次のとおりです。

• demo_datacenter
• demo_customer
• demo_host

demo_datacenter 列では、メトリクスを取得している2つのデータセンター、Paris と Tokyo があることがわかります。

グラフの線上にカーソルを横に移動させると、それに応じてデータテーブルが更新されるのがわかります。チャートのラインの1つをクリックすると、データテーブルに固定された値が表示されます。

ここでもう一度 Plot editor をクリックしてデータテーブルを閉じ、このチャートをダッシュボードに保存して、後で使用しましょう。

チャートを保存する

1. チャートの保存

チャートの保存するために、名前と説明をつけましょう。チャートの名前 Copy of Latency Histogram をクリックして、名前を “現在のレイテンシー” に変更します。

説明を変更するには、 Spread of latency values across time. をクリックし、 リアルタイムでのレイテンシー値 に変更します。

Save Asボタンをクリックします。チャートに名前が付いていることを確認します。前のステップで定義した 現在のレイテンシー という名前が使用されますが、必要に応じてここで編集することができます。

Okボタンを押して続行します。

2. ダッシュボードの作成

Choose dashboard ダイアログでは、新しいダッシュボードを作成する必要があります。New Dashboard ボタンをクリックしてください。

これで、New Dashboard ダイアログが表示されます。ここでは、ダッシュボードの名前と説明を付け、Write Permissions で書き込み権限を設定します。

ダッシュボードの名前には、自分の名前を使って YOUR_NAME-Dashboard の形式で設定してください。

YOUR_NAME を自分の名前に置き換えてから、編集権限をEveryone can Read or Write からRestricted Read and Write access に変更してみてください。

ここには、自分のログイン情報が表示されます。つまり、このダッシュボードを編集できるのは自分だけということになります。もちろん、ダッシュボードやチャートを編集できる他のユーザーやチームを下のドロップボックスから追加することもできますが、今回は、Everyone can Read or Write に 再設定 して制限を解除し、Save ボタンを押して続行してください。

新しいダッシュボードが利用可能になり、選択されましたので、チャートを新しいダッシュボードに保存することができます。

ダッシュボードが選択されていることを確認して、Okボタンを押します。

すると、下図のようにダッシュボードが表示されます。左上に、YOUR_NAME-DASHBOARD がダッシュボードグループ YOUR_NAME-Dashboard の一部であることがわかります。このダッシュボードグループに他のダッシュボードを追加することができます。

3. チームページへの追加

チームに関連するダッシュボードは、チームページにリンクさせるのが一般的です。そこで、後で簡単にアクセスできるように、ダッシュボードをチームページに追加してみましょう。 ナビバーのアイコンを再びクリックします。

これでチームダッシュボードに遷移します。ここでは、チーム Example Team を例にしていますが、ワークショップのものは異なります。

すると、 Select a dashboard group to link to this team ダイアログが表示されます。 検索ボックスにご自身のお名前（上記で使用したお名前）を入力して、ダッシュボードを探します。ダッシュボードがハイライトされるように選択し、Ok ボタンをクリックしてダッシュボードを追加します。

ダッシュボードグループがチームページの一部として表示されます。ワークショップを進めていくと、さらに多くのダッシュボードがここに表示されていくはずです。

次のモジュールでは、ダッシュボードのリンクをクリックして、チャートをさらに追加していきます！

3.3 フィルタと数式の使い方

1 新しいチャートの作成

それでは、新しいチャートを作成し、ダッシュボードに保存してみましょう。

UIの右上にある + アイコンを選択し、ドロップダウンから Chart を選択します。 または、

• New Chart

これで、以下のようなチャートのテンプレートが表示されます。

プロットするメトリックを入力してみましょう。ここでは、demo.trans.latency というメトリックを使用します。

Plot Editor タブの Signal に demo.trans.latency を入力します。

すると、折れ線グラフが表示されるはずです。時間を15分に切り替えてみてください。

2. フィルタリングと分析

次に、Paris データセンターを選択して分析を行ってみましょう。そのためにはフィルタを使用します。

Plot Editor タブに戻り、Add Filter をクリックして、入力補助として選択肢が出てくるので、そこから demo_datacenter を選択し、Paris を選択します。

F(x) 欄に分析関数 Percentile:Aggregation を追加し、値を 95 にします（枠外をクリックすると設定が反映されます）。

Percentile 関数やその他の関数の情報は、Chart Analytics を参照してください。

3. タイムシフト分析を追加

それでは、以前のメトリックと比較してみましょう。... をクリックして、ドロップダウンから Clone をクリックし、Signal A をクローンします。

A と同じような新しい行が B という名前で表示され、プロットされているのがわかります。

シグナル B に対して、F(x) 列に分析関数 Timeshift を追加し、1w（もしくは 7d でも同じ意味です）と入力し、外側をクリックして反映させます。

右端の歯車をクリックして、Plot Color を選択（例：ピンク）すると、 B のプロットの色を変更できます。

Close をクリックして、設定を終えます。

シグナル A （過去15分）のプロットが青、1週間前のプロットがピンクで表示されています。

より見やすくするために、Area chart アイコンをクリックして表示方法を変更してみましょう。

これで、前週にレイテンシーが高かった時期を確認することができます。

次に、Override バーの Time の隣にあるフィールドをクリックし、ドロップダウンから Past Hour を 選択してみましょう。

4. 計算式を使う

ここでは、1日と7日の間のすべてのメトリック値の差をプロットしてみましょう。

Enter Formula をクリックして、A-B （AからBを引いた値）を入力し、C を除くすべてのシグナルを隠します（目アイコンの選択を解除します）。

これで、 A と B のすべてのメトリック値の差だけがプロットされているのがわかります。B のメトリック値が、その時点での A のメトリック値よりも何倍か大きな値を持っているためです。

次のモジュールで、チャートとディテクターを動かすための SignalFlow を見てみましょう。

3.4 SignalFlow

1. はじめに

ここでは、Observability Cloud の分析言語であり、Monitoring as Codeを実現するために利用する SignalFlow について見てみましょう。

Splunk Infrastructure Monitoring の中心となるのは、Python ライクな、計算を実行する SignalFlow 分析エンジンです。SignalFlow のプログラムは、ストリーミング入力を受け取り、リアルタイムで出力します。SignalFlow には、時系列メトリック（MTS）を入力として受け取り、計算を実行し、結果の MTS を出力する分析関数が組み込まれています。

• 過去の基準との比較する（例：前週との比較）
• 分布したパーセンタイルチャートを使った母集団の概要を表示する
• 変化率（またはサービスレベル目標など、比率で表されるその他の指標）が重要な閾値を超えたかどうか検出する
• 相関関係にあるディメンジョンの発見する（例：どのサービスの挙動がディスク容量不足の警告と最も相関関係にあるかの判断する）

Infrastructure Monitoring は、Chart Builder ユーザーインターフェイスでこれらの計算を行い、使用する入力 MTS とそれらに適用する分析関数を指定できます。また、SignalFlow API を使って、SignalFlow のプログラムを直接実行することもできます。

SignalFlow には、時系列メトリックを入力とし、そのデータポイントに対して計算を行い、計算結果である時系列メトリックを出力する、分析関数の大規模なライブラリが組み込まれています。

2. SignalFlow の表示

チャートビルダーで View SignalFlow をクリックします。

作業していたチャートを構成する SignalFlow のコードが表示されます。UI内で直接 SignalFlow を編集できます。ドキュメントには、SignalFlow の関数やメソッドの 全てのリスト が掲載されています。

また、SignalFlow をコピーして、API や Terraform とやり取りする際に使用して、Monitoring as Code を実現することもできます。

A = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).publish(label='A', enable=False)
B = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).timeshift('1w').publish(label='B', enable=False)
C = (A-B).publish(label='C')

View Builder をクリックすると、Chart Builder の UI に戻ります。

この新しいチャートをダッシュボードに保存してみましょう！

ダッシュボードにチャートを追加する

1. 既存のダッシュボードに保存する

右上に YOUR_NAME-Dashboard と表示されていることを確認しましょう

これは、あなたのチャートがこのダッシュボードに保存されることを意味します。

チャートの名前を Latency History とし、必要に応じてチャートの説明を追加します。

Save And Close をクリックします。これで、ダッシュボードに戻ると2つのチャートが表示されているはずです！

では、先ほどのチャートを元に、もう一つのチャートをさくっと追加してみましょう。

2. チャートのコピー＆ペースト

ダッシュボードの Latency History チャート上の3つのドット ... をクリックし、 Copy をクリックします。

ページ左上の + の横に赤い円と白い1が表示されていれば、チャートがコピーされているということになります。

ページ上部の をクリックし、メニューの Paste Charts をクリックしてください (また、右側に 1 が見える赤い点があるはずです)。

これにより、先程のチャートのコピーがダッシュボードに配置されます。

3. 貼り付けたチャートを編集する

ダッシュボードの Latency History チャートの3つの点 ... をクリックし、Open をクリックします（または、チャートの名前（ここでは Latency History）をクリックすることもできます）。

すると、再び編集できる環境になります。

まず、チャートの右上にあるタイムボックスで、チャートの時間を -1h（1時間前から現在まで） に設定します。そして、シグナル「A」の前にある目のアイコンをクリックして再び表示させ、「C」 を非表示にし、Latency history の名前を Latency vs Load に変更します。

Add Metric Or Event ボタンをクリックします。これにより、新しいシグナルのボックスが表示されます。シグナル D に demo.trans.count と入力・選択します。

これにより、チャートに新しいシグナル D が追加され、アクティブなリクエストの数が表示されます。demo_datacenter:Paris のフィルタを追加してから、 Configure Plot ボタンをクリックしロールアップを Auto (Delta) から Rate/sec に変更します。名前を demo.trans.count から Latency vs Load に変更します。

最後に Save And Close ボタンを押します。これでダッシュボードに戻り、3つの異なるチャートが表示されます。

次のモジュールでは、「説明」のメモを追加して、チャートを並べてみましょう！

ノートの追加とダッシュボードのレイアウト

1. メモの追加

ダッシュボードには、ダッシュボードの利用者を支援するための短い「説明」ペインを配置することがよくあります。

ここでは、New Text Note ボタンをクリックして、ノートを追加してみましょう。

すると、ノートエディターが開きます。

ノートに単なるテキスト以外のものを追加できるように、Splunk ではこれらのノート/ペインで Markdown を使用できるようにしています。 Markdown は、ウェブページでよく使われるプレーンテキストを使ってフォーマットされたテキストを作成するための軽量なマークアップ言語です。

たとえば、以下のようなことができます (もちろん、それ以外にもいろいろあります)。

• ヘッダー (様々なサイズで)
• 強調スタイル
• リストとテーブル
• リンク: 外部の Web ページ (ドキュメントなど) や他の Splunk IM ダッシュボードへの直接リンクできます

以下は、ノートで使用できる上記のMarkdownオプションの例です。

# h1 Big headings

###### h6 To small headings

##### Emphasis

**This is bold text**, *This is italic text* , ~~Strikethrough~~

##### Lists

Unordered

+ Create a list by starting a line with `+`, `-`, or `*`
- Sub-lists are made by indenting 2 spaces:
- Marker character change forces new list start:
    * Ac tristique libero volutpat at
    + Facilisis in pretium nisl aliquet
* Very easy!

Ordered

1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa

##### Tables

| Option | Description |
| ------ | ----------- |
| chart  | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext    | extension to be used for dest files. |

#### Links

[link to webpage](https://www.splunk.com)

[link to dashboard with title](https://app.eu0.signalfx.com/#/dashboard/EaJHrbPAEAA?groupId=EaJHgrsAIAA&configId=EaJHsHzAEAA "Link to the Sample chart Dashboard!")

上記をコピーボタンでコピーして、Edit ボックスにペーストしてみてください。 プレビューで、どのように表示されるか確認できます。

2. チャートの保存

ノートチャートに名前を付けます。この例では、Example text chart としました。そして、Save And Close ボタンを押します。

これでダッシュボードに戻ると、メモが追加されました。

3. チャートの順序や大きさを変更

デフォルトのチャートの順番やサイズを変更したい場合は、ウィンドウをドラッグして、チャートを好きな場所に移動したり、サイズを変更したりすることができます。

チャートの 上側の枠 にマウスポインタを移動すると、マウスポインタがドラッグアイコンに変わります。これで、チャートを任意の場所にドラッグすることができます。

ここでは、 Latency vs Load チャートを Latency History と Example text chart の間に移動してください。

チャートのサイズを変更するには、側面または底面をドラッグします。

最後の練習として、ノートチャートの幅を他のチャートの3分の1程度にしてみましょう。チャートは自動的に、サポートしているサイズの1つにスナップします。他の3つのチャートの幅を、ダッシュボードの約3分の1にします。ノートを他のチャートの左側にドラッグして、他の23個のチャートに合わせてサイズを変更します。

最後に、時間を -1h に設定すると、以下のようなダッシュボードになります。

次は、ディテクターの登場です！

ミューティングルールを利用する

• ミューティングルールを設定する
• 通知を再開する

1. ミューティングルールの設定

特定の通知をミュートする必要がある場合があります。例えば、サーバーやサーバー群のメンテナンスのためにダウンタイムを設定したい場合や、新しいコードや設定をテストしている場合などがあります。このような場合には、Splunk Observability Cloud でミューティングルールを使用できます。それでは作成してみましょう。

ナビバーにある ボタンをクリックし、Detectors を選択します。現在設定されているディテクターの一覧が表示されます。フィルタを使ってディテクターを探すこともできます。

Creating a Detector でディテクターを作成した場合は、右端の3つの点 ... をクリックすると、そのディテクターが表示されます。

ドロップダウンから Create Muting Rule… をクリックします。

Muting Rule ウィンドウで、 Mute Indefinitely をチェックし、理由を入力します。

Next をクリックして、新しいモーダルウィンドウでミュートルールの設定を確認します。

Mute Indefinitely をクリックして、設定を確定させます。

これで、通知を再開するまで、ディテクターからのEメール通知は受け取ることがなくなりました。では、再開する方法を見てみましょう。

2. 通知を再開する

Muting Rules をクリックして、Detector の見出しの下に、通知をミュートしたディテクターの名前が表示されます。

右端にあるドット ... を開いて、Resume Notifications をクリックします。

Resume をクリックして、このディテクターの通知を確認し、再開します。

おめでとうございます！ これでアラート通知が再開されました。

チーム

• チームの管理
• チームの作成とメンバーの追加

1. チームの管理

Observability Cloudを使用する際に、ユーザーに関連するダッシュボードやアラートが表示されるようにするために、ほとんどの組織ではObservability Cloudのチーム機能を使用して、メンバーを1つまたは複数のチームに割り当てます。

これは、仕事に関連した役割と一致するのが理想的で、たとえば、DevOpsグループやプロダクトマネジメントグループのメンバーは、Observability Cloudの対応するチームに割り当てられます。

ユーザーがObservability Cloudにログインすると、どのチームダッシュボードをホームページにするかを選択することができ、通常は自分の主な役割に応じたページを選択します。

以下の例では、ユーザーは開発、運用、プロダクトマネジメントの各チームのメンバーであり、現在は運用チームのダッシュボードを表示しています。

このダッシュボードには、NGINX、Infra、K8s用の特定のダッシュボード・グループが割り当てられていますが、どのダッシュボード・グループもチーム・ダッシュボードにリンクすることができます。

左上のメニューを使って割り当てられたチーム間を素早く移動したり、右側の ALL TEAMS ドロップダウンを使って特定のチームのダッシュボードを選択したり、隣のリンクを使って ALL Dashboards に素早くアクセスしたりすることができます。

アラートを特定のチームにリンクすることで、チームは関心のあるアラートだけをモニターすることができます。上記の例では、現在1つのアクティブなクリティカルアラートがあります。

チームダッシュボードの説明文はカスタマイズ可能で、チーム固有のリソースへのリンクを含むことができます（Markdownを使用します）。

2. 新しいチームの作成

Splunk のチーム UI を使用するには、左下の » を開き、 Settings → Teams を選択します。

Team を選択すると、現在のチームのリストが表示されます。

新しいチームを追加するには、Create New Team ボタンをクリックします。これにより、Create New Team ダイアログが表示されます。

独自のチームを作ってみましょう。チーム名を [あなたのイニシャル]-Team のように入力し、あなた自身のユーザー選んで、Add リンクからチームに追加してみましょう。上手くいくと、次のような表示になるはずです。

選択したユーザーを削除するには、Remove または x を押します。

自分のイニシャルでグループを作成し、自分がメンバーとして追加されていることを確認して、Done をクリックします。

これでチームリストに戻り、自分のチームと他の人が作成したチームが表示されます。

自分のチームにメンバーが割り当てられていない場合は、メンバー数の代わりに青い Add Members のリンクが表示されます。このリンクをクリックすると、Edit Team ダイアログが表示され、自分を追加することができます。

自分のチームの行末にある3つのドット … を押しても、Edit Team と同じダイアログが表示されます。

… メニューでは、チームの編集、参加、離脱、削除を行うことができます（離脱と参加は、あなたが現在メンバーであるかどうかによって異なります）。

3. 通知ルールの追加

チームごとに特定の通知ルールを設定することができます。Notification Policy タブをクリックすると、通知編集メニューが表示されます。

デフォルトでは、システムはチームの一般的な通知ルールを設定する機能を提供します。

3.1 受信者の追加

Add Recipient をクリックすると、他の受信者を追加することができます。これらの受信者は Observability Cloud のユーザーである必要はありません。

Configure separate notification tiers for different severity alerts をクリックすると、各アラートレベルを個別に設定できます。

上の画像のように、異なるアラートレベルに対して異なるアラートルールを設定することができます。

Critical と Major は Splunk On-Call インシデント管理ソリューションを使用しています。Minor のアラートはチームの Slack チャンネルに送信し、Warning と Info はメールで送信する、という管理もできるようになります。

3.2 通知機能の統合

Observability Cloud では、アラート通知をメールで送信するだけでなく、以下のようなサービスにアラート通知を送信するように設定することができます。

チームの事情に合わせて、通知ルールを作成してください。

使用量を管理する

• 個別のアクセストークンを作成し、制限を設けることで利用を制限する方法を紹介します

1. アクセストークン

ホスト、コンテナ、カスタムメトリクス、高解像度メトリクスの使用量をコントロールしたい場合は、複数のアクセストークンを作成し、組織内の異なる部分に割り当てることができます。

左下の » を開いて、General Settings 配下の Settings → Access Tokens を選択します。

Access Tokens インターフェースでは、生成されたアクセストークンのリストで概要が表示されます。すべての組織では、最初のセットアップ時に Default のトークンが生成され、その他のトークンを追加・削除できるようになっています。

各トークンは一意であり、消費できるホスト、コンテナ、カスタムメトリクス、高解像度メトリクスの量に制限を設けることができます。

Usage Status 欄は、トークンが割り当てられた制限値を上回っているか下回っているかを素早く表示します。

2. 新しいトークンの作成

New Token ボタンをクリックして、新しいトークンを作成しましょう。Name Your Access Token ダイアログが表示されます。

ここでは、Ingest Token と API Token の両方のチェックボックスにチェックを入れてください。

OK を押すと、Access Token のUIに戻ります。ここでは、既存のトークンの中に、あなたの新しいトークンが表示されているはずです。

名前を間違えたり、トークンを無効/有効にしたり、トークンの制限を設定したい場合は、トークンの制限の後ろにある省略記号(…)のメニューボタンをクリックして、トークンの管理メニューを開きます。

タイプミスがあった場合は、Rename Token オプションを使用して、トークンの名前を修正することができます。

3. トークンの無効化

トークンがメトリクスの送信に使用できないようにする必要がある場合は、トークンを無効にすることができます。

Disable ボタンを押すことで、トークンを無効化できます。これにより、トークンがSplunk Observability Cloudへのデータ送信に使用できなくなります。

以下のスクリーンショットのように、トークンの行がグレーになり、無効化されたことを示しています。

省略記号(…)のメニューボタンをクリックして、トークンの無効化と有効化を行ってください。

4. トークンの使用制限の管理

… メニューの Manage Token Limit をクリックして、使用量を制限してみましょう。

トークン制限管理ダイアログが表示されます。

このダイアログでは、カテゴリごとに制限を設定することができます。

先に進み、各使用指標に対して以下のように制限を指定してください。

また、上の表に示すように、ダイアログボックスに正しい数字が表示されていることを再確認してください。

トークンリミットは、5分間の使用量がリミットの90％を超えたときに、1人または複数の受信者に通知するアラートのトリガーとして使用されます。

受信者を指定するには、Add Recipient をクリックして、使用する受信者または通知方法を選択します（受信者の指定は任意ですが、強くお勧めします）。

トークンアラートの重要度は常に「Critical」です。

Update をクリックすると、アクセストークンの制限とアラートの設定が保存されます。

これらの新しいアクセストークンを様々なチームに配布し、Observability Cloudに送信できる情報やデータの量をコントロールできるようになります。

これにより、Observability Cloudの使用量を調整することができ、過剰な使用を防ぐことができます。

おめでとうございます！ これで、管理機能のモジュールは終わりです！

1.1 Locustでトラフィックを発生させる

1. トラフィックを発生させる

Online Boutique のデプロイメントには、Locust が動作するコンテナが含まれており、これを使用してウェブサイトに対する負荷トラフィックを生成し、メトリクス、トレース、スパンを生成することができます。

Locust は、EC2インスタンスのIPアドレスの82番ポートで利用できます。ウェブブラウザで新しいタブを開き、 http://<EC2-IP>:82/ にアクセスすると、Locust が動作しているのが確認できます。

Spawn rate を 2 に設定し、Start Swarming をクリックすると、アプリケーションに緩やかな負荷がかかり続けます。

それでは、 Dashboards → All Dashboards → APM Services → Service を開きましょう。

そのためには、アプリケーションの Environment 名を知る必要があります。このワークショップでは、<hostname>-workshop のような Environment 名で定義されています。

ホスト名を調べるには、AWS/EC2インスタンス上で以下のコマンドを実行します:

echo $(hostname)-workshop

bdzx-workshop

前のステップで見つけた Environment を選択し、「frontend」サービスを選択し、時間を「Past 15 minutes」に設定します。

この自動生成されたダッシュボードでは、RED (Rate, Error & Duration) メトリクスを使用して、サービスの状態を監視することができます。このダッシュボードでは、パフォーマンスに関連したさまざまなチャートのほか、基盤となるホストやKubernetesポッド（該当する場合）の相関情報も提供されます。

ダッシュボードの様々なチャートを見てみましょう。

2. Splunk APM のメトリクスを確認する

画面左のメニューからAPMをクリックするとAPM Overviewダッシュボードが表示されます。

右側の Explore を選択し、先ほど見つけた Environment を選択し、時間を15分に設定します。これにより、自動的に生成されたOnline BoutiqueアプリケーションのDependency/Service Mapが表示されます。

以下のスクリーンショットのように表示されます:

ページの下部にある凡例では、依存関係/サービスマップでの表記について説明しています。

• サービスリクエスト、エラーレート、ルートエラーレート。
• リクエストレート、レイテンシー、エラーレート

また、このビューでは、全体的なエラー率とレイテンシー率のタイムチャートを見ることができます。

3. OpenTelemetry ダッシュボード

Open Telemetery Collector がデプロイされると、プラットフォームは自動的に OpenTelemetry Collector のメトリクスを表示するダッシュボードを作成します。

左上のナブメニューから、 Dashboards → OpenTelemetry Collector を選択し、メトリクスとスパンが送信されていることを確認しましょう。

4. OpenTelemetry zpages

送信されたトレースをデバッグするには、zpages 拡張機能を使用できます。zpages は OpenTelemetry Collector の一種で、トラブルシューティングや統計用のライブデータを提供します。これらは、EC2インスタンスのIPアドレスのポート 55679 で利用できます。Webブラウザで新しいタブを開き、 http://{==EC2-IP==}:55679/debug/tracez と入力すると、zpages の出力を見ることができます。

また、シェルプロンプトから、テキストベースのブラウザを実行することもできます。

lynx http://localhost:55679/debug/tracez

2.1 サービスマップ

サービスマップ

サービスマップの paymentservice をクリックし、paymentservice の下にあるbreakdownのドロップダウンフィルタから version を選択します。これにより、カスタムスパンタグの version でサービスマップがフィルタリングされます。

これで、サービスマップが以下のスクリーンショットのように更新され、paymentservice の異なるバージョンが表示されていることがわかります。

2.2 Tag Spotlight

タグスポットライト

画面の右側にある Tag Spotlight をスクロールダウンし、ドロップダウンから Top Across All Indexed Tags を選択します。選択したら、下のスクリーンショットにあるように をクリックします。

タグスポットライトのページが表示されます。このページでは、アプリケーションの上位のタグと、それに対応するエラー率や秒間リクエスト数を確認できます。

version スパンタグでは、バージョン 350.10 のエラー率が100%であることがわかります。また、tenant.level スパンタグでは、3つのテナント（Gold、Silver、Bronze）すべてにエラーがあることがわかります。

タグスポットライトのページはインタラクティブに、目的のタグをクリックするだけでフィルタとしてタグを追加することができます。tenant.level の下の gold をクリックして、フィルターとして追加します。これを行うと、ページには tenant.level が gold のデータのみが表示されます。

タグスポットライトは、データを分析して傾向を見極めるのに非常に便利です。Gold Tenantでは、リクエストの総数のうち55件がエラーであることがわかります。（この数字はワークショップの実施時刻により異なります）

これをバージョンタグと関連付けると、バージョン 350.10 が55件、バージョン 350.9 が17件のリクエストに対応していることがわかります。つまり、バージョン 350.10 を経由したリクエストは、すべてエラー状態になったということになります。

paymentservice のバージョン 350.10 からのすべてのリクエストがエラーになるというこの理論をさらに検証するために、タグセレクタを使用して、フィルタを別のテナントに変更することができます。フィルターを gold テナントから silver テナントに変更します。

ここで、silver テナントのエラーのあるリクエスト数を見て、バージョン番号と相関させることで、同様の分析を行うことができます。silver テナントのエラー数は、バージョン 350.10 のリクエスト数と一致していることに注目してください。

タグスポットライトでは、秒間リクエスト数やエラー率だけでなく、サービスごとのレイテンシーも見ることができます。これを行うには、レイテンシーボタンを選択し、silver テナントタグを削除することで、すべての paymentservice のレイテンシーを確認することができます。

右端の Clear All の下にある X ボタンを押して、サービスマップに戻りましょう。

2.3 サンプルトレース

サンプルトレース

右上にある「Services by Error Rate」グラフのピンク色の線上をクリックします。選択すると、サンプルトレースのリストが表示されます。Initiating Operation ofが frontend: POST /cart/checkout であるサンプルトレースの1つをクリックしてください。

スパンとともに、選択したトレースの全体が表示されます。エラーが発生したスパンは、その横に赤い！マークが表示されます。グレーのボックスにx6などの数字が表示されている場合は、それをクリックするとpaymentservice スパンを展開することができます。

赤い！マークが表示されたpaymentservice スパンの一つをクリックすると展開され、関連するメタデータやエラーの詳細が表示されます。このエラーが401エラーによるものであることがわかります。また、「テナント」や「バージョン」などの有用な情報も表示されています。

エラーの原因が 無効なリクエスト であることがわかりましたが、正確なリクエストが何であるかはわかりません。ページの下部に、ログへのコンテキストリンクが表示されます。このリンクをクリックすると、このスパンに関連付けられているログが表示されます。

下の画像と同様の Log Observer ダッシュボードが表示されます。

フィルタを使用して、エラーログのみを表示できます。右上にあるERRORをクリックしてから、Add to filterをクリックします。

severityがERRORであるログエントリに絞り込まれます。

いずれかのエントリを選択して詳細を表示します。これで、開発者が誤って本番環境にプッシュした 無効なAPIトークン の使用によってエラーがどのように発生したかを確認できます。

おめでとうございます。これで、このAPMワークショップは完了です。

OpenTelemetry Collectorをインストールする

1. はじめに

OpenTelemetry Collectorは、インフラストラクチャーとアプリケーションを計装するためのコアコンポーネントです。 その役割は収集と送信です：

• インフラストラクチャーのメトリクス（ディスク、CPU、メモリなど）
• アプリケーションパフォーマンスモニタリング（APM）のトレース情報
• プロファイリングに関するデータ
• ホストおよびアプリケーションのログ

Splunk Observability Cloudでは、インフラストラクチャーとアプリケーションの両方で Collector のセットアップを案内するウィザードを提供しています。デフォルトでは、ウィザードはコレクターのインストールのみを行うコマンドのみを提供します。

2. 環境変数を設定する

すでに Splunk IM ワークショップを終了している場合は、既存の環境変数を利用することができます。そうでない場合は、ACCESS_TOKENとREALMの環境変数を設定して、OpenTelemetry Collectorのインストールコマンドを実行していきます。

例えば、Realmが us1 の場合、export REALM=us1 と入力し、eu0 の場合は export REALM=eu0 と入力します。

export ACCESS_TOKEN="<replace_with_O11y-Workshop-ACCESS_TOKEN>"

export REALM="<replace_with_REALM>"

helm delete splunk-otel-collector

3. OpenTelemetry Collectorをインストールする

次に、Collectorをインストールします。インストールスクリプトに渡される追加のパラメータは --deployment-environment です。

curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \
sudo sh /tmp/splunk-otel-collector.sh --deployment-environment $(hostname)-petclinic --realm $REALM -- $ACCESS_TOKEN

sudo sed -i 's/gcp, ecs, ec2, azure, system/system, gcp, ecs, ec2, azure/g' /etc/otel/collector/agent_config.yaml

sudo systemctl restart splunk-otel-collector

インストールが完了したら、Splunk Observabilityの Hosts with agent installed ダッシュボードに移動して、Dashboards → Hosts with agent installed からホストのデータを確認してみましょう。

ダッシュボードのフィルタを使用して host.nameを選択し、仮想マシンのホスト名を入力または選択します。ホストのデータが表示されたら、APMコンポーネントを使用する準備が整いました。

OpenTelemetry Javaエージェントをインストールする

1. Spring PetClinic アプリケーションを動かす

APMをセットアップするためにまず必要なのは…そう、アプリケーションです！この演習では、Spring PetClinicアプリケーションを使用します。これはSpringフレームワーク（Spring Boot）で作られた、非常に人気のあるサンプルJavaアプリケーションです。

まずはPetClinicリポジトリをクローンし、そして、アプリケーションをコンパイル、ビルド、パッケージ、テストしていきます。

git clone https://github.com/spring-projects/spring-petclinic

spring-petclinic ディレクトリに移動します:

cd spring-petclinic

PetClinic が使用する MySQL データベースを起動します:

docker run -d -e MYSQL_USER=petclinic -e MYSQL_PASSWORD=petclinic -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=petclinic -p 3306:3306 docker.io/biarms/mysql:5.7

そして、Splunk版のOpenTelemetry Java APMエージェントをダウンロードしておきましょう。

curl -L https://github.com/signalfx/splunk-otel-java/releases/latest/download/splunk-otel-javaagent.jar \
-o splunk-otel-javaagent.jar

次に、mavenコマンドを実行してPetClinicをコンパイル/ビルド/パッケージ化します:

./mvnw package -Dmaven.test.skip=true

そして、以下のコマンドでアプリケーションを実行することができます:

java -javaagent:./splunk-otel-javaagent.jar \
-Dserver.port=8083 \
-Dotel.service.name=$(hostname).service \
-Dotel.resource.attributes=deployment.environment=$(hostname),version=0.314 \
-Dsplunk.profiler.enabled=true \
-Dsplunk.profiler.memory.enabled=true \
-Dsplunk.metrics.enabled=true \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

アプリケーションが動作しているかどうかは、http://<VM_IP_ADDRESS>:8083 にアクセスして確認することができます。 次に、トラフィックを生成し、クリックしまくり、エラーを生成し、ペットを追加するなどしてください。

• -Dotel.service.name=$(hostname).service では、アプリケーションの名前を定義しています。サービスマップ上のアプリケーションの名前等に反映されます。
• -Dotel.resource.attributes=deployment.environment=$(hostname),version=0.314 では、Environmentと、versionを定義しています。
  • deployment.environment=$(hostname) は、Splunk APM UIの上部「Environment」に反映されます。
  • version=0.314 はここでは、アプリケーションのバージョンを示しています。トレースをドリルダウンしたり、サービスマップの Breakdown の機能で分析したり、Tag Spotlightを開くと version 毎のパフォーマンス分析が使えます。
• -Dsplunk.profiler.enabled=true および splunk.profiler.memory.enabled=true では、CPUとメモリのプロファイリングを有効にしています。Splunk APM UIから、AlwaysOn Profilingを開いてみてください。
• -Dsplunk.metrics.enabled=true では、メモリやスレッドなどJVMメトリクスの送信を有効にしています。Dashboardsから、APM java servicesを開いてみてください。

その後、Splunk APM UIにアクセスして、それぞれのテレメトリーデータを確認してみましょう！

次のセクションではカスタム計装を追加して、OpenTelemetryでは何ができるのか、さらに見ていきます。

マニュアル計装

1. 依存ライブラリを追加する

前のセクション足したような、プロセス全体に渡る属性は便利なのですが、ときにはさらに、リクエストの内容に応じた状況を知りたくなるかもしれません。 心配ありません、OpenTelemetryのAPIを通じてそれらを計装し、データを送り、Splunk Observabilityで分析できるようになります。

最初に、JavaアプリケーションがOpenTelemetryのAPIを使えるように、ライブラリの依存を追加していきます。 もちろん、vimなどのお好みのエディタをお使い頂いても大丈夫です！

アプリケーションが起動中であれば、一旦停止しましょう。ターミナルで Ctrl-c を押すと、停止することができます。

nano pom.xml

そして、<dependencies> セクションの中（33行目）に↓を追加してください。 ファイル修正後、 ctrl-O のあとに Enter で、ファイルを保存します。次に ctrl-X で、nanoを終了します。

    <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-api</artifactId>
    </dependency>

念のため、コンパイルできるか確かめてみましょう:

./mvnw package -Dmaven.test.skip=true

git checkout pom.xml

これで、JavaのアプリケーションでOpenTelemetryのAPIが使う準備ができました。

2. Javaのコードにマニュアル計装を追加する

では、アプリケーションコードをちょっと変更して、リクエストのコンテキストのデータをスパン属性に追加してみましょう。

ここでは Pet Clinic アプリケーションの中で Find Owners が使われたときに、どのような検索文字列が指定されたのかを調査できるようにしていきます。 検索条件によってパフォーマンスが劣化してしまうケース、よくありませんか？そんなときは OwnerController に計装を追加していきましょう！

nano src/main/java/org/springframework/samples/petclinic/owner/OwnerController.java

このコードを 変更するのは2箇所 です。

まず、import jakarta.validation.Valid; の下、37行目付近に↓を足します:

import io.opentelemetry.api.trace.Span;

次に、 // find owners by last name のコメントがある箇所（おそらく95行目付近にあります）の下に、次のコードを足していきましょう:

                Span span = Span.current();
                span.setAttribute("lastName", owner.getLastName());

このコードで、Last Nameとして指定された検索条件が、スパン属性 lastName としてSplunk Observabilityに伝えるようになりました。

アプリケーションをコンパイルし直ししますが、Javaコードを多少汚してしまったかもしれません。 spring-javaformat:apply を指定しながらコンパイルしてみましょう。

./mvnw spring-javaformat:apply package -Dmaven.test.skip=true

アプリケーションを起動します。せっかくなので、バージョンを一つあげて version=0.315 としましょう。

java -javaagent:./splunk-otel-javaagent.jar \
-Dserver.port=8083 \
-Dotel.service.name=$(hostname).service \
-Dotel.resource.attributes=deployment.environment=$(hostname),version=0.315 \
-Dsplunk.profiler.enabled=true \
-Dsplunk.profiler.memory.enabled=true \
-Dsplunk.metrics.enabled=true \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

http://<VM_IP_ADDRESS>:8083 にアクセスして、オーナー検索をいくつか試してましょう。そしてSplunk APM UIからExploreを開き、アプリケーションのトレースを見ていきます。

検証が完了したら、ターミナルで Ctrl-c を押すと、アプリケーションを停止することができます。

次のセクションでは、RUMを使ってブラウザ上のパフォーマンスデータを収集してみましょう。

Real User Monitoring

1. RUMを有効にする

Real User Monitoring (RUM)計装のために、Open Telemetry Javascript https://github.com/signalfx/splunk-otel-js-web スニペットをページ内に追加します。再度ウィザードを使用します Data Management → Add Integrationボタン → Monitor user experience（画面上部タブ） → Browser Instrumentationを開きます。

ドロップダウンから設定済みの RUM ACCESS TOKEN を選択し、Next をクリックします。以下の構文で App name とEnvironment を入力します：

次に、ワークショップのRUMトークンを選択し、 App nameとEnvironmentを定義します。ウィザードでは、ページ上部の <head> セクションに配置する必要のある HTML コードの断片が表示されます。この例では、次のように記述していますが、ウィザードでは先程入力した値が反映されてるはずです。

• Application Name: <hostname>-petclinic-service
• Environment: <hostname>-petclinic-env

ウィザードで編集済みコードスニペットをコピーするか、以下のスニペットをコピーして適宜編集してください。ただし：

• [hostname]-petclinic-service - [hostname] をお使いのホスト名に書き換えてください
• [hostname]-petclinic-env - [hostname] をお使いのホスト名に書き換えてください

  <script src="https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web.js" crossorigin="anonymous"></script>
  <script>
  SplunkRum.init({
      beaconUrl: "https://rum-ingest.<REALM>.signalfx.com/v1/rum",
      rumAuth: "<RUM_ACCESS_TOKEN>",
      app: "<hostname>.service",
      environment: "<hostname>"
    });
  </script>

Spring PetClinicアプリケーションでは、1つのHTMLページを「レイアウト」ページとして使用し、アプリケーションのすべてのページで再利用しています。これは、Splunk RUM計装ライブラリを挿入するのに最適な場所であり、すべてのページで自動的に読み込まれます。

では、レイアウトページを編集してみましょう：

nano src/main/resources/templates/fragments/layout.html

そして、上で生成したスニップをページの <head> セクションに挿入してみましょう。さて、アプリケーションを再構築して、再び実行する必要があります。

2. PetClinicを再ビルドする

mavenコマンドを実行して、PetClinicをコンパイル/ビルド/パッケージ化します：

./mvnw package -Dmaven.test.skip=true

そして、アプリケーションを動かしてみましょう。バージョンを version=0.316 とするのをお忘れなく。

java -javaagent:./splunk-otel-javaagent.jar \
-Dserver.port=8083 \
-Dotel.service.name=$(hostname).service \
-Dotel.resource.attributes=deployment.environment=$(hostname),version=0.316 \
-Dsplunk.profiler.enabled=true \
-Dsplunk.profiler.memory.enabled=true \
-Dsplunk.metrics.enabled=true \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

次に、より多くのトラフィックを生成するために、アプリケーションに再度アクセスしてみましょう。 http://<VM_IP_ADDRESS>:8083 にアクセスすると、今度はRUMトレースが報告されるはずです。

RUMにアクセスして、トレースとメトリクスのいくつかを見てみましょう。左のメニューから RUM を選ぶと、Spring Pet Clinicでのユーザー（あなたです！）が体験したパフォーマンスが表示されます。

Log Observer

このセクションでは、Spring PetClinicアプリケーションをファイルシステムのファイルにログを書き込むように設定し、 Splunk OpenTelemetry Collectorがそのログファイルを読み取り（tail）、Splunk Observability Platformに情報を報告するように設定していきます。

1. FluentDの設定

Splunk OpenTelemetry Collectorを、Spring PetClinicのログファイルをtailし Splunk Observability Cloudエンドポイントにデータを報告するように設定する必要があります。

Splunk OpenTelemetry Collectorは、FluentDを使用してログの取得/報告を行い、 Spring PetClinicのログを報告するための適切な設定を行うには、 デフォルトディレクトリ（/etc/otel/collector/fluentd/conf.d/）にFluentDの設定ファイルを追加するだけです。

以下は、サンプルのFluentD設定ファイル petclinic.conf を新たに作成し、

sudo nano /etc/otel/collector/fluentd/conf.d/petclinic.conf

ファイル /tmp/spring-petclinic.logを読み取るよう設定を記述します。

<source>
  @type tail
  @label @SPLUNK
  tag petclinic.app
  path /tmp/spring-petclinic.log
  pos_file /tmp/spring-petclinic.pos_file
  read_from_head false
  <parse>
    @type none
  </parse>
</source>

このとき、ファイル petclinic.conf のアクセス権と所有権を変更する必要があります。

sudo chown td-agent:td-agent /etc/otel/collector/fluentd/conf.d/petclinic.conf
sudo chmod 755 /etc/otel/collector/fluentd/conf.d/petclinic.conf

ファイルが作成されたら、FluentDプロセスを再起動しましょう。

sudo systemctl restart td-agent

3. Logbackの設定

Spring Pet Clinicアプリケーションは、いくつかのJavaログライブラリを使用することができます。 このシナリオでは、logbackを使ってみましょう。

リソースフォルダに logback.xml という名前のファイルを作成して…

nano src/main/resources/logback.xml

以下の設定を保存しましょう:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xml>
<configuration scan="true" scanPeriod="30 seconds">
  <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
      <resetJUL>true</resetJUL>
  </contextListener>
  <logger name="org.springframework.samples.petclinic" level="debug"/>
  <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>/tmp/spring-petclinic.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>springLogFile.%d{yyyy-MM-dd}.log</fileNamePattern>
      <maxHistory>5</maxHistory>
      <totalSizeCap>1GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
      <pattern>
      %d{yyyy-MM-dd HH:mm:ss} - %logger{36} - %msg trace_id=%X{trace_id} span_id=%X{span_id} trace_flags=%X{trace_flags} service.name=%property{otel.resource.service.name}, deployment.environment=%property{otel.resource.deployment.environment} %n
      </pattern>
    </encoder>
  </appender>
  <root level="debug">
    <appender-ref ref="file" />
  </root>
</configuration>

その後、アプリケーションを再構築して再度実行していきます。

./mvnw package -Dmaven.test.skip=true

java -javaagent:./splunk-otel-javaagent.jar \
-Dserver.port=8083 \
-Dotel.service.name=$(hostname).service \
-Dotel.resource.attributes=deployment.environment=$(hostname),version=0.317 \
-Dsplunk.profiler.enabled=true \
-Dsplunk.profiler.memory.enabled=true \
-Dsplunk.metrics.enabled=true \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

これまで通り、アプリケーション http://<VM_IP_ADDRESS>:8083 にアクセスしてトラフィックを生成すると、ログメッセージが報告されるようになります。

左側のLog Observerアイコンをクリックして、ホストとSpring PetClinicアプリケーションからのログメッセージのみを選択するためのフィルタを追加できます。

1. Add Filter → Field → host.name → <あなたのホスト名>
2. Add Filter → Field → service.name → <あなたのホスト名>.service

4. まとめ

これでワークショップは終了です。 これまでに、Splunk Observability Cloudにメトリクス、トレース、ログ、データベースクエリのパフォーマンス、コードプロファイリングが報告されるようになりました。 おめでとうございます！

OpenTelemetry Collector Contrib をインストールする

OpenTelemetry Collector の Contrib ディストリビューションをダウンロードする

OpenTelemetry Collector のインストールのために、まずはダウンロードするのが最初のステップです。このラボでは、 wget コマンドを使って OpenTelemetry の GitHub リポジトリから .deb パッケージをダウンロードしていきます。

OpenTelemetry Collector Contrib releases page から、ご利用のプラットフォーム用の .deb パッケージを入手してください。

wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.80.0/otelcol-contrib_0.80.0_linux_amd64.deb

OpenTelemetry Collector の Contrib ディストリビューションをインストールする

dpkg を使って、 .deb パッケージをインストールします。下記の dpkg Output のようになれば、インストールは成功です！