はじめに

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 スクリーンで継続的に表示するヘルスダッシュボードを作成しました：

OpenTelemetry Collector のインストール

Splunk OpenTelemetry Collector は、インフラストラクチャとアプリケーションの計装における中核コンポーネントです。その役割は以下のデータを収集して送信することです：

• インフラストラクチャメトリクス（ディスク、CPU、メモリなど）
• Application Performance Monitoring (APM) トレース
• プロファイリングデータ
• ホストおよびアプリケーションのログ

helm delete splunk-otel-collector

curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh
sudo sh /tmp/splunk-otel-collector.sh --uninstall

インスタンスが正しく設定されていることを確認するために、このワークショップに必要な環境変数が正しく設定されているか確認する必要があります。ターミナルで以下のコマンドを実行してください：

. ~/workshop/petclinic/scripts/check_env.sh

出力で、以下のすべての環境変数が存在し、値が設定されていることを確認してください。不足している場合は、インストラクターに連絡してください：

ACCESS_TOKEN
REALM
RUM_TOKEN
HEC_TOKEN
HEC_URL
INSTANCE

これで Collector のインストールに進むことができます。インストールスクリプトには、いくつかの追加パラメータが渡されます：

• --with-instrumentation - Splunk ディストリビューションの OpenTelemetry Java からエージェントをインストールします。これにより、PetClinic Java アプリケーションの起動時に自動的にロードされます。設定は不要です！
• --deployment-environment - リソース属性 deployment.environment を指定された値に設定します。これは UI でビューをフィルタリングするために使用されます。
• --enable-profiler - Java アプリケーションのプロファイラを有効にします。これによりアプリケーションの CPU プロファイルが生成されます。
• --enable-profiler-memory - Java アプリケーションのプロファイラを有効にします。これによりアプリケーションのメモリプロファイルが生成されます。
• --enable-metrics - Micrometer メトリクスのエクスポートを有効にします
• --hec-token - Collector が使用する HEC トークンを設定します
• --hec-url - Collector が使用する HEC URL を設定します

curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \
sudo sh /tmp/splunk-otel-collector.sh --realm $REALM -- $ACCESS_TOKEN --mode agent --without-fluentd --with-instrumentation --deployment-environment $INSTANCE-petclinic --enable-profiler --enable-profiler-memory --enable-metrics --hec-token $HEC_TOKEN --hec-url $HEC_URL

次に、Collector にパッチを適用して、AWS インスタンス ID ではなくインスタンスのホスト名を公開するようにします。これにより、UI でのデータのフィルタリングが容易になります：

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

agent_config.yaml にパッチを適用したら、Collector を再起動する必要があります：

sudo systemctl restart splunk-otel-collector

インストールが完了したら、Hosts with agent installed ダッシュボードに移動して、ホストからのデータを確認できます。Dashboards → Hosts with agent installed の順に移動してください。

ダッシュボードフィルタを使用して host.name を選択し、ワークショップインスタンスのホスト名を入力または選択してください（これはターミナルセッションのコマンドプロンプトから取得できます）。ホストのデータが流れていることを確認したら、APM コンポーネントの作業を開始する準備が整いました。

Spring PetClinic アプリケーションのビルド

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

まず、PetClinic の GitHub リポジトリをクローンし、その後アプリケーションのコンパイル、ビルド、パッケージ化、テストを行います：

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

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

cd spring-petclinic
git checkout b26f235250627a235a2974a22f2317dbef27338d

Docker を使用して、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

次に、PetClinic アプリケーションにシンプルなトラフィックを生成する Locust を実行する別のコンテナを起動します。Locust は、Web アプリケーションにトラフィックを生成するために使用できるシンプルな負荷テストツールです。

docker run --network="host" -d -p 8090:8090 -v ~/workshop/petclinic:/mnt/locust docker.io/locustio/locust -f /mnt/locust/locustfile.py --headless -u 1 -r 1 -H http://127.0.0.1:8083

次に、maven を使用して PetClinic をコンパイル、ビルド、パッケージ化します：

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

ビルドが完了したら、実行しているインスタンスのパブリック IP アドレスを取得する必要があります。以下のコマンドを実行して取得できます：

curl http://ifconfig.me

IP アドレスが返されます。アプリケーションが実行されていることを確認するために必要になるので、この IP アドレスをメモしておいてください。

3. Real User Monitoring

Real User Monitoring (RUM) の計装では、ページに OpenTelemetry Javascript スニペット https://github.com/signalfx/splunk-otel-js-web を追加します。ウィザードを使用して Data Management → Add Integration → RUM Instrumentation → Browser Instrumentation の順に進みます。

インストラクターがドロップダウンから使用するトークンを指示します。Next をクリックしてください。以下の形式で App name と Environment を入力します：

• <INSTANCE>-petclinic-service - <INSTANCE> を先ほどメモした値に置き換えてください。
• <INSTANCE>-petclinic-env - <INSTANCE> を先ほどメモした値に置き換えてください。

ウィザードは、ページの <head> セクションの先頭に配置する必要がある HTML コードスニペットを表示します。以下は例です（このスニペットは使用せず、ウィザードが生成したものを使用してください）：

/*

IMPORTANT: Replace the <version> placeholder in the src URL with a
version from https://github.com/signalfx/splunk-otel-js-web/releases

*/
<script src="https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web.js" crossorigin="anonymous"></script>
<script>
    SplunkRum.init({
        realm: "eu0",
        rumAccessToken: "<redacted>",
        applicationName: "petclinic-1be0-petclinic-service",
        deploymentEnvironment: "petclinic-1be0-petclinic-env"
    });
</script>

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

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

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

次に、上記で生成したスニペットをページの <head> セクションに挿入します。コメントは含めず、ソース URL の <version> を latest に置き換えてください：

<!doctype html>
<html th:fragment="layout (template, menu)">

<head>
<script src="https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web.js" crossorigin="anonymous"></script>
<script>
    SplunkRum.init({
        realm: "eu0",
        rumAccessToken: "<redacted>",
        applicationName: "petclinic-1be0-petclinic-service",
        deploymentEnvironment: "petclinic-1be0-petclinic-env"
    });
</script>
...

コード変更が完了したら、アプリケーションを再ビルドして再度実行する必要があります。maven コマンドを実行して PetClinic をコンパイル/ビルド/パッケージ化します：

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

java \
-Dserver.port=8083 \
-Dotel.service.name=$INSTANCE-petclinic-service \
-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

次に、ブラウザを使用してアプリケーション http://<IP_ADDRESS>:8083 にアクセスし、実際のユーザートラフィックを生成します。

RUM で、上記の RUM スニペットで定義された環境にフィルタリングし、ダッシュボードをクリックして開きます。

RUM トレースをドリルダウンすると、スパン内に APM へのリンクが表示されます。トレース ID をクリックすると、現在の RUM トレースに対応する APM トレースに移動します。

Java 向け自動ディスカバリーおよび設定

以下のコマンドでアプリケーションを起動できます。mysql プロファイルをアプリケーションに渡していることに注目してください。これにより、先ほど起動した MySQL データベースを使用するようアプリケーションに指示します。また、otel.service.name と otel.resource.attributes をインスタンス名を使用した論理名に設定しています。これらは UI でのフィルタリングにも使用されます：

java \
-Dserver.port=8083 \
-Dotel.service.name=$INSTANCE-petclinic-service \
-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

http://<IP_ADDRESS>:8083（<IP_ADDRESS> を先ほど取得した IP アドレスに置き換えてください）にアクセスして、アプリケーションが実行されていることを確認できます。

Collector をインストールした際、AlwaysOn Profiling と Metrics を有効にするように設定しました。これにより、Collector はアプリケーションの CPU およびメモリプロファイルを自動的に生成し、Splunk Observability Cloud に送信します。

PetClinic アプリケーションを起動すると、Collector がアプリケーションを自動的に検出し、トレースとプロファイリングのために計装するのが確認できます。

Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/lib/splunk-instrumentation/splunk-otel-javaagent.jar
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
[otel.javaagent 2024-08-20 11:35:58:970 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-2.6.0-otel-2.6.0
[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration:
[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -                  splunk.profiler.enabled : true
[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -                splunk.profiler.directory : /tmp
[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -       splunk.profiler.recording.duration : 20s
[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -               splunk.profiler.keep-files : false
[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -            splunk.profiler.logs-endpoint : null
[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -              otel.exporter.otlp.endpoint : null
[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -           splunk.profiler.memory.enabled : true
[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -        splunk.profiler.memory.event.rate : 150/s
[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -      splunk.profiler.call.stack.interval : PT10S
[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -  splunk.profiler.include.internal.stacks : false
[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -      splunk.profiler.tracing.stacks.only : false
[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active.

Splunk APM UI にアクセスして、アプリケーションコンポーネント、トレース、プロファイリング、DB Query パフォーマンス、メトリクスを確認できます。左側のメニューから APM をクリックし、Environment ドロップダウンをクリックして、ご自身の環境（例：<INSTANCE>-petclinic、<INSTANCE> は先ほどメモした値に置き換えてください）を選択します。

検証が完了したら、Ctrl-c を押してアプリケーションを停止できます。

リソース属性は、報告されるすべてのスパンに追加できます。例えば version=0.314 のように指定します。カンマ区切りのリソース属性リストも定義できます（例：key1=val1,key2=val2）。

新しいリソース属性を使用して PetClinic を再度起動しましょう。実行コマンドにリソース属性を追加すると、Collector のインストール時に定義された内容が上書きされることに注意してください。新しいリソース属性 version=0.314 を追加しましょう：

java \
-Dserver.port=8083 \
-Dotel.service.name=$INSTANCE-petclinic-service \
-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \
-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql

Splunk APM UI に戻り、最近のトレースをドリルダウンすると、スパン内に新しい version 属性が表示されます。

4. Log Observer

Splunk Log Observer コンポーネントでは、Splunk OpenTelemetry Collector が Spring PetClinic アプリケーションからログを自動的に収集し、OTLP エクスポーターを使用して Splunk Observability Cloud に送信します。その際、ログイベントに trace_id、span_id、トレースフラグを付与します。

Log Observer は、アプリケーションとインフラストラクチャからのログをリアルタイムで表示します。ログの検索、フィルタリング、分析を行って、問題のトラブルシューティングや環境の監視が可能です。

PetClinic Web アプリケーションに戻り、Error リンクを数回クリックしてください。これにより、PetClinic アプリケーションログにいくつかのログメッセージが生成されます。

左側のメニューから Log Observer をクリックし、Index が splunk4rookies-workshop に設定されていることを確認してください。

次に、Add Filter をクリックし、フィールド service.name を検索して、値 <INSTANCE>-petclinic-service を選択し、=（include）をクリックします。これで、PetClinic アプリケーションからのログメッセージのみが表示されるはずです。

PetClinic アプリケーションの Error リンクをクリックして生成されたログエントリの1つを選択してください。ログメッセージと、ログメッセージに自動的にインジェクションされたトレースメタデータが表示されます。また、APM と Infrastructure の Related Content が利用可能であることにも注目してください。

これでワークショップは終了です。多くの内容をカバーしました。この時点で、メトリクス、トレース（APM と RUM）、ログ、データベースクエリパフォーマンス、コードプロファイリングが Splunk Observability Cloud に報告されているはずです。しかも、PetClinic アプリケーションのコードを変更することなく実現できました（RUM を除く）。

おめでとうございます！

アーキテクチャ

Spring PetClinic Java アプリケーションは、フロントエンドとバックエンドのサービスで構成されるシンプルなマイクロサービスアプリケーションです。フロントエンドサービスは、バックエンドサービスと対話するための Web インターフェースを提供する Spring Boot アプリケーションです。バックエンドサービスは、MySQL データベースと対話するための RESTful API を提供する Spring Boot アプリケーションです。

このワークショップを終えるころには、Kubernetes で実行される Java ベースのアプリケーション向けの自動ディスカバリーおよび設定を有効にする方法をより深く理解できるようになります。

以下の図は、Splunk OpenTelemetry Operator と自動ディスカバリーおよび設定を有効にした状態で Kubernetes 上で実行される Spring PetClinic Java アプリケーションのアーキテクチャを詳しく示しています。

Josh Voravong が作成したサンプルに基づいています。

ワークショップインスタンスの準備

インストラクターが、このワークショップで使用するインスタンスのログイン情報を提供します。

インスタンスに初めてログインすると、以下のような Splunk ロゴが表示されます。ワークショップインスタンスへの接続に問題がある場合は、インストラクターにお問い合わせください。

$ ssh -p 2222 splunk@<IP-ADDRESS>

███████╗██████╗ ██╗     ██╗   ██╗███╗   ██╗██╗  ██╗    ██╗
██╔════╝██╔══██╗██║     ██║   ██║████╗  ██║██║ ██╔╝    ╚██╗
███████╗██████╔╝██║     ██║   ██║██╔██╗ ██║█████╔╝      ╚██╗
╚════██║██╔═══╝ ██║     ██║   ██║██║╚██╗██║██╔═██╗      ██╔╝
███████║██║     ███████╗╚██████╔╝██║ ╚████║██║  ██╗    ██╔╝
╚══════╝╚═╝     ╚══════╝ ╚═════╝ ╚═╝  ╚═══╝╚═╝  ╚═╝    ╚═╝
Last login: Mon Feb  5 11:04:54 2024 from [Redacted]
splunk@show-no-config-i-0d1b29d967cb2e6ff ~ $

インスタンスが正しく設定されていることを確認するために、このワークショップに必要な環境変数が正しく設定されているか確認する必要があります。ターミナルで以下のスクリプトを実行し、環境変数が存在し、実際の有効な値が設定されていることを確認してください：

. ~/workshop/petclinic/scripts/check_env.sh

ACCESS_TOKEN = <redacted>
REALM = <e.g. eu0, us1, us2, jp0, au0 etc.>
RUM_TOKEN = <redacted>
HEC_TOKEN = <redacted>
HEC_URL = https://<...>/services/collector/event
INSTANCE = <instance_name>

INSTANCE 環境変数の値をメモしておいてください。後で Splunk Observability Cloud でデータをフィルタリングする際に使用します。

このワークショップでは、上記の環境変数がすべて必要です。値が不足しているものがある場合は、インストラクターに連絡してください。

helm delete splunk-otel-collector

Kubernetes クラスターメトリクスの確認

インストールが完了したら、Splunk Observability Cloud にログインして、Kubernetes クラスターからメトリクスが流れてきていることを確認できます。

左側のメニューから Infrastructure をクリックし、Kubernetes を選択してから、Kubernetes nodes タイルを選択します。

Kubernetes nodes の概要画面に入ったら、Time フィルタを -1h から過去15分 (-15m) に変更して最新のデータに焦点を当て、次に Table を選択してメトリクスを報告しているすべてのノードをリスト表示します。

次に、Refine by: パネルで Cluster name を選択し、リストからご自身のクラスターを選択します。

これにより、ご自身のクラスターのノードのみを表示するようにリストがフィルタリングされます。

K8s node logs ビューに切り替えて、ノードからのログを確認します。

APMの自動検出と設定のセットアップ

このセクションでは、Kubernetes 上で実行されている Java サービスに対して自動検出と設定を有効化します。これにより、OpenTelemetry Collector が Pod アノテーションを検索し、Java アプリケーションに Splunk OpenTelemetry Java エージェントで計装を行う必要があることを示します。これにより、クラスター上で実行されている Java サービスからトレース、スパン、およびプロファイリングデータを取得できるようになります。

Java アプリケーションの場合、OpenTelemetry Collector はinstrumentation.opentelemetry.io/inject-javaというアノテーションを検索します。

このアノテーションの値はtrueに設定するか、OpenTelemetry Collector のnamespace/daemonset（例：default/splunk-otel-collector）に設定できます。これにより、名前空間をまたいで動作することができ、このワークショップではこれを使用します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: admin-server
  labels:
    app.kubernetes.io/part-of: spring-petclinic
spec:
  selector:
    matchLabels:
      app: admin-server
  template:
    metadata:
      labels:
        app: admin-server
      annotations:
        instrumentation.opentelemetry.io/inject-java: "default/splunk-otel-collector"

APM Features

前のセクションで見てきたように、サービスで自動検出と設定を有効にすると、トレースがSplunk Observability Cloudに送信されます。

これらのトレースにより、Splunkは自動的にService MapsとRED Metricsを生成します。これらは、サービスの動作とサービス間の相互作用を理解するための最初のステップです。

次のセクションでは、トレース自体と、コードに触れることなくサービスの動作を理解するのに役立つ情報を詳しく見ていきます。

Always-On Profiling & DB Query Performance

前の章で見てきたように、APMを使用して、コードに触れることなく、さまざまなサービス間のインタラクションをトレースすることができ、問題をより迅速に特定できます。

トレーシングに加えて、automatic discovery and configurationは、問題をさらに迅速に発見するのに役立つ追加機能を最初から提供します。このセクションでは、そのうちの2つを見ていきます：

• Always-on Profiling and Java Metrics
• Database Query Performance

Always-on ProfilingまたはDatabase Query Performanceについてさらに深く学びたい場合は、Debug Problems in Microservicesという別のNinja Workshopがありますので、そちらをご覧ください。

Log Observer

この時点まで、コード変更は一切なく、トレーシング、プロファイリング、データベースクエリパフォーマンスのデータが Splunk Observability Cloud に送信されています。

次に、Splunk Log Observer を使用して Spring PetClinic アプリケーションからログデータを取得します。

Splunk OpenTelemetry Collector は、Spring PetClinic アプリケーションからログを自動的に収集し、OTLP エクスポーターを使用して Splunk Observability Cloud に送信します。その際、ログイベントには trace_id、span_id、トレースフラグが付与されます。

Splunk Log Observer を使用してログを表示し、ログ情報をサービスやトレースと自動的に関連付けます。

この機能は Related Content と呼ばれています。

Real User Monitoring

アプリケーションに Real User Monitoring (RUM) インストルメンテーションを有効にするには、コードベースに Open Telemetry Javascript https://github.com/signalfx/splunk-otel-js-web スニペットを追加する必要があります。

Spring PetClinic アプリケーションは、アプリケーションのすべてのビューで再利用される単一の index HTML ページを使用しています。これは、Splunk RUM インストルメンテーションライブラリを挿入するのに最適な場所です。すべてのページで自動的に読み込まれるためです。

api-gateway サービスはすでにインストルメンテーションを実行しており、RUM トレースを Splunk Observability Cloud に送信しています。次のセクションでデータを確認します。

スニペットを確認したい場合は、ブラウザでページを右クリックして View Page Source を選択することで、ページソースを表示できます。

    <script src="/env.js"></script>
    <script src="https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web.js" crossorigin="anonymous"></script>
    <script src="https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web-session-recorder.js" crossorigin="anonymous"></script>
    <script>
        var realm = env.RUM_REALM;
        console.log('Realm:', realm);
        var auth = env.RUM_AUTH;
        var appName = env.RUM_APP_NAME;
        var environmentName = env.RUM_ENVIRONMENT
        if (realm && auth) {
            SplunkRum.init({
                realm: realm,
                rumAccessToken: auth,
                applicationName: appName,
                deploymentEnvironment: environmentName,
                version: '1.0.0',
            });

            SplunkSessionRecorder.init({
                applicationName: appName,
                realm: realm,
                rumAccessToken: auth,
                  recorder: "splunk",
                  features: {
                    video: true,
                }
            });
            const Provider = SplunkRum.provider;
            var tracer=Provider.getTracer('appModuleLoader');
        } else {
        // Realm or auth is empty, provide default values or skip initialization
        console.log("Realm or auth is empty. Skipping Splunk Rum initialization.");
        }
    </script>
     <!-- Section added for  RUM -->

Workshop Wrap-up 🎁

おめでとうございます。Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry ワークショップを完了しました。

今日、既存の Kubernetes 上の Java アプリケーションにトレース、コードプロファイリング、データベースクエリパフォーマンスを追加することがいかに簡単かを学びました。

Automatic Discovery and Configuration を使用して、コードや設定に一切触れることなく、アプリケーションとインフラストラクチャの可観測性を即座に向上させました。

また、シンプルな設定変更により、さらに多くの可観測性 (logging や RUM) をアプリケーションに追加して、エンドツーエンドの可観測性を提供できることも学びました。

OpenTelemetry Collector Contrib のインストール

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

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

お使いのプラットフォーム用の .deb パッケージを OpenTelemetry Collector Contrib リリースページ から取得します。

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

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

dpkg を使用して .deb パッケージをインストールします。インストールが成功した場合の出力例は、下の dpkg Output タブを確認してください

sudo dpkg -i otelcol-contrib_0.111.0_linux_amd64.deb

Selecting previously unselected package otelcol-contrib.
(Reading database ... 89232 files and directories currently installed.)
Preparing to unpack otelcol-contrib_0.111.0_linux_amd64.deb ...
Unpacking otelcol-contrib (0.111.0) ...
Setting up otelcol-contrib (0.111.0) ...
Created symlink /etc/systemd/system/multi-user.target.wants/otelcol-contrib.service → /lib/systemd/system/otelcol-contrib.service.

OpenTelemetry Collector Extensions

OpenTelemetry Collector がインストールできたので、OpenTelemetry Collector の拡張機能について見ていきましょう。拡張機能はオプションであり、主にテレメトリデータの処理を伴わないタスクに使用されます。拡張機能の例としては、ヘルスモニタリング、サービスディスカバリ、データ転送などがあります。

%%{
  init:{
    "theme": "base",
    "themeVariables": {
      "primaryColor": "#ffffff",
      "clusterBkg": "#eff2fb",
      "defaultLinkColor": "#333333"
    }
  }
}%%

flowchart LR;
    style E fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
    subgraph Collector
    A[OTLP] --> M(Receivers)
    B[JAEGER] --> M(Receivers)
    C[Prometheus] --> M(Receivers)
    end
    subgraph Processors
    M(Receivers) --> H(Filters, Attributes, etc)
    E(Extensions)
    end
    subgraph Exporters
    H(Filters, Attributes, etc) --> S(OTLP)
    H(Filters, Attributes, etc) --> T(JAEGER)
    H(Filters, Attributes, etc) --> U(Prometheus)
    end

OpenTelemetry Collector Receivers

ワークショップの Receiver セクションへようこそ！ここは OpenTelemetry Collector のデータパイプラインの出発点です。早速始めましょう。

Receiver は、プッシュベースまたはプルベースであり、データを Collector に取り込む方法です。Receiver は1つ以上のデータソースをサポートできます。一般的に、Receiver は指定された形式でデータを受け取り、内部形式に変換してから、該当するパイプラインで定義された Processor と Exporter に渡します。

%%{
  init:{
    "theme":"base",
    "themeVariables": {
      "primaryColor": "#ffffff",
      "clusterBkg": "#eff2fb",
      "defaultLinkColor": "#333333"
    }
  }
}%%

flowchart LR;
    style M fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
    subgraph Collector
    A[OTLP] --> M(Receivers)
    B[JAEGER] --> M(Receivers)
    C[Prometheus] --> M(Receivers)
    end
    subgraph Processors
    M(Receivers) --> H(Filters, Attributes, etc)
    E(Extensions)
    end
    subgraph Exporters
    H(Filters, Attributes, etc) --> S(OTLP)
    H(Filters, Attributes, etc) --> T(JAEGER)
    H(Filters, Attributes, etc) --> U(Prometheus)
    end