Splunk Observability Workshops

Splunk Observabilityワークショップへようこそ

Splunk Observability Cloudの監視、分析、対応ツールを使用して、アプリケーションとインフラストラクチャをリアルタイムで把握することができます。

このワークショップでは、メトリクス、トレース、ログを取り込み、監視し、可視化し、分析するためのクラス最高のオブザーバビリティ（可観測性）プラットフォームについて説明します。

OpenTelemetry

このワークショップでOpenTelemetryをアプリケーションやインフラの分析に役立つテレメトリデータ（メトリクス、トレース、ログ）の計装、生成、収集、エクスポートに使用します。

GitHub

このドキュメントには、issueやpull requestで貢献することができます。より良いワークショップにするために、是非ご協力ください。

Twitter

SplunkのTwitterチャンネルでは、アップデート情報や興味深い読み物を紹介しています。

Splunk4Rookies ワークショップ
以下は初心者向けワークショップです。
Splunk4Ninjas Workshops
The following workshops require Ninja skills, wax on, wax off.
その他のワークショップ
Pet Clinic Java ワークショップ JavaアプリケーションをつかったSplunk Oservabilityのワークショップです OpenTelemetry Collector OpenTelemetry Collectorのコンセプトを学び、Splunk Observability Cloudにデータを送信する方法を理解しましょう。
リソース
よくある質問とその回答オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。ディメンション、プロパティ、タグディメンションとプロパティの比較で、どちらかを使うべきかというのはよく議論されます。 OpenTelemetryでのタグ付け大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、規則が遵守されるようにガバナンスプロセスを確立することが重要です。
Scenarios

Splunk4Rookies ワークショップ

Observability Cloud
このワークショップでは、Splunk Observability Cloudがフロントエンドアプリケーションからバックエンドサービスまで、ユーザー体験の視点からどのように即座に可視性を提供するかをお見せします - Splunk Observability Cloudの最も魅力的な機能と差別化要因を体験していただきます。 {class=“children children-type-tree children-sort-”}

Observability Cloud

2 minutes Authors Robert Castley & Pieter Hagen

このワークショップでは、Splunk Observability Cloudがフロントエンドアプリケーションからバックエンドサービスまで、ユーザー体験に関する即時の可視性をどのように提供するかをデモンストレーションします。他の可観測性ソリューションと一線を画す、プラットフォームの最も強力な機能をいくつか体験していただきます

インフラ監視（Infrastructure Monitoring, IM）
完全で忠実な Real User Monitoring（RUM）
Application Performance Monitoring（APM）による End to End の NoSample で完全忠実なトレースの可視性
コード入力を必要としないログクエリ
外形監視・合成監視（Synthetic Monitoring）
タグ分析とエラースタックによる根本原因分析
Related Contents によるコンポーネント間のシームレスなナビゲーション

Splunk Observability Cloudのコアとなる強みの一つは、テレメトリデータを統合し、エンドユーザーエクスペリエンスとアプリケーションスタック全体の包括的な全体像を作成する能力です。

このワークショップでは、AWS EC2インスタンス上にデプロイされたマイクロサービスベースのeコマースアプリケーションに焦点を当てます。ユーザーは商品を閲覧し、カートに商品を追加し、注文を完了できます。このアプリケーションは、詳細なパフォーマンスデータを取得するためにOpenTelemetryで計装されています。

OpenTelemetry とは？

OpenTelemetry は、メトリクス、トレース、ログなどのテレメトリデータの計装、生成、収集、エクスポートを支援するために設計されたオープンソースのツール、API、ソフトウェア開発キット（SDK）のコレクションです。このデータにより、ソフトウェアのパフォーマンスと動作の詳細な分析が可能になります。

OpenTelemetryコミュニティは急速に成長しており、Splunk、Google、Microsoft、Amazonなどの大手企業からのサポートを受けています。現在、Cloud Native Computing Foundationにおいて、Kubernetesに次いで2番目に多くのコントリビューターを抱えています。

ワークショップ概要

2 minutes

はじめに
このワークショップの目的は、Splunk Observability Cloudを使用して問題のトラブルシューティングを行い、根本原因を特定する実践的な経験を提供することです。私たちは、Kubernetes上で動作する完全に計装されたマイクロサービスベースのアプリケーションを用意しており、これがメトリクス、トレース、ログをSplunk Observability Cloudにリアルタイム分析のために送信します。

対象者
このワークショップは、Splunk Observability Cloudの実践的な知識を得たいと考えている方を対象としています。Observability Cloudを含むSplunk Platformに関する事前知識がほとんど、または全くない方向けに設計されています。

必要なもの
ノートパソコンと外部ウェブサイトにアクセスできるブラウザが必要です。ワークショップは対面またはZoomを通じて参加できます。Zoomクライアントをインストールしていない場合でも、ブラウザを使用して参加できます。

ワークショップ概要
この3時間のセッションでは、ストリーミング分析とNoSampleで完全に忠実な分散トレースを提供する唯一のプラットフォームであるSplunk Observabilityの基礎を、インタラクティブなハンズオン形式で説明します。以下が期待できる内容です

OpenTelemetry
最新のObservabilityにOpenTelemetryが不可欠である理由と、システムの可視性をどのように向上させるかを学びます。
Splunk Observability ユーザーインターフェイスツアー
Splunk Observability Cloudのインターフェイスのガイド付きツアーで、APM、RUM、Log Observer、Synthetics、Infrastructureという5つの主要コンポーネントの操作方法を紹介します。
実際のユーザーデータを生成
オンラインブティックというウェブサイトでシミュレートされた小売体験に飛び込みます。ブラウザ、モバイル、またはタブレットを使用して、サイトを探索し、メトリクス（問題はありますか？）、トレース（問題はどこにありますか？）、ログ（何が問題を引き起こしていますか？）を含む実際のユーザーデータを生成します。
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
Syntheticsがアプリケーションの24時間365日のモニタリングにどのように役立つかを発見します。オンラインブティックウェブサイトのパフォーマンスと可用性を監視するために、毎分実行される簡単な合成テストの設定方法を説明します。

このセッションを終えると、Splunk Observability Cloudの実践的な経験と、アプリケーションスタック全体の問題をトラブルシューティングして解決する方法についての確かな理解が得られるでしょう。

OpenTelemetryとは何か、なぜ重要なのか？

2 minutes

OpenTelemetry

クラウドコンピューティング、マイクロサービスアーキテクチャ、そして複雑化するビジネス要件の増加に伴い、可観測性の必要性はかつてないほど高まっています。可観測性とは、システムの出力を調査することで、そのシステムの内部状態を理解する能力です。ソフトウェアの文脈では、これはメトリクス、トレース、ログを含むテレメトリデータを調査することでシステムの内部状態を理解できることを意味します。

システムを観測可能にするには、計装が必要です。つまり、コードはトレース、メトリクス、ログを発行する必要があります。この計装データは、Splunk Observability Cloudなどの可観測性バックエンドに送信される必要があります。

メトリクス	トレース	ログ
問題がありますか？	問題はどこですか？	問題は何ですか？

OpenTelemetryは2つの重要なことを行います

独自のデータフォーマットやツールに縛られるのではなく、生成したデータを所有できるようにします。
単一のAPIセットと規約を学ぶことができます

これら2つの要素が組み合わさることで、今日の現代的なコンピューティング環境で必要な柔軟性をチームや組織に提供します。

可観測性を始めるにあたっては、重要な質問を含め多くの変数を考慮する必要があります： 「どのようにしてデータを可観測性ツールに取り込むのか？」 OpenTelemetryの業界全体での採用は、この質問に答えることをこれまで以上に容易にしています。

なぜ重要なのか？

OpenTelemetryは完全にオープンソースで無料で使用できます。過去のモニタリングや可観測性ツールは、独自のエージェントに大きく依存していたため、追加のツールを変更したり設定したりするために必要な労力は、インフラレベルからアプリケーションレベルまで、システム全体に大規模な変更を必要としていました。

OpenTelemetryはベンダー中立であり、可観測性分野の多くの業界リーダーにサポートされているため、採用者は計装にわずかな変更を加えるだけで、サポートされている可観測性ツール間をいつでも切り替えることができます。これは、Linuxのように様々なディストリビューションが設定やアドオンをバンドルしていても、基本的にはすべてがコミュニティ主導のOpenTelemetryプロジェクトに基づいているため、どのOpenTelemetryディストリビューションを使用しても変わりません。

Splunkは完全にOpenTelemetryにコミットしており、お客様があらゆる種類、あらゆる構造、あらゆるソースから、あらゆる規模で、すべてリアルタイムですべてのデータを収集して使用できるようにしています。OpenTelemetryは基本的にモニタリングの環境を変え、ITチームやDevOpsチームがすべての質問とすべてのアクションにデータをもたらすことを可能にしています。これらのワークショップでこれを体験することになります。

UI - クイックツアー 🚌

Splunk Observability Cloudの様々なコンポーネントについて簡単な説明から始めます。これはUIに慣れてもらうことを目的としています。

Splunk Observability Cloud へのサインイン
Real User Monitoring (RUM)
Application Performance Monitoring (APM)
Log Observer
Synthetics
Infrastructure Monitoring（IM）

ヒント

このワークショップを進める最も簡単な方法は以下を使用することです:

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）と右（▶️）のカーソルキー

はじめに

2 minutes

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

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

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

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

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

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

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

ホームページ

5分

Splunk Observability Cloudに登録してログインすると、ホームページ（ランディングページ）に移動します。ここでは、開始に役立ついくつかの便利な機能が見つかります。

データ探索パネル: どの統合が有効になっているかを表示し、管理者の場合は追加の統合を追加できます。
ドキュメントパネル: Splunk Observability Cloudの使用を開始するためのトレーニングビデオとドキュメントへのリンク。
最近のアクティビティパネル: 最近作成/訪問したダッシュボードやディテクターにすぐにアクセスできます。
メインメニューパネル: Splunk Observability Cloudのコンポーネントを操作します。
組織切り替え: 複数の組織のメンバーである場合は、組織間を簡単に切り替えることができます。
メインメニューの展開/縮小: スペースが限られている場合にメインメニューを展開 » / 折りたたむ « ことができます。

最初の演習から始めましょう

演習

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

ヒント

以前にSplunk Observabilityを使用したことがある場合は、以前に使用した組織に配置されている可能性があります。正しいワークショップ組織にいることを確認してください。複数の組織へのアクセス権がある場合は、インストラクターに確認してください。

演習

オンボーディングガイダンスをクリックします（ここでオンボーディングパネルの表示/非表示を切り替えることができます。製品に十分に精通していて、より多くの情報を表示するためにスペースを使用できる場合に便利です）。
ホームページのオンボーディングコンテンツを非表示にします。
メニューの下部で、お好みのテーマ：Light、Dark、または**System(Auto)**モードを選択します。
これがLog outオプションがある場所であることにも気づきましたか？どうかログアウトしないでください 😊！
< をクリックしてメインメニューに戻ります。

次に、Splunk Real User Monitoring (RUM) を確認しましょう。

Real User Monitoring概要

5 minutes

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

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

Real User Monitoring ホームページ

メインメニューのRUMをクリックすると、RUMのメインホームページ（ランディングページ）に移動します。このページの主な概念は、選択したすべてのRUMアプリケーションの全体的な状態を、フルダッシュボードまたはコンパクトビューのいずれかで一目で提供することです。

使用する状態ダッシュボードのタイプに関係なく、RUMホームページは3つの明確なセクションで構成されています

オンボーディングペイン: Splunk RUMの使用を開始するためのトレーニングビデオとドキュメントへのリンク。（画面のスペースが必要な場合、このペインを非表示にすることができます。）
フィルターペイン: 時間枠、環境、アプリケーション、ソースタイプでフィルタリングします。
アプリケーションサマリーペイン: RUMデータを送信するすべてのアプリケーションの概要。

RUM環境とアプリケーション、およびソースタイプ

Splunk Observabilityは、RUMトレースの一部として送信されるEnvironmentタグ（ウェブサイトやモバイルアプリとの各操作で作成される）を使用して、「本番環境」や「開発環境」などの異なる環境からのデータを分離します。
さらに アプリケーション(App) タグによる分離も可能です。これにより、同じ環境で実行されている別々のブラウザ/モバイルアプリケーションを区別することができます。
Splunk RUMはブラウザとモバイルアプリケーションの両方で利用可能です。Source タイプを使用してそれらを区別することも可能ですが、このワークショップではブラウザベースのRUMのみを使用します。

演習

時間ウィンドウが -15m に設定されていることを確認します
ドロップダウンボックスからワークショップの環境を選択します。命名規則は [ワークショップ名]-workshop です（これを選択すると、ワークショップRUMアプリケーションが表示されます）
App名を選択します。命名規則は [ワークショップ名]-store で、Sourceはすべてのままにしておきます
JavaScript Errorsタイルで、TypeErrorエントリ：Cannot read properties of undefined (reading ‘Prcie’) をクリックして詳細を確認します。ウェブサイトのどの部分でエラーが発生したかを素早く示してくれることに注意してください。これにより、迅速に修正することができます。
ペインを閉じます。
3番目のタイルはWeb Vitalsを報告します。これはユーザーエクスペリエンスの3つの重要な側面である読み込み、対話性、視覚的安定性に焦点を当てたメトリクスです。

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

Web Vitals メトリクスによれば、サイトの初期読み込みは良好であり、Goodと評価されています

最後のタイル、Most recent alerts タイルは、アプリケーションに対してアラートが発生しているかどうかを表示します。
アプリケーション名の前にある下向き矢印 ⌵ をクリックして、ビューをコンパクトスタイルに切り替えます。このビューでもすべての主要情報が利用可能であることに注目してください。コンパクトビューの任意の場所をクリックすると、フルビューに戻ります。

次に、Splunk Application Performance Monitoring（APM） を確認しましょう。

Application Performance Monitoring概要

5 minutes

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

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

Application Performance Monitoring ホームページ

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

オンボーディングペイン: Splunk APMの使用を開始するためのトレーニングビデオとドキュメントへのリンク。
APM 概要ペイン: トップサービスとトップビジネスワークフローのリアルタイムメトリクス。
機能ペイン: サービス、タグ、トレース、データベースクエリパフォーマンス、コードプロファイリングの詳細分析へのリンク。

APM 概要ペインは、アプリケーションの健全性の高レベルの概要を提供します。これにはアプリケーション内のサービス、レイテンシー、エラーの概要が含まれます。また、エラー率別のトップサービスとエラー率別のトップビジネスワークフローのリストも含まれています（ビジネスワークフローは、特定のアクティビティやトランザクションに関連するトレースコレクションの開始から終了までの旅程であり、エンドツーエンドのKPIの監視やルート原因とボトルネックの特定を可能にします）。

環境について

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

演習

作業している時間ウィンドウが過去15分（-15m）に設定されていることを確認します。
ドロップダウンボックスからワークショップ名を選択して、環境をワークショップ用に変更し、それのみが選択されていることを確認します。

エラー率別のトップサービスチャートから何を結論づけることができますか？

paymentserviceはエラー率が高い

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

Splunk APMは、リモートサービスを呼び出すスパンが必要な情報を持っている場合、リモートサービスまたは推測されたサービスの存在を推測できます。推測されるサービスの例としては、データベース、HTTPエンドポイント、メッセージキューなどがあります。推測されたサービスは計装されていませんが、サービスマップとサービスリストに表示されます。

次に、Splunk ログオブザーバー（LO） を確認しましょう。

Log Observer概要

5 minutes

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

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

Log Observerホームページ

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

オンボーディングペイン: SplunkLog Observerの使用を開始するためのトレーニングビデオとドキュメントへのリンク。
フィルターバー: 時間、インデックス、フィールドでフィルタリングし、クエリを保存することもできます。
ログテーブルペイン: 現在のフィルター条件に一致するログエントリのリスト。
フィールドペイン: 現在選択されているインデックスで利用可能なフィールドのリスト。

Splunk Index

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

ヒント

以前にSplunk EnterpriseまたはSplunk Cloudを使用したことがある場合は、おそらくログから調査を開始することに慣れているでしょう。以下の演習で見るように、Splunk Observability Cloudでも同様のことができます。ただし、このワークショップでは、調査にOpenTelemetryのすべてのシグナルを使用します。

簡単な検索演習を行いましょう

演習

時間枠を -15m に設定します。
フィルターバーでAdd Filterをクリックし、ダイアログでFieldをクリックします。
cardTypeと入力して選択します。
トップ値の下でvisaをクリックし、次に = をクリックしてフィルターに追加します。
ログテーブルのログエントリの1つをクリックして、エントリに cardType: "visa" が含まれていることを確認します。
出荷されたすべての注文を見つけましょう。フィルターバーのClear Allをクリックして、前のフィルターを削除します。
フィルターバーで再びAdd Filterをクリックし、キーワードを選択します。次に**キーワードを入力…**ボックスに order: と入力し、Enterキーを押します。
これで「order:」という単語を含むログ行のみが表示されるはずです。まだたくさんのログ行があるので、さらにフィルタリングしましょう。
別のフィルターを追加します。今回はFieldボックスを選択し、Find a field … 検索ボックスに severity と入力して選択します。
注文ログ行には重要度が割り当てられていないため、ダイアログボックスの下部にあるExclude all logs with this fieldをクリックしてください。これにより、他のログが削除されます。
上部にオンボーディングコンテンツがまだ表示されている場合は、Exclude all logs with this fieldボタンを見るためにページを下にスクロールする必要があるかもしれません。
これで、過去15分間に販売された注文のリストが表示されるはずです。

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

Synthetics概要

5 minutes

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

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

Syntheticsホームページ

メインメニューのSyntheticsをクリックします。これにより、Syntheticsホームページに移動します。このページには、役立つ情報を提供するか、Syntheticテストを選択または作成できる3つの明確なセクションがあります。

オンボーディングペイン: SplunkSyntheticsの使用を開始するためのトレーニングビデオとドキュメントへのリンク。
テストペイン: 設定されているすべてのテスト（ブラウザ、API、稼働時間）のリスト。
テスト作成ペイン: 新しいSyntheticテストを作成するためのドロップダウン。

情報

ワークショップの一環として、実行しているアプリケーションに対するデフォルトのブラウザテストを作成しています。テストペイン（2）でそれを見つけることができます。名前はWorkshop Browser Test forで、その後にワークショップの名前が続きます（インストラクターがそれを提供しているはずです）。

ツアーを続けるために、ワークショップの自動ブラウザテストの結果を見てみましょう。

演習

テストペインで、ワークショップの名前を含む行をクリックします。結果は次のようになります

注意：Syntheticテストページでは、最初のペインに過去1日、8日、30日間のサイトのパフォーマンスが表示されます。上のスクリーンショットに示すように、テストが過去に十分遡って開始された場合のみ、対応するチャートに有効なデータが含まれます。ワークショップでは、これはワークショップが作成された時期によって異なります。
パフォーマンスKPIドロップダウンで、デフォルトの4時間から過去1時間に時間を変更します。

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

テストは1 分間隔でラウンドロビン方式によりフランクフルト、ロンドン、パリから実行されています

次に、Splunk インフラストラクチャモニタリング（IM） を使用して、アプリケーションが実行されているインフラストラクチャを調べてみましょう。

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

5 minutes

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

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

ショッピングに行きましょう 💶

5 minutes

ペルソナ

あなたは次の目新しいアイテムを有名なオンラインブティックショップで購入したいと思っているおしゃれな都会人です。オンラインブティックはあなたのヒップスターな要求すべてを満たすための場所だと聞いています。

この演習の目的は、オンラインブティックウェブアプリケーションと対話することです。これはSplunk Observability Cloudの機能を実演するために使用されるサンプルアプリケーションです。このアプリケーションは簡単なEコマースサイトで、商品の閲覧、カートへの追加、そして精算が可能です。

このアプリケーションはすでにデプロイされており、インストラクターがオンラインブティックウェブサイトへのリンクを提供します。例

http://<s4r-workshop-i-xxx.splunk>.show:81/。アプリケーションは80および443ポートでも実行されているので、そちらを使用するか、ポート81が到達不能な場合はそれらを使用することもできます。

演習 - ショッピングに行きましょう

オンラインブティックへのリンクが得られたら、いくつかの商品を閲覧し、カートに追加し、最後に精算を行ってください。
この演習を数回繰り返し、可能であれば異なるブラウザ、モバイルデバイス、またはタブレットを使用してください。これによりより多くのデータが生成され、探索できるようになります。

ヒント

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

演習 (続き)

精算プロセスについて何か気づいたことはありますか？完了までに時間がかかったように思えましたが、最終的には完了しましたか？こうした場合は、注文確認 IDをコピーしてローカルに保存してください。後で必要になります。
ショッピングに使用したブラウザセッションを閉じてください。

これは、ユーザーエクスペリエンスが悪い場合の感覚で、これは潜在的な顧客満足度の問題であるため、すぐにトラブルシューティングを行う必要があります。

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

Splunk RUM

15 minutes

ペルソナ

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

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

1. RUMダッシュボード

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

演習

ドロップダウンが以下のように設定/選択されていることを確認して、ワークショップを選択してください
- 時間枠は -15m に設定されていること。
- 選択されているEnvironmentは [ワークショップ名]-workshop であること。
- 選択されているAppは [ワークショップ名]-store であること。
- SourceはAllに設定されていること。
次に、Page Views / JavaScript Errorsチャートの上にある [ワークショップ名]-store をクリックします。
これにより、UX Metrics、Front-end Health、Back-end Health、Custom Eventsごとにメトリクスを分類し、過去のメトリクス（デフォルトでは1時間）と比較する新しいダッシュボードビューが表示されます。

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

演習

各タブ（UX Metrics、Front-end Health、Back-end Health、Custom Events）をクリックしてデータを調べます。

「Custom Events」タブのチャートを調べると、どのチャートがレイテンシースパイクを明確に示していますか？

それは 「Custom Event Latency」 チャートです

2. Tag Spotlight

演習

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

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

演習

時間枠を過去 1 時間に変更します。
Add filtersをクリックし、OS Versionを選択し、!=をクリックしてSyntheticsとRUMLoadGenを選択し、フィルターを適用ボタンをクリックします。
Custom Events Nameチャートを見つけ、リスト内のPlaceOrderを見つけてクリックし、Add to filterを選択します。
上部のグラフに大きなスパイクがあることに注目してください。
User Sessionタブをクリックします。
Durationの見出しを2回クリックして、セッションを期間で並べ替えます（最も長いものが上部に表示されます）。
テーブルの上にあるをクリックし、追加の列のリストからSf Geo Cityを選択し、保存をクリックします。

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

3. セッションリプレイ

セッション

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

演習

User Sessionテーブルで、最も長いDuration（20秒以上）の上位のSession IDをクリックすると、RUMセッションビューに移動します。

演習

RUMセッションリプレイ Replayボタンをクリックします。RUMセッションリプレイでは、ユーザーセッションを再生して確認することができます。これはユーザーが体験した内容を正確に確認するための優れた方法です。
ボタンをクリックしてリプレイを開始します。

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

ヒント

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

4. ユーザーセッション

演習

右上隅のXをクリックして、RUMセッションリプレイを閉じます。
スパンの長さに注目してください。これは注文を完了するのにかかった時間で、良くありません！
ページを下にスクロールすると、タグメタデータ（Tag Spotlightで使用されるもの）が表示されます。タグの後に、ウォーターフォールが表示され、読み込まれたページオブジェクト（HTML、CSS、画像、JavaScriptなど）が表示されます。
ページを下にスクロールし続けて、青いAPMリンク（URLの末尾に /cart/checkout があるもの）まで移動し、その上にカーソルを置きます。

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

演習

上のスクリーンショットのように、paymentserviceとcheckoutserviceがエラー状態にあることがわかります。
ワークフロー名の下にある front-end:/cart/checkout をクリックすると、APM サービスマップが表示されます。

Splunk APM

20 minutes

ペルソナ

あなたはバックエンド開発者で、SREが発見した問題の調査を手伝うよう依頼されました。SREはユーザーエクスペリエンスの低下を特定し、あなたにその問題を調査するよう依頼しました。

RUMトレース（フロントエンド）からAPMトレース（バックエンド）にジャンプすることで、完全なエンドツーエンドの可視性の力を発見します。すべてのサービスはテレメトリ（トレースとスパン）を送信しており、Splunk Observability Cloudはこれを視覚化、分析し、異常やエラーを検出するために使用できます。

RUMとAPMは同じコインの表と裏です。RUMはアプリケーションのクライアント側からの視点であり、APMはサーバー側からの視点です。このセクションでは、APMを使用して掘り下げ、問題がどこにあるかを特定します。

1. APM探索

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

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

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

演習

サービスマップでpaymentserviceをクリックします。

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

演習

右側のペインで、青色のpaymentserviceをクリックします。

2. APMサービスビュー

サービスビュー

サービスオーナーとして、Splunk APMのサービスビューを使用して、単一のパネルでサービスの健全性の完全なビューを取得できます。サービスビューには、可用性、依存関係、リクエスト、エラー、および期間（RED）メトリクス、ランタイムメトリクス、インフラストラクチャメトリクス、Tag Spotlight、エンドポイント、および選択したサービスのログのためのサービスレベルインジケーター（SLI）が含まれています。また、サービスビューからサービスのコードプロファイリングとメモリプロファイリングにすぐにアクセスすることもできます。

演習

時間ボックスを確認すると、ダッシュボードは以前に選択したAPMトレースが完了するまでにかかった時間に関連するデータのみを表示していることがわかります（チャートは静的であることに注意してください）。
時間ボックスで時間枠を -1h に変更します。
これらのチャートはパフォーマンスの問題を素早く特定するのに非常に役立ちます。このダッシュボードを使用して、サービスの健全性を監視できます。
ページを下にスクロールしてInfrustructure Metricsを展開します。ここでホストとPodのメトリクスが表示されます。
Runtime Metricsは、Node.jsで書かれたサービスにはプロファイリングデータが利用できないため、使用できません。
では、探索ビューに戻りましょう。ブラウザの戻るボタンを押してください。

演習

サービスマップでpaymentserviceの上にカーソルを置いてください。ポップアップサービスチャートからどのような結論を導き出せますか？

エラーの割合が非常に高い。

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

3. APM Tag Spotlight

演習

paymentserviceのタグを表示するには、paymentserviceをクリックし、右側の機能ペインのTag Spotlightをクリックします（画面の解像度によっては下にスクロールする必要があるかもしれません）。
Tag Spotlightに入ったら、フィルターアイコンからShow tags with no valuesチェックボックスがオフになっていることを確認してください。

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

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

Requests
Errors
Root Cause errors
P50 Latency
P90 Latency
P99 Latency

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

演習

どのカードが問題を特定するタグを明らかにしていますか？

「Version」カードです。v350.10 に対するリクエスト数がエラー数と一致しています（つまり 100%）

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

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

演習

サービスマップでpaymentserviceを選択します。
右側のペインでBreakdownをクリックします。
リストから tenant.level を選択します。
サービスマップに戻り、goldをクリックします。
Breakdownをクリックして version を選択します。これはサービスバージョンを表示するタグです。
これをsilverとbronzeについても繰り返します。

表示されている内容からどのような結論が導き出せますか？

すべての tenant.level が v350.10 の影響を受けています

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

スパンタグ

スパンタグを使用してサービスを分解することは非常に強力な機能です。これにより、異なる顧客、異なるバージョン、異なる地域などに対して、サービスがどのようにパフォーマンスを発揮しているかを確認できます。この演習では、paymentserviceの v350.10 がすべての顧客に問題を引き起こしていることを特定しました。

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

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

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

トレースアナライザー

Splunk Observability Cloudは、アプリケーション監視データを探索するためのいくつかのツールを提供しています。Trace Analyzerは、未知または新しい問題を調査するための高カーディナリティ、高粒度の検索と探索が必要なシナリオに適しています。

演習

paymentserviceの外側のボックスを選択した状態で、右側のペインでTraceをクリックします。
Trace Analyzerを使用していることを確認するため、クSwitch to Classic Viewボタンが表示されていることを確認します。表示されていない場合は、Switch to Trace Analyzerをクリックします。
時間範囲を過去 15 分に設定します。
Sample Ratioが 1:10 ではなく 1:1 に設定されていることを確認します。

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

演習

Trace & Error countと表示されているドロップダウンメニューをクリックし、Trace Durationに変更します

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

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

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

演習

Trace DurationからTrace & Error countに戻します。
時間選択で過去 1 時間を選択します。
ほとんどのトレースにエラー（赤）があり、エラーのないトレース（青）は限られていることに注意してください。
Sample Ratioが 1:10 ではなく 1:1 に設定されていることを確認します。
Add filtersをクリックし、orderId と入力してリストからorderIdを選択します。
ワークショップの前半でショッピングを行った際のOrder Confirmation IDを貼り付けてEnterキーを押します。もしIDを記録していない場合は、インストラクターに確認してください。

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

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

演習

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

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

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

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

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

演習

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

スパン詳細で報告されているエラーメッセージとバージョンは何ですか？

Invalid request（無効なリクエスト）と v350.10 です。

問題を引き起こしているpaymentserviceのバージョンを特定したので、エラーについてさらに詳しい情報が見つかるか確認してみましょう。ここで関連ログの出番です。

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

service.name
deployment.environment
host.name
trace_id
span_id

演習

トレースウォーターフォールの一番下でLogs (1)をクリックします。これは、このトレースに関連ログがあることを示しています。
ポップアップのLogs for trace xxx（トレースxxxのログ）エントリをクリックすると、Log Observerで完全なトレースのログが開きます。

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

Splunk Log Observer

20 minutes

ペルソナ

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

APMトレースに関連するコンテンツ（ログ）を使用して、Splunk Log Observerでさらに掘り下げ、問題が正確に何であるかを理解します。

関連コンテンツは、あるコンポーネントから別のコンポーネントにジャンプできる強力な機能で、メトリクス、トレース、ログで利用可能です。

1. ログフィルタリング

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

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

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

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

演習

ログ内のエラーメッセージだけに焦点を当てる必要があります

Group By（グループ化）ドロップダウンボックスをクリックし、フィルターを使用してSeverity（重要度）を見つけます。
選択したらApplyボタンをクリックします（チャートの凡例がデバッグ、エラー、情報を表示するように変わることに注意してください）。
エラーログのみを選択するには、凡例の「error」（1）という単語をクリックし、Add to filterを選択します。次にRun Searchをクリックします。
複数のサービスにエラー行がある場合は、sf_service=paymentservice などのサービス名もフィルターに追加できますが、今回のケースでは必要ありません。

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

2. ログエントリの表示

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

メトリクス	トレース	ログ
問題がありますか？	問題はどこですか？	問題は何ですか？

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

演習

ログテーブルのエラーエントリをクリックします（リストに別のサービスからのまれなエラーもある場合は、hostname: "paymentservice-xxxx" と表示されていることを確認してください）。

メッセージに基づいて、問題を解決するために開発チームに何を伝えますか？

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

ログメッセージペインのXをクリックして閉じます。

おめでとうございます

Splunk Observability Cloudを正常に使用して、オンラインブティックでショッピング中に不良なユーザーエクスペリエンスを体験した理由を理解しました。RUM、APM、ログを使用して、サービス環境で何が起こったかを理解し、その後、可観測性の3本柱であるメトリクス、トレース、ログに基づいて根本原因を見つけました。

また、アプリケーションの動作パターンを検出するためにTag Spotlightでインテリジェントなタグ付けと分析を使用する方法と、問題のコンテキストを維持しながら異なるコンポーネント間を迅速に移動するために関連コンテンツのフルスタック相関パワーを使用する方法も学びました。

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

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

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

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

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

演習

まず、関心のある列のみに情報量を減らします

ログテーブルの上にあるテーブル設定アイコンをクリックしてTable Settingを開き、_raw のチェックを外し、次のフィールドが選択されていることを確認します：k8s.pod.name、message、version。
時間選択から固定時間を削除し、過去 15 分に設定します。
すべてのトレースでこれを機能させるには、フィルターから trace_id を削除し、フィールド sf_service=paymentservice と sf_environment=[WORKSHOPNAME] を追加します。
Saveをクリックし、Save to Dashboardを選択します。
表示されるチャート作成ダイアログボックスで、Chart nameとして ログタイムライン を使用します。
Select Dashboardをクリックし、ダッシュボード選択ダイアログボックスでNew Dashboardをクリックします。
New Dashboardダイアログボックスに、新しいダッシュボードの名前を入力します（説明を入力する必要はありません）。次の形式を使用します：イニシャル - サービスヘルスダッシュボード、そしてSaveをクリックします。
リスト内で新しいダッシュボードが強調表示されていることを確認し（1）、OK（2）をクリックします。
Chart TypeとしてLog timelineが選択されていることを確認します。
Saveボタンをクリックします（この時点ではSave and go to dashboardをクリックしないでください）。

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

4. ログビューチャート

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

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

演習

前回の演習後、まだLog Observerにいることを確認してください。
フィルターは前回の演習と同じで、時間選択が過去 15 分に設定され、severity=error、sf_service=paymentservice、sf_environment=[WORKSHOPNAME] でフィルタリングされている必要があります。
必要なフィールドのみを含むヘッダーがあることを確認してください。
再度Saveをクリックし、Save to Dashvoardをクリックします。
これによりチャート作成ダイアログが再度表示されます。
Chart nameとしてログビューを使用します。
今回はSelect Dashboardをクリックし、前回の演習で作成したダッシュボードを検索します。検索ボックス（1）にあなたのイニシャルを入力することから始めることができます。
あなたのダッシュボード名をクリックして強調表示し（2）、OK（3）をクリックします。
これによりチャート作成ダイアログに戻ります。
Chart typeとしてLog viewが選択されていることを確認します。
ダッシュボードを表示するには、Save and go to dashboardをクリックします。
結果は以下のダッシュボードと同様になるはずです
この演習の最後のステップとして、あなたのダッシュボードをワークショップチームページに追加しましょう。これにより、ワークショップの後半で簡単に見つけることができます。
ページ上部で、あなたのダッシュボード名の左にある … をクリックします。
ドロップダウンからLinks to Teamを選択します。
次のLinks to Teamダイアログボックスで、インストラクターが提供したワークショップチームを見つけてDoneをクリックします。

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

Splunk Synthetics

15 minutes

ペルソナ

SREの帽子を再び被って、オンラインブティックの監視を設定するよう依頼されました。アプリケーションが24時間365日、利用可能で良好なパフォーマンスを発揮していることを確認する必要があります。

アプリケーションを24時間365日監視し、問題が発生したときにアラートを受け取ることができたらいいと思いませんか？ここでSyntheticsの出番です。オンラインブティックを通じて典型的なユーザージャーニーのパフォーマンスと可用性を毎分チェックする簡単なテストを紹介します。

1. Syntheticsダッシュボード

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

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

演習

Searchボックスに [ワークショップ名] を入力し、あなたのワークショップのテストを選択します（インストラクターがどれを選択するか指示します）。
Performance KPIsの下で、時間選択を過去 1 時間に設定してEnterキーを押します。
Locationをクリックし、ドロップダウンからPageを選択します。次のフィルターには、テストの一部であるページが表示されます。
Durationをクリックし、Durationの選択を解除してFirst byte timeを選択します。
凡例を見て、First byte time - Page 4の色に注目してください。
First byte time - Page 4の最も高いデータポイントを選択します。これで、この特定のテスト実行のRun resultsに移動します。

2. Syntheticsテスト詳細

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

情報

以下のスクリーンショットにはエラーを示す赤いバナーは含まれていませんが、あなたの実行結果には表示されている場合があります。これは、場合によってはテスト実行が失敗することがあり、ワークショップに影響しないため予期されることです。

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

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

演習

マウスを使用してフィルムストリップを左右にスクロールし、テスト実行中にサイトがどのようにレンダリングされていたかを確認します。
ビデオペインで、再生ボタン ▶ を押してテスト再生を見ます。省略記号 ⋮ をクリックすると、再生速度の変更、ピクチャーインピクチャーでの表示、さらにビデオのダウンロードもできます。
Syntheticトランザクションペインのビジネストランザクションヘッダーの下で、最初のボタンHomeをクリックします。
下のウォーターフォールにはページを構成するすべてのオブジェクトが表示されます。最初の行はHTML自体です。次の行は、ページを構成するオブジェクト（HTML、CSS、JavaScript、画像、フォントなど）です。
ウォーターフォールでGET splunk-otel-web.jsの行を見つけます。
> ボタンをクリックしてメタデータセクションを開き、リクエスト/レスポンスヘッダー情報を確認します。
Syntheticトランザクションペインで、2番目のビジネストランザクションShopをクリックします。フィルムストリップが調整され、新しいトランザクションの先頭に移動することに注意してください。
他のすべてのトランザクションについても同じことを繰り返し、最後にPlace Orderトランザクションを選択します。

3. SyntheticsからAPMへ

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

演習

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

演習

paymentserviceに対して1つ以上のエラーが表示されていることを確認します（1）。
同じエラーであることを確認するには、ログの関連コンテンツをクリックします（2）。
前回の演習を繰り返して、エラーのみにフィルタリングします。
エラーログを表示して、無効なトークンによる支払い失敗を確認します。

4. Synthetics Detector

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

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

演習

左側のメニューからSyntheticsホームページに戻ります
ワークショップのテストを再度選択し、ページ上部のCreate Detectorボタンをクリックします。
New Synthetics Detectorというテキスト（1）を編集し、イニシャル -[ワークショップ名]に置き換えます。
Run DurationとStatic threasholdが選択されていることを確認します。
Trigger threasholt（2）を 65,000〜68,000 に設定し、Enterキーを押してチャートを更新します。上図のように、しきい値ラインを切る複数のスパイクがあることを確認してください（実際のレイテンシーに合わせてしきい値を少し調整する必要があるかもしれません）。
残りはデフォルトのままにします。
スパイクの下に赤と白の三角形の列が表示されるようになったことに注意してください（3）。赤い三角形は、テストが指定されたしきい値を超えたことをDetectorが検出したことを知らせ、白い三角形は結果がしきい値を下回ったことを示します。各赤い三角形がアラートをトリガーします。
アラートの重大度（4）は、ドロップダウンを別のレベルに変更することで変更できます。また、アラート方法も変更できます。受信者を追加しないでください。アラートストームの対象になる可能性があります！
Actibateをクリックして、 Detectorをデプロイします。
新しく作成したDetectorを見るには、Edit Testボタンをクリックします。
ページの下部にアクティブなDetectorのリストがあります。
あなたのDetectorが見つからず、新しい Synthetics Detectorという名前のものが表示されている場合は、あなたの名前で正しく保存されていない可能性があります。新しい Synthetics Detectorのリンクをクリックして、名前の変更をやり直してください。
閉じるボタンをクリックして編集モードを終了します。

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

15 minutes

ペルソナ

SREの帽子が似合っているので、引き続き着用してpaymentservice用のカスタムサービスヘルスダッシュボードの構築を依頼されたと想定します。要件はREDメトリクス、ログ、Syntheticテスト期間の結果を表示することです。

開発チームとSREチームが、アプリケーションやサービスの健全性の概要を必要とすることは一般的です。これらは多くの場合、壁に取り付けられたTVに表示されます。Splunk Observability Cloudは、カスタムダッシュボードを作成することでこれに最適なソリューションを提供しています。

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

ダッシュボードの強化

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

演習

2つのログチャートがあるダッシュボードに戻るには、メインメニューからDashboardをクリックすると、チームダッシュボードビューに移動します。Dashboardの下にあるSearch Dashboardをクリックして、あなたのサービスヘルスダッシュボードグループを検索します。
名前をクリックすると、以前に保存したダッシュボードが表示されます。
ログ情報は便利ですが、チームにとって意味のあるものにするにはさらに情報が必要なので、もう少し情報を追加しましょう。
最初のステップは、ダッシュボードに説明チャートを追加することです。New text noteをクリックし、ノート内のテキストを次のテキストに置き換えてから、Save and Closeボタンをクリックし、チャートに手順と名前をつけます。

テキストノートで使用する情報

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

チャートが適切な順序になっていません。チャートを役立つように並べ替えましょう。
手順チャートの上端にマウスを移動すると、マウスポインタが ☩ に変わります。これにより、ダッシュボード内でチャートをドラッグできるようになります。手順チャートを左上の位置にドラッグし、右端をドラッグしてページの1/3のサイズにリサイズします。
ログタイムラインビューチャートを手順チャートの横にドラッグして追加し、ページの残りの2/3を埋めるようにリサイズして、2つのチャートの横にエラー率チャートを配置し、ページ全体を埋めるようにリサイズします。
次に、ログラインチャートをページの幅にリサイズし、少なくとも2倍の長さになるようにリサイズします。
以下のダッシュボードに似た形になっているはずです

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

カスタムチャートの追加

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

演習

ダッシュボードの上部にある + をクリックし、チャートを選択します。
まず、Untitled Chart入力フィールドを使用して、チャートに全体テスト所要時間という名前を付けます。
この演習では棒グラフまたは柱状グラフが必要なので、チャートオプションボックスの3番目のアイコンをクリックします。
Plot editorのSignalボックスに synthetics.run.duration.time.ms（これはテストの実行時間です）と入力し、Enterキーを押します。
現在、異なる色の棒が表示されています。テストが実行される各リージョンごとに異なる色になっています。これは必要ないので、分析を追加することでその動作を変更できます。
Add Analyticsボタンをクリックします。
ドロップダウンからMeanオプションを選択し、mean:aggregation を選択してダイアログボックスの外をクリックします。メトリクスが集計されるため、チャートが単色に変わることに注目してください。
x軸は現在、時間を表していません。これを変更するには、プロットラインの最後にある設定アイコンをクリックします。次のダイアログが開きます
ドロップダウンボックスのDisplay Units（2）をnoneから Time (autoscaling)/Milliseconds(ms) に変更します。ドロップダウンがMillisecondに変わり、チャートのx軸がテスト所要時間を表すようになります。
設定アイコンをクリックするか、Closeボタンをクリックして、ダイアログを閉じます。
Link Detectirボタンをクリックし、以前に作成したディテクターの名前の入力を開始して、ディテクターを追加します。
ディテクター名をクリックして選択します。
チャートの周りに色付きの枠が表示され、アラートのステータスが示されます。また、以下のようにダッシュボードの上部にベルアイコンが表示されることに注目してください
Save and Closeボタンをクリックします。
ダッシュボードで、チャートを移動して以下のスクリーンショットのように表示させます
最後のタスクとして、ページ上部（Event Overlayの横）にある3つのドット … をクリックし、View fullscreenをクリックします。これは壁掛けテレビモニターで使用するビューです（元に戻るにはEscキーを押します）。

ヒント

時間があれば、RUMメトリクスを使用してダッシュボードにもう1つのカスタムチャートを追加してみてください。既製のRUM アプリケーションダッシュボードグループからチャートをコピーすることができます。または、RUMメトリクス rum.client_error.count を使用して、アプリケーションのクライアントエラー数を表示するチャートを作成することもできます。

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

ワークショップまとめ 🎁

10 minutes

おめでとうございます。Splunk4Rookies - Observability Cloud ワークショップを修了しました。今日はSplunk Observability Cloudを使用してアプリケーションとインフラストラクチャを監視する方法に慣れました。

この修了証をあなたのLinkedIn プロフィールに追加して成果をアピールしましょう。

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

主要なポイント

このワークショップを通じて、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スクリーンで継続的に表示するヘルスダッシュボードを作成しました

Splunk4Ninjas Workshops

自動ディスカバリーワークショップ
Java アプリケーション向けの Splunk 自動ディスカバリーおよび設定機能の活用方法を学びます。これらのワークショップでは、ゼロコード計装を使用して、モノリスおよび Kubernetes デプロイメント全体でメトリクス、トレース、ログを即座に生成し、包括的なオブザーバビリティを実現する方法をデモンストレーションします。
Horizontal Pod Autoscaling
Splunk OpenTelemetry Collector を使用して Kubernetes Horizontal Pod Autoscaling (HPA) を監視し、メトリクス、イベント、オートスケーリングの動作をリアルタイムで確認する方法を学びます
OpenTelemetry Collector ワークショップ
OpenTelemetry Collector の基本概念 OpenTelemetry Collector の概念と、Splunk Observability Cloud へデータを送信する方法を学びます。 Advanced OpenTelemetry Collector OpenTelemetry Collector の設定をゼロから行う練習を行い、いくつかの高度な設定シナリオを体験します。
Splunk Synthetic Scripting
ユーザーフロー、ビジネストランザクション、API 全体のパフォーマンス問題をプロアクティブに検出・修正し、より優れたデジタルエクスペリエンスを提供します。
Lambdaトレーシング
このワークショップでは、AWS Lambdaで実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesisを介してメッセージをproduceおよびconsumeする方法を学びます
Dashboard Workshop
Splunk Observability Cloud のチャート機能、フィルター、分析関数、SignalFlow を使用して、洞察に満ちた可視化とカスタムダッシュボードを構築する方法を学びます
OpenTelemetry、Docker、K8sを実践で学ぶ
このワークショップでは、これらの概念を説明するためにシンプルな.NETアプリケーションを使用します。さあ、始めましょう！ワークショップの終わりまでに、OpenTelemetryを使用した.NETアプリケーションの計装の実践経験を積み、そのアプリケーションのDocker化およびKubernetesへのデプロイを行います。また、Helmを使用したOpenTelemetryコレクターのデプロイ、コレクター設定のカスタマイズ、コレクター設定の問題のトラブルシューティングの経験も得られます。
O11y Cloud で問題を解決する
OpenTelemetry Collector のデプロイと設定、OpenTelemetry によるアプリケーションの計装、Troubleshooting MetricSets と Tag Spotlight を活用した Splunk Observability Cloud でのパフォーマンス問題の特定と解決方法を学びます。
Ingest Processor for Observability Cloud
Splunk Ingest Processor を使用してログをメトリクスに変換し、オブザーバビリティコストを最適化し、MTTD を改善する方法を、Splunk Observability Cloud でのハンズオン演習を通じて学びます。
Splunk Observability Cloud による Cisco AI Pods のモニタリング
This hands-on workshop demonstrates how to monitor Cisco AI Pods with Splunk Observability Cloud. Learn to deploy the OpenTelemetry Collector in Red Hat OpenShift, ingest infrastructure metrics using Prometheus receivers, and configure APM to monitor Python services that interact with Large Language Models (LLMs).
Splunk4Ninjas AppDynamics
Splunk AppDynamics を使用したフルスタックアプリケーションパフォーマンス監視について学びます。Java APM エージェントのインストール、アプリケーションの健全性監視、パフォーマンス問題のトラブルシューティング、BRUM によるブラウザメトリクスの追跡、データベースパフォーマンスの分析、Business IQ によるビジネスインサイトの取得まで幅広くカバーします。

自動ディスカバリーワークショップ

PetClinic モノリスワークショップ
Spring PetClinic サンプルアプリケーションを使用して、Java アプリケーション向けの Splunk Observability Cloud の自動ディスカバリーおよび設定機能をデモンストレーションするハンズオンワークショップです。
PetClinic Kubernetes ワークショップ
Kubernetes で実行される Java ベースのアプリケーション向けの自動ディスカバリーおよび設定を有効にする方法を学びます。リアルタイムモニタリングを体験し、エンドツーエンドの可視性でアプリケーションの動作を最大限に活用しましょう。

PetClinic モノリスワークショップ

30 minutes Author Robert Castley

このワークショップの目的は、Splunk Observability Cloud プラットフォームの以下のコンポーネントを設定するための基本的な手順を説明することです

Splunk Infrastructure Monitoring (IM)
Splunk Automatic Discovery for Java (APM)
- Database Query Performance
- AlwaysOn Profiling
Splunk Real User Monitoring (RUM)
RUMからAPMへの相関
Splunk Log Observer (LO)

また、サンプルJavaアプリケーション（Spring PetClinic）のクローン（ダウンロード）方法、およびアプリケーションのコンパイル、パッケージ化、実行方法についても説明します。

アプリケーションが起動して実行されると、Splunk APM 製品で使用されるJava 2.x向けの自動ディスカバリーおよび設定機能により、メトリクス、トレース、ログが即座に表示されるようになります。

その後、Splunk OpenTelemetry Javascript Libraries (RUM) を使用してPetClinicのエンドユーザーインターフェース（アプリケーションがレンダリングするHTMLページ）を計装します。これにより、エンドユーザーが実行するすべてのクリックやページ読み込みに対してRUMトレースが生成されます。

最後に、PetClinicアプリケーションログへのトレースメタデータの自動インジェクションによって生成されたログを確認します。

前提条件

ポート 2222 へのアウトバウンドSSHアクセス
ポート 8083 へのアウトバウンドHTTPアクセス
bash シェルおよび vi/vim エディタの基本的な知識

OpenTelemetry Collector のインストール

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

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

既存のOpenTelemetry Collectorの削除

Splunk IMワークショップを完了している場合は、続行する前にKubernetesで実行中のCollectorを削除してください。以下のコマンドを実行して削除できます

helm delete splunk-otel-collector

EC2インスタンスには、古いバージョンのCollectorがすでにインストールされている場合があります。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を除く）。

おめでとうございます！

Kubernetes 上の Spring PetClinic SpringBoot ベースのマイクロサービス

90 minutes Author Pieter Hagen

このワークショップの目的は、Java向けのSplunk 自動ディスカバリーおよび設定機能を紹介することです。

ワークショップのシナリオは、Kubernetesにシンプルな（計装されていない）Javaマイクロサービスアプリケーションをインストールすることで作成されます。

既存のJavaベースのデプロイメント向けに自動ディスカバリー機能付きのSplunk OpenTelemetry Collectorをインストールする簡単な手順に従うことで、メトリクス、トレース、ログを Splunk Observability Cloud に送信することがいかに簡単かを確認できます。

前提条件

ポート 2222 へのアウトバウンド SSH アクセス
ポート 81 へのアウトバウンド HTTP アクセス
Linux コマンドラインの基本的な知識

このワークショップでは、以下のコンポーネントをカバーします

Splunk Infrastructure Monitoring (IM)
Splunk automatic discovery and configuration for Java (APM)
- Database Query Performance
- AlwaysOn Profiling
Splunk Log Observer (LO)
Splunk Real User Monitoring (RUM)

Splunk Synthetics は少し寂しそうですが、他のワークショップでカバーしています

アーキテクチャ

5 minutes

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

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

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

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

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

15 minutes

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

インスタンスに初めてログインすると、以下のような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 でデータをフィルタリングする際に使用します。

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

既存の OpenTelemetry Collector の削除

この EC2 インスタンスを使用して以前に Splunk Observability ワークショップを完了している場合は、既存の Splunk OpenTelemetry Collector のインストールが削除されていることを確認する必要があります。これは以下のコマンドを実行することで行えます

helm delete splunk-otel-collector

Splunk OpenTelemetry Collector のデプロイ

オブザーバビリティシグナル（メトリクス、トレース、ログ）を Splunk Observability Cloud に送信するには、KubernetesクラスターにSplunk OpenTelemetry Collectorをデプロイする必要があります。

このワークショップでは、Splunk OpenTelemetry Collector Helm Chartを使用します。まず、Helm chartリポジトリをHelmに追加し、helm repo update を実行して最新バージョンを確認します

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update

Using ACCESS_TOKEN={REDACTED}
Using REALM=eu0
"splunk-otel-collector-chart" has been added to your repositories
Using ACCESS_TOKEN={REDACTED}
Using REALM=eu0
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "splunk-otel-collector-chart" chart repository
Update Complete. ⎈Happy Helming!⎈

Splunk Observability Cloud では、Kubernetes上でのOpenTelemetry Collectorのセットアップを案内するUIウィザードが提供されていますが、時間の都合上、以下のHelm installコマンドを使用します。自動ディスカバリーおよび設定とコードプロファイリング用のオペレーターを有効にするための追加パラメータが設定されています。

--set="operator.enabled=true" - 自動ディスカバリーおよび設定を処理するためのOpenTelemetryオペレーターをインストールします。
--set="splunkObservability.profilingEnabled=true" - オペレーター経由でコードプロファイリングを有効にします。

Collectorをインストールするには、以下のコマンドを実行してください。これを編集しないでください

helm install splunk-otel-collector --version 0.136.0 \
--set="operatorcrds.install=true", \
--set="operator.enabled=true", \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="splunkObservability.profilingEnabled=true" \
--set="agent.service.enabled=true"  \
--set="environment=$INSTANCE-workshop" \
--set="splunkPlatform.endpoint=$HEC_URL" \
--set="splunkPlatform.token=$HEC_TOKEN" \
--set="splunkPlatform.index=splunk4rookies-workshop" \
splunk-otel-collector-chart/splunk-otel-collector \
-f ~/workshop/k3s/otel-collector.yaml

LAST DEPLOYED: Fri Apr 19 09:39:54 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-o11y-workshop-eu0.splunkcloud.com:443/services/collector/event".

Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.

[INFO] You've enabled the operator's auto-instrumentation feature (operator.enabled=true)! The operator can automatically instrument Kubernetes hosted applications.
  - Status: Instrumentation language maturity varies. See `operator.instrumentation.spec` and documentation for utilized instrumentation details.
  - Splunk Support: We offer full support for Splunk distributions and best-effort support for native OpenTelemetry distributions of auto-instrumentation libraries.

続行する前に、Podが Running として報告されていることを確認してください（通常約30秒かかります）。

kubectl get pods | grep splunk-otel

splunk-otel-collector-k8s-cluster-receiver-6bd5567d95-5f8cj     1/1     Running   0          10m
splunk-otel-collector-agent-tspd2                               1/1     Running   0          10m
splunk-otel-collector-operator-69d476cb7-j7zwd                  2/2     Running   0          10m

Splunk OpenTelemetry Collectorからエラーが報告されていないことを確認してください（ctrl + c で終了）。または、インストール済みの素晴らしい k9s ターミナルUIを使用するとボーナスポイントです！

kubectl logs -l app=splunk-otel-collector -f --container otel-collector

2021-03-21T16:11:10.900Z        INFO    service/service.go:364  Starting receivers...
2021-03-21T16:11:10.900Z        INFO    builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"}
2021-03-21T16:11:11.009Z        INFO    builder/receivers_builder.go:75 Receiver started.       {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"}
2021-03-21T16:11:11.009Z        INFO    builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
2021-03-21T16:11:11.009Z        INFO    k8sclusterreceiver@v0.21.0/watcher.go:195       Configured Kubernetes MetadataExporter  {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster", "exporter_name": "signalfx"}
2021-03-21T16:11:11.009Z        INFO    builder/receivers_builder.go:75 Receiver started.       {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
2021-03-21T16:11:11.009Z        INFO    healthcheck/handler.go:128      Health Check state change       {"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "status": "ready"}
2021-03-21T16:11:11.009Z        INFO    service/service.go:267  Everything is ready. Begin running and processing data.
2021-03-21T16:11:11.009Z        INFO    k8sclusterreceiver@v0.21.0/receiver.go:59       Starting shared informers and wait for initial cache sync.      {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
2021-03-21T16:11:11.281Z        INFO    k8sclusterreceiver@v0.21.0/receiver.go:75       Completed syncing shared informer caches.       {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}

失敗したインストールの削除

OpenTelemetry Collector のインストールでエラーが発生した場合は、以下のコマンドでインストールを削除してやり直すことができます

helm delete splunk-otel-collector

PetClinic アプリケーションのデプロイ

アプリケーションの最初のデプロイメントでは、ビルド済みのコンテナを使用して、観測を開始したいKubernetesで実行される通常のJavaマイクロサービスベースのアプリケーションという基本シナリオを作成します。それでは、アプリケーションをデプロイしましょう

kubectl apply -f ~/workshop/petclinic/deployment.yaml

deployment.apps/config-server created
service/config-server created
deployment.apps/discovery-server created
service/discovery-server created
deployment.apps/api-gateway created
service/api-gateway created
service/api-gateway-external created
deployment.apps/customers-service created
service/customers-service created
deployment.apps/vets-service created
service/vets-service created
deployment.apps/visits-service created
service/visits-service created
deployment.apps/admin-server created
service/admin-server created
service/petclinic-db created
deployment.apps/petclinic-db created
configmap/petclinic-db-initdb-config created
deployment.apps/petclinic-loadgen-deployment created
configmap/scriptfile created

この時点で、Podが実行されていることを確認してデプロイメントを検証できます。コンテナのダウンロードと起動が必要なため、数分かかる場合があります。

kubectl get pods

NAME                                                            READY   STATUS    RESTARTS   AGE
splunk-otel-collector-k8s-cluster-receiver-655dcd9b6b-dcvkb     1/1     Running   0          114s
splunk-otel-collector-agent-dg2vj                               1/1     Running   0          114s
splunk-otel-collector-operator-57cbb8d7b4-dk5wf                 2/2     Running   0          114s
petclinic-db-64d998bb66-2vzpn                                   1/1     Running   0          58s
api-gateway-d88bc765-jd5lg                                      1/1     Running   0          58s
visits-service-7f97b6c579-bh9zj                                 1/1     Running   0          58s
admin-server-76d8b956c5-mb2zv                                   1/1     Running   0          58s
customers-service-847db99f79-mzlg2                              1/1     Running   0          58s
vets-service-7bdcd7dd6d-2tcfd                                   1/1     Running   0          58s
petclinic-loadgen-deployment-5d69d7f4dd-xxkn4                   1/1     Running   0          58s
config-server-67f7876d48-qrsr5                                  1/1     Running   0          58s
discovery-server-554b45cfb-bqhgt                                1/1     Running   0          58s

kubectl get pods の出力が、上記のOutputタブに示されている出力と一致することを確認してください。すべてのサービスが Running と表示されていることを確認してください（または k9s を使用してステータスを継続的に監視できます）。

アプリケーションをテストするには、インスタンスのパブリックIPアドレスを取得する必要があります。以下のコマンドを実行して取得できます

curl http://ifconfig.me

http://<IP_ADDRESS>:81（<IP_ADDRESS> を上記で取得したIPアドレスに置き換えてください）にアクセスして、アプリケーションが実行されていることを確認してください。PetClinicアプリケーションが実行されているのが確認できるはずです。アプリケーションはポート 80 と 443 でも実行されているので、これらを使用するか、ポート 81 に到達できない場合はそちらを使用してください。

All Owners (1) タブと Veterinarians (2) タブにアクセスして、各ページに名前のリストが表示されることを確認し、アプリケーションが正しく動作していることを確認してください。

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

10 minutes

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

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

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

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

Tip

特定のクラスターを識別するには、セットアップ中に実行したシェルスクリプト出力の INSTANCE 値を使用してください。この一意の識別子により、リスト内の他のノードの中からワークショップクラスターを見つけることができます。

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

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

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

10分

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

自動検出と設定

自動検出と設定は、コード変更や再コンパイルを必要とせずにアプリケーションからトレース、スパン、およびプロファイリングデータを取得するように設計されていることを理解することが重要です。

これはAPMを始めるための優れた方法ですが、手動計装の代替ではありません。手動計装では、カスタムスパン、タグ、ログをアプリケーションに追加でき、トレースにより多くのコンテキストと詳細を提供できます。

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

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

deployment.yamlの使用

Podが自動的にトレースを送信するようにしたい場合は、以下に示すように deployment.yaml にアノテーションを追加できます。これにより、初期デプロイメント時に計装ライブラリが追加されます。時間を節約するために、以下のPodに対してこれを実施済みです

admin-server
config-server
discovery-server

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"

デプロイメントのパッチ適用

自動検出と設定を構成するには、デプロイメントに計装アノテーションを追加するためのパッチを適用する必要があります。パッチが適用されると、OpenTelemetry Collectorが自動検出と設定ライブラリを注入し、Podが再起動されてトレースとプロファイリングデータの送信が開始されます。まず、以下を実行して api-gateway に splunk-otel-java イメージがないことを確認します

kubectl describe pods api-gateway | grep Image:

Image:         quay.io/phagen/spring-petclinic-api-gateway:0.0.2

次に、デプロイメントにアノテーションを追加して、すべてのサービスのJava自動検出と設定を有効にします。以下のコマンドは、すべてのデプロイメントにパッチを適用します。これにより、OpenTelemetry Operatorが splunk-otel-java イメージをPodに注入します

kubectl get deployments -l app.kubernetes.io/part-of=spring-petclinic -o name | xargs -I % kubectl patch % -p "{\"spec\": {\"template\":{\"metadata\":{\"annotations\":{\"instrumentation.opentelemetry.io/inject-java\":\"default/splunk-otel-collector\"}}}}}"

deployment.apps/config-server patched (no change)
deployment.apps/admin-server patched (no change)
deployment.apps/customers-service patched
deployment.apps/visits-service patched
deployment.apps/discovery-server patched (no change)
deployment.apps/vets-service patched
deployment.apps/api-gateway patched

config-server、discovery-server、admin-serverについては、すでにパッチが適用されているため変更はありません。

api-gateway Podのコンテナイメージを再度確認するには、以下のコマンドを実行します

kubectl describe pods api-gateway | grep Image:

Image:         ghcr.io/signalfx/splunk-otel-java/splunk-otel-java:v1.30.0
Image:         quay.io/phagen/spring-petclinic-api-gateway:0.0.2

api-gateway に新しいイメージが追加され、ghcr.io から splunk-otel-java がプルされます（注：2つの api-gateway コンテナが表示される場合、元のコンテナがまだ終了処理中の可能性があるため、数秒待ってください）。

Splunk Observability CloudのKubernetes Navigatorに戻ります。数分後、Podがオペレーターによって再起動され、自動検出と設定コンテナが追加されることが確認できます。以下のスクリーンショットのような表示になります

Kubernetes NavigatorでPodが緑色になるまで待ってから、次のセクションに進んでください。

Splunk APMでのデータの表示

左側のメニューでAPMをクリックして、新しく計装されたサービスからのトレースによって生成されたデータを確認します。

ドロップダウンボックスでEnvironmentフィルター (1) をワークショップインスタンスの名前に変更します。

メモ

これは**<INSTANCE>-workshopになります。ここでINSTANCE**は、先ほど実行したシェルスクリプトの値です。これのみが選択されていることを確認してください。

Service Map (2) ペインをクリックして、次のセクションの準備をします。

APM Features

15 minutes

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

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

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

APM Service Map

上記のマップは、すべてのサービス間のすべての相互作用を示しています。PetClinic Microserviceアプリケーションが起動して完全に同期するまで数分かかるため、マップはまだ中間状態にある可能性があります。時間フィルタを**-2mと入力してカスタム時間の2分に減らすと役立ちます。画面右上のRefreshボタン(1)**をクリックできます。赤い円で示される初期起動関連のエラーは最終的に消えます。

次に、各サービスで利用可能なメトリクスを調べるために、リクエスト、エラー、期間（RED）メトリクスダッシュボードを見てみましょう。

この演習では、サービスオペレーションが高いレイテンシやエラーを示している場合に使用する一般的なシナリオを使用します。

依存関係マップでcustomers-serviceをクリックし、Servicesドロップダウンボックス**(1)で customers-service が選択されていることを確認します。次に、サービス名に隣接するOperationsドロップダウン(2)**から GET /owners を選択します。

これにより、以下に示すように GET /owners でフィルタリングされたワークフローが表示されます

APM Trace

トレースを選択するには、Service Requests & Errors チャート**(1)**の線を選択します。関連するトレースの選択肢が表示されます。

関連するトレースのリストが表示されたら、青い**(2)** Trace ID Linkをクリックします。選択するトレースがServicesカラムに記載されている3つのサービスと同じものであることを確認してください。

これにより、ウォーターフォールビューで選択されたトレースが表示されます

ここにはいくつかのセクションがあります

Waterfall Pane (1)：トレースとスパンとして表示されるすべてのインストルメントされた関数が、その期間表示と順序/関係とともに表示されます。
Trace Info Pane (2)：選択されたスパン情報が表示されます（Waterfall Pane内でスパンの周りにボックスでハイライトされています）。
Span Pane (3)：選択されたスパンで送信されたすべてのタグを見つけることができます。下にスクロールしてすべてを確認できます。
Process Pane：スパンを作成したプロセスに関連するタグが表示されます（スクリーンショットに含まれていないため、下にスクロールして確認してください）。
Trace Properties：ペインの右上にあり、デフォルトでは折りたたまれています。

APM Span

スパンを調べる際、トレーシングの上で自動検出と設定を使用すると、コード変更なしで得られるいくつかの標準機能を見てみましょう

まず、Waterfall Paneで、以下のスクリーンショットに示すように customers-service:SELECT petclinic または類似のスパンが選択されていることを確認してください

基本的なレイテンシ情報は、インストルメントされた関数または呼び出しのバーとして表示されます。上記の例では、17.8ミリ秒かかりました。
いくつかの類似したスパン**(1)**は、スパンが複数回繰り返される場合にのみ表示されます。この場合、例では10回の繰り返しがあります。10x をクリックすると、すべてのスパンが順番に表示されるように表示/非表示を切り替えることができます。
Inferred Services：インストルメントされていない外部システムへの呼び出しは、グレーの「推測された」スパンとして表示されます。この例のInferred Serviceまたはスパンは、上記に示すようにMysqlデータベース mysql:petclinic SELECT petclinic **(2)**への呼び出しです。
Span Tags：Tag Paneには、自動検出と設定によって生成された標準タグが表示されます。この場合、スパンはデータベースを呼び出しているため、db.statement タグ**(3)**が含まれています。このタグは、このスパン中に実行されたデータベース呼び出しで使用されるDBクエリステートメントを保持します。これはDB-Query Performance機能で使用されます。DB-Query Performanceについては次のセクションで見ていきます。
Always-on Profiling：システムがスパンのライフサイクル中にプロファイリングデータをキャプチャするように設定されている場合、スパンのタイムラインでキャプチャされたコールスタックの数が表示されます。上記の例では、customer-service:GET /owners スパンに対して18個のコールスタックがあることがわかります。(4)

次のセクションでプロファイリングを見ていきます。

Service Centric View

Splunk APMは、エンジニアに1つの集中ビューでサービスパフォーマンスの深い理解を提供するService Centric Viewsを提供します。すべてのサービスにわたって、エンジニアはサービスの基盤となるインフラストラクチャからのエラーやボトルネックを迅速に特定し、新しいデプロイによるパフォーマンス低下を特定し、すべてのサードパーティ依存関係の健全性を可視化できます。

api-gateway のこのダッシュボードを表示するには、左側のメニューからAPMをクリックし、リストの api-gateway サービスをクリックします。これにより、Service Centric Viewダッシュボードが表示されます

インストルメントされた各サービスで利用可能なこのビューは、Service metrics、Error breakdown、Runtime metrics (Java)、Infrastructure metricsの概要を提供します。

Always-On Profiling & DB Query Performance

15 minutes

前の章で見てきたように、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がありますので、そちらをご覧ください。

Always-On Profiling & Metrics

先ほどHelmチャートを使用してSplunk Distribution of the OpenTelemetry Collectorをインストールした際、AlwaysOn ProfilingとMetricsを有効にするように設定しました。これにより、OpenTelemetry JavaはアプリケーションのCPUとメモリのプロファイリングを自動的に生成し、Splunk Observability Cloudに送信します。

PetClinicアプリケーションをデプロイしてアノテーションを設定すると、collectorは自動的にアプリケーションを検出し、トレースとプロファイリングのためにインストルメントします。これを確認するために、次のスクリプトを実行して、インストルメントしているJavaコンテナの1つの起動ログを調べることができます

ログには、Javaの自動検出と設定によって取得されたフラグが表示されます

.  ~/workshop/petclinic/scripts/get_logs.sh

2024/02/15 09:42:00 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s
2024/02/15 09:42:01 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s
2024/02/15 09:42:02 Connected to tcp://discovery-server:8761
Picked up JAVA_TOOL_OPTIONS:  -javaagent:/otel-auto-instrumentation-java/javaagent.jar
Picked up _JAVA_OPTIONS: -Dspring.profiles.active=docker,mysql -Dsplunk.profiler.call.stack.interval=150
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
[otel.javaagent 2024-02-15 09:42:03:056 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-1.30.1-otel-1.32.1
[otel.javaagent 2024-02-15 09:42:03:768 +0000] [main] INFO com.splunk.javaagent.shaded.io.micrometer.core.instrument.push.PushMeterRegistry - publishing metrics for SignalFxMeterRegistry every 30s
[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration:
[otel.javaagent 2024-02-15 09:42:07:480 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -                  splunk.profiler.enabled : true
[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -                splunk.profiler.directory : /tmp
[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -       splunk.profiler.recording.duration : 20s
[otel.javaagent 2024-02-15 09:42:07:506 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -               splunk.profiler.keep-files : false
[otel.javaagent 2024-02-15 09:42:07:510 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -            splunk.profiler.logs-endpoint : http://10.13.2.38:4317
[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -              otel.exporter.otlp.endpoint : http://10.13.2.38:4317
[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -           splunk.profiler.memory.enabled : true
[otel.javaagent 2024-02-15 09:42:07:515 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -             splunk.profiler.tlab.enabled : true
[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -        splunk.profiler.memory.event.rate : 150/s
[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -      splunk.profiler.call.stack.interval : PT0.15S
[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -  splunk.profiler.include.internal.stacks : false
[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger -      splunk.profiler.tracing.stacks.only : false
[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
[otel.javaagent 2024-02-15 09:42:07:518 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active.

私たちが注目しているのは、com.splunk.opentelemetry.profiler.ConfigurationLogger によって書き込まれたセクション、つまりProfiling Configurationです。

splunk.profiler.directory など、制御できるさまざまな設定を確認できます。これは、エージェントがSplunkに送信する前にコールスタックを書き込む場所です。（これは、コンテナの設定方法によって異なる場合があります。）

変更したいもう1つのパラメータは splunk.profiler.call.stack.interval です。これは、システムがCPU Stack traceをキャプチャする頻度です。Pet Clinicアプリケーションのような短いスパンがある場合は、このインターバル設定を短くすることをお勧めします。デモアプリケーションでは、デフォルトのインターバル値を変更しなかったため、スパンに常にCPU Call Stackが関連付けられているとは限りません。

これらのパラメータを設定する方法はこちらで確認できます。以下の例では、deployment.yaml でコールスタックのより高い収集レートを設定する方法を示しています。これは、JAVA_OPTIONS configセクションでこの値を設定することで行います。

env:
- name: JAVA_OPTIONS
  value: "-Xdebug -Dsplunk.profiler.call.stack.interval=150"

Trace Waterfall内のAlways-On Profiling

APM WaterfallビューでオリジナルのTrace & Span (1)（または類似のもの）を選択し、右側のペインから**Memory Stack Traces (2)**を選択してください

ペインにMemory Stack Trace Flame Graph **(3)**が表示されます。スクロールするか、ペインの右側をドラッグして拡大できます。

AlwaysOn Profilingは、アプリケーションのコードのスナップショット、つまりスタックトレースを常に取得しています。何千ものスタックトレースを読まなければならないことを想像してみてください！それは現実的ではありません。これを支援するために、AlwaysOn Profilingはプロファイリングデータを集約して要約し、Flame Graphと呼ばれるビューでCall Stacksを探索する便利な方法を提供します。これは、アプリケーションからキャプチャされたすべてのスタックトレースの要約を表します。Flame Graphを使用して、パフォーマンスの問題を引き起こしている可能性のあるコードの行を発見し、コードに加えた変更が意図した効果を持っているかどうかを確認できます。

Always-on Profilingをさらに詳しく調べるには、Memory Stack Tracesの下のProfiling Paneで上の画像で参照されているSpan **(3)**を選択してください。これにより、Always-on Profilingのメイン画面が開き、Memoryビューがあらかじめ選択されています

Timeフィルタは、選択したスパンの時間枠に設定されます (1)
Java Memory Metric Charts **(2)**では、Heap Memoryのモニター、Memory Allocation Rate や Garbage Collecting Metricsなどの Application Activity を確認できます。
スパン **(3)**に関連するメトリクスとStack Tracesのみにフォーカス/表示する機能。これにより、必要に応じてJavaアプリケーションで実行されているバックグラウンドアクティビティをフィルタで除外できます。
識別されたJava Function calls **(4)**により、その関数から呼び出されたメソッドにドリルダウンできます。
プロファイルされたサービスのスタックトレースに基づく階層の視覚化を持つFlame Graph (5)。
サービスが複数のバージョンを起動する場合に備えて、Service instance **(6)**を選択する機能。

さらなる調査のために、UIではスタックトレースをクリックして、呼び出された関数と、フレームチャートから関連する行を確認できます。これを使用して、コーディングプラットフォームで実際のコードの行を表示できます（もちろん、お好みのコーディングプラットフォームによって異なります）。

Database Query Performance

Database Query Performanceを使用すると、Splunk APMで直接、データベースクエリがサービスの可用性に与える影響をモニターできます。これにより、データベースをインストルメントすることなく、長時間実行されるクエリ、最適化されていないクエリ、または重いクエリを迅速に特定し、それらが引き起こしている可能性のある問題を軽減できます。

データベースクエリのパフォーマンスを確認するには、ブラウザで戻るか、メニューバーのAPMセクションに移動してAPMのService Mapページに移動し、Service Mapタイルをクリックします。

Dependency mapで推論されたデータベースサービス mysql:petclinic Inferred Database serverを選択し (1)、次に右側のペインをスクロールしてDatabase Query Performance Pane **(2)**を見つけます。

マップで選択したサービスが実際に（推論された）データベースサーバーである場合、このペインには期間に基づく上位90%（P90）のデータベースコールが表示されます。db-queryパフォーマンス機能をさらに詳しく調べるには、ペインの上部にあるDatabase Query Performanceという単語のどこかをクリックします。

これにより、DB-query Performanceの概要画面が表示されます

Database Query Normalization

デフォルトでは、Splunk APMインストルメンテーションはデータベースクエリをサニタイズして、db.statements からシークレットや個人を特定できる情報（PII）などの機密データを削除またはマスクします。データベースクエリの正規化をオフにする方法はこちらで確認できます。

この画面には、Splunk Observability Cloudに送信されたTraces & Spansに基づいて、アプリケーションからデータベースに対して実行されたすべてのDatabase queries **(1)**が表示されます。時間ブロック間で比較したり、Total Time、P90 Latency & Requests **(2)**でソートしたりできることに注意してください。

リスト内の各Database queryについて、時間ウィンドウ中の最高レイテンシ、コールの総数、および1秒あたりのリクエスト数 **(3)**が表示されます。これにより、クエリを最適化できる場所を特定できます。

右側のペイン **(5)**の2つのチャートを使用して、Database Callsを含むトレースを選択できます。Tag Spotlightペイン **(6)**を使用して、エンドポイントやタグに基づいて、データベースコールに関連するタグを確認します。

クエリの詳細ビューを表示する必要がある場合

特定のQuery **(1)**をクリックします。これにより、Query Details pane **(2)**が開き、より詳細な調査に使用できます。

Log Observer

10 minutes

この時点まで、コード変更は一切なく、トレーシング、プロファイリング、データベースクエリパフォーマンスのデータが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 と呼ばれています。

ログを確認する

ログを表示するには、左側のメニューで Log Observer をクリックします。Log Observerに入ったら、フィルターバーの Index が splunk4rookies-workshop に設定されていることを確認してください。(1)

次に、Add Filter をクリックし、Fields (2) オプションを使用して deployment.environment フィールド (3) を検索します。ドロップダウンリストから、あなたのワークショップインスタンスを選択し (4)、= (含める) をクリックします。これで、PetClinicアプリケーションからのログメッセージのみが表示されます。

次に、service.name フィールドを検索し、値 customers-service を選択して = (含める) をクリックします。これがフィルターバー (1) に表示されます。次に、Run Search ボタン (2) をクリックします。

これによりログエントリがリフレッシュされ、customers-service からのエントリのみが表示されるように絞り込まれます。

“Saving pet” で始まるエントリ (1) をクリックします。サイドペーンが開き、関連するトレースIDやスパンID (2) を含む詳細情報を確認できます。

下部のペインには、関連するコンテンツが表示されます。以下のスクリーンショットでは、APMがこのログ行に関連するトレースを見つけたことがわかります (1):

Trace for 960432ac9f16b98be84618778905af50 (2) をクリックすると、このログ行が生成された特定のトレースのAPMウォーターフォールに移動します:

ログに関する Related Content ペーンが表示されていることに注意してください (1)。これをクリックすると、Log Observerに戻り、このトレースの一部であるすべてのログ行が表示されます。

Real User Monitoring

10 minutes

アプリケーションに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 -->

Select the RUM view for the Petclinic App

左側のメニューで RUM をクリックして、RUMの簡単な概要ツアーを始めましょう。次に、Environment フィルター (1) をドロップダウンボックスから変更し、ワークショップインスタンスの名前 <INSTANCE>-workshop (1) を選択します (ここで INSTANCE は、以前に実行したシェルスクリプトの値です)。これのみが選択されていることを確認してください。

次に、App (2) ドロップダウンボックスをアプリの名前に変更します。これは <INSTANCE>-store になります。

Environment と App を選択すると、アプリケーションのRUMステータスを示す概要ページが表示されます。(Summary Dashboardが単一行の数値だけの場合は、縮小表示になっています。アプリケーション名の前にある > (1) をクリックして展開できます)。JavaScriptエラーが発生した場合は、以下のように表示されます:

続けるには、青いリンク (ワークショップ名) をクリックして詳細ページに移動します。これにより、UX Metrics、Front-end Health、Back-end Health、Custom Eventsによるインタラクションの内訳が表示され、過去のメトリクス (デフォルトでは1時間) と比較される新しいダッシュボードビューが表示されます。

通常、最初のチャートには1つの線のみがあります。Petclinicショップに関連するリンクをクリックしてください。この例では http://198.19.249.202:81 です:

これにより、Tag Spotlightページに移動します。

RUM trace Waterfall view & linking to APM

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

User Sessions (1) をクリックすると、タイムウィンドウ中に発生したユーザーセッションのリストが表示されます。

セッションの1つを見たいので、Duration (2) をクリックして期間でソートし、長いものの1つのリンク (3) をクリックしてください:

RUM trace Waterfall view & linking to APM

RUMトレースウォーターフォールを見ています。これは、ユーザーがpetclinicアプリケーションのページにアクセスしたときに、ユーザーデバイス上で何が起こったかを示します。

ウォーターフォールを下にスクロールして、右側の #!/owners/details セグメント (1) を見つけてクリックすると、Vetsリクエストの処理中に発生したアクションのリストが表示されます。HTTPリクエストには、リターンコードの前に青い APM リンクがあることに注意してください。1つを選択し、APMリンクをクリックします。これにより、KubernetesでホストされているこのバックエンドサービスコールのAPM情報が表示されます。

リクエストで何が起こったかを確認するためにドリルダウンしたい場合は、Trace IDのURLをクリックしてください。

これにより、RUMからのリクエストに関連するトレースが表示されます:

サービスへのエントリーポイントに RUM (1) 関連コンテンツリンクが追加されており、バックエンドサービスで何が起こったかを確認した後、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) をアプリケーションに追加して、エンドツーエンドの可観測性を提供できることも学びました。

Kubernetes における Horizontal Pod Autoscaling の監視

45 minutes Author Robert Castley

このハンズオンワークショップでは、Splunk OpenTelemetry Collectorを使用してKubernetes Horizontal Pod Autoscaling (HPA) を監視する方法を学びます。PHP/Apacheアプリケーションとロードジェネレーターをデプロイしてオートスケーリングイベントをトリガーし、スケーリングのライフサイクル全体を観察します。

実践的な演習を通じて、OpenTelemetry Receivers、Kubernetes Namespaces、ReplicaSets、HPAのメカニズムを探求しながら、すべてをSplunk Observability Cloudで監視します。Kubernetes Navigatorの使い方をマスターし、カスタムダッシュボードを構築し、メトリクスとイベントを分析し、スケーリングアクティビティに対するアラートを設定するディテクターを構成します。

このワークショップでは、Splunkが事前設定済みのAWS/EC2上のUbuntu Linuxインスタンスを用意しています。

ワークショップで使用するインスタンスにアクセスするには、ワークショップリーダーから提供されるURLにアクセスしてください。

Kubernetes への OpenTelemetry Collector のデプロイ

1. EC2 インスタンスへの接続

Mac、Linux、またはWindowsデバイスからSSHを使用してワークショップインスタンスに接続できます。インストラクターから提供されたシートへのリンクを開いてください。このシートには、ワークショップインスタンスのIPアドレスとパスワードが記載されています。

情報

ワークショップインスタンスには、このワークショップ用の正しい Access Token と Realm が事前設定されています。これらを設定する必要はありません。

2. Helm を使用した Splunk OTel のインストール

Splunk Helmチャートを使用してOpenTelemetry Collectorをインストールします。まず、Splunk Helmチャートリポジトリを追加して更新します:

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update

Using ACCESS_TOKEN=<REDACTED>
Using REALM=eu0
"splunk-otel-collector-chart" has been added to your repositories
Using ACCESS_TOKEN=<REDACTED>
Using REALM=eu0
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "splunk-otel-collector-chart" chart repository
Update Complete. ⎈Happy Helming!⎈

以下のコマンドでOpenTelemetry Collector Helmをインストールします。編集しないでください:

helm install splunk-otel-collector --version 0.136.0 \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="splunkPlatform.endpoint=$HEC_URL" \
--set="splunkPlatform.token=$HEC_TOKEN" \
--set="splunkPlatform.index=splunk4rookies-workshop" \
splunk-otel-collector-chart/splunk-otel-collector \
-f ~/workshop/k3s/otel-collector.yaml

3. デプロイの確認

kubectl get pods を実行してデプロイの進行状況を監視できます。通常、約30秒後に新しいPodが起動して実行中であることが報告されます。

続行する前に、ステータスが Running と報告されていることを確認してください。

kubectl get pods

NAME                                                         READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-ks9jn                            1/1     Running   0          27s
splunk-otel-collector-agent-lqs4j                            0/1     Running   0          27s
splunk-otel-collector-agent-zsqbt                            1/1     Running   0          27s
splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj   0/1     Running   0          27s

helm インストールで設定されたラベルを使用してログを追跡します（終了するには ctrl + c を押す必要があります）。

kubectl logs -l app=splunk-otel-collector -f --container otel-collector

または、インストール済みの k9s ターミナルUIを使用します。

失敗したインストールの削除

Splunk OpenTelemetry Collectorのインストールでエラーが発生した場合は、以下のコマンドを使用してインストールを削除し、やり直すことができます:

helm delete splunk-otel-collector

K8s Namespaces と DNS

1. Kubernetes における Namespaces

多くのお客様は、Kubernetesを実行するために何らかのプライベートまたはパブリッククラウドサービスを利用しています。一元管理が容易であるため、少数の大規模なKubernetesクラスターのみを持つことを選択することが多いです。

Namespacesは、これらの大規模なKubernetesクラスターを仮想的なサブクラスターに整理する方法です。異なるチームやプロジェクトがKubernetesクラスターを共有する場合に役立ちます。これにより、自分のリソースだけを簡単に表示して作業できるようになります。

クラスター内では任意の数のNamespacesがサポートされており、それぞれが論理的に分離されていますが、相互に通信する機能を持っています。コンポーネントは、Namespaceを選択した場合、または kubectl に --all-namespaces フラグを追加した場合にのみ表示されます。Namespaceを選択することで、プロジェクトに関連するコンポーネントのみを表示できます。

ほとんどのお客様は、アプリケーションを別のNamespaceにインストールすることを望んでいます。このワークショップでは、そのベストプラクティスに従います。

2. Kubernetes における DNS とサービス

Domain Name System（DNS）は、IPアドレスなどのさまざまな情報を覚えやすい名前にリンクするメカニズムです。DNSシステムを使用してリクエスト名をIPアドレスに変換することで、エンドユーザーは目的のドメイン名に簡単にアクセスできます。

ほとんどのKubernetesクラスターには、サービスディスカバリのための軽量なアプローチを提供するデフォルトで設定された内部DNSサービスが含まれています。Podやサービスが作成、削除、またはノード間で移動された場合でも、組み込みのサービスディスカバリにより、アプリケーションはKubernetesクラスター上のサービスを識別して通信することが簡素化されます。

簡単に言えば、KubernetesのDNSシステムは、各Podとサービスに対してDNSエントリを作成します。一般的に、Podは以下のDNS解決を持ちます:

pod-name.my-namespace.pod.cluster-domain.example

例えば、default Namespace内のPodが my_pod というPod名を持ち、クラスターのドメイン名が cluster.local の場合、Podは以下のDNS名を持ちます:

my_pod.default.pod.cluster.local

サービスによって公開されるPodは、以下のDNS解決が利用可能です:

my_pod.service-name.my-namespace.svc.cluster-domain.example

詳細については、こちらを参照してください: DNS for Service and Pods

Apache OTel Receiver

1. PHP/Apache 用の OTel Receiver の確認

YAMLファイル ~/workshop/k3s/otel-apache.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/otel-apache.yaml

このファイルには、PHP/Apacheデプロイメントを監視するためのOpenTelemetryエージェントの設定が含まれています。

agent:
  config:
    receivers:
      receiver_creator:
        receivers:
          apache:
            rule: type == "port" && pod.name matches "apache" && port == 80
            config:
              endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto

2. OpenTelemetry 設定における観測ルール

上記のファイルには、OTel receiver_creator を使用したApacheの観測ルールが含まれています。このReceiverは、観測されたエンドポイントが設定されたルールに一致するかどうかに基づいて、実行時に他のReceiverをインスタンス化できます。

設定されたルールは、検出された各エンドポイントに対して評価されます。ルールがtrueと評価された場合、そのルールのReceiverは、一致したエンドポイントに対して設定どおりに開始されます。

上記のファイルでは、OpenTelemetryエージェントに対して、名前が apache に一致し、ポート 80 が開いているPodを探すように指示しています。見つかると、エージェントは設定されたURLからApacheメトリクスを読み取るApache Receiverを設定します。上記のYAML内のサービス用のK8s DNSベースのURLに注目してください。

Apache設定を使用するには、以下のコマンドで既存のSplunk OpenTelemetry Collector Helmチャートをアップグレードして otel-apache.yaml ファイルを使用します:

helm upgrade splunk-otel-collector \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="splunkPlatform.endpoint=$HEC_URL" \
--set="splunkPlatform.token=$HEC_TOKEN" \
--set="splunkPlatform.index=splunk4rookies-workshop" \
splunk-otel-collector-chart/splunk-otel-collector \
-f ~/workshop/k3s/otel-collector.yaml \
-f ~/workshop/k3s/otel-apache.yaml

注意

デプロイメントの REVISION 番号が変更されました。これは変更を追跡するのに便利な方法です。

Release "splunk-otel-collector" has been upgraded. Happy Helming!
NAME: splunk-otel-collector
LAST DEPLOYED: Mon Nov  4 14:56:25 2024
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-workshop.splunkcloud.com:443/services/collector/event".

Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.

3. Kubernetes ConfigMaps

ConfigMapは、アプリケーションに注入できるキーと値のペアで構成されるKubernetesのオブジェクトです。ConfigMapを使用すると、設定をPodから分離できます。

ConfigMapを使用すると、設定データのハードコーディングを防ぐことができます。ConfigMapは、機密性のない暗号化されていない設定情報を保存および共有するのに便利です。

OpenTelemetry Collector/エージェントは、ConfigMapを使用してエージェントとK8s Cluster Receiverの設定を保存します。変更後にエージェントの現在の設定を確認するには、以下のコマンドを実行します:

kubectl get cm

ワークショップの質問

Collectorで使用されているConfigMapはいくつありますか？

NamespaceからConfigMapのリストを取得したら、otel-agent 用のものを選択し、以下のコマンドで表示します:

kubectl get cm splunk-otel-collector-otel-agent -o yaml

注意

オプション -o yaml は、ConfigMapの内容を読みやすいYAML形式で出力します。

ワークショップの質問

otel-apache.yaml の設定は、CollectorエージェントのConfigMapに表示されていますか？

Apache のデプロイ

1. PHP/Apache デプロイメント YAML の確認

YAMLファイル ~/workshop/k3s/php-apache.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/php-apache.yaml

このファイルには、PHP/Apacheデプロイメントの設定が含まれており、PHP/Apacheイメージの単一レプリカを持つ新しいStatefulSetを作成します。

ステートレスアプリケーションは、どのネットワークを使用しているかを気にせず、永続ストレージを必要としません。ステートレスアプリの例としては、Apache、Nginx、TomcatなどのWebサーバーがあります。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: php-apache
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      run: php-apache
  serviceName: "php-apache-svc"
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: ghcr.io/splunk/php-apache:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "8"
            memory: "8Mi"
          requests:
            cpu: "6"
            memory: "4Mi"

---
apiVersion: v1
kind: Service
metadata:
  name: php-apache-svc
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

2. PHP/Apache のデプロイ

apache Namespaceを作成し、PHP/Apacheアプリケーションをクラスターにデプロイします。

apache Namespaceを作成します:

kubectl create namespace apache

PHP/Apacheアプリケーションをデプロイします:

kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache

デプロイメントが作成されたことを確認します:

kubectl get statefulset -n apache

ワークショップの質問

Apache web servers (OTel) Navigator で、Apacheインスタンスのどのメトリクスが報告されていますか？

ワークショップの質問

Log Observerを使用して、PHP/Apacheデプロイメントの問題は何ですか？

ヒント: フィルターを調整して、k8s.namespace.name = apache および k8s.cluster.name = <your_cluster> を使用してください。

PHP/Apache の問題の修正

1. Kubernetes リソース

特に本番環境のKubernetesクラスターでは、CPUとメモリは貴重なリソースと見なされています。クラスター運用者は通常、デプロイメントでPodまたはサービスが必要とするCPUとメモリの量を指定するよう求めます。これにより、クラスターがソリューションを配置するノードを自動的に管理できます。

これは、アプリケーション/Podのデプロイメントにリソースセクションを配置することで行います。

例:

resources:
  limits:         # Maximum amount of CPU & memory for peek use
    cpu: "8"      # Maximum of 8 cores of CPU allowed at for peek use
    memory: "8Mi" # Maximum allowed 8Mb of memory
  requests:       # Request are the expected amount of CPU & memory for normal use
    cpu: "6"      # Requesting 4 cores of a CPU
    memory: "4Mi" # Requesting 4Mb of memory

詳細については、こちらを参照してください: Resource Management for Pods and Containers

アプリケーションまたはPodがデプロイメントで設定された制限を超えると、Kubernetesはクラスター上の他のアプリケーションを保護するためにPodを強制終了して再起動します。

もう1つのシナリオは、ノードに十分なメモリまたはCPUがない場合です。その場合、クラスターはより多くのスペースがある別のノードにPodを再スケジュールしようとします。

それが失敗した場合、またはアプリケーションをデプロイするときに十分なスペースがない場合、クラスターはワークロード/デプロイメントをスケジュールモードにして、利用可能なノードのいずれかに制限に従ってPodをデプロイするのに十分なスペースができるまで待機します。

2. PHP/Apache デプロイメントの修正

ワークショップの質問

開始する前に、PHP/Apacheデプロイメントの現在の状態を確認しましょう。Alerts & Detectors で、どのディテクターが発火しましたか？この情報は他にどこで見つけることができますか？

PHP/Apache StatefulSetを修正するには、以下のコマンドを使用して ~/workshop/k3s/php-apache.yaml を編集し、CPUリソースを削減します:

vim ~/workshop/k3s/php-apache.yaml

リソースセクションを見つけて、CPU limitsを 1 に、CPU requestsを 0.5 に削減します:

resources:
  limits:
    cpu: "1"
    memory: "8Mi"
  requests:
    cpu: "0.5"
    memory: "4Mi"

変更を保存します（ヒント: Esc を押してから :wq! を入力して変更を保存します）。

次に、既存のStatefulSetを削除して再作成する必要があります。StatefulSetは不変（イミュータブル）であるため、既存のものを削除して新しい変更で再作成する必要があります。

kubectl delete statefulset php-apache -n apache

次に、変更をデプロイします:

kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache

3. 変更の検証

以下のコマンドを実行して、変更が適用されたことを確認できます:

kubectl describe statefulset php-apache -n apache

PodがSplunk Observability Cloudで実行中であることを確認します。

ワークショップの質問

Apache Web Servers ダッシュボードにデータが表示されていますか？

ヒント: フィルターと時間枠を使用してデータを絞り込むことを忘れないでください。

数分間、Apache web servers Navigatorダッシュボードを監視してください。

ワークショップの質問

Hosts reporting チャートでは何が起きていますか？

4. メモリの問題の修正

Apacheダッシュボードに戻ると、メトリクスが送信されなくなっていることに気付くでしょう。別のリソースの問題があり、今回はメモリ不足です。StatefulSetを編集して、以下に示す値にメモリを増やしましょう:

kubectl edit statefulset php-apache -n apache

resources:
  limits:
    cpu: "1"
    memory: 16Mi
  requests:
    cpu: 500m
    memory: 12Mi

変更を保存します。

ヒント

kubectl edit は内容を vi エディターで開きます。Esc を押してから :wq! を入力して変更を保存します。

StatefulSetは不変（イミュータブル）であるため、既存のPodを削除して、StatefulSetが新しい変更で再作成できるようにする必要があります。

kubectl delete pod php-apache-0 -n apache

以下のコマンドを実行して、変更が適用されたことを確認します:

kubectl describe statefulset php-apache -n apache

ロードジェネレーターのデプロイ

それでは、php-apache Podに負荷をかけてみましょう。これを行うには、クライアントとして動作する別のPodを起動する必要があります。クライアントPod内のコンテナは無限ループで実行され、php-apache サービスにHTTP GETを送信し続けます。

1. loadgen YAML の確認

YAMLファイル ~/workshop/k3s/loadgen.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/loadgen.yaml

このファイルには、ロードジェネレーターの設定が含まれており、ロードジェネレーターイメージの2つのレプリカを持つ新しいReplicaSetを作成します。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: loadgen
  labels:
    app: loadgen
spec:
  replicas: 2
  selector:
    matchLabels:
      app: loadgen
  template:
    metadata:
      name: loadgen
      labels:
        app: loadgen
    spec:
      containers:
      - name: infinite-calls
        image: busybox
        command:
        - /bin/sh
        - -c
        - "while true; do wget -q -O- http://php-apache-svc.apache.svc.cluster.local; done"

2. 新しい Namespace の作成

kubectl create namespace loadgen

3. loadgen YAML のデプロイ

kubectl apply -f ~/workshop/k3s/loadgen.yaml --namespace loadgen

ロードジェネレーターをデプロイすると、loadgen NamespaceでPodが実行されているのを確認できます。以前と同様のコマンドを使用して、コマンドラインからPodのステータスを確認してください。

ワークショップの質問

Apache Navigatorでどのメトリクスが大幅に増加しましたか？

4. ロードジェネレーターのスケール

ReplicaSetは、Podの複数のインスタンスを実行し、指定された数のPodを一定に保つプロセスです。その目的は、Podが失敗したりアクセスできなくなったりした場合でも、ユーザーがアプリケーションにアクセスできなくならないように、クラスター内で指定された数のPodインスタンスが常に実行されている状態を維持することです。

ReplicaSetは、既存のPodが失敗した場合に新しいインスタンスを起動し、実行中のインスタンスが指定された数に達していない場合にスケールアップし、同じラベルを持つ別のインスタンスが作成された場合にPodをスケールダウンまたは削除するのに役立ちます。ReplicaSetは、指定された数のPodレプリカが継続的に実行されることを保証し、リソース使用量が増加した場合の負荷分散に役立ちます。

以下のコマンドを使用して、ReplicaSetを4レプリカにスケールしましょう:

kubectl scale replicaset/loadgen --replicas 4 -n loadgen

コマンドラインとSplunk Observability Cloudの両方からレプリカが実行されていることを確認します:

kubectl get replicaset loadgen -n loadgen

ワークショップの質問

Apache Navigatorでどのような影響が見られますか？

ロードジェネレーターを約2〜3分間実行し、Kubernetes NavigatorとApache Navigatorでメトリクスを観察し続けてください。

Horizontal Pod Autoscaling (HPA) のセットアップ

Kubernetesでは、HorizontalPodAutoscalerがワークロードリソース（DeploymentやStatefulSetなど）を自動的に更新し、需要に合わせてワークロードを自動的にスケーリングします。

水平スケーリングとは、負荷の増加に対応してより多くのPodをデプロイすることを意味します。これは垂直スケーリングとは異なります。Kubernetesにおける垂直スケーリングは、ワークロードですでに実行されているPodにより多くのリソース（メモリやCPUなど）を割り当てることを意味します。

負荷が減少し、Podの数が設定された最小値を超えている場合、HorizontalPodAutoscalerはワークロードリソース（Deployment、StatefulSet、またはその他の類似リソース）にスケールダウンするよう指示します。

1. HPA のセットアップ

~/workshop/k3s/hpa.yaml ファイルを確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/hpa.yaml

このファイルには、Horizontal Pod Autoscalerの設定が含まれており、php-apache デプロイメント用の新しいHPAを作成します。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: apache
spec:
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 50
        type: Utilization
  - type: Resource
    resource:
      name: memory
      target:
        averageUtilization: 75
        type: Utilization
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: php-apache

デプロイされると、php-apache は平均CPU使用率が50% を超えるか、デプロイメントの平均メモリ使用率が75% を超えると自動スケールします。最小1 Pod、最大4 Podです。

kubectl apply -f ~/workshop/k3s/hpa.yaml

2. HPA の検証

kubectl get hpa -n apache

Kubernetesの Workloads または Node Detail タブに移動し、HPAデプロイメントを確認します。

ワークショップの質問

追加で作成された php-apache-x Podはいくつありますか？
Apache web servers (OTel) Navigator でどのメトリクスが再び大幅に増加しましたか？

3. HPA レプリカ数の増加

maxReplicas を8に増やします

kubectl edit hpa php-apache -n apache

変更を保存します（ヒント: Esc を押してから :wq! を入力して変更を保存します）。

ワークショップの質問

現在実行中のPodはいくつありますか？
保留中のPodはいくつありますか？
なぜ保留中なのですか？

おめでとうございます！ ワークショップが完了しました。

OpenTelemetry Collector ワークショップ

OpenTelemetry Collector の基本概念
OpenTelemetry Collector の概念と、Splunk Observability Cloud へデータを送信する方法を学びます。
Advanced OpenTelemetry Collector
OpenTelemetry Collector の設定をゼロから行う練習を行い、いくつかの高度な設定シナリオを体験します。

OpenTelemetry でオブザーバビリティをクラウドネイティブに

1 hour Author Robert Castley

概要

OpenTelemetry を始めたばかりの組織では、まずオブザーバビリティバックエンドに直接データを送信することから始めることが多いでしょう。これは初期テストには有効ですが、OpenTelemetry Collector をオブザーバビリティアーキテクチャの一部として使用することで多くのメリットがあり、本番環境へのデプロイには推奨されています。

このワークショップでは、OpenTelemetry Collector の使用に焦点を当て、Splunk Observability Cloud で使用するための Receiver、Processor、Exporter の設定の基本から始めます。参加者は初心者から、分散プラットフォームのビジネスオブザーバビリティニーズを解決するためのカスタムコンポーネントを追加できるレベルまで到達します。

Ninja セクション

ワークショップを通じて、展開可能な Ninja セクションがあります。これらはより実践的で、ワークショップ中または自分の時間に探求できる詳細な技術情報を提供します。

OpenTelemetry プロジェクトは頻繁に開発が行われているため、これらのセクションの内容が古くなる可能性があることに注意してください。詳細が同期していない場合はリンクが提供されます。更新が必要な箇所を見つけた場合はお知らせください。

Ninja: テストしてみよう！

このワークショップを完了すると、正式に OpenTelemetry Collector Ninja になれます！

対象者

このインタラクティブなワークショップは、OpenTelemetry Collector のアーキテクチャとデプロイについて詳しく学びたい開発者およびシステム管理者を対象としています。

前提条件

データ収集の基本的な理解があること
コマンドラインと vim/vi の経験があること
Ubuntu 20.04 LTS または 22.04 LTS を実行しているインスタンス/ホスト/VM があること
- 最小要件は AWS/EC2 t2.micro（1 CPU、1GB RAM、8GB ストレージ）です

学習目標

このワークショップを終えると、参加者は以下ができるようになります

OpenTelemetry のコンポーネントを理解する
Receiver、Processor、Exporter を使用してデータを収集・分析する
OpenTelemetry を使用するメリットを理解する
ビジネスニーズを解決するカスタムコンポーネントを構築する

OpenTelemetry アーキテクチャ

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

flowchart LR;
    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 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 Contrib のインストール

Collector が動作していることを確認する

Collector が動作しているはずです。systemctl コマンドを使用して root として確認します。ステータス表示を終了するには q を押してください。

sudo systemctl status otelcol-contrib

● otelcol-contrib.service - OpenTelemetry Collector Contrib
     Loaded: loaded (/lib/systemd/system/otelcol-contrib.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-10-07 10:27:49 BST; 52s ago
   Main PID: 17113 (otelcol-contrib)
      Tasks: 13 (limit: 19238)
     Memory: 34.8M
        CPU: 155ms
     CGroup: /system.slice/otelcol-contrib.service
             └─17113 /usr/bin/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml

Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Descriptor:
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]:      -> Name: up
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]:      -> Description: The scraping was successful
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]:      -> Unit:
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]:      -> DataType: Gauge
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: NumberDataPoints #0
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Timestamp: 2024-10-07 09:28:36.942 +0000 UTC
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Value: 1.000000
Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]:         {"kind": "exporter", "data_type": "metrics", "name": "debug"}

このワークショップでは、設定ファイルの変更、環境変数の設定、Collector の再起動を複数回行うため、Collector サービスを停止し、起動時の自動起動を無効にする必要があります。

sudo systemctl stop otelcol-contrib && sudo systemctl disable otelcol-contrib

Ninja: Open Telemetry Collector Builder (ocb) を使用して独自の Collector をビルドする

このパートでは、システムに以下がインストールされている必要があります

Golang（最新バージョン）

cd /tmp
wget https://golang.org/dl/go1.20.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz

.profile を編集して、以下の環境変数を追加します

export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

シェルセッションを更新します

source ~/.profile

Go のバージョンを確認します

go version

ocb のインストール
- プロジェクトリリースから ocb バイナリをダウンロードし、以下のコマンドを実行します
```
mv ocb_0.80.0_darwin_arm64 /usr/bin/ocb
chmod 755 /usr/bin/ocb
```
  別の方法として、golang ツールチェーンを使用してローカルでバイナリをビルドすることもできます
```
go install go.opentelemetry.io/collector/cmd/builder@v0.80.0
mv $(go env GOPATH)/bin/builder /usr/bin/ocb
```
（オプション）Docker

なぜ独自の Collector をビルドするのか？

Collector のデフォルトディストリビューション（core と contrib）は、提供する機能が多すぎるか少なすぎるかのどちらかです。

また、contrib Collector を本番環境で実行することは推奨されません。これは、インストールされるコンポーネントの量が多く、そのほとんどがデプロイメントに必要ないためです。

独自の Collector をビルドするメリットは？

独自の Collector バイナリ（一般的にディストリビューションと呼ばれる）を作成することは、必要なものだけをビルドすることを意味します。

これには以下のメリットがあります

より小さなサイズのバイナリ
脆弱性に対して既存の Go スキャナーを使用できる
組織と連携できる内部コンポーネントを含めることができる

Collector をビルドする際の考慮事項は？

さて、いくつかのデメリットがなければ 🥷 Ninja ゾーンとは言えません

Go の経験が推奨される（必須ではないが）
Splunk サポートなし
ディストリビューションとライフサイクル管理の責任

プロジェクトは安定性に向けて取り組んでいますが、変更によってワークフローが壊れないとは限らないことに注意することが重要です。Splunk のチームは、より高いサポートと安定性を提供しており、デプロイメントのニーズに応じたキュレーションされた体験を提供できます。

Ninja ゾーン

必要なツールがすべてインストールされたら、otelcol-builder.yaml という名前の新しいファイルを作成し、以下のディレクトリ構造に従います

.
└── otelcol-builder.yaml

ファイルを作成したら、いくつかの追加メタデータとともにインストールするコンポーネントのリストを追加する必要があります。

この例では、入門用の設定に必要なコンポーネントのみをインストールするビルダーマニフェストを作成します

dist:
  name: otelcol-ninja
  description: A custom build of the Open Telemetry Collector
  output_path: ./dist

extensions:
- gomod: go.opentelemetry.io/collector/extension/ballastextension v0.80.0
- gomod: go.opentelemetry.io/collector/extension/zpagesextension  v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/httpforwarder v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0

exporters:
- gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/splunkhecexporter v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/signalfxexporter v0.80.0

processors:
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0
- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.80.0

receivers:
- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/zipkinreceiver v0.80.0

yaml ファイルが ocb 用に更新されたら、以下のコマンドを実行します

ocb --config=otelcol-builder.yaml

これにより、以下のディレクトリ構造が作成されます

├── dist
│   ├── components.go
│   ├── components_test.go
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   ├── main_others.go
│   ├── main_windows.go
│   └── otelcol-ninja
└── otelcol-builder.yaml

参考資料

https://opentelemetry.io/docs/collector/custom-collector/

デフォルト設定

OpenTelemetry は YAML ファイルを通じて設定されます。これらのファイルには、ニーズに合わせて変更できるデフォルト設定があります。提供されるデフォルト設定を見てみましょう

cat /etc/otelcol-contrib/config.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:

exporters:
  debug:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

おめでとうございます！OpenTelemetry Collector のダウンロードとインストールに成功しました。OTel Ninja への道を順調に歩んでいます。しかしまず、設定ファイルと OpenTelemetry Collector の異なるディストリビューションについて説明していきましょう。

メモ

Splunk は独自の、完全にサポートされた OpenTelemetry Collector ディストリビューションを提供しています。このディストリビューションは、Splunk GitHub リポジトリからインストールするか、Splunk Observability Cloud のウィザードを使用してコピー＆ペーストするだけの簡単なインストールスクリプトを作成できます。このディストリビューションには、OpenTelemetry Collector Contrib ディストリビューションでは利用できない多くの追加機能と拡張が含まれています。

Splunk Distribution of the OpenTelemetry Collector は本番環境でテスト済みです。大多数のお客様が本番環境で使用しています。
このディストリビューションを使用するお客様は、SLA 内で Splunk の公式サポートから直接サポートを受けることができます。
お客様は、メトリクスとトレース収集のコア設定体験に対する将来の破壊的変更を心配することなく、Splunk Distribution of the OpenTelemetry Collector を使用または移行できます（OpenTelemetry ログ収集の設定はベータ版です）。Collector のメトリクスには破壊的変更がある可能性があります。

これから設定ファイルの各セクションを説明し、ホストメトリクスを Splunk Observability Cloud に送信するように変更していきます。

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 Extensions

Health Check

拡張機能は、インストール手順で参照した同じ config.yaml ファイルで設定します。config.yaml ファイルを編集して拡張機能を設定しましょう。pprof と zpages 拡張機能はデフォルトの config.yaml ファイルに既に設定されていることに注意してください。このワークショップでは、Collector のヘルス状態にアクセスできるよう、すべてのネットワークインターフェースでポートを公開するように health_check 拡張機能のみを更新します。

sudo vi /etc/otelcol-contrib/config.yaml

extensions:
  health_check:
    endpoint: 0.0.0.0:13133

Collector を起動します

otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml

この拡張機能により、OpenTelemetry Collector のステータスを確認するためにプローブできる HTTP URL が有効になります。この拡張機能は、Kubernetes で liveness プローブや readiness プローブとして使用できます。curl コマンドについて詳しく知るには、curl man page を確認してください。

新しいターミナルセッションを開き、インスタンスに SSH 接続して以下のコマンドを実行します

curl http://localhost:13133

{"status":"Server available","upSince":"2024-10-07T11:00:08.004685295+01:00","uptime":"12.56420005s"}

OpenTelemetry Collector Extensions

Performance Profiler

Performance Profiler 拡張機能は、golang の net/http/pprof エンドポイントを有効にします。これは通常、開発者がパフォーマンスプロファイルを収集し、サービスの問題を調査するために使用されます。このワークショップではこれを扱いません。

OpenTelemetry Collector Extensions

zPages

zPages は、外部エクスポーターの代わりにインプロセスで使用できる機能です。組み込まれると、バックグラウンドでトレースとメトリクス情報を収集・集約し、リクエストされたときにウェブページでこのデータを提供します。zPages は、Collector が期待どおりに動作していることを確認するための非常に便利な診断機能です。

ServiceZ は、Collector サービスの概要と、pipelinez、extensionz、featurez の各 zPages へのクイックアクセスを提供します。このページには、ビルド情報とランタイム情報も表示されます。

サンプル URL: http://localhost:55679/debug/servicez（localhost をご自身の環境に合わせて変更してください）。

PipelineZ は、Collector で実行されているパイプラインに関する洞察を提供します。タイプ、データが変更されるかどうかの情報を確認でき、各パイプラインで使用されているレシーバー、プロセッサー、エクスポーターの情報も確認できます。

サンプル URL: http://localhost:55679/debug/pipelinez（localhost をご自身の環境に合わせて変更してください）。

ExtensionZ は、Collector でアクティブな拡張機能を表示します。

サンプル URL: http://localhost:55679/debug/extensionz（localhost をご自身の環境に合わせて変更してください）。

Ninja: storage 拡張機能でデータの耐久性を向上させる

このためには、使用しているディストリビューションに file_storage 拡張機能がインストールされていることを確認する必要があります。これは、otelcol-contrib components コマンドを実行することで確認でき、以下のような結果が表示されるはずです

# ... truncated for clarity
extensions:
  - file_storage

buildinfo:
    command: otelcol-contrib
    description: OpenTelemetry Collector Contrib
    version: 0.80.0
receivers:
    - prometheus_simple
    - apache
    - influxdb
    - purefa
    - purefb
    - receiver_creator
    - mongodbatlas
    - vcenter
    - snmp
    - expvar
    - jmx
    - kafka
    - skywalking
    - udplog
    - carbon
    - kafkametrics
    - memcached
    - prometheus
    - windowseventlog
    - zookeeper
    - otlp
    - awsecscontainermetrics
    - iis
    - mysql
    - nsxt
    - aerospike
    - elasticsearch
    - httpcheck
    - k8sobjects
    - mongodb
    - hostmetrics
    - signalfx
    - statsd
    - awsxray
    - cloudfoundry
    - collectd
    - couchdb
    - kubeletstats
    - jaeger
    - journald
    - riak
    - splunk_hec
    - active_directory_ds
    - awscloudwatch
    - sqlquery
    - windowsperfcounters
    - flinkmetrics
    - googlecloudpubsub
    - podman_stats
    - wavefront
    - k8s_events
    - postgresql
    - rabbitmq
    - sapm
    - sqlserver
    - redis
    - solace
    - tcplog
    - awscontainerinsightreceiver
    - awsfirehose
    - bigip
    - filelog
    - googlecloudspanner
    - cloudflare
    - docker_stats
    - k8s_cluster
    - pulsar
    - zipkin
    - nginx
    - opencensus
    - azureeventhub
    - datadog
    - fluentforward
    - otlpjsonfile
    - syslog
processors:
    - resource
    - batch
    - cumulativetodelta
    - groupbyattrs
    - groupbytrace
    - k8sattributes
    - experimental_metricsgeneration
    - metricstransform
    - routing
    - attributes
    - datadog
    - deltatorate
    - spanmetrics
    - span
    - memory_limiter
    - redaction
    - resourcedetection
    - servicegraph
    - transform
    - filter
    - probabilistic_sampler
    - tail_sampling
exporters:
    - otlp
    - carbon
    - datadog
    - f5cloud
    - kafka
    - mezmo
    - skywalking
    - awsxray
    - dynatrace
    - loki
    - prometheus
    - logging
    - azuredataexplorer
    - azuremonitor
    - instana
    - jaeger
    - loadbalancing
    - sentry
    - splunk_hec
    - tanzuobservability
    - zipkin
    - alibabacloud_logservice
    - clickhouse
    - file
    - googlecloud
    - prometheusremotewrite
    - awscloudwatchlogs
    - googlecloudpubsub
    - jaeger_thrift
    - logzio
    - sapm
    - sumologic
    - otlphttp
    - googlemanagedprometheus
    - opencensus
    - awskinesis
    - coralogix
    - influxdb
    - logicmonitor
    - signalfx
    - tencentcloud_logservice
    - awsemf
    - elasticsearch
    - pulsar
extensions:
    - zpages
    - bearertokenauth
    - oidc
    - host_observer
    - sigv4auth
    - file_storage
    - memory_ballast
    - health_check
    - oauth2client
    - awsproxy
    - http_forwarder
    - jaegerremotesampling
    - k8s_observer
    - pprof
    - asapclient
    - basicauth
    - headers_setter

この拡張機能は、エクスポーターが設定されたエンドポイントにデータを送信できない場合に、エクスポーターがデータをディスクにキューイングする機能を提供します。

拡張機能を設定するには、以下の情報を含めるように設定を更新する必要があります。まず、/tmp/otel-data ディレクトリを作成し、読み書き権限を付与してください

extensions:
...
  file_storage:
    directory: /tmp/otel-data
    timeout: 10s
    compaction:
      directory: /tmp/otel-data
      on_start: true
      on_rebound: true
      rebound_needed_threshold_mib: 5
      rebound_trigger_threshold_mib: 3

# ... truncated for clarity

service:
  extensions: [health_check, pprof, zpages, file_storage]

なぜデータをディスクにキューイングするのか？

これにより、Collector はネットワークの中断（さらには Collector の再起動）を乗り越えて、データがアップストリームプロバイダーに送信されることを保証できます。

データをディスクにキューイングする際の考慮事項

ディスクのパフォーマンスにより、データスループットのパフォーマンスに影響を与える可能性があります。

参考資料

設定の確認

拡張機能について学んだので、設定の変更を確認しましょう。

Check-in設定を確認する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:

exporters:
  debug:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

拡張機能について確認したので、次はワークショップのデータパイプライン部分に進みましょう。パイプラインは、Collector 内でデータが辿る経路を定義し、受信から始まり、さらなる処理や変更を経て、最終的にエクスポーターを通じて Collector を出ていきます。

OpenTelemetry Collector のデータパイプラインは、レシーバー、プロセッサー、エクスポーターで構成されています。まずはレシーバーから始めます。

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

OpenTelemetry Collector Receivers

Host Metrics Receiver

Host Metrics Receiver は、さまざまなソースからスクレイピングしたホストシステムに関するメトリクスを生成します。これは、Collector がエージェントとしてデプロイされる場合に使用することを想定しており、このワークショップでもその方法を採用します。

/etc/otel-contrib/config.yaml ファイルを更新して、hostmetrics Receiver を設定しましょう。以下の YAML を receivers セクションの下に挿入してください。インデントはスペース2つで行います。

sudo vi /etc/otelcol-contrib/config.yaml

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:

OpenTelemetry Collector Receivers

Prometheus Receiver

prometheus という別の Receiver があることにも気づくでしょう。Prometheus は、OpenTelemetry Collector が使用するオープンソースのツールキットです。この Receiver は、OpenTelemetry Collector 自体からメトリクスをスクレイピングするために使用されます。これらのメトリクスは、Collector の健全性を監視するために使用できます。

prometheus Receiver を変更して、Collector 自体からメトリクスを収集するためのものであることを明確にしましょう。Receiver の名前を prometheus から prometheus/internal に変更することで、その Receiver が何をしているかがより明確になります。設定ファイルを以下のように更新してください

prometheus/internal:
  config:
    scrape_configs:
    - job_name: 'otel-collector'
      scrape_interval: 10s
      static_configs:
      - targets: ['0.0.0.0:8888']

ダッシュボード例 - Prometheus メトリクス

以下のスクリーンショットは、Prometheus internal Receiver が OpenTelemetry Collector から収集するメトリクスの一部を表示するダッシュボード例です。ここでは、受け入れられたスパン、メトリクス、ログレコードと送信されたものを確認できます。

メモ

以下のスクリーンショットは、Splunk Observability Cloud の標準（OOTB）ダッシュボードで、Splunk OpenTelemetry Collector のインストール状況を簡単に監視できます。

OpenTelemetry Collector Receivers

その他の Receiver

デフォルト設定には、otlp、opencensus、jaeger、zipkin などの他の Receiver があることに気づくでしょう。これらは他のソースからテレメトリデータを受信するために使用されます。このワークショップではこれらの Receiver については取り上げませんので、そのままにしておいてください。

Ninja: Receiver を動的に作成する

Docker コンテナ、Kubernetes Pod、SSH セッションなどの短期間のタスクを監視するために、receiver creator と observer extensions を使用して、これらのサービスが起動するときに新しい Receiver を作成できます。

何が必要ですか？

receiver creator とそれに関連する observer extension を使い始めるには、それらが Collector のビルドマニフェストに含まれている必要があります。

詳細は installation を参照してください。

考慮すべき事項

一部の短期間のタスクでは、username や password などの追加設定が必要な場合があります。これらの値は環境変数で参照するか、 ${file:./path/to/database/password} のようなスキーム展開構文を使用できます。この方法を採用する場合は、組織のシークレット管理のベストプラクティスに従ってください。

Ninja ゾーン

この Ninja ゾーンに必要なことは2つだけです

ビルダーマニフェストに receiver creator と observer extension が追加されていることを確認します。
検出されたエンドポイントとマッチングするために使用できる設定を作成します。

テンプレート化された設定を作成するには、以下のようにします

receiver_creator:
  watch_observers: [host_observer]
  receivers:
    redis:
      rule: type == "port" && port == 6379
      config:
        password: ${env:HOST_REDIS_PASSWORD}

その他の例については、receiver creator の例を参照してください。

設定の確認

Receiver について説明しましたので、設定の変更を確認しましょう。

Check-in設定を確認する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:

exporters:
  debug:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

Receiver を通じてデータが OpenTelemetry Collector にどのように取り込まれるかを確認しました。次は、Collector が受信したデータをどのように処理するかを見ていきましょう。

警告

/etc/otelcol-contrib/config.yaml はまだ完成していないため、この時点では Collector を再起動しないでください。

OpenTelemetry Collector Processors

Processors は、データを受信してからエクスポートするまでの間に実行されます。Processors はオプションですが、一部は推奨されています。OpenTelemetry contrib Collector には 多数の Processors が含まれています。

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

flowchart LR;
    style Processors 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 Processors

Batch Processor

デフォルトでは、batch processor のみが有効になっています。この processor は、データをエクスポートする前にバッチ処理するために使用されます。これは、exporter へのネットワーク呼び出しの回数を減らすのに役立ちます。このワークショップでは、Collector にハードコードされている以下のデフォルト値を継承します

send_batch_size（デフォルト = 8192）：タイムアウトに関係なくバッチが送信されるスパン、メトリクスデータポイント、またはログレコードの数。send_batch_size はトリガーとして機能し、バッチのサイズには影響しません。パイプラインの次のコンポーネントに送信されるバッチサイズの制限を強制する必要がある場合は、send_batch_max_size を参照してください。
timeout（デフォルト = 200ms）：サイズに関係なくバッチが送信されるまでの時間。ゼロに設定すると、send_batch_max_size のみに従ってデータが即座に送信されるため、send_batch_size は無視されます。
send_batch_max_size（デフォルト = 0）：バッチサイズの上限。0 はバッチサイズに上限がないことを意味します。このプロパティは、大きなバッチを小さな単位に分割することを保証します。send_batch_size 以上である必要があります。

Batch processor の詳細については、Batch Processor のドキュメントを参照してください。

OpenTelemetry Collector Processors

Resource Detection Processor

resourcedetection processor は、ホストからリソース情報を検出し、テレメトリデータのリソース値にこの情報を追加または上書きするために使用できます。

デフォルトでは、ホスト名は可能であれば FQDN に設定され、それ以外の場合は OS が提供するホスト名がフォールバックとして使用されます。このロジックは hostname_sources 設定オプションを使用して変更できます。FQDN を取得せずに OS が提供するホスト名を使用するには、hostname_sources を os に設定します。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]

ワークショップインスタンスが AWS/EC2 インスタンスで実行されている場合、EC2 メタデータ API から以下のタグを収集できます（これは他のプラットフォームでは利用できません）。

cloud.provider ("aws")
cloud.platform ("aws_ec2")
cloud.account.id
cloud.region
cloud.availability_zone
host.id
host.image.id
host.name
host.type

これらのタグをメトリクスに追加するために、別の processor を作成します。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]

OpenTelemetry Collector Processors

Attributes Processor

attributes processor は、スパン、ログ、またはメトリクスの属性を変更します。この processor は、指定されたアクションに含めるか除外するかを決定するために、入力データをフィルタリングおよびマッチングする機能もサポートしています。

設定で指定された順序で実行されるアクションのリストを受け取ります。サポートされているアクションは以下の通りです

insert：キーがまだ存在しない入力データに新しい属性を挿入します。
update：キーが存在する入力データの属性を更新します。
upsert：insert または update を実行します。キーがまだ存在しない入力データに新しい属性を挿入し、キーが存在する入力データの属性を更新します。
delete：入力データから属性を削除します。
hash：既存の属性値をハッシュ化（SHA1）します。
extract：正規表現ルールを使用して入力キーからルールで指定されたターゲットキーに値を抽出します。ターゲットキーがすでに存在する場合は上書きされます。

すべてのホストメトリクスに participant.name という新しい属性を insert する attributes processor を作成します。値にはあなたの名前（例：marge_simpson）を設定します。

警告

INSERT_YOUR_NAME_HERE を必ずあなたの名前に置き換えてください。また、名前にスペースを使用しないようにしてください。

ワークショップの後半で、Splunk Observability Cloud でメトリクスをフィルタリングするためにこの属性を使用します。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

Ninja: connector を使用して内部インサイトを取得する

Collector への最新の追加機能の1つは connector の概念で、あるパイプラインの出力を別のパイプラインの入力に接続できます。

これが有益な例として、一部のサービスはエクスポートされるデータポイントの量、エラーステータスを含むログの数、または特定のデプロイ環境から送信されるデータ量に基づいてメトリクスを出力します。count connector はこれをすぐに使える形で対処するのに役立ちます。

processor の代わりに connector を使用する理由

processor は処理したデータを渡す必要があるため、追加データを生成する点で制限があり、追加情報を公開するのが困難です。connector は受信したデータを出力する必要がないため、求めているインサイトを作成する機会を提供します。

例えば、デプロイ環境属性を持たないログ、メトリクス、トレースの数をカウントする connector を作成できます。

デプロイ環境別にデータ使用量を分類できる非常にシンプルな例です。

connector に関する考慮事項

connector は、あるパイプラインからエクスポートされ、別のパイプラインで受信されたデータのみを受け入れます。これは、connector を活用するために Collector の設定をどのように構成するかを検討する必要があることを意味します。

参考資料

設定の確認

processors について説明しました。設定の変更を確認しましょう。

Check-in設定を確認する

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  debug:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

OpenTelemetry Collector Exporters

Exporter はプッシュ型またはプル型で、1つ以上のバックエンド/宛先にデータを送信する方法です。Exporter は1つ以上のデータソースをサポートする場合があります。

このワークショップでは、otlphttp exporter を使用します。OpenTelemetry Protocol (OTLP) は、テレメトリデータを送信するためのベンダー中立で標準化されたプロトコルです。OTLP exporter は、OTLP プロトコルを実装しているサーバーにデータを送信します。OTLP exporter は gRPC と HTTP/JSON の両方のプロトコルをサポートしています。

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

flowchart LR;
    style Exporters 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 Exporters

OTLP HTTP Exporter

HTTP 経由で Splunk Observability Cloud にメトリクスを送信するには、otlphttp エクスポーターを設定する必要があります。

/etc/otelcol-contrib/config.yaml ファイルを編集して、otlphttp エクスポーターを設定しましょう。以下の YAML を exporters セクションの下に挿入してください。インデントは2スペースで揃えます。

また、ディスクがいっぱいになるのを防ぐために、ロギングエクスポーターの詳細度も変更します。デフォルトの detailed は非常に出力が多いです。

exporters:
  debug:
    verbosity: normal
  otlphttp/splunk:

次に、metrics_endpoint を定義してターゲット URL を設定する必要があります。

メモ

Splunk 主催のワークショップに参加している場合、使用しているインスタンスにはすでに Realm 環境変数が設定されています。設定ファイルでその環境変数を参照します。それ以外の場合は、新しい環境変数を作成して Realm を設定する必要があります。例

export REALM="us1"

使用する URL は https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp です。（Splunk はデータレジデンシーのために、世界の主要な地理的ロケーションに Realm を設置しています）。

otlphttp エクスポーターは、traces_endpoint と logs_endpoint にそれぞれターゲット URL を定義することで、トレースとログを送信するように設定することもできます。これらの設定はこのワークショップの範囲外です。

exporters:
  debug:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp

デフォルトでは、すべてのエンドポイントで gzip 圧縮が有効になっています。これはエクスポーター設定で compression: none を設定することで無効にできます。このワークショップでは、データを送信する最も効率的な方法であるため、圧縮を有効のままにしてデフォルトを使用します。

Splunk Observability Cloud にメトリクスを送信するには、アクセストークンを使用する必要があります。これは Splunk Observability Cloud UI で新しいトークンを作成することで行えます。トークンの作成方法の詳細については、Create a token を参照してください。トークンのタイプは INGEST である必要があります。

メモ

Splunk 主催のワークショップに参加している場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定済み）。設定ファイルでその環境変数を参照します。それ以外の場合は、新しいトークンを作成して環境変数として設定する必要があります。例

export ACCESS_TOKEN=<replace-with-your-token>

トークンは、headers: セクションの下に X-SF-TOKEN: ${env:ACCESS_TOKEN} を挿入することで設定ファイルに定義します

exporters:
  debug:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-TOKEN: ${env:ACCESS_TOKEN}

設定の確認

エクスポーターについて説明したので、設定の変更を確認しましょう

Check-in設定を確認する

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  debug:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-Token: ${env:ACCESS_TOKEN}

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

もちろん、metrics_endpoint を OTLP プロトコルをサポートする他のソリューションに向けて設定することも簡単にできます。

次に、config.yaml の service セクションで、設定したレシーバー、プロセッサー、エクスポーターを有効にする必要があります。

OpenTelemetry Collector Service

Service セクションは、receivers、processors、exporters、extensions セクションで定義された設定に基づいて、Collector でどのコンポーネントを有効にするかを設定するために使用します。

情報

コンポーネントが設定されていても、Service セクション内で定義されていない場合、そのコンポーネントは有効になりません。

service セクションは3つのサブセクションで構成されています

extensions
pipelines
telemetry

デフォルト設定では、extension セクションは health_check、pprof、zpages を有効にするよう設定されています。これらは先ほど Extensions モジュールで設定しました。

service:
  extensions: [health_check, pprof, zpages]

それでは、Metric Pipeline を設定しましょう！

OpenTelemetry Collector Service

Hostmetrics Receiver

ワークショップの Receivers セクションで、さまざまなソースからスクレイプされるホストシステムに関するメトリクスを生成する Host Metrics Receiver を定義したことを思い出してください。この receiver を有効にするには、metrics パイプラインに hostmetrics receiver を含める必要があります。

metrics パイプラインで、metrics の receivers セクションに hostmetrics を追加します。

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [debug]

OpenTelemetry Collector Service

Prometheus Internal Receiver

ワークショップの前半で、Collector 内部のメトリクスを収集していることを反映するために prometheus receiver の名前を prometheus/internal に変更しました。

ここで、metrics パイプラインで prometheus/internal receiver を有効にする必要があります。metrics パイプラインの receivers セクションに prometheus/internal を含めるように更新します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch]
      exporters: [debug]

OpenTelemetry Collector Service

Resource Detection Processor

また、Collector がインスタンスのホスト名と AWS/EC2 メタデータをキャプチャできるように、resourcedetection/system と resourcedetection/ec2 processor を追加しました。ここで、metrics パイプラインでこれら2つの processor を有効にする必要があります。

metrics パイプラインの processors セクションに resourcedetection/system と resourcedetection/ec2 を含めるように更新します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2]
      exporters: [debug]

OpenTelemetry Collector Service

Attributes Processor

また、このワークショップの Processors セクションで、Collector がすべてのメトリクスに participant.name という新しい属性を挿入するように attributes/conf processor を追加しました。ここで、metrics パイプラインでこれを有効にする必要があります。

metrics パイプラインの processors セクションに attributes/conf を含めるように更新します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
      exporters: [debug]

OpenTelemetry Collector Service

OTLP HTTP Exporter

ワークショップの Exporters セクションで、メトリクスを Splunk Observability Cloud に送信するための otlphttp exporter を設定しました。ここで、metrics パイプラインでこれを有効にする必要があります。

metrics パイプラインの exporters セクションに otlphttp/splunk を含めるように更新します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
      exporters: [debug, otlphttp/splunk]

Ninja: Collector の内部を観察する

Collector は、実行中のコンポーネントからの追加シグナルを含む、自身の動作に関する内部シグナルをキャプチャします。これは、データフローに関する判断を行うコンポーネントが、その情報をメトリクスまたはトレースとして公開する方法を必要とするためです。

なぜ Collector を監視するのか？

これは「監視者を誰が監視するのか？」という、鶏と卵のような問題ですが、この情報を公開できることは重要です。Collector の歴史において興味深い点は、Go メトリクス SDK が安定版と見なされる前から存在していたため、当面の間、Collector はこの機能を提供するために Prometheus エンドポイントを公開しているということです。

考慮事項

組織内で実行中の各 Collector の内部使用状況を監視すると、大量の新しい Metric Time Series (MTS) が発生する可能性があります。Splunk ディストリビューションでは、これらのメトリクスが厳選されており、予想される増加を予測するのに役立ちます。

Ninja Zone

Collector の内部オブザーバビリティを公開するために、いくつかの追加設定を調整できます

service:
  telemetry:
    logs:
      level: <info|warn|error>
      development: <true|false>
      encoding: <console|json>
      disable_caller: <true|false>
      disable_stacktrace: <true|false>
      output_paths: [<stdout|stderr>, paths...]
      error_output_paths: [<stdout|stderr>, paths...]
      initial_fields:
        key: value
    metrics:
      level: <none|basic|normal|detailed>
      # Address binds the promethues endpoint to scrape
      address: <hostname:port>

service:
  telemetry:
    logs:
      level: info
      encoding: json
      disable_stacktrace: true
      initial_fields:
        instance.name: ${env:INSTANCE}
    metrics:
      address: localhost:8888

参考資料

https://opentelemetry.io/docs/collector/configuration/#service

最終設定

Check-in最終設定を確認する

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  opencensus:
    endpoint: 0.0.0.0:55678

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_binary:
        endpoint: 0.0.0.0:6832
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268

  zipkin:
    endpoint: 0.0.0.0:9411

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  debug:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-Token: ${env:ACCESS_TOKEN}

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [debug]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
      exporters: [debug, otlphttp/splunk]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

  extensions: [health_check, pprof, zpages]

ヒント

Collector を再起動する前に、設定ファイルを検証することをお勧めします。config.yaml ファイルの内容を otelbin.io に貼り付けることで検証できます。

ScreenshotOTelBin

これで動作する設定ができたので、Collector を起動して zPages が何を報告しているか確認しましょう。

otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml

ブラウザで zPages を開きます：http://localhost:55679/debug/pipelinez（localhost を自分の環境に合わせて変更してください）。

データの可視化

Splunk Observability Cloud

OpenTelemetry Collector からメトリクスを Splunk Observability Cloud に送信する設定が完了したので、Splunk Observability Cloud でデータを確認してみましょう。Splunk Observability Cloud への招待を受け取っていない場合は、インストラクターがログイン資格情報を提供します。

その前に、少し面白くするためにインスタンスでストレステストを実行してみましょう。これによりダッシュボードが活性化されます。

sudo apt install stress
while true; do stress -c 2 -t 40; stress -d 5 -t 40; stress -m 20 -t 40; done

Splunk Observability Cloud にログインしたら、左側のナビゲーションを使用してメインメニューから Dashboards に移動します。これによりチームビューが表示されます。このビューの上部にある All Dashboards をクリックします

検索ボックスで OTel Contrib を検索します

情報

ダッシュボードが存在しない場合は、インストラクターがすぐに追加できます。Splunk 主催のワークショップに参加していない場合は、インポートするダッシュボードグループをこのページの下部で見つけることができます。

OTel Contrib Dashboard ダッシュボードをクリックして開き、次にダッシュボード上部の Participant Name ボックスをクリックして、config.yaml で participant.name に設定した名前をドロップダウンリストから選択するか、名前を入力して検索します

これで、OpenTelemetry Collector を設定したホストのホストメトリクスを確認できます。

Download Dashboard Group JSON for importing

OpenTelemetry-Contrib-Dashboard-Group.json (40 KB)

OpenTelemetry Collector 開発

カスタムコンポーネントの開発

OpenTelemetry Collector 用のコンポーネントを構築するには、3つの主要な部分が必要です

Configuration - ユーザーに公開される設定値
Factory - 提供された値を使用してコンポーネントを作成する
Business Logic - コンポーネントが実行する必要がある処理

ここでは、プロジェクトの重要な DevOps メトリクスを追跡できるように、Jenkins と連携するコンポーネントを構築する例を使用します。

測定しようとしているメトリクスは以下の通りです

Lead time for changes - “コミットが本番環境にデプロイされるまでにかかる時間”
Change failure rate - “本番環境で障害を引き起こすデプロイメントの割合”
Deployment frequency - "[チーム]が本番環境に正常にリリースする頻度"
Mean time to recover - "[チーム]が本番環境の障害から復旧するまでにかかる時間"

これらの指標は、ソフトウェア開発チームのパフォーマンスを示すために、Google の DevOps Research and Assessment（DORA）[^1] チームによって特定されました。Jenkins CI を選択した理由は、同じオープンソースソフトウェアのエコシステム内にとどまることで、将来ベンダーが管理する CI ツールが採用するための例として機能できるからです。

計装 vs コンポーネント

組織内のオブザーバビリティのレベルを向上させる際に考慮すべきことがあります。いくつかのトレードオフが生じるためです。

	メリット	デメリット
（自動）計装	システムを監視するために外部 API を監視する必要がありません。	計装を変更するにはプロジェクトへの変更が必要です。
	システムオーナー/開発者がオブザーバビリティを変更する権限を持てます。	追加のランタイム依存関係が必要です。
	システムコンテキストを理解し、キャプチャしたデータを Exemplars と関連付けることができます。	システムのパフォーマンスに影響を与える可能性があります。
コンポーネント	データ名やセマンティクスへの変更をシステムのリリースサイクルとは独立して展開できます。	API の破壊的な変更には、システムと Collector の間で調整されたリリースが必要です。
	収集されるデータの更新/拡張は、ユーザーにとってシームレスな変更です。	キャプチャされたデータのセマンティクスが、新しいシステムリリースと一致しない形で予期せず壊れる可能性があります。
	サポートチームがオブザーバビリティの実践について深い理解を持つ必要がありません。	システムから外部に公開された情報のみを表面化できます。

OpenTelemetry Collector 開発

プロジェクトのセットアップ Ninja

メモ

このワークショップセクションを完了するまでの時間は、経験によって異なります。

行き詰まった場合やインストラクターに沿って進めたい場合は、こちらに完全なソリューションがあります。

新しい Jenkins CI レシーバーの開発を始めるには、まず Golang プロジェクトをセットアップする必要があります。新しい Golang プロジェクトを作成する手順は以下の通りです

${HOME}/go/src/jenkinscireceiver という名前の新しいディレクトリを作成し、そのディレクトリに移動します
1. 実際のディレクトリ名や場所は厳密ではなく、独自の開発ディレクトリを選択して作成できます。
go mod init splunk.conf/workshop/example/jenkinscireceiver を実行して golang モジュールを初期化します
1. これにより go.mod というファイルが作成され、直接的および間接的な依存関係を追跡するために使用されます
2. 最終的には、インポートされる依存関係のチェックサム値である go.sum が生成されます。

Check-ingo.mod を確認する

module splunk.conf/workshop/example/jenkinscireceiver

go 1.20

OpenTelemetry Collector 開発

Configuration の構築

コンポーネントの Configuration 部分は、ユーザーがコンポーネントに対して入力を行う方法です。そのため、設定に使用される値は以下の条件を満たす必要があります

そのフィールドが何を制御するかをユーザーが直感的に理解できること
必須と任意を明確にすること
一般的な名前とフィールドを再利用すること
オプションをシンプルに保つこと

---
jenkins_server_addr: hostname
jenkins_server_api_port: 8089
interval: 10m
filter_builds_by:
    - name: my-awesome-build
      status: amber
track:
    values:
        example.metric.1: yes
        example.metric.2: yes
        example.metric.3: no
        example.metric.4: no

---
# Required Values
endpoint: http://my-jenkins-server:8089
auth:
    authenticator: basicauth/jenkins
# Optional Values
collection_interval: 10m
metrics:
    example.metric.1:
        enabled: true
    example.metric.2:
        enabled: true
    example.metric.3:
        enabled: true
    example.metric.4:
        enabled: true

悪い設定例は、設定のベストプラクティスの逆を行うことがコンポーネントの使いやすさにどのように影響するかを示しています。フィールド値が何であるべきかが明確ではなく、既存のプロセッサにプッシュできる機能が含まれており、フィールド名が Collector に存在する他のコンポーネントと一貫していません。

良い設定例は、必須の値をシンプルに保ち、他のコンポーネントからフィールド名を再利用し、コンポーネントが Jenkins と Collector 間の相互作用のみに焦点を当てることを確保しています。

コードタブは、私たちが追加する必要がある量と、Collector 内の共有ライブラリによってすでに提供されているものを示しています。これらはビジネスロジックに到達したときにより詳細に説明します。Configuration は小さく始まり、追加機能が必要になるとビジネスロジックが含まれるようになると変更されます。

コードを書く

Configuration に必要なコードを実装するために、以下の内容で config.go という新しいファイルを作成します

package jenkinscireceiver

import (
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type Config struct {
    // HTTPClientSettings contains all the values
    // that are commonly shared across all HTTP interactions
    // performed by the collector.
    confighttp.HTTPClientSettings `mapstructure:",squash"`
    // ScraperControllerSettings will allow us to schedule
    // how often to check for updates to builds.
    scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
    // MetricsBuilderConfig contains all the metrics
    // that can be configured.
    metadata.MetricsBuilderConfig `mapstructure:",squash"`
}

OpenTelemetry Collector 開発

コンポーネントのレビュー

Jenkins からメトリクスをキャプチャするために必要なコンポーネントの種類を振り返ります

Extension が解決するビジネスユースケースは以下の通りです

ランタイム設定が必要な共有機能を持つこと
Collector のランタイムを観測することを間接的に支援すること

詳細は Extensions の概要 を参照してください。

Receiver が解決するビジネスユースケースは以下の通りです

リモートソースからデータをフェッチする
リモートソースからデータを受信する

これは一般的に pull 型と push 型のデータ収集と呼ばれ、詳細は Receiver の概要で読むことができます。

Processor が解決するビジネスユースケースは以下の通りです

データ、フィールド、または値の追加や削除
データを観測し、意思決定を行う
バッファリング、キューイング、並び替え

留意すべき点は、Processor を流れるデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があるということです。詳細は Processor の概要をお読みください。

Exporter が解決するビジネスユースケースは以下の通りです

ツール、サービス、またはストレージにデータを送信する

OpenTelemetry Collector は「バックエンド」、つまりオールインワンのオブザーバビリティスイートになることを望んでおらず、むしろ OpenTelemetry を創設した原則を維持しています。つまり、すべての人のためのベンダーに依存しないオブザーバビリティです。詳細を再確認するには、Exporter の概要 をお読みください。

これはワークショップで見逃されたコンポーネントタイプです。比較的新しい Collector への追加であるためです。Connector を考える最良の方法は、異なるテレメトリタイプとパイプライン間で使用できる Processor のようなものです。つまり、Connector はログとしてデータを受け入れ、メトリクスを出力したり、あるパイプラインからメトリクスを受け入れ、観測したデータに関するメトリクスを提供したりできます。

Connector が解決するビジネスケースは以下の通りです

異なるテレメトリタイプ間の変換
- ログからメトリクス
- トレースからメトリクス
- メトリクスからログ
受信データを観測し、独自のデータを生成する
- メトリクスを受け入れ、データの分析メトリクスを生成する。

Processor の概要の Ninja セクションに簡単な概要がありました。新しい Connector コンポーネントの更新についてはプロジェクトを確認してください。

コンポーネントの概要から、Jenkins 用のプルベースのレシーバーを開発することが明確です。

OpenTelemetry Collector 開発

メトリクスの設計

レシーバーでキャプチャしたメトリクスを定義およびエクスポートするために、mdatagen を使用します。これは、YAML で定義されたメトリクスをコードに変換する Collector 用に開発されたツールです。

---
# Type defines the name to reference the component
# in the configuration file
type: jenkins

# Status defines the component type and the stability level
status:
  class: receiver
  stability:
    development: [metrics]

# Attributes are the expected fields reported
# with the exported values.
attributes:
  job.name:
    description: The name of the associated Jenkins job
    type: string
  job.status:
    description: Shows if the job had passed, or failed
    type: string
    enum:
    - failed
    - success
    - unknown

# Metrics defines all the pontentially exported values from this receiver.
metrics:
  jenkins.jobs.count:
    enabled: true
    description: Provides a count of the total number of configured jobs
    unit: "{Count}"
    gauge:
      value_type: int
  jenkins.job.duration:
    enabled: true
    description: Show the duration of the job
    unit: "s"
    gauge:
      value_type: int
    attributes:
    - job.name
    - job.status
  jenkins.job.commit_delta:
    enabled: true
    description: The calculation difference of the time job was finished minus commit timestamp
    unit: "s"
    gauge:
      value_type: int
    attributes:
    - job.name
    - job.status

// To generate the additional code needed to capture metrics,
// the following command to be run from the shell:
//  go generate -x ./...

//go:generate go run github.com/open-telemetry/opentelemetry-collector-contrib/cmd/mdatagen@v0.80.0 metadata.yaml
package jenkinscireceiver

// There is no code defined within this file.

次のセクションに進む前に、これらのファイルをプロジェクトフォルダー内に作成してください。

Factory の構築

Factory は、オブジェクト（この場合は jenkinscireceiver）を提供された設定で動的に作成できるようにするソフトウェアデザインパターンです。より現実世界の例を使うと、電話ショップに行き、自分の説明と正確に一致する電話を求め、それを提供してもらうようなものです。

go generate -x ./... コマンドを実行すると、定義されたメトリクスをエクスポートするために必要なすべてのコードを含む新しいフォルダー jenkinscireceiver/internal/metadata が作成されます。必要なコードは以下の通りです

package jenkinscireceiver

import (
    "errors"

    "go.opentelemetry.io/collector/component"
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

func NewFactory() receiver.Factory {
    return receiver.NewFactory(
        metadata.Type,
        newDefaultConfig,
        receiver.WithMetrics(newMetricsReceiver, metadata.MetricsStability),
    )
}

func newMetricsReceiver(_ context.Context, set receiver.CreateSettings, cfg component.Config, consumer consumer.Metrics) (receiver.Metrics, error) {
    // Convert the configuration into the expected type
    conf, ok := cfg.(*Config)
    if !ok {
        return nil, errors.New("can not convert config")
    }
    sc, err := newScraper(conf, set)
    if err != nil {
        return nil, err
    }
    return scraperhelper.NewScraperControllerReceiver(
        &conf.ScraperControllerSettings,
        set,
        consumer,
        scraperhelper.AddScraper(sc),
    )
}

package jenkinscireceiver

import (
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type Config struct {
    // HTTPClientSettings contains all the values
    // that are commonly shared across all HTTP interactions
    // performed by the collector.
    confighttp.HTTPClientSettings `mapstructure:",squash"`
    // ScraperControllerSettings will allow us to schedule
    // how often to check for updates to builds.
    scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
    // MetricsBuilderConfig contains all the metrics
    // that can be configured.
    metadata.MetricsBuilderConfig `mapstructure:",squash"`
}

func newDefaultConfig() component.Config {
    return &Config{
        ScraperControllerSettings: scraperhelper.NewDefaultScraperControllerSettings(metadata.Type),
        HTTPClientSettings:        confighttp.NewDefaultHTTPClientSettings(),
        MetricsBuilderConfig:      metadata.DefaultMetricsBuilderConfig(),
    }
}

package jenkinscireceiver

type scraper struct {}

func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
    // Create a our scraper with our values
    s := scraper{
        // To be filled in later
    }
    return scraperhelper.NewScraper(metadata.Type, s.scrape)
}

func (scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    // To be filled in
    return pmetrics.NewMetrics(), nil
}

---
dist:
  name: otelcol
  description: "Conf workshop collector"
  output_path: ./dist
  version: v0.0.0-experimental

extensions:
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/basicauthextension v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0

receivers:
  - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
  - gomod: splunk.conf/workshop/example/jenkinscireceiver v0.0.0
    path: ./jenkinscireceiver

processors:
  - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0

exporters:
  - gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
  - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.80.0

# This replace is a go directive that allows for redefine
# where to fetch the code to use since the default would be from a remote project.
replaces:
- splunk.conf/workshop/example/jenkinscireceiver => ./jenkinscireceiver

├── build-config.yaml
└── jenkinscireceiver
    ├── go.mod
    ├── config.go
    ├── factory.go
    ├── scraper.go
    └── internal
      └── metadata

これらのファイルを期待される内容でプロジェクトに書き込んだら、go mod tidy を実行します。これにより、すべてのリモート依存関係がフェッチされ、go.mod が更新され、go.sum ファイルが生成されます。

OpenTelemetry Collector 開発

ビジネスロジックの構築

この時点で、現在何もしないカスタムコンポーネントがあるため、Jenkins からこのデータをキャプチャするために必要なロジックを追加する必要があります。

ここから、実行する必要があるステップは以下の通りです

Jenkins に接続するクライアントを作成する
設定されたすべてのジョブをキャプチャする
設定されたジョブの最後のビルドのステータスを報告する
コミットのタイムスタンプとジョブ完了の時間差を計算する

変更は scraper.go に対して行われます。

Jenkins サーバーに接続できるようにするために、“github.com/yosida95/golang-jenkins” パッケージを使用します。このパッケージは、Jenkins サーバーからデータを読み取るために必要な機能を提供します。

次に、“go.opentelemetry.io/collector/receiver/scraperhelper” ライブラリのヘルパー関数を利用して、コンポーネントの起動が完了した後に Jenkins サーバーに接続できるように start 関数を作成します。

package jenkinscireceiver

import (
    "context"

    jenkins "github.com/yosida95/golang-jenkins"
    "go.opentelemetry.io/collector/component"
    "go.opentelemetry.io/collector/pdata/pmetric"
    "go.opentelemetry.io/collector/receiver"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type scraper struct {
    mb     *metadata.MetricsBuilder
    client *jenkins.Jenkins
}

func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
    s := &scraper{
        mb : metadata.NewMetricsBuilder(cfg.MetricsBuilderConfig, set),
    }

    return scraperhelper.NewScraper(
        metadata.Type,
        s.scrape,
        scraperhelper.WithStart(func(ctx context.Context, h component.Host) error {
            client, err := cfg.ToClient(h, set.TelemetrySettings)
            if err != nil {
                return err
            }
            // The collector provides a means of injecting authentication
            // on our behalf, so this will ignore the libraries approach
            // and use the configured http client with authentication.
            s.client = jenkins.NewJenkins(nil, cfg.Endpoint)
            s.client.SetHTTPClient(client)
            return nil
        }),
    )
}

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    // To be filled in
    return pmetric.NewMetrics(), nil
}

これで Jenkins レシーバーを初期化するために必要なすべてのセットアップコードが完了しました。

ここからは、入力を待っていた scrape メソッドに焦点を当てます。このメソッドは、設定で構成された間隔（デフォルトでは毎分）で実行されます。

設定されたジョブの数をキャプチャしたい理由は、Jenkins サーバーの成長を確認し、オンボードしたプロジェクトの数を測定できるようにするためです。これを行うために、Jenkins クライアントを呼び出してすべてのジョブをリストし、エラーが報告された場合はメトリクスなしでそれを返し、そうでなければメトリクスビルダーからデータを出力します。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value.
    now := pcommon.NewTimestampFromTime(time.Now())

    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))

    // To be filled in

    return s.mb.Emit(), nil
}

前のステップでは、すべてのジョブをキャプチャし、ジョブの数を報告することができました。このステップでは、各ジョブを調べ、報告された値を使用してメトリクスをキャプチャします。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value.
    now := pcommon.NewTimestampFromTime(time.Now())

    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))

    for _, job := range jobs {
        // Ensure we have valid results to start off with
        var (
            build  = job.LastCompletedBuild
            status = metadata.AttributeJobStatusUnknown
        )

        // This will check the result of the job, however,
        // since the only defined attributes are
        // `success`, `failure`, and `unknown`.
        // it is assume that anything did not finish
        // with a success or failure to be an unknown status.

        switch build.Result {
        case "aborted", "not_built", "unstable":
            status = metadata.AttributeJobStatusUnknown
        case "success":
            status = metadata.AttributeJobStatusSuccess
        case "failure":
            status = metadata.AttributeJobStatusFailed
        }

        s.mb.RecordJenkinsJobDurationDataPoint(
            now,
            int64(job.LastCompletedBuild.Duration),
            job.Name,
            status,
        )
    }

    return s.mb.Emit(), nil
}

最後のステップは、コミットからジョブ完了までにかかった時間を計算し、DORA メトリクスを推測するのに役立てることです。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value.
    now := pcommon.NewTimestampFromTime(time.Now())

    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))

    for _, job := range jobs {
        // Ensure we have valid results to start off with
        var (
            build  = job.LastCompletedBuild
            status = metadata.AttributeJobStatusUnknown
        )

        // Previous step here

        // Ensure that the `ChangeSet` has values
        // set so there is a valid value for us to reference
        if len(build.ChangeSet.Items) == 0 {
            continue
        }

        // Making the assumption that the first changeset
        // item is the most recent change.
        change := build.ChangeSet.Items[0]

        // Record the difference from the build time
        // compared against the change timestamp.
        s.mb.RecordJenkinsJobCommitDeltaDataPoint(
            now,
            int64(build.Timestamp-change.Timestamp),
            job.Name,
            status,
        )
    }

    return s.mb.Emit(), nil
}

これらのステップがすべて完了すると、カスタム Jenkins CI レシーバーの構築が完了です！

次のステップ

コンポーネントから欲しい機能がおそらくもっとあるでしょう。例えば

ジョブが使用したブランチ名を含めることはできますか？
ジョブのプロジェクト名を含めることはできますか？
プロジェクトの累積ジョブ期間をどのように計算しますか？
変更が機能することをどのように検証しますか？

この時間を使って、遊んでみたり、壊してみたり、変更したり、ビルドからログをキャプチャしてみたりしてください。

Advanced OpenTelemetry Collector

75 minutes Authors Robert Castley, Charity Anderson, Pieter Hagen, & Geoff Higginbottom

このワークショップの目的は、OpenTelemetry Collector の設定ファイルを作成・変更する際の自信を深めることです。最小限の agent.yaml と gateway.yaml ファイルから始め、いくつかの高度な実際のシナリオに対応できるよう段階的に構築していきます。

このワークショップの重要なポイントは、テレメトリーデータをサードパーティベンダーのバックエンドに送信するのではなく、ローカルに保存するよう OpenTelemetry Collector を設定する方法を学ぶことです。このアプローチはデバッグやトラブルシューティングを簡素化するだけでなく、本番システムへのデータ送信を避けたいテストや開発環境にも最適です。

このワークショップを最大限に活用するために、以下の知識が必要です

OpenTelemetry Collector とその設定ファイル構造の基本的な理解
YAML ファイルの編集スキル

このワークショップのすべての内容はローカルで実行できるよう設計されており、実践的でアクセスしやすい学習体験を提供します。それでは、構築を始めましょう！

ワークショップの概要

このワークショップでは、以下のトピックを取り上げます

Agent と Gateway をローカルでセットアップ: メトリクス、トレース、ログが Agent 経由で Gateway に送られることをテストします。
Agent の耐障害性を強化: フォールトトレランスのための基本設定を行います。
Processor の設定:
- 特定のスパン（例：ヘルスチェック）をドロップしてノイズをフィルタリングします。
- 不要なタグを削除し、機密データを処理します。
- エクスポート前にパイプラインで OTTL（OpenTelemetry Transformation Language）を使用してデータを変換します。
Connector の設定:
- 受信した値に基づいて、データを異なるエンドポイントにルーティングします。

このワークショップを終了すると、さまざまな実際のユースケースに対応する OpenTelemetry Collector の設定に精通しているでしょう。

前提条件

5 minutes

前提条件

vi、vim、nano、またはお好みのテキストエディタを使用して YAML ファイルを編集するスキル
サポートされている環境
- 提供される Splunk Workshop インスタンス（推奨）。ssh アクセス用にポート 2222 への外部アクセスが必要です。
- Apple Mac（Apple Silicon）。jq のインストールが必要です - https://jqlang.org/download/

Exercise

ディレクトリの作成: 環境内で新しいディレクトリを作成し、そのディレクトリに移動します

mkdir advanced-otel-workshop && \
cd advanced-otel-workshop

このワークショップの残りの部分では、このディレクトリを [WORKSHOP] と呼びます。

既存の OpenTelemetry Collector を削除してください

Splunk IM ワークショップを完了している場合は、続行する前に Kubernetes で実行中の Collector を削除してください。以下のコマンドを実行して削除できます

helm delete splunk-otel-collector

その場合、EC2 インスタンスでこのワークショップと干渉する可能性のあるサービスが実行されている場合があるため、以下のコマンドを実行してそれらが存在する場合は停止してください

kubectl delete ~/workshop/apm/deployment.yaml

ワークショップバイナリのダウンロード: [WORKSHOP] ディレクトリに移動し、OpenTelemetry Collector、Load Generator バイナリ、およびセットアップスクリプトをダウンロードします

curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v0.136.0/otelcol_linux_amd64 -o otelcol && \
curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-linux-amd64 -o loadgen && \
curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \
chmod +x setup-workshop.sh

curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v0.136.0/otelcol_darwin_arm64 -o otelcol && \
curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-darwin-arm64 -o loadgen && \
curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \
chmod +x setup-workshop.sh

setup-workshop.sh スクリプトを実行します。このスクリプトは正しい権限を設定し、Agent と Gateway の初期設定も作成します

./setup-workshop.sh

███████╗██████╗ ██╗     ██╗   ██╗███╗   ██╗██╗  ██╗    ██╗
██╔════╝██╔══██╗██║     ██║   ██║████╗  ██║██║ ██╔╝    ╚██╗
███████╗██████╔╝██║     ██║   ██║██╔██╗ ██║█████╔╝      ╚██╗
╚════██║██╔═══╝ ██║     ██║   ██║██║╚██╗██║██╔═██╗      ██╔╝
███████║██║     ███████╗╚██████╔╝██║ ╚████║██║  ██╗    ██╔╝
╚══════╝╚═╝     ╚══════╝ ╚═════╝ ╚═╝  ╚═══╝╚═╝  ╚═╝    ╚═╝

Welcome to the Splunk Advanced OpenTelemetry Workshop!
======================================================

macOS detected. Removing quarantine attributes...
otelcol version v0.126.0
Usage: loadgen [OPTIONS]
Options:
  -base       Send base traces (enabled by default)
  -health     Send health traces
  -security   Send security traces
  -logs       Enable logging of random quotes to quotes.log
  -json       Output logs in JSON format (only applicable with -logs)
  -count      Number of traces or logs to send (default: infinite)
  -h, --help  Display this help message

Example:
  loadgen -health -security -count 10   Send 10 health and security traces
  loadgen -logs -json -count 5          Write 5 random quotes in JSON format to quotes.log
Creating workshop directories...
✓ Created subdirectories:
  ├── 1-agent-gateway
  ├── 2-building-resilience
  ├── 3-dropping-spans
  ├── 4-sensitive-data
  ├── 5-transform-data
  ├── 6-routing-data
  └── 7-sum-count

Creating configuration files for 1-agent-gateway...
Creating OpenTelemetry Collector agent configuration file: 1-agent-gateway/agent.yaml
✓ Configuration file created successfully: 1-agent-gateway/agent.yaml
✓ File size:     4355 bytes

Creating OpenTelemetry Collector gateway configuration file: 1-agent-gateway/gateway.yaml
✓ Configuration file created successfully: 1-agent-gateway/gateway.yaml
✓ File size:     3376 bytes

✓ Completed configuration files for 1-agent-gateway

Creating configuration files for 2-building-resilience...
Creating OpenTelemetry Collector agent configuration file: 2-building-resilience/agent.yaml
✓ Configuration file created successfully: 2-building-resilience/agent.yaml
✓ File size:     4355 bytes

Creating OpenTelemetry Collector gateway configuration file: 2-building-resilience/gateway.yaml
✓ Configuration file created successfully: 2-building-resilience/gateway.yaml
✓ File size:     3376 bytes

✓ Completed configuration files for 2-building-resilience

Workshop environment setup complete!
Configuration files created in the following directories:
  1-agent-gateway/
    ├── agent.yaml
    └── gateway.yaml
  2-building-resilience/
    ├── agent.yaml
    └── gateway.yaml

[WORKSHOP]
├── 1-agent-gateway
├── 2-building-resilience
├── 3-dropping-spans
├── 4-sensitive-data
├── 5-transform-data
├── 6-routing-data
├── 7-sum-count
├── loadgen
├── otelcol
└── setup-workshop.sh

1. Agent 設定の確認

15 minutes

ようこそ！このセクションでは、Agent と Gateway の両方を含む完全に機能する OpenTelemetry セットアップから始めます。

まず、設定ファイルを簡単に確認して、全体的な構造に慣れ、テレメトリーパイプラインを制御する重要なセクションを確認します。

Tip

ワークショップを通じて、複数のターミナルウィンドウを使用します。整理しやすくするために、各ターミナルに固有の名前または色を付けてください。これにより、演習中にターミナルを簡単に識別して切り替えることができます。

これらのターミナルを Agent、Gateway、Loadgen、Test と呼びます。

Exercise

最初のターミナルウィンドウを作成し、Agent と名前を付けます。最初の演習用ディレクトリ [WORKSHOP]/1-agent-gateway に移動し、必要なファイルが生成されていることを確認します
```
cd 1-agent-gateway
ls -l
```
ディレクトリに以下のファイルが表示されるはずです。表示されない場合は、前提条件 セクションで説明されている setup-workshop.sh スクリプトを再実行してください
. ├── agent.yaml └── gateway.yaml

Agent 設定の理解

このワークショップで使用する agent.yaml ファイルの主要なコンポーネントを確認しましょう。メトリクス、トレース、ログをサポートするために重要な追加が行われています。

Receiver

receivers セクションは、Agent がテレメトリーデータを取り込む方法を定義します。このセットアップでは、3種類の Receiver が設定されています

Host Metrics Receiver

hostmetrics:                         # Host Metrics Receiver
  collection_interval: 3600s         # Collection Interval (1hr)
  scrapers:
    cpu:                             # CPU Scraper

ローカルシステムから1時間ごとに CPU 使用率を収集します。これを使用してサンプルメトリクスデータを生成します。

OTLP Receiver（HTTP プロトコル）

otlp:                                # OTLP Receiver
  protocols:
    http:                            # Configure HTTP protocol
      endpoint: "0.0.0.0:4318"       # Endpoint to bind to

Agent がポート 4318 で HTTP 経由でメトリクス、トレース、ログを受信できるようにします。これは、今後の演習で Collector にデータを送信するために使用されます。

FileLog Receiver

filelog/quotes:                      # Receiver Type/Name
  include: ./quotes.log              # The file to read log data from
  include_file_path: true            # Include file path in the log data
  include_file_name: false           # Exclude file name from the log data
  resource:                          # Add custom resource attributes
    com.splunk.source: ./quotes.log  # Source of the log data
    com.splunk.sourcetype: quotes    # Source type of the log data

Agent がローカルログファイル（quotes.log）を tail し、source や sourceType などのメタデータで強化された構造化ログイベントに変換できるようにします。

Exporter

Debug Exporter

  debug:                               # Exporter Type
    verbosity: detailed                # Enabled detailed debug output

OTLPHTTP Exporter
```
  otlphttp:                            # Exporter Type
    endpoint: "http://localhost:5318"  # Gateway OTLP endpoint
```
debug Exporter はワークショップ中の可視性とデバッグのためにデータをコンソールに送信し、otlphttp Exporter はすべてのテレメトリーをローカルの Gateway インスタンスに転送します。
このデュアルエクスポート戦略により、生データをローカルで確認しながら、さらなる処理とエクスポートのためにダウンストリームに送信することができます。

1.1 Gateway 設定の確認

OpenTelemetry Gateway は、テレメトリーデータの受信、処理、エクスポートのための中央ハブとして機能します。テレメトリーソース（アプリケーションやサービスなど）と Splunk Observability Cloud のようなオブザーバビリティバックエンドの間に位置します。

テレメトリートラフィックを集中化することで、Gateway はデータのフィルタリング、エンリッチメント、変換、および1つ以上の宛先へのルーティングなどの高度な機能を実現します。個々のサービスからテレメトリー処理をオフロードすることで負担を軽減し、分散システム全体で一貫した標準化されたデータを確保します。

これにより、オブザーバビリティパイプラインの管理、スケーリング、分析が容易になります。特に複雑なマルチサービス環境では効果的です。

Exercise

2つ目のターミナルウィンドウを開くか作成し、Gateway と名前を付けます。最初の演習ディレクトリ [WORKSHOP]/1-agent-gateway に移動し、gateway.yaml ファイルの内容を確認します。

このファイルは、Gateway モードでデプロイされた OpenTelemetry Collector のコア構造を示しています。

Gateway 設定の理解

このワークショップで Gateway モードの OpenTelemetry Collector がどのように設定されているかを定義する gateway.yaml ファイルを確認しましょう。この Gateway は、Agent からテレメトリーを受信し、処理してから検査または転送のためにエクスポートする役割を担います。

OTLP Receiver（カスタムポート）
```
receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:5318"
```
ポート 5318 は Agent 設定の otlphttp Exporter と一致しており、Agent が送信するすべてのテレメトリーデータが Gateway で受け入れられることを保証します。

メモ

このポートの分離により、競合を回避し、Agent と Gateway の役割間の責任を明確に保ちます。

File Exporter

Gateway は3つの File Exporter を使用して、テレメトリーデータをローカルファイルに出力します。これらの Exporter は以下のように定義されています

exporters:                        # List of exporters
  debug:                          # Debug exporter
    verbosity: detailed           # Enable detailed debug output
  file/traces:                    # Exporter Type/Name
    path: "./gateway-traces.out"  # Path for OTLP JSON output for traces
    append: false                 # Overwrite the file each time
  file/metrics:                   # Exporter Type/Name
    path: "./gateway-metrics.out" # Path for OTLP JSON output for metrics
    append: false                 # Overwrite the file each time
  file/logs:                      # Exporter Type/Name
    path: "./gateway-logs.out"    # Path for OTLP JSON output for logs
    append: false                 # Overwrite the file each time

各 Exporter は、特定のシグナルタイプを対応するファイルに書き込みます。

これらのファイルは Gateway が起動すると作成され、Agent がデータを送信すると実際のテレメトリーが書き込まれます。これらのファイルをリアルタイムで監視して、パイプラインを通過するテレメトリーの流れを観察できます。

1.2 設定の検証とテスト

次に、Gateway と Agent を起動します。Agent は起動時に自動的に Host Metrics を送信するよう設定されています。これにより、データが Agent から Gateway に正しくルーティングされることを確認します。

Exercise

Gateway: Gateway ターミナル ウィンドウで、以下のコマンドを実行して Gateway を起動します

../otelcol --config=gateway.yaml

すべてが正しく設定されている場合、Collector が起動し、出力に Everything is ready. Begin running and processing data. と表示されます。以下のような出力になります

2025-06-09T09:22:11.944+0100    info    service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data. {"resource": {}}

Gateway が実行されると、ポート 5318 で受信データをリッスンし、受信したデータを以下のファイルにエクスポートします

gateway-traces.out
gateway-metrics.out
gateway-logs.out

Agent の起動: Agent ターミナル ウィンドウで、Agent 設定を使用して Agent を起動します

../otelcol --config=agent.yaml

CPU メトリクスの確認:

Agent が起動すると、すぐに CPU メトリクスの送信を開始することを確認します。
Agent と Gateway の両方がデバッグ出力にこのアクティビティを表示します。出力は以下のスニペットのようになります

<snip>
NumberDataPoints #31
Data point attributes:
     -> cpu: Str(cpu3)
     -> state: Str(wait)
StartTimestamp: 2025-07-07 16:49:42 +0000 UTC
Timestamp: 2025-07-09 09:36:21.190226459 +0000 UTC
Value: 77.380000
        {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "metrics"}

この段階で、Agent は1時間ごとまたは再起動ごとに CPU メトリクスを収集し、Gateway に送信し続けます。Gateway はこれらのメトリクスを処理し、gateway-metrics.out という名前のファイルにエクスポートします。このファイルは、パイプラインサービスの一部としてエクスポートされたメトリクスを保存します。

Gateway にデータが到着したことの確認: CPU メトリクス（特に cpu0）が Gateway に正常に到達したことを確認するために、jq コマンドを使用して gateway-metrics.out ファイルを検査します。

以下のコマンドは、system.cpu.time メトリクスをフィルタリングして抽出し、cpu0 に焦点を当てます。メトリクスの状態（例：user、system、idle、interrupt）と対応する値を表示します。

3つ目のターミナルウィンドウを開くか作成し、Tests と名前を付けます。Tests ターミナル で以下のコマンドを実行して system.cpu.time メトリクスを確認します

jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.time") | .sum.dataPoints[] | select(.attributes[0].value.stringValue == "cpu0") | {cpu: .attributes[0].value.stringValue, state: .attributes[1].value.stringValue, value: .asDouble}' gateway-metrics.out

{
  "cpu": "cpu0",
  "state": "user",
  "value": 123407.02
}
{
  "cpu": "cpu0",
  "state": "system",
  "value": 64866.6
}
{
  "cpu": "cpu0",
  "state": "idle",
  "value": 216427.87
}
{
  "cpu": "cpu0",
  "state": "interrupt",
  "value": 0
}

重要

Agent と Gateway のプロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

2. 耐障害性の構築

10 minutes

OpenTelemetry Collector の FileStorage Extension は、より耐障害性の高いテレメトリーパイプラインを構築するための重要なコンポーネントです。これにより、Collector は処理中のデータを確実にチェックポイントし、リトライを効率的に管理し、貴重なテレメトリーを失うことなく一時的な障害を適切に処理できます。

FileStorage を有効にすると、Collector は中間状態をディスクに永続化できるため、ネットワークの中断、バックエンドの停止、または Collector の再起動時にもトレース、メトリクス、ログが失われないことが保証されます。つまり、ネットワーク接続が切断されたり、バックエンドが一時的に利用できなくなったりしても、Collector はテレメトリーの受信とバッファリングを継続し、接続が復旧すると配信をシームレスに再開します。

FileStorage Extension をパイプラインに統合することで、オブザーバビリティスタックの耐久性を強化し、接続が不安定な環境でも高品質なテレメトリー取り込みを維持できます。

メモ

このソリューションは、接続ダウンタイムが短い場合（最大15分）のメトリクスに対して機能します。ダウンタイムがこれを超えると、Splunk Observability Cloud はデータポイントの順序が乱れないようにデータをドロップする可能性があります。

ログについては、今後の Splunk OpenTelemetry Collector リリースで完全なエンタープライズ対応ソリューションを実装する計画があります。

2.1 File Storage の設定

この演習では、agent.yaml ファイルの extensions: セクションを更新します。このセクションは OpenTelemetry 設定 YAML の一部であり、OpenTelemetry Collector の動作を拡張または変更するオプションのコンポーネントを定義します。

これらのコンポーネントはテレメトリーデータを直接処理しませんが、Collector の機能を向上させる貴重な機能とサービスを提供します。

Exercise

重要

すべての ターミナルウィンドウを 2-building-resilience ディレクトリに移動し、clear コマンドを実行してください。

ディレクトリ構造は以下のようになります

.
├── agent.yaml
└── gateway.yaml

agent.yaml の更新: Agent ターミナル ウィンドウで、既存の health_check Extension の下に file_storage Extension を追加します

  file_storage/checkpoint:             # Extension Type/Name
    directory: "./checkpoint-dir"      # Define directory
    create_directory: true             # Create directory
    timeout: 1s                        # Timeout for file operations
    compaction:                        # Compaction settings
      on_start: true                   # Start compaction at Collector startup
      # Define compaction directory
      directory: "./checkpoint-dir/tmp"
      max_transaction_size: 65536      # Max. size limit before compaction occurs

Exporter への file_storage の追加: otlphttp Exporter を変更して、リトライとキューイングメカニズムを設定し、障害が発生した場合にデータが保持され再送信されるようにします。endpoint: "http://localhost:5318" の下に以下を追加し、インデントが endpoint と一致していることを確認してください

    retry_on_failure:
      enabled: true                    # Enable retry on failure
    sending_queue:                     #
      enabled: true                    # Enable sending queue
      num_consumers: 10                # No. of consumers
      queue_size: 10000                # Max. queue size
      storage: file_storage/checkpoint # File storage extension

services セクションの更新: 既存の extensions: セクションに file_storage/checkpoint Extension を追加します。設定は以下のようになります

service:
  extensions:
  - health_check
  - file_storage/checkpoint            # Enabled extensions for this collector

metrics パイプラインの更新: この演習では、デバッグとログのノイズを減らすために、Metric パイプラインから hostmetrics Receiver をコメントアウトします。設定は以下のようになります

    metrics:
      receivers:
      # - hostmetrics                    # Hostmetric reciever (cpu only)
      - otlp

otelbin.io を使用して Agent 設定を検証してください。参考までに、パイプラインの metrics: セクションは以下のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;otlp&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRO1(memory_limiter<br>fa:fa-microchip):::processor
      PRO2(resourcedetection<br>fa:fa-microchip):::processor
      PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
      EXP1(&ensp;debug&ensp;<br>fa:fa-upload):::exporter
      EXP2(otlphttp<br>fa:fa-upload):::exporter
      EXP3(&ensp;file&ensp;<br>fa:fa-upload):::exporter
    %% Links
    subID1:::sub-metrics
    subgraph " "
      subgraph subID1[**Metrics**]
      direction LR
      REC1 --> PRO1
      PRO1 --> PRO2
      PRO2 --> PRO3
      PRO3 --> EXP1
      PRO3 --> EXP3
      PRO3 --> EXP2
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;

2.2 耐障害性テスト用の環境セットアップ

次に、File Storage 設定をテストする準備として環境を設定します。

Exercise

Gateway の起動: Gateway ターミナル ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent の起動: Agent ターミナル ウィンドウで以下を実行します

../otelcol --config=agent.yaml

5つのテストスパンを送信: Loadgen ターミナル ウィンドウで以下を実行します

../loadgen -count 5

Agent と Gateway の両方がデバッグログを表示し、Gateway が ./gateway-traces.out ファイルを作成するはずです。

すべてが正常に機能している場合、システムの耐障害性のテストに進むことができます。

2.3 障害のシミュレーション

Agent の耐障害性を評価するために、一時的な Gateway の停止をシミュレートし、Agent がそれをどのように処理するかを観察します

Exercise

ネットワーク障害のシミュレーション: Gateway ターミナル で Ctrl-C を使用して Gateway を停止し、Gateway のコンソールが停止したことを示すまで待ちます。Agent は引き続き実行されますが、Gateway にデータを送信できません。Gateway ターミナル の出力は以下のようになります

2025-07-09T10:22:37.941Z        info    service@v0.126.0/service.go:345 Shutdown complete.      {"resource": {}}

トレースの送信: Loadgen ターミナル ウィンドウで、loadgen を使用してさらに5つのトレースを送信します。

../loadgen -count 5

Agent のリトライメカニズムが有効になり、データを再送信しようと継続的に試みていることに注目してください。Agent のコンソール出力には、以下のようなメッセージが繰り返し表示されます

2025-01-28T14:22:47.020+0100  info  internal/retry_sender.go:126  Exporting failed. Will retry the request after interval.  {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"}

Agent の停止: Agent ターミナル ウィンドウで、Ctrl-C を使用して Agent を停止します。Agent のコンソールが停止を確認するまで待ちます

2025-07-09T10:25:59.344Z        info    service@v0.126.0/service.go:345 Shutdown complete.      {"resource": {}}

重要

Agent を停止すると、リトライ用にメモリに保持されているメトリクス、トレース、ログは失われます。ただし、FileStorage Extension を設定しているため、ターゲットエンドポイントでまだ受け入れられていないすべてのテレメトリーはディスクに安全にチェックポイントされています。

Agent の停止は、Agent が再起動されたときにシステムがどのように復旧するかを明確に示すための重要なステップです。

2.4 復旧

この演習では、Gateway Collector を再起動することで、OpenTelemetry Collector がネットワーク障害からどのように復旧するかをテストします。Gateway が再び利用可能になると、Agent は最後にチェックポイントされた状態からデータの送信を再開し、データ損失がないことを保証します。

Exercise

Gateway の再起動: Gateway ターミナル ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent の再起動: Agent ターミナル ウィンドウで以下を実行します

../otelcol --config=agent.yaml

Agent が起動して実行されると、File_Storage Extension がチェックポイントフォルダー内のバッファされたデータを検出します。最後のチェックポイントフォルダーから保存されたスパンをデキューし始め、データが失われないことを保証します。

Agent デバッグ出力の確認: Agent のデバッグ出力は変化せず、以下の行を表示し続け、新しいデータがエクスポートされていないことを示していることに注意してください

2025-07-11T08:31:58.176Z        info    service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data.   {"resource": {}}

Gateway デバッグ出力の確認 Gateway のデバッグ画面から、以前見逃されていたトレースを追加のアクションなしで受信し始めていることが確認できるはずです。例

Attributes:
   -> user.name: Str(Luke Skywalker)
   -> user.phone_number: Str(+1555-867-5309)
   -> user.email: Str(george@deathstar.email)
   -> user.password: Str(LOTR>StarWars1-2-3)
   -> user.visa: Str(4111 1111 1111 1111)
   -> user.amex: Str(3782 822463 10005)
   -> user.mastercard: Str(5555 5555 5555 4444)
   -> payment.amount: Double(75.75)
      {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "traces"}

gateway-traces.out ファイルの確認: jq を使用して、再作成された gateway-traces.out 内のトレース数をカウントします。Gateway がダウンしていたときに送信した数と一致するはずです。

jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out

"5 resourceSpans found"

重要

Agent と Gateway のプロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

まとめ

この演習では、file_storage Extension の設定、otlp Exporter のリトライメカニズムの有効化、および一時的なデータ保存用のファイルベースのキューの使用により、OpenTelemetry Collector の耐障害性を強化する方法を示しました。

ファイルベースのチェックポイントとキューの永続化を実装することで、テレメトリーパイプラインが一時的な中断から適切に復旧できることを保証し、本番環境でより堅牢で信頼性の高いものにします。

3. Spanのドロップ

5 minutes

このセクションでは、Filter Processor を使用して、特定の条件に基づいてSpanを選択的にドロップする方法を説明します。

具体的には、Span名に基づいてトレースをドロップします。これは、ヘルスチェックや内部通信トレースなどの不要なSpanをフィルタリングするためによく使用されます。今回は、ヘルスチェックリクエストに関連付けられることが多く、通常は非常に「ノイジー」な "/_healthz" を含むSpanをフィルタリングします。

Exercise

重要

すべてのターミナルウィンドウを 3-dropping-spans ディレクトリに移動し、clear コマンドを実行してください。

2-building-resilience ディレクトリから *.yaml を 3-dropping-spans にコピーします。更新後のディレクトリ構造は次のようになります

.
├── agent.yaml
└── gateway.yaml

次に、filter processor と対応するパイプラインを設定します。

3.1 設定

Exercise

Gateway terminal ウィンドウに切り替えて、gateway.yaml ファイルを開きます。以下の設定で processors セクションを更新します

filter プロセッサを追加する /_healthz という名前のSpanを除外するようにGatewayを設定します。error_mode: ignore ディレクティブは、フィルタリング中に発生したエラーを無視し、パイプラインがスムーズに動作し続けることを保証します。traces セクションはフィルタリングルールを定義し、/_healthz という名前のSpanを除外対象として指定します。
```
  filter/health:                       # Defines a filter processor
    error_mode: ignore                 # Ignore errors
    traces:                            # Filtering rules for traces
      span:                            # Exclude spans named "/_healthz"
       - 'name == "/_healthz"'
```
traces パイプラインに filter プロセッサを追加する traces パイプラインに filter/health プロセッサを追加します。最適なパフォーマンスを得るために、フィルターはできるだけ早い段階に配置します。memory_limiter の直後、batch プロセッサの前に配置してください。設定は次のようになります
```
  traces:
    receivers:
      - otlp
    processors:
      - memory_limiter
      - filter/health             # Filters data based on rules
      - resource/add_mode
      - batch
    exporters:
      - debug
      - file/traces
```

この設定により、ヘルスチェック関連のSpan（/_healthz）がパイプラインの早い段階でフィルタリングされ、テレメトリーデータの不要なノイズが削減されます。

otelbin.io を使用してAgent設定を検証します。参考として、パイプラインの traces: セクションは次のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;otlp&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRO1(memory_limiter<br>fa:fa-microchip):::processor
      PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
      PRO4(filter<br>fa:fa-microchip<br>health):::processor
      PRO5(batch<br>fa:fa-microchip):::processor
      EXP1(&ensp;debug&ensp;<br>fa:fa-upload):::exporter
      EXP2(&ensp;&ensp;file&ensp;&ensp;<br>fa:fa-upload<br>traces):::exporter
    %% Links
    subID1:::sub-traces
    subgraph " "
      subgraph subID1[**Traces**]
      direction LR
      REC1 --> PRO1
      PRO1 --> PRO4
      PRO4 --> PRO3
      PRO3 --> PRO5
      PRO5 --> EXP1
      PRO5 --> EXP2
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;

3.2 Filter Processorのテスト

設定をテストするには、"/_healthz" という名前のSpanを含むトレースデータを生成する必要があります。

Exercise

Gatewayを起動する：Gateway terminal ウィンドウで Gateway を起動します。

../otelcol --config ./gateway.yaml

Agentを起動する：Agent terminal ウィンドウで Agent を起動します。

../otelcol --config ./agent.yaml

Loadgenを起動する：Loadgen terminal ウィンドウで、次のコマンドを実行してヘルスチェックSpanを有効にした状態でロードジェネレーターを起動します

../loadgen -health -count 5

Agent terminal のデバッグ出力に _healthz Spanが表示されます

InstrumentationScope healthz 1.0.0
Span #0
   Trace ID       : 0cce8759b5921c8f40b346b2f6e2f4b6
   Parent ID      :
   ID             : bc32bd0e4ddcb174
   Name           : /_healthz
   Kind           : Server
   Start time     : 2025-07-11 08:47:50.938703979 +0000 UTC
   End time       : 2025-07-11 08:47:51.938704091 +0000 UTC
   Status code    : Ok
   Status message : Success

これらは、先ほど設定したFilter Processorによってドロップされるため、Gateway のデバッグ出力には表示されません。

agent.out を確認する：Test terminal で jq を使用して、Agent が受信したSpanの名前を確認します

jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./agent.out

"Span 1 found with name /movie-validator"
"Span 2 found with name /_healthz"
"Span 3 found with name /movie-validator"
"Span 4 found with name /_healthz"
"Span 5 found with name /movie-validator"
"Span 6 found with name /_healthz"
"Span 7 found with name /movie-validator"
"Span 8 found with name /_healthz"
"Span 9 found with name /movie-validator"
"Span 10 found with name /_healthz"

Gateway のデバッグ出力を確認する：jq を使用して、Gateway が受信したSpanの名前を確認します

jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./gateway-traces.out

gateway-metrics.out ファイルには /_healthz という名前のSpanは含まれません。

"Span 1 found with name /movie-validator"
"Span 2 found with name /movie-validator"
"Span 3 found with name /movie-validator"
"Span 4 found with name /movie-validator"
"Span 5 found with name /movie-validator"

Tip

Filter Processorで最適なパフォーマンスを確保するには、受信データの形式を十分に理解し、設定を厳密にテストしてください。できるだけ具体的なフィルタリング条件を使用して、重要なデータを誤ってドロップするリスクを最小限に抑えてください。

この設定は、さまざまな属性、タグ、またはカスタム条件に基づいてSpanをフィルタリングするように拡張でき、特定のオブザーバビリティ要件に合わせて OpenTelemetry Collector の柔軟性と効率を向上させることができます。

重要

Agent と Gateway プロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

4. 機密データの秘匿化

10 minutes

このセクションでは、OpenTelemetry Collector を設定して、テレメトリーSpanから特定のタグを削除し、機密データを秘匿化する方法を学びます。これは、クレジットカード番号、個人データ、その他のセキュリティ関連の詳細など、処理またはエクスポートする前に匿名化する必要がある機密情報を保護するために重要です。

OpenTelemetry Collector の主要なプロセッサの設定について説明します

Attributes Processor：特定のSpan属性を変更または削除します。
Redaction Processor：機密データが保存または送信される前にサニタイズされることを保証します。

Exercise

重要

すべてのターミナルウィンドウを 4-sensitive-data ディレクトリに移動し、clear コマンドを実行してください。

3-dropping-spans ディレクトリから *.yaml を 4-sensitive-data にコピーします。更新後のディレクトリ構造は次のようになります

.
├── agent.yaml
└── gateway.yaml

4.1 設定

このステップでは、agent.yaml を修正して attributes と redaction プロセッサを追加します。これらのプロセッサは、Span属性内の機密データがログに記録またはエクスポートされる前に適切に処理されるようにします。

以前、コンソールに表示されたSpan属性の一部に個人情報や機密データが含まれていることに気づいたかもしれません。これから、この情報を効果的にフィルタリングおよび秘匿化するために必要なプロセッサを設定します。

Attributes:
     -> user.name: Str(George Lucas)
     -> user.phone_number: Str(+1555-867-5309)
     -> user.email: Str(george@deathstar.email)
     -> user.account_password: Str(LOTR>StarWars1-2-3)
     -> user.visa: Str(4111 1111 1111 1111)
     -> user.amex: Str(3782 822463 10005)
     -> user.mastercard: Str(5555 5555 5555 4444)
  {"kind": "exporter", "data_type": "traces", "name": "debug"}

Exercise

Agent terminal ウィンドウに切り替えて、エディタで agent.yaml ファイルを開きます。テレメトリーデータのセキュリティとプライバシーを強化するために、2つのプロセッサを追加します。

1. attributes プロセッサを追加する：Attributes Processor を使用すると、Span属性（タグ）の値を更新、削除、またはハッシュ化して変更できます。これは、機密情報をエクスポートする前に難読化する場合に特に便利です。

このステップでは

user.phone_number 属性を静的な値（"UNKNOWN NUMBER"）に更新します。
user.email 属性をハッシュ化して、元のメールアドレスが公開されないようにします。
user.password 属性を削除して、Spanから完全に取り除きます。

  attributes/update:
    actions:                           # Actions
      - key: user.phone_number         # Target key
        action: update                 # Update action
        value: "UNKNOWN NUMBER"        # New value
      - key: user.email                # Target key
        action: hash                   # Hash the email value
      - key: user.password             # Target key
        action: delete                 # Delete the password

2. redaction プロセッサを追加する：Redaction Processor は、クレジットカード番号やその他の個人識別情報（PII）などの定義済みパターンに基づいて、Span属性内の機密データを検出して秘匿化します。

このステップでは

すべての属性が処理されるように allow_all_keys: true を設定します（false に設定すると、明示的に許可されたキーのみが保持されます）。
Visa と MasterCard のクレジットカード番号を検出して秘匿化するための正規表現を blocked_values で定義します。
summary: debug オプションは、デバッグ目的で秘匿化プロセスに関する詳細情報をログに記録します。

  redaction/redact:
    allow_all_keys: true               # If false, only allowed keys will be retained
    blocked_values:                    # List of regex patterns to block
      - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b'       # Visa
      - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b'  # MasterCard
    summary: debug                     # Show debug details about redaction

traces パイプラインを更新する：両方のプロセッサを traces パイプラインに統合します。最初は redaction プロセッサをコメントアウトしておいてください（後の演習で有効にします）。設定は次のようになります

    traces:
      receivers:
      - otlp
      processors:
      - memory_limiter
      - attributes/update              # Update, hash, and remove attributes
      #- redaction/redact               # Redact sensitive fields using regex
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - file
      - otlphttp

otelbin.io を使用してAgent設定を検証します。参考として、パイプラインの traces: セクションは次のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;otlp&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRML(memory_limiter<br>fa:fa-microchip):::processor
      PRRD(resourcedetection<br>fa:fa-microchip):::processor
      PRRS(resource<br>fa:fa-microchip<br>add_mode):::processor
      PRUP(attributes<br>fa:fa-microchip<br>update):::processor
      EXP1(otlphttp<br>fa:fa-upload):::exporter
      EXP2(&ensp;&ensp;debug&ensp;&ensp;<br>fa:fa-upload):::exporter
      EXP3(file<br>fa:fa-upload):::exporter

    %% Links
    subID1:::sub-traces
    subgraph " "
      subgraph subID1[**Traces**]
      direction LR
      REC1 --> PRML
      PRML --> PRUP
      PRUP --> PRRD
      PRRD --> PRRS
      PRRS --> EXP2
      PRRS --> EXP3
      PRRS --> EXP1
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;

4.2 Attribute Processorのテスト

この演習では、Agent がエクスポートする前に、Spanデータから user.account_password を削除し、user.phone_number 属性を更新し、user.email をハッシュ化します。

Exercise

Gatewayを起動する：Gateway terminal ウィンドウで Gateway を起動します。

../otelcol --config=gateway.yaml

Agentを起動する：Agent terminal ウィンドウで Agent を起動します。

../otelcol --config=agent.yaml

Load Generatorを起動する：Loadgen terminal ウィンドウで loadgen を起動します

../loadgen -count 1

デバッグ出力を確認する：Agent と Gateway の両方で、user.account_password が削除され、user.phone_number と user.email が更新されていることを確認します

   -> user.name: Str(George Lucas)
   -> user.phone_number: Str(UNKNOWN NUMBER)
   -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
   -> payment.amount: Double(51.71)
   -> user.visa: Str(4111 1111 1111 1111)
   -> user.amex: Str(3782 822463 10005)
   -> user.mastercard: Str(5555 5555 5555 4444)

    -> user.name: Str(George Lucas)
    -> user.phone_number: Str(+1555-867-5309)
    -> user.email: Str(george@deathstar.email)
    -> user.password: Str(LOTR>StarWars1-2-3)
    -> user.visa: Str(4111 1111 1111 1111)
    -> user.amex: Str(3782 822463 10005)
    -> user.mastercard: Str(5555 5555 5555 4444)
    -> payment.amount: Double(95.22)

ファイル出力を確認する：jq を使用して、gateway-traces.out で user.account_password が削除され、user.phone_number と user.email が更新されていることを検証します

jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.password" or .key == "user.phone_number" or .key == "user.email") | {key: .key, value: .value.stringValue}' ./gateway-traces.out

user.account_password が削除され、user.phone_number と user.email が更新されていることに注目してください

{
  "key": "user.phone_number",
  "value": "UNKNOWN NUMBER"
}
{
  "key": "user.email",
  "value": "62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287"
}

重要

Agent と Gateway プロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

4.3 Redaction Processorのテスト

redaction プロセッサは、テレメトリーデータからどの属性と値を許可または削除するかを正確に制御できます。

この演習では、Agent がエクスポートする前に、Spanデータの user.visa と user.mastercard の値を秘匿化します。

Exercise

Gatewayを起動する：Gateway terminal ウィンドウで Gateway を起動します。

../otelcol --config=gateway.yaml

redaction/redact プロセッサを有効にする：Agent terminal ウィンドウで、agent.yaml を編集して前の演習で追加した # を削除します。

    traces:
      receivers:
      - otlp
      processors:
      - memory_limiter
      - attributes/update              # Update, hash, and remove attributes
      - redaction/redact               # Redact sensitive fields using regex
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - file
      - otlphttp

Agentを起動する：Agent terminal ウィンドウで Agent を起動します。

../otelcol --config=agent.yaml

Load Generatorを起動する：Loadgen terminal ウィンドウで loadgen を起動します

../loadgen -count 1

デバッグ出力を確認する：Agent と Gateway の両方で、user.visa と user.mastercard の値が更新されていることを確認します。user.amex 属性の値は、blocked_values に一致する正規表現パターンが追加されていないため、秘匿化されていないことに注意してください。

   -> user.name: Str(George Lucas)
   -> user.phone_number: Str(UNKNOWN NUMBER)
   -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
   -> payment.amount: Double(69.71)
   -> user.visa: Str(****)
   -> user.amex: Str(3782 822463 10005)
   -> user.mastercard: Str(****)
   -> redaction.masked.keys: Str(user.mastercard,user.visa)
   -> redaction.masked.count: Int(2)

    -> user.name: Str(George Lucas)
    -> user.phone_number: Str(+1555-867-5309)
    -> user.email: Str(george@deathstar.email)
    -> user.password: Str(LOTR>StarWars1-2-3)
    -> user.visa: Str(4111 1111 1111 1111)
    -> user.amex: Str(3782 822463 10005)
    -> user.mastercard: Str(5555 5555 5555 4444)
    -> payment.amount: Double(65.54)

メモ

redaction プロセッサに summary:debug を含めると、デバッグ出力に、どの一致するキー値が秘匿化されたか、およびマスクされた値の数に関するサマリー情報が含まれます。

     -> redaction.masked.keys: Str(user.mastercard,user.visa)
     -> redaction.masked.count: Int(2)

ファイル出力を確認する：jq を使用して、gateway-traces.out で user.visa と user.mastercard が更新されていることを検証します。

jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.visa" or .key == "user.mastercard" or .key == "user.amex") | {key: .key, value: .value.stringValue}' ./gateway-traces.out

blocked_values に一致する正規表現パターンが追加されていないため、user.amex は秘匿化されていないことに注意してください

{
  "key": "user.visa",
  "value": "****"
}
{
  "key": "user.amex",
  "value": "3782 822463 10005"
}
{
  "key": "user.mastercard",
  "value": "****"
}

これらは、attributes と redaction プロセッサを設定して機密データを保護する方法のほんの一例です。

重要

Agent と Gateway プロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

5. Transform Data

10 minutes

Transform Processor を使用すると、パイプラインを流れるテレメトリデータ（ログ、メトリクス、トレース）を変更できます。OpenTelemetry Transformation Language (OTTL) を使用して、アプリケーションコードを変更することなく、データのフィルタリング、エンリッチメント、変換をその場で行うことができます。

この演習では、gateway.yaml を更新して、次の処理を行う Transform Processor を追加します

ログリソース属性の フィルタリング
JSON構造化ログデータの属性への パース
ログメッセージ本文に基づくログ重大度レベルの設定

以前のログで SeverityText や SeverityNumber が未定義だったことにお気づきかもしれません。これは filelog レシーバーの典型的な動作です。ただし、重大度はログ本文内に埋め込まれています。例

SeverityText:
SeverityNumber: Unspecified(0)
Body: Str(2025-01-31 15:49:29 [WARN] - Do or do not, there is no try.)

ログには、ログ本文内にJSONとしてエンコードされた構造化データが含まれていることがよくあります。これらのフィールドを属性として抽出することで、インデックス作成、フィルタリング、クエリの効率が向上します。下流のシステムで手動でJSONをパースする代わりに、OTTLを使用してテレメトリパイプラインレベルで自動的に変換できます。

Exercise

重要

すべてのターミナルウィンドウを 5-transform-data ディレクトリに移動し、clear コマンドを実行してください。

4-sensitve-data ディレクトリから *.yaml を 5-transform-data にコピーします。更新後のディレクトリ構造は次のようになります

.
├── agent.yaml
└── gateway.yaml

5.1 Configuration

Exercise

transform プロセッサーを追加する: Gateway terminal ウィンドウに切り替え、gateway.yaml を編集して次の transform プロセッサーを追加します

  transform/logs:                      # Processor Type/Name
    log_statements:                    # Log Processing Statements
      - context: resource              # Log Context
        statements:                    # List of attribute keys to keep
          - keep_keys(attributes, ["com.splunk.sourcetype", "host.name", "otelcol.service.mode"])

-context: resource キーを使用することで、ログの resourceLog 属性をターゲットにしています。

この設定により、関連するリソース属性（com.splunk.sourcetype、host.name、otelcol.service.mode）のみが保持され、ログの効率が向上し、不要なメタデータが削減されます。

ログ重大度マッピング用のコンテキストブロックを追加する: ログレコードの severity_text と severity_number フィールドを適切に設定するために、log_statements 内に log コンテキストブロックを追加します。この設定では、ログ本文から level 値を抽出し、severity_text にマッピングし、ログレベルに基づいて対応する severity_number を割り当てます

      - context: log                   # Log Context
        statements:                    # Transform Statements Array
          - set(cache, ParseJSON(body)) where IsMatch(body, "^\\{")  # Parse JSON log body into a cache object
          - flatten(cache, "")                                        # Flatten nested JSON structure
          - merge_maps(attributes, cache, "upsert")                   # Merge cache into attributes, updating existing keys
          - set(severity_text, attributes["level"])                   # Set severity_text from the "level" attribute
          - set(severity_number, 1) where severity_text == "TRACE"    # Map severity_text to severity_number
          - set(severity_number, 5) where severity_text == "DEBUG"
          - set(severity_number, 9) where severity_text == "INFO"
          - set(severity_number, 13) where severity_text == "WARN"
          - set(severity_number, 17) where severity_text == "ERROR"
          - set(severity_number, 21) where severity_text == "FATAL"

merge_maps 関数は、2つのマップ（辞書）を1つに結合するために使用されます。この場合、cache オブジェクト（ログ本文からパースされたJSONデータを含む）を attributes マップにマージします。

パラメータ:
- attributes: データがマージされるターゲットマップ
- cache: パースされたJSONデータを含むソースマップ
- "upsert": このモードは、attributes マップにすでにキーが存在する場合、その値が cache の値で更新されることを保証します。キーが存在しない場合は、挿入されます。

このステップは、ログ本文からのすべての関連フィールド（例：level、message など）が attributes マップに追加され、さらなる処理やエクスポートで利用可能になることを保証するため、非常に重要です。

主要な変換の概要:

Parse JSON: ログ本文から構造化データを抽出します。
Flatten JSON: ネストされたJSONオブジェクトをフラットな構造に変換します。
Merge Attributes: 抽出されたデータをログ属性に統合します。
Map Severity Text: ログの level 属性から severity_text を割り当てます。
Assign Severity Numbers: 重大度レベルを標準化された数値に変換します。

重要

resource 用のコンテキストブロックと log 用のコンテキストブロックの2つを含む 単一の transform プロセッサーが必要です。

この設定により、ログの重大度が正しく抽出、標準化され、効率的な処理のために構造化されます。

Tip

すべてのJSONフィールドをトップレベルの属性にマッピングするこの方法は、OTTLのテストとデバッグのみに使用してください。本番環境では高いカーディナリティが発生します。

logs パイプラインを更新する: logs: パイプラインに transform/logs: プロセッサーを追加し、設定が次のようになるようにします

    logs:                         # Logs pipeline
      receivers:
      - otlp                      # OTLP receiver
      processors:                 # Processors for logs
      - memory_limiter
      - resource/add_mode
      - transform/logs
      - batch
      exporters:
      - debug                     # Debug exporter
      - file/logs

https://otelbin.io を使用して Agent の設定を検証します。参考として、パイプラインの logs: セクションは次のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;otlp&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRO1(memory_limiter<br>fa:fa-microchip):::processor
      PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
      PRO4(transform<br>fa:fa-microchip<br>logs):::processor
      PRO5(batch<br>fa:fa-microchip):::processor
      EXP1(file<br>fa:fa-upload<br>logs):::exporter
      EXP2(&ensp;&ensp;debug&ensp;&ensp;<br>fa:fa-upload):::exporter
    %% Links
    subID1:::sub-logs
    subgraph " "
      subgraph subID1[**Logs**]
      direction LR
      REC1 --> PRO1
      PRO1 --> PRO3
      PRO3 --> PRO4
      PRO4 --> PRO5
      PRO5 --> EXP2
      PRO5 --> EXP1
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;

5.2 Setup Environment

Exercise

Gateway を起動する: Gateway terminal で以下を実行します

../otelcol --config=gateway.yaml

Agent を起動する: Agent terminal で以下を実行します

../otelcol --config=agent.yaml

Load Generator を起動する: Loadgen terminal ウィンドウで、次のコマンドを実行して JSON を有効にした Load Generator を起動します

../loadgen -logs -json -count 5

loadgen は JSON 形式で 5 行のログを ./quotes.log に書き込みます。

5.3 Test Transform Processor

このテストでは、Agent によってエクスポートされる前に、com.splunk/source と os.type のメタデータがログリソース属性から削除されていることを確認します。さらに、このテストでは以下を確認します

重大度情報を抽出するためにログ本文がパースされていること
- SeverityText と SeverityNumber が LogRecord に設定されていること
ログ本文の JSON フィールドがログ attributes に昇格していること

これにより、エクスポート前に適切なメタデータフィルタリング、重大度マッピング、および構造化ログのエンリッチメントが行われることが保証されます。

Exercise

デバッグ出力を確認する: Agent と Gateway の両方で、com.splunk/source と os.type が削除されていることを確認します

Resource attributes:
   -> com.splunk.sourcetype: Str(quotes)
   -> host.name: Str(workshop-instance)
   -> otelcol.service.mode: Str(agent)

Resource attributes:
   -> com.splunk.source: Str(./quotes.log)
   -> com.splunk.sourcetype: Str(quotes)
   -> host.name: Str(workshop-instance)
   -> os.type: Str(linux)
   -> otelcol.service.mode: Str(agent)

Agent と Gateway の両方で、LogRecord の SeverityText と SeverityNumber がログ本文の重大度 level で定義されていることを確認します。また、本文の JSON フィールドがトップレベルのログ Attributes としてアクセスできることを確認します

<snip>
SeverityText: WARN
SeverityNumber: Warn(13)
Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
Attributes:
     -> log.file.path: Str(quotes.log)
     -> level: Str(WARN)
     -> message: Str(Your focus determines your reality.)
     -> movie: Str(SW)
     -> timestamp: Str(2025-03-07 11:17:26)
</snip>

<snip>
SeverityText:
SeverityNumber: Unspecified(0)
Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
Attributes:
     -> log.file.path: Str(quotes.log)
</snip>

ファイル出力を確認する: 新しい gateway-logs.out ファイルでデータが変換されていることを確認します

jq '[.resourceLogs[].scopeLogs[].logRecords[] | {severityText, severityNumber, body: .body.stringValue}]' gateway-logs.out

[
  {
    "severityText": "DEBUG",
    "severityNumber": 5,
    "body": "{\"level\":\"DEBUG\",\"message\":\"All we have to decide is what to do with the time that is given us.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
  },
  {
    "severityText": "WARN",
    "severityNumber": 13,
    "body": "{\"level\":\"WARN\",\"message\":\"The Force will be with you. Always.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
  },
  {
    "severityText": "ERROR",
    "severityNumber": 17,
    "body": "{\"level\":\"ERROR\",\"message\":\"One does not simply walk into Mordor.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
  },
  {
    "severityText": "DEBUG",
    "severityNumber": 5,
    "body": "{\"level\":\"DEBUG\",\"message\":\"Do or do not, there is no try.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
  }
]
[
  {
    "severityText": "ERROR",
    "severityNumber": 17,
    "body": "{\"level\":\"ERROR\",\"message\":\"There is some good in this world, and it's worth fighting for.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
  }
]

重要

それぞれのターミナルで Ctrl-C を押して、Agent と Gateway のプロセスを停止してください。

6. Routing Data

10 minutes

OpenTelemetry の Routing Connector は、特定の条件に基づいてデータ（traces、metrics、または logs）を異なるパイプライン/宛先に振り分けることができる強力な機能です。これは、テレメトリデータのサブセットに異なる処理やエクスポートロジックを適用したい場合に特に有用です。

例えば、本番環境 のデータを1つのエクスポーターに送信し、テスト や開発のデータを別のエクスポーターに振り分けることができます。同様に、サービス名、環境、スパン名などの属性に基づいて特定のスパンをルーティングし、カスタムの処理やストレージロジックを適用することもできます。

Exercise

重要

すべてのターミナルウィンドウを 6-routing-data ディレクトリに移動し、clear コマンドを実行してください。

5-transform-data ディレクトリから *.yaml を 6-routing-data にコピーします。更新後のディレクトリ構造は次のようになります

.
├── agent.yaml
└── gateway.yaml

次に、Routing Connector とそれぞれのパイプラインを設定します。

6.1 Configure the Routing Connector

この演習では、gateway.yaml で Routing Connector を設定します。Routing Connector はメトリクス、トレース、ログを任意の属性に基づいてルーティングできますが、ここでは deployment.environment 属性に基づくトレースルーティングに焦点を当てます（ただし、任意のスパン/ログ/メトリクス属性を使用できます）。

Exercise

新しい file エクスポーターを追加する: routing コネクターには、ルーティング用に異なるターゲットが必要です。Gateway terminal で、gateway.yaml の exporters セクションに 2 つの新しいファイルエクスポーター file/traces/route1-regular と file/traces/route2-security を作成し、データが正しく振り分けられるようにします

  file/traces/route1-regular:                     # Exporter for regular traces
    path: "./gateway-traces-route1-regular.out"   # Path for saving trace data
    append: false                                 # Overwrite the file each time
  file/traces/route2-security:                    # Exporter for security traces
    path: "./gateway-traces-route2-security.out"  # Path for saving trace data
    append: false                                 # Overwrite the file each time

ルーティングを有効にする: routing コネクターを追加します。OpenTelemetry の設定ファイルでは、connectors はレシーバーやプロセッサーと同様に専用のセクションを持っています。

#connectors: セクションを見つけてコメントを解除します。次に、connectors: セクションの下に以下を追加します

  routing:
    default_pipelines: [traces/route1-regular]  # Default pipeline if no rule matches
    error_mode: ignore                          # Ignore errors in routing
    table:                                      # Define routing rules
      # Routes spans to a target pipeline if the resourceSpan attribute matches the rule
      - statement: route() where attributes["deployment.environment"] == "security-applications"
        pipelines: [traces/route2-security]     # Security target pipeline

設定ファイルのデフォルトパイプラインは、キャッチオールとして機能します。ルーティングルールテーブルのルールに一致しないすべてのデータ（この場合はスパン）のルーティング先となります。このテーブルには、["deployment.environment"] == "security-applications" ルールに一致するスパンのターゲットパイプラインが定義されています。

routing の設定が完了したら、次のステップはこれらのルーティングルールを適用する pipelines を設定することです。

6.2 Configuring the Pipelines

Exercise

元の traces パイプラインをルーティングを使用するように更新する:

routing を有効にするには、元の traces パイプラインを更新して、routing のみをエクスポーターとして使用します。これにより、すべてのスパンデータが Routing Connector を経由して評価され、接続されたパイプラインに転送されます。また、すべての プロセッサーを削除し、空の配列（[]）に置き換えます。これは、traces/route1-regular と traces/route2-security パイプラインで処理されるようになり、各ルートに対してカスタム動作が可能になるためです。traces: の設定は次のようになります
```
traces:                       # Traces pipeline
  receivers:
  - otlp                      # OTLP receiver
  processors: []              # Processors for traces
  exporters:
  - routing
```

既存の traces パイプラインの下に route1-regular と route2-security の両方のトレースパイプラインを追加する:

Route1-regular パイプラインを設定する: このパイプラインは、コネクターのルーティングテーブルに一致しないすべてのスパンを処理します。これは唯一のレシーバーとして routing を使用し、元の traces パイプラインからの connection を通じてデータを受信することに注意してください。

    traces/route1-regular:         # Default pipeline for unmatched spans
      receivers:
      - routing                    # Receive data from the routing connector
      processors:
      - memory_limiter             # Memory Limiter Processor
      - resource/add_mode          # Adds collector mode metadata
      - batch
      exporters:
      - debug                      # Debug Exporter
      - file/traces/route1-regular # File Exporter for unmatched spans

route2-security パイプラインを追加する: このパイプラインは、ルーティングルールの "[deployment.environment"] == "security-applications" ルールに一致するすべてのスパンを処理します。このパイプラインもレシーバーとして routing を使用しています。このパイプラインを traces/route1-regular の下に追加します。

    traces/route2-security:         # Default pipeline for unmatched spans
      receivers:
      - routing                     # Receive data from the routing connector
      processors:
      - memory_limiter              # Memory Limiter Processor
      - resource/add_mode           # Adds collector mode metadata
      - batch
      exporters:
      - debug                       # Debug exporter
      - file/traces/route2-security # File exporter for unmatched spans

otelbin.io を使用して Agent の設定を検証します。参考として、パイプラインの traces: セクションは次のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;&nbsp;otlp&nbsp;&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRO1(memory_limiter<br>fa:fa-microchip):::processor
      PRO2(memory_limiter<br>fa:fa-microchip):::processor
      PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
      PRO4(resource<br>fa:fa-microchip<br>add_mode):::processor
      PRO5(batch<br>fa:fa-microchip):::processor
      PRO6(batch<br>fa:fa-microchip):::processor
      EXP1(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
      EXP2(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload<br>traces):::exporter
      EXP3(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
      EXP4(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload<br>traces):::exporter
      ROUTE1(&nbsp;routing&nbsp;<br>fa:fa-route):::con-export
      ROUTE2(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
      ROUTE3(&nbsp;routing&nbsp;<br>fa:fa-route):::con-receive
    %% Links
    subID1:::sub-traces
    subID2:::sub-traces
    subID3:::sub-traces
    subgraph " "
    direction LR
      subgraph subID1[**Traces**]
      REC1 --> ROUTE1
      end
      subgraph subID2[**Traces/route2-security**]
      ROUTE1 --> ROUTE2
      ROUTE2 --> PRO1
      PRO1 --> PRO3
      PRO3 --> PRO5
      PRO5 --> EXP1
      PRO5 --> EXP2
      end
      subgraph subID3[**Traces/route1-regular**]
      ROUTE1 --> ROUTE3
      ROUTE3 --> PRO2
      PRO2 --> PRO4
      PRO4 --> PRO6
      PRO6 --> EXP3
      PRO6 --> EXP4
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;

6.3 Test Routing Connector

Exercise

このセクションでは、Gateway 用に設定した routing ルールをテストします。期待される結果は、"[deployment.environment"] == "security-applications" ルールに一致する loadgen によって生成された span が gateway-traces-route2-security.out ファイルに送信されることです。

Gateway を起動する: Gateway terminal ウィンドウで Gateway を起動します。

../otelcol --config gateway.yaml

Agent を起動する: Agent terminal ウィンドウで Agent を起動します。

../otelcol --config agent.yaml

通常のスパンを送信する: Loadgen terminal ウィンドウで loadgen を使用して通常のスパンを送信します

../loadgen -count 1

Agent と Gateway の両方でデバッグ情報が表示されます。Gateway は新しい gateway-traces-route1-regular.out ファイルも生成します。これが通常のスパンの指定された宛先になりました。

Tip

gateway-traces-route1-regular.out を確認すると、loadgen によって送信された span が含まれています。また、空の gateway-traces-route2-security..out ファイルも表示されます。これは、ルーティング設定が、一致するスパンがまだ処理されていなくても、すぐに出力ファイルを作成するためです。

セキュリティスパンを送信する: Loadgen terminal ウィンドウで security フラグを使用してセキュリティスパンを送信します

../loadgen -security -count 1

再び、Agent と Gateway の両方で、送信したスパンを含むデバッグ情報が表示されるはずです。今回は、Gateway が gateway-traces-route2-security.out ファイルに行を書き込みます。これは、deployment.environment リソース属性が "security-applications" に一致するスパン用に指定されたファイルです。

jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-route2-security.out

{"spanId":"cb799e92e26d5782","deploymentEnvironment":"security-applications"}

このシナリオを複数回繰り返すことができ、各トレースは対応する出力ファイルに書き込まれます。

重要

それぞれのターミナルで Ctrl-C を押して、Agent と Gateway のプロセスを停止してください。

まとめ

このセクションでは、異なるスパンを送信し、その宛先を確認することで、Gateway のルーティングコネクターを正常にテストしました。

通常のスパン は gateway-traces-route1-regular.out に正しくルーティングされ、一致する deployment.environment 属性を持たないスパンがデフォルトパイプラインに従うことが確認されました。
セキュリティ関連のスパン は gateway-traces-route2-security.out にルーティングされ、"deployment.environment": "security-applications" に基づくルーティングルールが期待どおりに機能することが実証されました。

出力ファイルを検査することで、OpenTelemetry Collector が スパン属性を正しく評価し、適切な宛先にルーティングしている ことを確認しました。これにより、ルーティングルールが異なるユースケース向けにテレメトリデータを効果的に分離して振り分けることができることが検証されました。

追加のルーティングルールを定義して、異なる属性に基づいてスパン、メトリクス、ログをさらに分類することで、このアプローチを拡張できます。

7. Count Connector でメトリクスを作成する

10 minutes

このセクションでは、Count Connector を使用して、ログから属性値を抽出し、意味のあるメトリクスに変換する方法を説明します。

具体的には、Count Connector を使用して、ログに出現する「Star Wars」と「Lord of the Rings」の名言の数を追跡し、測定可能なデータポイントに変換します。

Exercise

重要

すべてのターミナルウィンドウを 7-sum-count ディレクトリに変更し、clear コマンドを実行してください。

6-routing-data ディレクトリから *.yaml を 7-sum-count にコピーしてください。更新後のディレクトリ構造は以下のようになります

.
├── agent.yaml
└── gateway.yaml

agent.yaml を更新して、ログを読み取る頻度を変更します。 agent.yaml 内の filelog/quotes レシーバーを見つけ、poll_interval 属性を追加してください

  filelog/quotes:                      # Receiver Type/Name
    poll_interval: 10s                 # Only read every ten seconds

遅延を設定する理由は、OpenTelemetry Collector の Count Connector が各処理インターバル内でのみログをカウントするためです。つまり、データが読み取られるたびに、次のインターバルでカウントがゼロにリセットされます。デフォルトの Filelog receiver インターバル 200ms では、loadgen が書き込むすべての行を読み取り、カウントが1になります。このインターバルを設定することで、複数のエントリをカウントできるようになります。

以下に示すように、条件を省略することで、Collector は各読み取りインターバルの累計カウントを維持できます。ただし、バックエンドは長期間にわたってカウントを追跡できるため、累計カウントはバックエンドに任せるのがベストプラクティスです。

Exercise

Count Connector を追加する

設定の connectors セクションに Count Connector を追加し、使用するメトリクスカウンターを定義します

connectors:
  count:
    logs:
      logs.full.count:
        description: "Running count of all logs read in interval"
      logs.sw.count:
        description: "StarWarsCount"
        conditions:
        - attributes["movie"] == "SW"
      logs.lotr.count:
        description: "LOTRCount"
        conditions:
        - attributes["movie"] == "LOTR"
      logs.error.count:
        description: "ErrorCount"
        conditions:
        - attributes["level"] == "ERROR"

メトリクスカウンターの説明
- logs.full.count：各読み取りインターバルで処理されたログの総数を追跡します。このメトリクスにはフィルタリング条件がないため、システムを通過するすべてのログがカウントに含まれます。
- logs.sw.count：Star Wars 映画の名言を含むログをカウントします。
- logs.lotr.count：Lord of the Rings 映画の名言を含むログをカウントします。
- logs.error.count：読み取りインターバルで重大度レベルが ERROR のログをカウントする、実際のシナリオを表します。
パイプラインで Count Connector を設定する 以下のパイプライン設定では、connector exporter が logs セクションに追加され、connector receiver が metrics セクションに追加されています。

  pipelines:
    traces:
      receivers:
      - otlp
      processors:
      - memory_limiter
      - attributes/update              # Update, hash, and remove attributes
      - redaction/redact               # Redact sensitive fields using regex
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - file
      - otlphttp
    metrics:
      receivers:
      - count                           # Count Connector that receives count metric from logs count exporter in logs pipeline.
      - otlp
      #- hostmetrics                    # Host Metrics Receiver
      processors:
      - memory_limiter
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - otlphttp
    logs:
      receivers:
      - otlp
      - filelog/quotes
      processors:
      - memory_limiter
      - resourcedetection
      - resource/add_mode
      - transform/logs                 # Transform logs processor
      - batch
      exporters:
      - count                          # Count Connector that exports count as a metric to metrics pipeline.
      - debug
      - otlphttp

ログは属性に基づいてカウントされます。ログデータが属性ではなくログボディに格納されている場合は、パイプラインで Transform プロセッサーを使用して、キー/バリューのペアを抽出し、属性として追加する必要があります。

このワークショップでは、05-transform-data セクションで既に merge_maps(attributes, cache, "upsert") を追加しています。これにより、関連するすべてのデータが処理用のログ属性に含まれるようになります。

属性を作成するフィールドを選択する際は注意が必要です。すべてのフィールドを無差別に追加することは、本番環境では一般的に理想的ではありません。不要なデータの乱雑さを避けるため、本当に必要なフィールドのみを選択してください。

Exercise

otelbin.io を使用して agent 設定を検証してください。参考として、パイプラインの logs と metrics: セクションは以下のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
    REC1(otlp<br>fa:fa-download):::receiver
    REC2(filelog<br>fa:fa-download<br>quotes):::receiver
    REC3(otlp<br>fa:fa-download):::receiver
    PRO1(memory_limiter<br>fa:fa-microchip):::processor
    PRO2(memory_limiter<br>fa:fa-microchip):::processor
    PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
    PRO4(resource<br>fa:fa-microchip<br>add_mode):::processor
    PRO5(batch<br>fa:fa-microchip):::processor
    PRO6(batch<br>fa:fa-microchip):::processor
    PRO7(resourcedetection<br>fa:fa-microchip):::processor
    PRO8(resourcedetection<br>fa:fa-microchip):::processor
    PRO9(transfrom<br>fa:fa-microchip<br>logs):::processor
    EXP1(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
    EXP2(&emsp;&emsp;otlphttp&emsp;&emsp;<br>fa:fa-upload):::exporter
    EXP3(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload):::exporter
    EXP4(&emsp;&emsp;otlphttp&emsp;&emsp;<br>fa:fa-upload):::exporter
    ROUTE1(&nbsp;count&nbsp;<br>fa:fa-route):::con-export
    ROUTE2(&nbsp;count&nbsp;<br>fa:fa-route):::con-receive

    %% Links
    subID1:::sub-logs
    subID2:::sub-metrics
    subgraph " "
      direction LR
      subgraph subID1[**Logs**]
      direction LR
      REC1 --> PRO1
      REC2 --> PRO1
      PRO1 --> PRO7
      PRO7 --> PRO3
      PRO3 --> PRO9
      PRO9 --> PRO5
      PRO5 --> ROUTE1
      PRO5 --> EXP1
      PRO5 --> EXP2
      end

      subgraph subID2[**Metrics**]
      direction LR
      ROUTE1 --> ROUTE2
      ROUTE2 --> PRO2
      REC3 --> PRO2
      PRO2 --> PRO8
      PRO8 --> PRO4
      PRO4 --> PRO6
      PRO6 --> EXP3
      PRO6 --> EXP4
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;

7.1 Count Connector のテスト

Exercise

Gateway を起動する Gateway terminal ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent を起動する Agent terminal ウィンドウで以下を実行します

../otelcol --config=agent.yaml

Loadgen で12行のログを送信する Spans terminal ウィンドウで、12行のログを送信します。これらは2つのインターバルで読み取られるはずです。以下の loadgen コマンドを実行してください

../loadgen -logs -json -count 12

Agent と Gateway の両方がデバッグ情報を表示し、データを処理していることを示します。loadgen が完了するまで待ちます。

メトリクスが生成されたことを確認する ログが処理されると、Agent がメトリクスを生成して Gateway に転送し、Gateway がそれらを gateway-metrics.out に書き込みます。

出力に logs.full.count、logs.sw.count、logs.lotr.count、logs.error.count のメトリクスが含まれているか確認するには、以下の jq クエリを実行します

jq '.resourceMetrics[].scopeMetrics[].metrics[]
    | select(.name == "logs.full.count" or .name == "logs.sw.count" or .name == "logs.lotr.count" or .name == "logs.error.count")
    | {name: .name, value: (.sum.dataPoints[0].asInt // "-")}' gateway-metrics.out

{
  "name": "logs.sw.count",
  "value": "2"
}
{
  "name": "logs.lotr.count",
  "value": "2"
}
{
  "name": "logs.full.count",
  "value": "4"
}
{
  "name": "logs.error.count",
  "value": "2"
}
{
  "name": "logs.error.count",
  "value": "1"
}
{
  "name": "logs.sw.count",
  "value": "2"
}
{
  "name": "logs.lotr.count",
  "value": "6"
}
{
  "name": "logs.full.count",
  "value": "8"
}

Tip

注：logs.full.count は通常 logs.sw.count + logs.lotr.count と等しくなりますが、logs.error.count はランダムな数値になります。

重要

それぞれのターミナルで Ctrl-C を押して Agent と Gateway のプロセスを停止してください。

7.2 Sum Connector でメトリクスを作成する

10 minutes

このセクションでは、Sum Connector がスパンから値を抽出してメトリクスに変換する方法を説明します。

具体的には、ベーススパンからクレジットカードの請求額を取得し、Sum Connector を活用して合計請求額をメトリクスとして取得します。

この connector は、スパン、スパンイベント、メトリクス、データポイント、およびログレコードから属性値を収集（sum）するために使用できます。各個別の値をキャプチャし、メトリクスに変換して転送します。ただし、これらのメトリクスと属性を使用して計算やさらなる処理を行うのはバックエンドの役割です。

Exercise

Agent terminal ウィンドウに切り替えて、エディターで agent.yaml ファイルを開きます。

Sum Connector を追加する 設定の connectors セクションに Sum Connector を追加し、メトリクスカウンターを定義します

  sum:
    spans:
       user.card-charge:
        source_attribute: payment.amount
        conditions:
          - attributes["payment.amount"] != "NULL"
        attributes:
          - key: user.name

上記の例では、スパン内の payment.amount 属性をチェックしています。有効な値がある場合、Sum connector は user.card-charge というメトリクスを生成し、user.name を属性として含めます。これにより、バックエンドは請求サイクルなどの長期間にわたってユーザーの合計請求額を追跡して表示できます。

以下のパイプライン設定では、connector exporter が traces セクションに追加され、connector receiver が metrics セクションに追加されています。

Exercise

パイプラインで Count Connector を設定する

  pipelines:
    traces:
      receivers:
      - otlp
      processors:
      - memory_limiter
      - attributes/update              # Update, hash, and remove attributes
      - redaction/redact               # Redact sensitive fields using regex
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - file
      - otlphttp
      - sum                            # Sum connector which aggregates payment.amount from spans and sends to metrics pipeline
    metrics:
      receivers:
      - sum                            # Receives metrics from the sum exporter in the traces pipeline
      - count                          # Receives count metric from logs count exporter in logs pipeline.
      - otlp
      #- hostmetrics                   # Host Metrics Receiver
      processors:
      - memory_limiter
      - resourcedetection
      - resource/add_mode
      - batch
      exporters:
      - debug
      - otlphttp
    logs:
      receivers:
      - otlp
      - filelog/quotes
      processors:
      - memory_limiter
      - resourcedetection
      - resource/add_mode
      - transform/logs                 # Transform logs processor
      - batch
      exporters:
      - count                          # Count Connector that exports count as a metric to metrics pipeline.
      - debug
      - otlphttp

otelbin.io を使用して agent 設定を検証してください。参考として、パイプラインの traces と metrics: セクションは以下のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
    REC1(otlp<br>fa:fa-download<br> ):::receiver
    REC3(otlp<br>fa:fa-download<br> ):::receiver
    PRO1(memory_limiter<br>fa:fa-microchip<br> ):::processor
    PRO2(memory_limiter<br>fa:fa-microchip<br> ):::processor
    PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
    PRO4(resource<br>fa:fa-microchip<br>add_mode):::processor
    PRO5(batch<br>fa:fa-microchip<br> ):::processor
    PRO6(batch<br>fa:fa-microchip<br> ):::processor
    PRO7(resourcedetection<br>fa:fa-microchip<br> ):::processor
    PRO8(resourcedetection<br>fa:fa-microchip<br>):::processor

    PROA(attributes<br>fa:fa-microchip<br>redact):::processor
    PROB(redaction<br>fa:fa-microchip<br>update):::processor
    EXP1(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload<br> ):::exporter
    EXP2(&emsp;&emsp;file&emsp;&emsp;<br>fa:fa-upload<br> ):::exporter
    EXP3(&nbsp;&ensp;debug&nbsp;&ensp;<br>fa:fa-upload<br> ):::exporter
    EXP4(&emsp;&emsp;otlphttp&emsp;&emsp;<br>fa:fa-upload<br> ):::exporter
    EXP5(&emsp;&emsp;otlphttp&emsp;&emsp;<br>fa:fa-upload<br> ):::exporter
    ROUTE1(&nbsp;sum&nbsp;<br>fa:fa-route<br> ):::con-export
    ROUTE2(&nbsp;count&nbsp;<br>fa:fa-route<br> ):::con-receive
    ROUTE3(&nbsp;sum&nbsp;<br>fa:fa-route<br> ):::con-receive

    %% Links
    subID1:::sub-traces
    subID2:::sub-metrics
    subgraph " "
      direction LR
      subgraph subID1[**Traces**]
      direction LR
      REC1 --> PRO1
      PRO1 --> PROA
      PROA --> PROB
      PROB --> PRO7
      PRO7 --> PRO3
      PRO3 --> PRO5
      PRO5 --> EXP1
      PRO5 --> EXP2
      PRO5 --> EXP5
      PRO5 --> ROUTE1
      end

      subgraph subID2[**Metrics**]
      direction LR
      ROUTE1 --> ROUTE3
      ROUTE3 --> PRO2
      ROUTE2 --> PRO2
      REC3 --> PRO2
      PRO2 --> PRO8
      PRO8 --> PRO4
      PRO4 --> PRO6
      PRO6 --> EXP3
      PRO6 --> EXP4
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;

7.3 Sum Connector のテスト

Exercise

Gateway を起動する Gateway terminal ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent を起動する Agent terminal ウィンドウで以下を実行します

../otelcol --config=agent.yaml

Loadgen を起動する Spans terminal ウィンドウで、以下の loadgen コマンドを使用して8つのスパンを送信します

../loadgen -count 8

Agent と Gateway の両方がデバッグ情報を表示し、データを処理していることを示します。loadgen が完了するまで待ちます。

メトリクスを確認する スパンを処理する際、Agent はメトリクスを生成して Gateway に転送します。Gateway はそれらを gateway-metrics.out に書き込みます。

メトリクス出力に user.card-charge が存在し、それぞれに user.name 属性があることを確認するには、以下の jq クエリを実行します

jq -r '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "user.card-charge") | .sum.dataPoints[] | "\(.attributes[] | select(.key == "user.name").value.stringValue)\t\(.asDouble)"' gateway-metrics.out | while IFS=$'\t' read -r name charge; do
    printf "%-20s %s\n" "$name" "$charge"
done

George Lucas         67.49
Frodo Baggins        87.14
Thorin Oakenshield   90.98
Luke Skywalker       51.37
Luke Skywalker       65.56
Thorin Oakenshield   67.5
Thorin Oakenshield   66.66
Peter Jackson        94.39

重要

それぞれのターミナルで Ctrl-C を押して Agent と Gateway のプロセスを停止してください。

8. まとめ

Splunk Synthetic Scripting

45 minutes Author Robert Castley

問題がユーザーに影響を与える前に、Webアプリケーションのパフォーマンスをプロアクティブにモニタリングします。Splunk Synthetic Monitoring を使用すると、技術チームとビジネスチームは詳細なテストを作成し、開発サイクルのあらゆる段階でWebサイト、Webアプリケーション、リソースの速度と信頼性を継続的にモニタリングできます。

Splunk Synthetic Monitoring は、唯一の完全なオブザーバビリティスイートであるSplunk Observability Cloudの一部として、稼働時間とWebパフォーマンス最適化のための最も包括的で詳細な機能を提供します。

API、サービスエンドポイント、エンドユーザーエクスペリエンスのモニタリングを簡単にセットアップできます。Splunk Synthetic Monitoring を使用すると、基本的な稼働時間とパフォーマンスモニタリングを超えて、問題のプロアクティブな検出と修正、Webパフォーマンスの最適化、顧客への最高のユーザーエクスペリエンス提供に集中できます。

Splunk Synthetic Monitoring では以下のことが可能です:

重要なユーザーフロー、ビジネストランザクション、APIエンドポイント全体で問題を迅速に検出・解決
インテリジェントなWeb最適化エンジンにより、Webパフォーマンスの問題が顧客に影響を与える前に防止
すべてのページリソースとサードパーティ依存関係のパフォーマンスを改善

1. Real Browser Test

はじめに

このワークショップでは、Chrome DevTools Recorder を使用して、Splunkデモインスタンスに対するSyntheticトランザクションを作成する方法を説明します。

Chrome DevTools RecorderからエクスポートしたJSONを使用して、Splunk Synthetic MonitoringのReal Browser Testを作成します。

また、API Test や Uptime Test など、他のSplunk Synthetic Monitoringチェックについても学びます。

前提条件

Google Chromeブラウザがインストールされていること
Splunk Observability Cloudへのアクセス権があること

1.1 テストの記録

開始 URL を開く

ワークショップの開始URLをChromeで開きます。以下の適切なリンクをクリックして、新しいタブでサイトを開きます。

メモ

ワークショップの開始URLは EMEA と AMER/APAC で異なります。お住まいの地域に応じて正しいURLを使用してください。

https://online-boutique-eu.splunko11y.com/

https://online-boutique-us.splunko11y.com/

Chrome DevTools Recorder を開く

次に、（上記で開いた新しいタブで）Developer Toolsを開きます。Windowsでは Ctrl + Shift + I、Macでは Cmd + Option + I を押し、トップレベルメニューまたは More tools フライアウトメニューから Recorder を選択します。

注意

サイトの要素はビューポートの幅によって変わる場合があります。記録する前に、作成するテストの種類（デスクトップ、タブレット、モバイル）に応じてブラウザウィンドウを適切な幅に設定してください。必要に応じて、DevToolsの「dock side」を別ウィンドウとしてポップアウトさせると便利です。

新しい記録を作成

DevToolsウィンドウでRecorderパネルを開いた状態で、Create a new recording ボタンをクリックして開始します。

Recording Name には、イニシャルを接頭辞として使用します（例: <your initials> - Online Boutique）。Start Recording をクリックして、アクションの記録を開始します。

記録が開始されたら、サイトで以下のアクションを実行します:

Vintage Camera Lens をクリック
Add to Cart をクリック
Place Order をクリック
Recorderパネルの End recording をクリック

記録のエクスポート

Export ボタンをクリックします:

フォーマットとして JSON を選択し、Save をクリックします。

おめでとうございます！ Chrome DevTools Recorderを使用した記録の作成に成功しました。次に、この記録を使用してSplunk Synthetic MonitoringでReal Browser Testを作成します。

JSONファイルを表示するにはここをクリック

{
    "title": "RWC - Online Boutique",
    "steps": [
        {
            "type": "setViewport",
            "width": 1430,
            "height": 1016,
            "deviceScaleFactor": 1,
            "isMobile": false,
            "hasTouch": false,
            "isLandscape": false
        },
        {
            "type": "navigate",
            "url": "https://online-boutique-eu.splunko11y.com/",
            "assertedEvents": [
                {
                    "type": "navigation",
                    "url": "https://online-boutique-eu.splunko11y.com/",
                    "title": "Online Boutique"
                }
            ]
        },
        {
            "type": "click",
            "target": "main",
            "selectors": [
                [
                    "div:nth-of-type(2) > div:nth-of-type(2) a > div"
                ],
                [
                    "xpath//html/body/main/div/div/div[2]/div[2]/div/a/div"
                ],
                [
                    "pierce/div:nth-of-type(2) > div:nth-of-type(2) a > div"
                ]
            ],
            "offsetY": 170,
            "offsetX": 180,
            "assertedEvents": [
                {
                    "type": "navigation",
                    "url": "https://online-boutique-eu.splunko11y.com/product/66VCHSJNUP",
                    "title": ""
                }
            ]
        },
        {
            "type": "click",
            "target": "main",
            "selectors": [
                [
                    "aria/ADD TO CART"
                ],
                [
                    "button"
                ],
                [
                    "xpath//html/body/main/div[1]/div/div[2]/div/form/div/button"
                ],
                [
                    "pierce/button"
                ],
                [
                    "text/Add to Cart"
                ]
            ],
            "offsetY": 35.0078125,
            "offsetX": 46.4140625,
            "assertedEvents": [
                {
                    "type": "navigation",
                    "url": "https://online-boutique-eu.splunko11y.com/cart",
                    "title": ""
                }
            ]
        },
        {
            "type": "click",
            "target": "main",
            "selectors": [
                [
                    "aria/PLACE ORDER"
                ],
                [
                    "div > div > div.py-3 button"
                ],
                [
                    "xpath//html/body/main/div/div/div[4]/div/form/div[4]/button"
                ],
                [
                    "pierce/div > div > div.py-3 button"
                ],
                [
                    "text/Place order"
                ]
            ],
            "offsetY": 29.8125,
            "offsetX": 66.8203125,
            "assertedEvents": [
                {
                    "type": "navigation",
                    "url": "https://online-boutique-eu.splunko11y.com/cart/checkout",
                    "title": ""
                }
            ]
        }
    ]
}

1.2 Real Browser Test の作成

Splunk Observability Cloudで Synthetics に移動し、Add new test をクリックします。

ドロップダウンから Browser test を選択します。

Browser test content 設定ページが表示されます。

1.3 JSON のインポート

テストの設定を開始するには、Chrome DevTools RecorderからエクスポートしたJSONをインポートする必要があります。Import ボタンを有効にするには、まずテストに名前を付ける必要があります（例: <your initials> - Online Boutique）。

Import ボタンが有効になったら、クリックしてChrome DevTools RecorderからエクスポートしたJSONファイルをドロップするか、ファイルをアップロードします。

JSONファイルがアップロードされたら、Continue to edit steps をクリックします。

テストを編集する前に、まず設定を構成します。< Return to test をクリックします。

1.4 設定

シンプル設定では、テストの基本を構成できます:

Name: テストの名前（例: RWC - Online Boutique）
Details:
- Locations: テストを実行するロケーション
- Device: 異なるデバイスと接続速度をエミュレート。選択したデバイスに合わせてビューポートも調整されます
- Frequency: テストの実行頻度
- Round-robin: 複数のロケーションを選択した場合、すべてのロケーションで同時に実行するのではなく、一度に1つのロケーションからテストを実行します
- Active: テストをアクティブまたは非アクティブに設定

![Return to Test]このワークショップでは、モニタリングを行うロケーションを設定します。Locations フィールドをクリックすると、グローバルロケーションのリスト（合計50以上）が表示されます。

以下のロケーションを選択します:

AWS - N. Virginia
AWS - London
AWS - Melbourne

完了したら、下にスクロールして Submit をクリックしてテストを保存します。

これで、選択した3つのロケーションから5分ごとにテストが実行されるようスケジュールされます。スケジュールの作成には数分かかります。

テストのスケジュール作成を待つ間、Edit test をクリックしてAdvanced設定を確認しましょう。

1.5 Advanced 設定

Advanced をクリックします。これらの設定はオプションで、テストをさらに詳細に構成するために使用できます。

メモ

このワークショップでは、これらの設定は情報提供のみを目的としており、実際には使用しません。

Security:
- TLS/SSL validation: 有効にすると、SSL/TLS証明書の有効期限切れ、無効なホスト名、信頼できない発行者の検証を強制します
- Authentication: 企業ネットワーク内など、追加のセキュリティプロトコルを必要とするサイトで認証するための資格情報を追加します。Authenticationフィールドで concealed global variables を使用することで、資格情報のセキュリティレイヤーを追加し、チェック間で資格情報を共有しやすくなります
Custom Content:
- Custom headers: 各リクエストで送信するカスタムヘッダーを指定します。たとえば、リクエストに特定のヘッダーを送信することで、バックエンドの分析からリクエストを除外するヘッダーを追加できます。カスタムヘッダーを使用してCookieを設定することもできます
- Cookies: テスト開始前にブラウザにCookieを設定します。たとえば、ポップアップモーダルがランダムに表示されてテストに干渉するのを防ぐためにCookieを設定できます。設定されたCookieは、チェックの開始URLのドメインに適用されます。Splunk Synthetics Monitoringはpublic suffix listを使用してドメインを判定します
- Host overrides: あるホストから別のホストにリクエストをリルーティングするホストオーバーライドルールを追加します。たとえば、既存の本番サイトを開発サイトや特定のCDNエッジノードから読み込まれたページリソースに対してテストするホストオーバーライドを作成できます

次に、テストステップを編集して、各ステップにより意味のある名前を付けます。

1.6 テストステップの編集

ステップを編集するには、+ Edit steps or synthetic transactions ボタンをクリックします。ここから、各ステップに意味のある名前を付けていきます。

4つのステップそれぞれに意味のある名前を付けます。

Step 1: Go to URL というテキストを HomePage - Online Boutique に置き換えます
Step 2: Select Vintage Camera Lens と入力します
Step 3: Add to Cart と入力します
Step 4: Place Order と入力します

< Return to test をクリックしてテスト設定ページに戻り、Save をクリックしてテストを保存します。

テストダッシュボードに戻り、テスト結果が表示され始めます。

おめでとうございます！ Splunk Synthetic MonitoringでReal Browser Testの作成に成功しました。次に、テスト結果をより詳しく見ていきます。

1.7 テスト結果の表示

前のステップの散布図で、いずれかのドットをクリックしてテスト実行データにドリルダウンします。できれば、最新のテスト実行（最も右側）を選択してください。

API Test

API Testは、APIエンドポイントの機能とパフォーマンスを柔軟にチェックする方法を提供します。APIファーストの開発へのシフトにより、フロントエンドのコア機能を提供するバックエンドサービスをモニタリングする必要性が高まっています。

マルチステップのAPIインタラクションのテストに興味がある場合でも、エンドポイントのパフォーマンスを可視化したい場合でも、API Testは目標の達成を支援します。

Global Variables

APIテストを実行するために使用するグローバル変数を確認します。歯車アイコンの下にある Global Variables をクリックします。env.encoded_auth という名前のグローバル変数を使用して、Spotify APIトランザクションを構築します。

新しい API テストの作成

新しい API テストを作成

Add new test ボタンをクリックし、ドロップダウンから API test を選択して新しいAPIテストを作成します。テスト名には イニシャル に続けて Spotify API と入力します（例: RWC - Spotify API）。

認証リクエスト

認証リクエストの追加

+ Add requests をクリックし、リクエストステップ名を入力します（例: Authenticate with Spotify API）。

Requestセクションを展開し、ドロップダウンからリクエストメソッドを POST に変更して、以下のURLを入力します:

https://accounts.spotify.com/api/token

Payload body セクションに以下を入力します:

grant_type=client_credentials

次に、以下のキー/値のペアで2つのリクエストヘッダーを追加します:

CONTENT-TYPE: application/x-www-form-urlencoded
AUTHORIZATION: Basic {{env.encoded_auth}}

Validation セクションを展開し、以下の抽出を追加します:

Extract from Response body JSON $.access_token as access_token

これにより、Spotify APIから受信したJSONペイロードを解析し、アクセストークンを抽出してカスタム変数として保存します。

検索リクエスト

検索リクエストの追加

+ Add Request をクリックして次のステップを追加します。ステップ名を Search for Tracks named “Up around the bend” とします。

Request セクションを展開し、リクエストメソッドを GET に変更して、以下のURLを入力します:

https://api.spotify.com/v1/search?q=Up%20around%20the%20bend&type=track&offset=0&limit=5

次に、以下のキー/値のペアで2つのリクエストヘッダーを追加します:

CONTENT-TYPE: application/json
AUTHORIZATION: Bearer {{custom.access_token}}

Validation セクションを展開し、以下の抽出を追加します:

Extract from Response body JSON $.tracks.items[0].id as track.id

< Return to test をクリックしてテスト設定ページに戻ります。次に Save をクリックしてAPIテストを保存します。

結果の表示

テストがプロビジョニングされて実行されるまで数分待ちます。テストが正常に実行されたら、実行をクリックしてテスト結果を表示します:

6. リソース

AWS Lambda関数の分散トレーシング

45 minutes Author Guy-Francis Kono

このワークショップでは、AWS Lambdaで実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesisを介してメッセージをproduceおよびconsumeする方法を学びます。

まず、OpenTelemetryの自動計装がどのようにトレースをキャプチャし、選択した宛先にエクスポートするかを確認します。

次に、手動計装によってコンテキスト伝播を有効にする方法を見ていきます。

このワークショップのために、SplunkはAWS/EC2上のUbuntu Linuxインスタンスを事前に構成しています。このインスタンスにアクセスするには、ワークショップインストラクターが提供するURLにアクセスしてください。

セットアップ

前提条件

Observability ワークショップインスタンス

Observabilityワークショップは、多くの場合、Splunkが提供する事前設定済みのUbuntu EC2インスタンス上で実施されます。

ワークショップのインストラクターから、割り当てられたワークショップインスタンスの認証情報が提供されます。

インスタンスには以下の環境変数が既に設定されているはずです

ACCESS_TOKEN
REALM
- これらはワークショップ用の Splunk Observability Cloud の Access Token と Realm です。
- これらは OpenTelemetry Collector によって、データを正しい Splunk Observability Cloud 組織に転送するために使用されます。

また、Multipass を使用してローカルの Observability ワークショップインスタンスをデプロイすることもできます。

AWS Command Line Interface (awscli)

AWS Command Line Interface、または awscli は、AWSリソースと対話するために使用されるAPIです。このワークショップでは、特定のスクリプトがデプロイするリソースと対話するために使用されます。

Splunkが提供するワークショップインスタンスには、既に awscli がインストールされているはずです。

インスタンスに aws コマンドがインストールされているか、次のコマンドで確認します
```
which aws
```
- 予想される出力は /usr/local/bin/aws です
インスタンスに aws コマンドがインストールされていない場合は、次のコマンドを実行します
```
sudo apt install awscli
```

Terraform

Terraformは、リソースを構成ファイルで定義することで、デプロイ、管理、破棄するためのInfrastructure as Code（IaC）プラットフォームです。TerraformはHCLを使用してこれらのリソースを定義し、さまざまなプラットフォームやテクノロジのための複数のプロバイダーをサポートしています。

このワークショップでは、コマンドラインでTerraformを使用して、以下のリソースをデプロイします

AWS API Gateway
Lambda関数
Kinesis Stream
CloudWatchロググループ
S3バケット
- およびその他のサポートリソース

Splunkが提供するワークショップインスタンスには、既に terraform がインストールされているはずです。

インスタンスに terraform コマンドがインストールされているか確認します
```
which terraform
```
- 予想される出力は /usr/local/bin/terraform です

インスタンスに terraform コマンドがインストールされていない場合は、以下のTerraformが推奨するインストールコマンドを実行してください

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update && sudo apt install terraform

ワークショップディレクトリ (o11y-lambda-workshop)

ワークショップディレクトリ o11y-lambda-workshop は、今日使用する例のLambdaベースのアプリケーションの自動計装と手動計装の両方を完了するための、すべての設定ファイルとスクリプトを含むリポジトリです。

ホームディレクトリにワークショップディレクトリがあることを確認します
```
cd && ls
```
- 予想される出力には o11y-lambda-workshop が含まれるはずです
o11y-lambda-workshop ディレクトリがホームディレクトリにない場合は、次のコマンドでクローンします

git clone https://github.com/gkono-splunk/o11y-lambda-workshop.git

AWS & Terraform 変数

AWS

AWSのCLIでは、サービスによってデプロイされたリソースにアクセスし管理するための認証情報が必要です。このワークショップでは、TerraformとPythonスクリプトの両方がタスクを実行するためにこれらの変数を必要とします。

このワークショップのために awscli を access key ID、secret access key および region で構成します
```
aws configure
```
- このコマンドは以下のようなプロンプトを表示するはずです：
```
AWS Access Key ID [None]: XXXXXXXXXXXXXXXX
AWS Secret Acces Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]: us-east-1
Default outoput format [None]:
```
インスタンスで awscli が設定されていない場合は、次のコマンドを実行し、インストラクターから提供される値を入力してください。
```
aws configure
```

Terraform

Terraformでは、機密情報や動的データを.tf設定ファイルにハードコーディングさせない、またはそれらの値をリソース定義全体で再利用できるようにするため、変数の受け渡しをサポートしています。

このワークショップでは、OpenTelemetry Lambda layerの適切な値でLambda関数をデプロイするため、Splunk Observability Cloudの取り込み値のため、そして環境とリソースを独自で即座に認識できるようにするための変数をTerraformで必要とします。

Terraform変数(variable)は以下の方法で定義されます

変数を main.tf ファイルまたは variables.tf に定義する
以下のいずれかの方法で変数の値を設定する
- ホストレベルで環境変数を設定し、その定義と同じ変数名を使用して、接頭辞として TF_VAR をつける
- terraform.tfvars ファイルに変数の値を設定する
- terraform apply実行時に引数として値を渡す

このワークショップでは、variables.tf と terraform.tfvars ファイルの組み合わせを使用して変数を設定します。

vi または nano のいずれかを使用して、auto または manual ディレクトリにある terraform.tfvars ファイルを開きます
```
vi ~/o11y-lambda-workshop/auto/terraform.tfvars
```
変数に値を設定します。CHANGEME プレースホルダーをインストラクターから提供された値に置き換えてください。
```
o11y_access_token = "CHANGEME"
o11y_realm        = "CHANGEME"
otel_lambda_layer = ["CHANGEME"]
prefix            = "CHANGEME"
```
- 引用符（"）や括弧 ( [ ] ) はそのまま残し、プレースホルダーCHANGEME のみを変更してください。
- prefix は、他の参加者のリソースと区別するため、任意の文字列で設定する固有の識別子です。氏名やメールアドレスのエイリアスを使用することをお勧めします。
- prefix には小文字のみを使用してください。S3 のような特定の AWS リソースでは、大文字を使用するとエラーが発生します。
ファイルを保存してエディタを終了します。
最後に、編集した terraform.tfvars ファイルを他のディレクトリにコピーします。
```
cp ~/o11y-lambda-workshop/auto/terraform.tfvars ~/o11y-lambda-workshop/manual
```
- これは、自動計装と手動計装の両方の部分で同じ値を使用するためです

ファイル権限

他のすべてのファイルはそのままでよいですが、auto と manual の両方にあるsend_message.pyスクリプトは、ワークショップの一部として実行する必要があります。そのため、期待通りに実行するには、適切な権限が必要です。以下の手順に従って設定してください。

まず、o11y-lambda-workshop ディレクトリにいることを確認します
```
cd ~/o11y-lambda-workshop
```
次に、以下のコマンドを実行して send_message.py スクリプトに実行権限を設定します
```
sudo chmod 755 auto/send_message.py manual/send_message.py
```

これで前提条件が整いましたので、ワークショップを始めることができます！

自動計装

ワークショップの最初の部分では、OpenTelemetryによる自動計装がどのようにしてOpenTelemetry Collectorに関数がどの言語で書かれているかを自動検出させ、それらの関数のトレースの取得を開始させるかを示します。

自動計装ワークショップディレクトリとコンテンツ

まず、o11y-lambda-workshop/auto ディレクトリとそのファイルの一部を見てみましょう。ここにはワークショップの自動計装部分のすべてのコンテンツがあります。

`auto` ディレクトリ

以下のコマンドを実行して o11y-lambda-workshop/auto ディレクトリに移動します
```
cd ~/o11y-lambda-workshop/auto
```

このディレクトリの内容を確認します

ls

出力には以下のファイルとディレクトリが含まれるはずです：

handler             outputs.tf          terraform.tf        variables.tf
main.tf             send_message.py     terraform.tfvars

出力には以下のファイルとディレクトリが含まれるはずです：

get_logs.py    main.tf       send_message.py
handler        outputs.tf    terraform.tf

`main.tf` ファイル

main.tf ファイルをより詳しく見てみましょう
```
cat main.tf
```

ワークショップの質問

このテンプレートによってどのAWSリソースが作成されているか特定できますか？
OpenTelemetry計装がどこでセットアップされているか特定できますか？
- ヒント: Lambda 関数の定義を調べてください
以前に設定した環境変数によってどの計装情報が提供されているか判断できますか？

各Lambda関数の環境変数が設定されているセクションが見つかるはずです。

environment {
  variables = {
    SPLUNK_ACCESS_TOKEN = var.o11y_access_token
    SPLUNK_REALM = var.o11y_realm
    OTEL_SERVICE_NAME = "producer-lambda"
    OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop"
    AWS_LAMBDA_EXEC_WRAPPER = "/opt/nodejs-otel-handler"
    KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name
  }
}

これらの環境変数を使用することで、いくつかの方法で自動計装を構成しています

環境変数を設定して、データのエクスポート先となるSplunk Observability Cloud組織をOpenTelemetry collectorに伝えています。
```
SPLUNK_ACCESS_TOKEN = var.o11y_access_token
SPLUNK_ACCESS_TOKEN = var.o11y_realm
```
また、OpenTelemetryが関数/サービスを識別し、それが属する環境/アプリケーションを認識するのに役立つ変数も設定しています。
```
OTEL_SERVICE_NAME = "producer-lambda" # consumer関数の場合はconsumer-lambda
OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop"
```
コード言語に基づいて、関数のハンドラーに自動的にトレースデータを取得するために適用する必要があるラッパーをOpenTelemetryに知らせる環境変数を設定しています。
```
AWS_LAMBDA_EXEC_WRAPPER - "/opt/nodejs-otel-handler"
```
producer-lambda 関数の場合、レコードを配置するKinesisストリームを関数に知らせるための環境変数を設定しています。
```
KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name
```
これらの値は、「前提条件」セクションで設定した環境変数、および、このTerraform構成ファイルの一部としてデプロイされるリソースから取得されます。

また、各関数にSplunk OpenTelemetry Lambda layerを設定する引数も確認できるはずです

layers = var.otel_lambda_layer

OpenTelemetry Lambda layerは、Lambda関数の呼び出し時に計測データを収集、処理、およびエクスポートするために必要なライブラリと依存関係を含むパッケージです。
すべてのOpenTelemetryサポート言語のライブラリと依存関係を持つ一般的なOTel Lambda layerがありますが、関数をさらに軽量化するための言語固有のLambda layerも存在します。
- 各 AWS リージョンの関連する Splunk OpenTelemetry Lambda layer ARN（Amazon Resource Name）と最新バージョンはこちらで確認できます

`producer.mjs` ファイル

次に、producer-lambda 関数のコードを見てみましょう

以下のコマンドを実行して producer.mjs ファイルの内容を表示します
```
cat ~/o11y-lambda-workshop/auto/handler/producer.mjs
```
- このNodeJSモジュールにはプロデューサー関数のコードが含まれています。
- 基本的に、この関数はメッセージを受け取り、そのメッセージを対象のKinesisストリームにレコードとして配置します

Lambda 関数のデプロイとトレースデータの生成

auto ディレクトリの内容に慣れたところで、ワークショップ用のリソースをデプロイし、Lambda関数からトレースデータを生成していきます。

`auto` ディレクトリで Terraform を初期化する

main.tf ファイルで定義されたリソースをデプロイするには、まずTerraformがそのファイルと同じフォルダで初期化されていることを確認する必要があります。

auto ディレクトリにいることを確認します:
```
pwd
```
- 予想される出力は ~/o11y-lambda-workshop/auto です
auto ディレクトリにいない場合は、次のコマンドを実行します
```
cd ~/o11y-lambda-workshop/auto
```
次のコマンドを実行して、このディレクトリでTerraformを初期化します
```
terraform init
```
- このコマンドは同じフォルダにいくつかの要素を作成します
  - .terraform.lock.hcl ファイル：リソースを提供するために使用するプロバイダーを記録します
  - .terraform ディレクトリ：プロバイダーの構成を保存します
- 上記のファイルに加えて、apply サブコマンドを使用してterraformを実行すると、デプロイされたリソースの状態を追跡するために terraform.tfstate ファイルが作成されます。
- これらにより、Terraformは auto ディレクトリの main.tf ファイル内で定義されたとおりに、リソースの作成、状態、破棄を管理できます

Lambda 関数とその他の AWS リソースをデプロイする

このディレクトリでTerraformを初期化したら、リソースのデプロイに進むことができます。

まず、terraform plan コマンドを実行して、Terraformが問題なくリソースを作成できることを確認します。
```
terraform plan
```
- これにより、リソースをデプロイするプランといくつかのデータが出力され、意図したとおりに動作することを確認できます。
- プランに表示される値の一部は、作成後に判明するか、セキュリティ上の理由でマスクされていることに注意してください。

次に、terraform apply コマンドを実行して、main.tf ファイルからLambda関数とその他のサポートリソースをデプロイします

terraform apply

Enter a value: プロンプトが表示されたら yes と応答します

これにより、以下のような出力が得られます

Outputs:

base_url = "https://______.amazonaws.com/serverless_stage/producer"
consumer_function_name = "_____-consumer"
consumer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-consumer"
consumer_log_group_name = "/aws/lambda/______-consumer"
environment = "______-lambda-shop"
lambda_bucket_name = "lambda-shop-______-______"
producer_function_name = "______-producer"
producer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-producer"
producer_log_group_name = "/aws/lambda/______-producer"

Terraform 出力は outputs.tf ファイルで定義されています。
これらの出力は、ワークショップの他の部分でもプログラム的に使用されます。

`producer-lambda` URL (`base_url`) にトラフィックを送信する

デプロイしたLambda関数からトレースを取得し始めるには、トラフィックを生成する必要があります。producer-lambda 関数のエンドポイントにメッセージを送信し、それをKinesisストリームにレコードとして配置し、その後 consumer-lambda 関数によってストリームから取得されるようにします。

auto ディレクトリにいることを確認します
```
pwd
```
- 予想される出力は ~/o11y-lambda-workshop/auto です
auto ディレクトリにいない場合は、次のコマンドを実行します
```
cd ~/o11y-lambda-workshop/auto
```

send_message.py スクリプトは、コマンドラインで入力を受け取り、JSONディクショナリに追加し、whileループの一部として producer-lambda 関数のエンドポイントに繰り返し送信するPythonスクリプトです。

Run the send_message.py script as a background process
- --name と --superpower 引数が必要です
```
nohup ./send_message.py --name CHANGEME --superpower CHANGEME &
```
- メッセージが成功した場合は、以下のような出力が表示されるはずです
```
[1] 79829
user@host manual % appending output to nohup.out
```
  - ここで重要な情報は 2 つあります:
    - 1 行目のプロセス ID（この例では 79829）、および
    - appending output to nohup.out メッセージ
  - nohup コマンドはスクリプトがバックグラウンドに送られた時に切断されないようにします。また、コマンドからの curl 出力を、現在いるフォルダと同じフォルダにある nohup.out ファイルにキャプチャします。
  - & はシェルプロセスにこのプロセスをバックグラウンドで実行するよう指示し、シェルが他のコマンドを実行できるようにします。
次に、response.logs ファイルの内容を確認して、producer-lambda エンドポイントへのリクエストが成功したことを確認します
```
cat response.logs
```
- メッセージが成功していれば、画面に印刷された行の中に次の出力が表示されるはずです
```
{"message": "Message placed in the Event Stream: {prefix}-lambda_stream"}
```
- 失敗した場合は、次のように表示されます
```
{"message": "Internal server error"}
```

重要

この場合は、ワークショップ進行役の一人に支援を求めてください。

Lambda 関数のログを表示する

次に、Lambda関数のログを確認しましょう。

producer-lambda ログを表示するには、producer.logs ファイルを確認します
```
cat producer.logs
```
consumer-lambda ログを表示するには、consumer.logs ファイルを確認します
```
cat consumer.logs
```

ログを注意深く調べてください。

ワークショップの質問

OpenTelemetryが読み込まれているのが見えますか？splunk-extension-wrapper のある行に注目してください
- - splunk-extension-wrapperが読み込まれているのを見るために head -n 50 producer.logs または head -n 50 consumer.logs の実行を検討してください。

Splunk APM、Lambda関数およびトレース

Lambda関数は相当量のトレースデータを生成しているはずで、それを確認する必要があります。Lambda関数のリソース定義で構成された環境変数とOpenTelemetry Lambda layerの組み合わせにより、Splunk APMで関数とトレースを表示する準備が整いました。

Splunk APM 概要で環境名を確認する

まず、Splunk APMが受信しているトレースデータから Environment を認識していることを確認しましょう。これは main.tf のLambda関数定義で設定した OTEL_RESOURCE_ATTRIBUTES 変数の一部として設定した deployment.name です。これは先ほど実行した terraform apply コマンドの出力の1つでもありました。

Splunk Observability Cloudで

左側のメインメニューから APM ボタンをクリックします。これによりSplunk APM概要に移動します。
Environment: ドロップダウンからあなたのAPM環境を選択します。
- APM 環境は PREFIX-lambda-shop 形式になっているはずです。PREFIX は前提条件セクションで設定した環境変数から取得されます

メモ

トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください

環境のサービスマップを表示する

Environmentドロップダウンから環境名を選択したら、Lambda関数のサービスマップを確認できます。

APM概要ページの右側にある Service Map ボタンをクリックします。これによりサービスマップビューに移動します。

producer-lambda 関数とそのレコードを配置するためにKinesisストリームに対して行っている呼び出しが表示されるはずです。

ワークショップの質問

あなたの consumer-lambda 関数はどうなっていますか？

Lambda 関数からのトレースを調査する

Traces ボタンをクリックしてトレースアナライザーを表示します。

このページでは、producer-lambda 関数のOpenTelemetry Lambda layerから取り込まれたトレースを確認できます。

リストからハイパーリンクされた Trace ID をクリックして、調査するトレースを選択します。

producer-lambda 関数がKinesisストリームにレコードを配置しているのが確認できます。しかし、consumer-lambda 関数のアクションが見当たりません！

これはトレースコンテキストが伝播されていないためです。このワークショップの時点では、Kinesisサービスはトレースコンテキスト伝播をすぐには対応していません。分散トレースはKinesisサービスで止まっており、そのコンテキストがストリームを通じて自動的に伝播されないため、それ以上先を見ることができません。

少なくとも、今はまだ…

次のセクションでこの問題にどう対処するか見ていきましょう。しかしその前に、後片付けをしましょう！

クリーンアップ

この自動計装演習の一部としてデプロイしたリソースはクリーンアップする必要があります。同様に、producer-lambda エンドポイントに対してトラフィックを生成していたスクリプトも、まだ実行中であれば停止する必要があります。以下の手順に従ってクリーンアップを行ってください。

`send_message` の停止

send_message.py スクリプトがまだ実行中の場合は、次のコマンドで停止します
```
fg
```
- これによりバックグラウンドプロセスがフォアグラウンドに移動します。
- 次に [CONTROL-C] を押してプロセスを終了できます。

全ての AWS リソースを破棄する

Terraformは個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。

以下の手順に従ってリソースを破棄してください

auto ディレクトリにいることを確認します
```
pwd
```
- 期待される出力は ~/o11y-lambda-workshop/auto です
auto ディレクトリにいない場合は、以下のコマンドを実行します
```
cd ~/o11y-lambda-workshop/auto
```
先ほどデプロイしたLambda関数とその他のAWSリソースを破棄します
```
terraform destroy
```
- Enter a value: プロンプトが表示されたら yes と応答します
- これによりリソースが破棄され、クリーンな環境が残ります

このプロセスにより、私たちの活動の結果として作成されたファイルとディレクトリは残ります。それらについては心配する必要はありません。

手動計装

ワークショップの第2部では、OpenTelemetryによる手動計装が計測データ収集を強化する方法を実演することに焦点を当てます。より具体的には、今回のケースでは、producer-lambda 関数から consumer-lambda 関数にトレースコンテキストデータを伝播させることができるようになります。これにより、現在は自動コンテキスト伝播をサポートしていないKinesisストリームを介しても、2つの関数間の関係を見ることができるようになります。

手動計装ワークショップディレクトリとコンテンツ

再度、作業ディレクトリとそのファイルの一部を確認することから始めます。今回は o11y-lambda-workshop/manual ディレクトリです。ここにはワークショップの手動計装部分のすべてのコンテンツがあります。

`manual` ディレクトリ

以下のコマンドを実行して o11y-lambda-workshop/manual ディレクトリに移動します
```
cd ~/o11y-lambda-workshop/manual
```
ls コマンドでこのディレクトリの内容を確認します
```
ls
```
- 出力には以下のファイルとディレクトリが含まれるはずです：
```
handler             outputs.tf          terraform.tf        variables.tf
main.tf             send_message.py     terraform.tfvars
```

ワークショップの質問

このディレクトリと最初に始めたautoディレクトリに何か違いがありますか？

`auto` と `manual` のファイルを比較する

見た目が同じように見えるこれらのファイルが実際に同じかどうか確認しましょう。

auto と manual ディレクトリの main.tf ファイルを比較します
```
diff ~/o11y-lambda-workshop/auto/main.tf ~/o11y-lambda-workshop/manual/main.tf
```
- 違いはありません！(違いがあるはずはありません。もし違いがあれば、ワークショップ進行役に支援を求めてください)
次に、producer.mjs ファイルを比較してみましょう
```
diff ~/o11y-lambda-workshop/auto/handler/producer.mjs ~/o11y-lambda-workshop/manual/handler/producer.mjs
```
- ここにはかなりの違いがあります！
ファイル全体を表示してその内容を調べたい場合は以下を実行します
```
cat ~/o11y-lambda-workshop/handler/producer.mjs
```
- 必要な手動計装タスクを処理するために、いくつかのOpenTelemetryオブジェクトを関数に直接インポートしていることに注目してください。
```
import { context, propagation, trace } from "@opentelemetry/api";
```
- プロデューサー関数でコンテキストを伝播するために、@opentelemetry/api から次のオブジェクトをインポートしています
  - context
  - propagation
  - trace
最後に、consumer.mjs ファイルを比較します
```
diff ~/o11y-lambda-workshop/auto/handler/consumer.mjs ~/o11y-lambda-workshop/manual/handler/consumer.mjs
```
- ここにもいくつかの注目すべき違いがあります。より詳しく見てみましょう
```
cat handler/consumer.mjs
```
  - このファイルでは、次の @opentelemetry/api オブジェクトをインポートしています
    - propagation
    - trace
    - ROOT_CONTEXT
  - これらを使用して、プロデューサー関数から伝播されたトレースコンテキストを抽出します
  - その後、抽出したトレースコンテキストに name と superpower に基づいた新しいスパン属性を追加します

プロデューサー関数からのトレースコンテキスト伝播

以下のコードはプロデューサー関数内で次のステップを実行します

このトレース用のトレーサーを取得する
コンテキストキャリアオブジェクトを初期化する
アクティブスパンのコンテキストをキャリアオブジェクトに注入する
Kinesisストリームに配置しようとしているレコードを修正し、アクティブスパンのコンテキストをコンシューマーに運ぶキャリアを含める

...
import { context, propagation, trace, } from "@opentelemetry/api";
...
const tracer = trace.getTracer('lambda-app');
...
  return tracer.startActiveSpan('put-record', async(span) => {
    let carrier = {};
    propagation.inject(context.active(), carrier);
    const eventBody = Buffer.from(event.body, 'base64').toString();
    const data = "{\"tracecontext\": " + JSON.stringify(carrier) + ", \"record\": " + eventBody + "}";
    console.log(
      `Record with Trace Context added:
      ${data}`
    );

    try {
      await kinesis.send(
        new PutRecordCommand({
          StreamName: streamName,
          PartitionKey: "1234",
          Data: data,
        }),
        message = `Message placed in the Event Stream: ${streamName}`
      )
...
    span.end();

コンシューマー関数でのトレースコンテキスト抽出

以下のコードはコンシューマー関数内で次のステップを実行します

producer-lambda から取得したコンテキストをキャリアオブジェクトに抽出する
現在のコンテキストからトレーサーを抽出する
抽出したコンテキスト内でトレーサーを使用して新しいスパンを開始する
ボーナス：メッセージからの値を含むカスタム属性など、追加の属性をスパンに追加する！
完了したら、スパンを終了する

import { propagation, trace, ROOT_CONTEXT } from "@opentelemetry/api";
...
      const carrier = JSON.parse( message ).tracecontext;
      const parentContext = propagation.extract(ROOT_CONTEXT, carrier);
      const tracer = trace.getTracer(process.env.OTEL_SERVICE_NAME);
      const span = tracer.startSpan("Kinesis.getRecord", undefined, parentContext);

      span.setAttribute("span.kind", "server");
      const body = JSON.parse( message ).record;
      if (body.name) {
        span.setAttribute("custom.tag.name", body.name);
      }
      if (body.superpower) {
        span.setAttribute("custom.tag.superpower", body.superpower);
      }
...
      span.end();

これでどのような違いが生まれるか見てみましょう！

Lambda関数のデプロイとトレースデータの生成

トレースデータを収集したい関数やサービスに手動計装を適用する方法がわかったので、Lambda関数を再度デプロイして、producer-lambda エンドポイントに対するトラフィックを生成していきましょう。

`manual` ディレクトリで Terraform を初期化する

新しいディレクトリにいるので、ここでもう一度Terraformを初期化する必要があります。

manual ディレクトリにいることを確認します
```
pwd
```
- 予想される出力は ~/o11y-lambda-workshop/manual です
manual ディレクトリにいない場合は、次のコマンドを実行します
```
cd ~/o11y-lambda-workshop/manual
```
次のコマンドを実行して、このディレクトリでTerraformを初期化します
```
terraform init
```

Lambda 関数とその他の AWS リソースをデプロイする

それでは、これらのリソースを再度デプロイしましょう！

問題がないことを確認するために、terraform plan コマンドを実行します。
```
terraform plan
```

続いて、terraform apply コマンドを使用して main.tf ファイルからLambda関数とその他のサポートリソースをデプロイします

terraform apply

Enter a value: プロンプトが表示されたら yes と応答します

これにより、以下のような出力が得られます

Outputs:

base_url = "https://______.amazonaws.com/serverless_stage/producer"
consumer_function_name = "_____-consumer"
consumer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-consumer"
consumer_log_group_name = "/aws/lambda/______-consumer"
environment = "______-lambda-shop"
lambda_bucket_name = "lambda-shop-______-______"
producer_function_name = "______-producer"
producer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-producer"
producer_log_group_name = "/aws/lambda/______-producer"

見ての通り、base_urlの最初の部分とログループARN以外は、このワークショップの自動計装部分をこの同じ時点まで実行したときと出力は概ね同じはずです。

`producer-lambda` エンドポイント (base_url) にトラフィックを送信する

もう一度、name と superpower をメッセージとしてエンドポイントに送信します。これはトレースコンテキストとともに、Kinesisストリーム内のレコードに追加されます。

manual ディレクトリにいることを確認します
```
pwd
```
- 予想される出力は ~/o11y-lambda-workshop/manual です
manual ディレクトリにいない場合は、次のコマンドを実行します
```
cd ~/o11y-lambda-workshop/manual
```
send_message.py スクリプトをバックグラウンドプロセスとして実行します
```
nohup ./send_message.py --name CHANGEME --superpower CHANGEME &
```
次に、response.logsファイルの内容を確認して、producer-lambdaエンドポイントへの呼び出しが成功しているか確認します
```
cat response.logs
```
- メッセージが成功していれば、画面に表示される行の中に次の出力が表示されるはずです
```
{"message": "Message placed in the Event Stream: hostname-eventStream"}
```
- 失敗した場合は、次のように表示されます
```
{"message": "Internal server error"}
```

重要

これが発生した場合は、ワークショップ進行役の一人に支援を求めてください。

Lambda 関数のログの確認

ログがどのようになっているか見てみましょう。

producer.logs ファイルを確認します
```
cat producer.logs
```
そして consumer.logs ファイルを確認します
```
cat consumer.logs
```

ログを注意深く調べてください。

ワークショップの質問

違いに気づきましたか？

`consumer-lambda` ログからのトレース ID のコピー

今回は、consumer-lambdaのロググループが、我々が伝播した tracecontext とともに、メッセージを record としてログに記録しているのが確認できます。

トレースIDをコピーするには

Kinesis Message ログの1つを見てみましょう。その中には data ディクショナリがあります
ネストされた tracecontext ディクショナリを見るために、data をより詳しく見てください
tracecontext ディクショナリ内には、traceparent というキーと値のペアがあります
traceparent キーと値のペアには、私たちが探しているトレースIDが含まれています
- - で区切られた4つの値のグループがあります。トレースIDは2番目の文字グループです
トレース ID をコピーして保存してください。 このワークショップの後のステップで必要になります

Splunk APM、Lambda関数とトレース、再び！

ログの外部でコンテキスト伝播の結果を確認するために、もう一度Splunk APM UIを参照します。

Splunk APM サービスマップで Lambda 関数を表示する

もう一度APMで環境のサービスマップを確認してみましょう。

Splunk Observability Cloudで

メインメニューの APM ボタンをクリックします。
Environment: ドロップダウンからあなたのAPM環境を選択します。
APM概要ページの右側にある Service Map ボタンをクリックします。これによりサービスマップビューに移動します。

> 注意：トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください

ワークショップの質問

違いに気づきましたか？

今回は、伝播されたコンテキストによってリンクされた producer-lambda と consumer-lambda 関数が見えるはずです！

トレース ID で Lambda トレースを調査する

次に、環境に関連するトレースをもう一度確認します。

コンシューマー関数のログからコピーしたトレースIDを、Traces下の View Trace ID 検索ボックスに貼り付け、Go をクリックします

メモ

トレース ID は、私たちが伝播したトレースコンテキストの一部でした。

最も一般的な2つの伝播規格について読むことができます

ワークショップの質問

私たちはどちらを使用していますか？

私たちの NodeJS 関数をサポートする Splunk Distribution of Opentelemetry JS は、デフォルトで W3C 標準を使用しています

ワークショップの質問

ボーナス質問：W3CヘッダーとB3ヘッダーを混在させるとどうなりますか？

consumer-lambda スパンをクリックしてください。

ワークショップの質問

あなたのメッセージからの属性を見つけることができますか？

クリーンアップ

いよいよワークショップの最後に来ました。後片付けをしましょう！

`send_message` の停止

send_message.py スクリプトがまだ実行中の場合は、次のコマンドで停止します
```
fg
```
- これによりバックグラウンドプロセスがフォアグラウンドに移動します。
- 次に [CONTROL-C] を押してプロセスを終了できます。

すべての AWS リソースを破棄する

以下の手順に従ってリソースを破棄してください

manual ディレクトリにいることを確認します
```
pwd
```
- 予想される出力は ~/o11y-lambda-workshop/manual です
manual ディレクトリにいない場合は、次のコマンドを実行します
```
cd ~/o11y-lambda-workshop/manual
```
以前にデプロイしたLambda関数とその他のAWSリソースを破棄します
```
terraform destroy
```
- Enter a value: プロンプトが表示されたら yes と応答します
- これにより、リソースが破棄され、クリーンな環境が残ります

結論

Lambda Tracingワークショップを終えたことをおめでとうございます！自動計装を手動のステップで補完して、producer-lambda 関数のコンテキストをKinesisストリーム内のレコードを介して consumer-lambda 関数に送信する方法を見てきました。これにより、期待される分散トレースを構築し、Splunk APMで両方の関数間の関係をコンテキスト化することができました。

これで、2つの異なる関数を手動でリンクしてトレースを構築することができます。これは、自動計装や第三者のシステムがコンテキスト伝播を標準でサポートしていない場合や、より関連性の高いトレース分析のためにカスタム属性をトレースに追加したい場合に役立ちます。

Dashboard Workshop

45 minutes Author Pieter Hagen

Splunk Observability Cloudの Dashboards に関するワークショップへようこそ。このセッションでは、洞察に満ちた可視化を構築するためのハンズオン体験を提供します。

Splunk Observability Suiteで利用可能な既存のデモデータを使用して作業します。アクセス可能な trial または production のSplunk Observability組織を使用してフォローできます。

学習内容

ダッシュボード

ワークショップの最初のパートでは、ダッシュボードとチャートに焦点を当てます：

ダッシュボードの理解とチャートの役割
既存のチャートの編集と新しいチャートの作成
フィルターの適用と分析関数の使用
数式の構築とカスタマイズ
再利用のためのダッシュボードへのチャートの保存
高度なチャート作成のためのSignalFlow入門

ダッシュボード入門

10 minutes

1. ダッシュボード

ダッシュボードは、主要なメトリクスを1か所に表示するチャートと可視化のコレクションです。適切に設計されたダッシュボードは、システムの健全性とパフォーマンスに関する迅速で実用的な洞察を提供します。シンプルなものから詳細なものまで、いくつかのフォーカスされたチャートから複数のサービスにまたがる複雑なビューまで、必要に応じて作成できます。

このモジュールでは、いくつかのチャートを作成し、それらを以下のカスタムダッシュボードにまとめます。

2. ダッシュボードへのアクセス

まず、Splunk Observability Suiteでダッシュボードを見つけましょう。

左側のナビゲーションメニューで Dashboards (1) ボタンをクリックします。メニューが折りたたまれている場合は、画面左上のハンバーガーアイコンをクリックして展開できます。

これにより、メインのダッシュボードビューに移動し、Splunk Observabilityによって提供される事前構築されたダッシュボードを含むすべての利用可能なダッシュボードが表示されます。

組織がCloud API統合またはSplunk OpenTelemetry Agentを通じてすでにデータを取り込んでいる場合は、それらのサービスに関連する追加のダッシュボードも表示されることがあります。

サンプルデータの場所

10 minutes

1. サンプルデータの探索

利用可能なダッシュボードのリストで、Sample Data (2) というグループを探してください。

このグループには、サンプルメトリクスから構築された可視化を紹介するダッシュボードが含まれています。これらは、Splunk Observabilityのチャートとダッシュボードを使用してさまざまなデータをどのように表現できるかを理解するのに役立ちます。

Sample Data ダッシュボードグループをクリックして展開し、Sample Charts (3) ダッシュボードを選択します。

このダッシュボードでは、Splunk Observabilityで利用可能なさまざまなチャートタイプ、スタイル、およびフォーマットオプションを紹介しています。ダッシュボードがどれほど柔軟でカスタマイズ可能かを体感するのに最適な方法です。

サンプルデータは10分サイクルで実行され、時間の経過とともにさまざまなパターンと動作を生成します。これらの変化を実際に確認するには、ダッシュボードの右上隅にある時間範囲を Last 15 minutes に調整するか、より良い概要を得るために Last 1 hour を選択してください。これにより、データがどのように更新され、さまざまな条件を循環するかを観察できます。

このダッシュボードのチャートを少し探索してみてください。各チャートは、サンプルデータを可視化する方法について異なる視点を提供しています。

チャートの探索

このセクションでは、Splunk Observabilityでチャートがどのように構築され表示されるかを探索することから始めます。既存のチャートを調べて操作することで、チャートエディタの動作方法、データソースの選択方法、ビジュアルオプションの設定方法、そしてさまざまな設定が表示内容にどのように影響するかを理解できます。

1. チャートの選択

開始するには、SAMPLE CHARTS ダッシュボードを開いていることを確認し、ダッシュボードの右上隅にある時間範囲を -5M（過去5分間）に戻すか、reset to default を選択してください。

Latency histogram チャートを見つけて、チャートの右上隅にある three dots (…) (1) をクリックします。メニューから Open (3) を選択します。また、チャートタイトル (Latency histogram) (2) をクリックして直接開くこともできます。

チャートエディタが開くと、Latency histogramチャートの設定が表示されます。

チャートエディタは、データの可視化方法を制御できる場所です。チャートタイプの変更、変換関数の適用、時間設定の調整、その他のビジュアルおよびデータ関連のオプションを特定のニーズに合わせてカスタマイズできます。

Plot Editor (1) タブの Signal (2) セクションで、現在使用されているメトリクス demo.trans.latency (3) を確認できます。このシグナルは、チャートがプロットしているレイテンシデータを表しています。このエリアを使用して、シグナルを編集したり、追加のシグナルを追加して可視化を比較または充実させることができます。

チャートには複数の Line プロットが表示されています。ラベル 18 ts (4) は、チャートが現在 18個の個別のメトリクス時系列 をプロットしていることを示しています。

さまざまな可視化スタイルを探索するには、エディタ内のさまざまなチャートタイプアイコンをクリックしてみてください。各アイコンにカーソルを合わせると、その名前が表示され、各タイプが何を表すかを理解するのに役立ちます。

たとえば、Heat Map アイコンをクリックして、同じデータが異なるフォーマットでどのように表現されるかを確認してみてください。

Note

さまざまなチャートタイプを使用してメトリクスを可視化できます。強調したい洞察を最もよく表現するものを選択してください。

利用可能なチャートタイプとその使用タイミングの詳細な概要については、Choosing a chart type. を参照してください。

チャートの編集

このセクションでは、既存のチャートを編集することで、チャートがどのように構成されているかを探索し始めます。これは、チャートエディタのハンズオン体験を得て、チャート設定、データソース、および可視化オプションがどのように連携するかを理解するための素晴らしい方法です。

チャートエディタで Latency histogram チャートを開いた状態で、ワークショップ用に設定を始めましょう。

visualization ペインで Line chart タイプアイコン (1) をクリックしてチャートタイプを変更します。データは折れ線グラフとして表示されるようになります。

2. チャートの時間ウィンドウの変更

より多くの履歴データを表示するために、チャートの時間範囲を調整できます。これを行うには、チャートエディタの右上隅にある Time (1) ドロップダウンをクリックし、Past 15 minutes (2) を選択します。

これにより時間ウィンドウが拡大され、より長い期間にわたるメトリクスの傾向を確認できます。

3. Data Table の探索

チャートエディタで Data Table (1) タブをクリックします。

Data Table は、チャートを駆動するメトリクス時系列の舞台裏を見ることができます。

テーブルの各行は単一の時系列を表し、各列はその時系列に関連付けられたディメンションを示しています。メトリクス demo.trans.latency の場合、以下のディメンションが表示されます：

demo_datacenter (2)
demo_customer (3)
demo_host (4)

demo_datacenter 列には、2つのデータセンター Paris (5) と Tokyo (6) があることがわかります。それぞれに複数の関連する時系列があります。

チャート上でカーソルを（時間軸に沿って水平に）移動させると、Data Table は現在の時点の値を反映してリアルタイムで更新されます。チャートの特定の線をクリックすると、その時系列がテーブルに固定され、固定された値が表示されます。これは pinned value (7) で示されます。

準備ができたら、Plot editor (8) タブをクリックしてData Tableを閉じます。

次に、このチャートをダッシュボードに保存して、後で再利用できるようにしましょう！

チャートとダッシュボードの保存

チャートをニーズに合わせてカスタマイズしたら、次のステップはダッシュボードの一部として保存することです。作業を保存することで、主要な可視化を再利用、共有、および長期間にわたって監視できます。このセクションでは、チャートに名前と説明を付ける方法と、後で簡単にアクセスできるようにダッシュボードに追加する方法を学びます。

1. チャートの保存

チャートを保存するために、まず明確な名前と説明を付けましょう。

現在 Copy of Latency Histogram とラベル付けされているチャートタイトルをクリックし、“Active Latency” (1) に名前を変更します。

次に、チャートの説明を更新します。既存のテキスト Spread of latency values across time をクリックし、以下に変更します： Overview of latency values in real-time (2)

これらの更新により、チャートが大きなダッシュボードの一部になった場合や他のユーザーと共有された場合に、識別と理解がしやすくなります。

Save As (3) ボタンをクリックして保存プロセスを開始します。チャートは先ほど設定した Active Latency という名前を使用しますが、必要に応じてここで名前を更新できます。

準備ができたら、Ok (1) ボタンをクリックして確認し続行します。

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

チャートを保存するので、それを格納する場所、つまり ダッシュボード が必要です。

ダッシュボードは、関連するチャートを整理してグループ化するのに役立ち、1つのビューで主要なメトリクスを監視しやすくします。このワークショップでは、作成するチャートを保持するための 新しいダッシュボード を作成します。

Choose dashboard ダイアログで、New Dashboard (1) ボタンをクリックします。

重要: 既存のダッシュボードを選択しないでください。この演習では必ず新しいダッシュボードを作成してください。

New Dashboard ダイアログが表示され、新しいダッシュボードの詳細を設定できます。

まず、ダッシュボードに名前を付けます。このワークショップでは、次の形式を使用してください：YOUR_NAME-Dashboard YOUR_NAME を実際の名前に置き換えて、ダッシュボードを識別しやすくしてください。

次に、permissions を更新します。Restricted Read and Write access に設定して、あなた（または特定のユーザー）のみがダッシュボードを表示および変更できるようにします。ユーザーアカウントが含まれており、読み取りと書き込みの両方のアクセス権があることを確認してください。

権限に自分のユーザーアカウントがリストされているはずです。これは 現在、このダッシュボードを編集できるのはあなただけ であることを意味します。

必要に応じて、下のドロップダウンから追加のユーザーまたはチームを追加できます。

このワークショップの目的上、制限を解除しましょう。セッション中にアクセスが制限されないように、権限設定を Everyone can Read and Write に変更します。

次に、Save ボタンをクリックして続行します。新しいダッシュボードが作成され、自動的に選択されるので、チャートを直接保存できます。

新しく作成したダッシュボードが選択されていることを確認し (1)、Ok ボタン (2) をクリックして続行します。

ダッシュボードに移動します。左上隅に、YOUR_NAME-DASHBOARD が同じ名前のDashboard Groupの一部であることが表示されます。このダッシュボードグループに追加のダッシュボードを追加して、異なるユースケース、システム、またはプロジェクトごとにチャートを整理できます。

新しいチャートの作成

1 新しいチャートの作成

それでは、新しいチャートを作成して、作業中のダッシュボードに追加しましょう！

開始するには、インターフェースの上部中央にあるプラスアイコン (1) をクリックします。ドロップダウンから Chart (2) を選択します。または、+ New Chart ボタン (3) をクリックして、新しいチャートを直接作成することもできます。

設定の準備ができた空白のチャートテンプレートが表示されます：

まず、可視化するメトリクスを追加しましょう。この例では、先ほど使用したのと同じメトリクス demo.trans.latency を引き続き使用します。

Plot Editor (1) で、Signal (2) セクションに移動し、入力フィールドに demo.trans.latency(3) を入力します。これにより、レイテンシの時系列データがチャートにロードされ、可視化の構築とカスタマイズを開始できます。

18個の時系列 (4) を表示する見慣れた折れ線グラフが表示されるはずです。最近のアクティビティを表示するには、Time dropdown (1) から Past 15 minutes を選択して時間範囲を変更します。

フィルターと分析の使用

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

Splunk Observability では、フィルター と 分析関数 を使用して、大量のメトリクスデータを簡単に探索できます。フィルターは、特定のサービス、ホスト、または場所など、データの特定のセグメントに焦点を当てるのに役立ちます。一方、分析関数を使用すると、より深い洞察を得るためにデータを変換および分析できます。

それでは、より的を絞った分析を適用できるように、Paris データセンター に焦点を当てるようにデータを絞り込みましょう。これには フィルター を使用します。

まず Plot Editor タブに戻ります。以下のスクリーンショットに示すように、Add Filter ボタン (2) をクリックします。

利用可能なディメンションが表示されるまで少し待ちます。その後：

フィルターディメンションとして demo_datacenter (1) を選択します。
フィルターする値として Paris (2) を選択します。

このフィルターにより、チャートはParisデータセンターからの時系列のみを表示するように制限され、分析がより焦点を絞った意味のあるものになります。

チャートエディタの F(x) (1) 列で、Add Analytics ボタンをクリックして分析関数を適用します。ドロップダウンリストから Percentile (2) を選択し、次に Percentile:Aggregation (3) オプションを選択します。フォローアップパネルで、パーセンタイル値を90のままにしておきます。これにより、チャートは選択した時系列の90パーセンタイルを表示します。

このコンテキストでは、90パーセンタイルは、レイテンシ測定値の90%がこの値を下回ることを表します。つまり、最も高い10% の値のみがこの点を超えます。これは「最悪のケースの通常」パフォーマンスを理解するのに役立つ方法です。時折発生するスパイクを除外しながら、レイテンシが許容できないレベルに近づいているときを表示します。

関数を適用するには、パネルの外側の任意の場所をクリックして選択を確認します (4)。

Percentile 関数およびその他の関数の詳細については、Chart Analytics を参照してください。

TimeShift と数式の使用

1. Timeshift 分析関数の使用

多くの場合、現在のパフォーマンスを過去のデータと比較することが有用です。たとえば、時間の経過に伴うトレンド、回帰、または改善を特定するためです。Timeshift 関数は、時系列を過去にシフトさせることでこれを簡単にし、過去の値を現在と並べて表示できるようにします。

開始するには、Signal A の横にある ... メニュー (1) をクリックし、ドロップダウンから Clone (2) を選択してクローンを作成します。

シグナルを クローン すると、同じメトリクス、フィルター、および設定を持つ同一のコピーが作成されます。この複製、Signal B は、元のシグナルを変更せずに、1週間前のメトリクスがどのように見えたかを可視化するための Timeshift の適用など、さらなる計算や比較に使用できます。

クローン作成後、Signal B (1) というラベルの新しいシグナルが表示されます。これは Signal A の正確なコピーであるため、両方のシグナルは同じ時間範囲で同じデータを表示します。その結果、チャート上で 完全に重なって 表示され、1本の線しかないように見えます。

比較を意味のあるものにするために、Signal B に Timeshift を適用し、データを1週間過去にシフトさせます。これにより、現在のレイテンシのトレンドが先週の同時期と比較してどうなっているかを確認できます。

Signal Bの横にある F(x) 列で、+ (2) をクリックし、リストから Timeshift (3) 関数を選択します。

プロンプトが表示されたら、タイムシフト値として 1w（または7日間の場合は 7d）(4) を入力します。パネルの外側の任意の場所をクリック (5) して変更を確認します。

これにより、Signal B のデータが1週間過去にシフトされ、現在のレイテンシのトレンドを先週の同時期と視覚的に比較できます。

Signal B の色を変更するには、その行の右端にある ⚙️ 設定アイコン (1) をクリックして設定メニューを開きます。次に、ピンクなどの Plot Color (2) を選択して、チャート上で Signal B を元のシグナルと視覚的に区別します。完了したら、Close (3) をクリックします。

チャートに2つのプロットが表示されるはずです：現在のレイテンシの p90（Signal A）が青で表示され、1週間前の p90（Signal B）がピンクで表示されます。

それらの違いを解釈しやすくするために、Area chart アイコン (1) をクリックして可視化スタイルを変更します。これにより、曲線の下の領域が強調表示され、先週のレイテンシが現在の値より高かった時期を見つけやすくなります。

次に、Overrideバーの Time (2) の横にあるフィールドをクリックし、ドロップダウンから Past Hour (3) を選択して時間範囲を更新します。

2. 数式の使用

次に、2つの時間シフトされたメトリクス値の差を計算することで、さらに一歩進めましょう。たとえば、今日のデータをちょうど1週間前のデータと比較します。

行 C (1) の Enter Formula ボタンをクリックし、A - B (2) と入力して Signal B を Signal A から減算します。これにより、C というラベルの新しい計算シグナルが作成されます。

この数式の結果のみに焦点を当てるには、A (3) と B (4) の横にある目のアイコンをクリックして他のシグナルを非表示にし、C のみを表示したままにします。

現在のメトリクス値（A）と1週間前の値（B）の差を表す単一の線が表示されるはずです。チャートでは、一部の値が負になることがあります。これは、その時点で古いメトリクス（B）が現在のもの（A）より高かった場合に発生します。

ビジュアルチャート分析を探索したので、次のセクションでチャートとDetectorを駆動するSignalFlowの仕組みを見てみましょう！

SignalFlow の使用

1. SignalFlow の紹介

それでは、Splunk Observability Cloudを支える強力な分析言語である SignalFlow を詳しく見てみましょう。SignalFlowを使用すると、監視ロジックをコードとして定義でき、メトリクスを扱いアラートを自動化するための柔軟でリアルタイムな方法を提供します。

Splunk Infrastructure Monitoring の中核には、ストリーミングメトリクスデータをリアルタイムで処理する SignalFlow 分析エンジン があります。SignalFlowはPythonに似た構文で記述され、メトリクス時系列（MTS） を取り込み、変換や計算を実行し、新しいMTSを出力する計算を構築できます。

SignalFlowの一般的なユースケースには以下が含まれます：

週次比較など、現在の値と過去のトレンドの比較
分散パーセンタイルチャートを使用した母集団レベルの洞察の作成
Service Level Objective（SLO）違反の検出など、変化率やしきい値の監視
ディスク容量不足アラートの増加に関連するサービスの特定など、相関ディメンションの識別

Chart Builder インターフェースでメトリクスを選択し、分析関数を視覚的に適用することで、SignalFlowベースの計算を直接作成できます。より高度なユースケースでは、SignalFlow API を使用してSignalFlowプログラムを直接記述および実行することもできます。

SignalFlowには、時系列データを操作する堅牢な組み込み関数セットが含まれており、複雑なシステム全体でのダイナミックでリアルタイムな監視に最適です。

Info

SignalFlowの詳細については、Analyze incoming data using SignalFlow を参照してください。

2. SignalFlow の表示

Chart Builderで View SignalFlow をクリックして、チャートを駆動する基盤となるコードを開きます。

View SignalFlow をクリックすると、チャートの背後にあるロジックと変換を定義する SignalFlow プログラム (1) が表示されます。このビューにより、可視化を駆動するコードに直接アクセスでき、ビジュアルエディタでは不可能な微調整や拡張が可能になります。

以下は、先ほど作成したチャートのSignalFlowコードの例です。このスニペットは、2つのパーセンタイルシグナル（現在と1週間前）を定義し、タイムシフトを適用し、それらの差を計算した方法を示しています。コードを確認することで、各ステップが最終的なチャートにどのように貢献しているかが明確になります。

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 (2) をクリックして、Chart Builder UIに戻ります。

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

ダッシュボードへのチャートの追加

1. 既存のダッシュボードへの保存

チャートを保存する前に、左上隅で YOUR_NAME-Dashboard: YOUR_NAME-Dashboard (1) が選択されていることを確認してください。これにより、チャートが正しいダッシュボードに保存されます。

次に、チャートに名前を付けます。Latency History (2) と入力し、必要に応じて Chart Description (3) に簡単な説明を追加してください（例のように）。

準備ができたら、Save And Close ボタン (4) をクリックします。ダッシュボードに戻り、2つのチャートが含まれるようになります。

2. チャートのコピーと貼り付け

次に、先ほど作成したチャートを複製して、別のチャートをすばやく追加しましょう。

ダッシュボードで Latency History チャートを見つけ、チャートの右上隅にあるthree dots ... (1) をクリックします。メニューから Copy (2) を選択します。

コピー後、ページ上部の + アイコン (3) の前に小さな白い 1 が表示されます。これは、1つのチャートが貼り付け可能であることを示しています。

ページ上部の + アイコン (1) をクリックし、ドロップダウンメニューで (2) を選択します。その行の末尾にも 1 が表示され、コピーしたチャートが追加可能であることを確認できます。

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

3. 貼り付けたチャートの編集

複製したチャートを編集するには、ダッシュボード内の Latency History チャートの1つでthree dots ... をクリックし、Open を選択します。または、チャートのタイトル Latency History を直接クリックしてエディタで開くこともできます。

これにより、再びエディタ環境に移動します。

まず、チャートの右上隅にある時間範囲を調整します。最近のデータをより広く表示するために Past 1 Hour (1) に設定します。

次に、チャートをカスタマイズしてユニークにしましょう。Signal A (2) の横にある目のアイコンをクリックして、再び表示させます。次に、Signal C (3) の目のアイコンをクリックして非表示にします。

チャートタイトルを Latency history から Latency vs Load (4) に更新し、必要に応じてチャートの説明を追加または編集して、更新されたフォーカスを反映させます (5)。

Add Metric Or Event ボタンをクリックして、新しいシグナルを作成します。表示される入力フィールドに demo.trans.count (1) と入力して選択し、Signal D として追加します。

これにより、新しいシグナル Signal D がチャートに追加されます。これは、処理中のアクティブなリクエストの数を表します。

Paris データセンター に焦点を当てるために、demo_datacenter: Paris (2) のフィルターを追加します。次に、Configure Plot ⚙️ (3) ボタンをクリックして、データの表示方法を調整します。rollup タイプを Auto (Delta) から Rate/sec (4) に変更して、1秒あたりの受信リクエストの割合を表示します。

最後に、シグナル名を demo.trans.count から Latency vs Load (5) に変更して、チャート内での役割をより明確に反映させます。

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

「説明」ノートを追加してチャートを配置しましょう！

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

1. ノートの追加

ダッシュボードでは、ユーザーを支援する短い「説明」ペインを配置することが有効な場合がよくあります。New Text Note ボタンをクリックして、今すぐ追加しましょう。

これによりノートエディタが開きます。

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

これには以下が含まれます（ただし、これらに限定されません）：

ヘッダー（さまざまなサイズで）
強調スタイル
リストとテーブル
リンク。外部の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の幅に広げます。ノートを他のチャートの右側にドラッグし、他の3つのチャートと一致するようにサイズを変更します。Time を -1h に設定すると、以下のようなダッシュボードができあがります！

OpenTelemetry、Docker、K8sを実践で学ぶ

2 minutes Author Derek Mitchell

このワークショップでは、以下の項目について実践経験を積むことができます

LinuxおよびKubernetes環境で、SplunkディストリビューションのOpenTelemetry .NETを使用してコレクターのデプロイと.NETアプリケーションの計装を実践します。
.NETアプリケーションの「Docker化」、Dockerでの実行、そしてSplunk OpenTelemetry計装の追加を実践します。
Helmを使用したK8s環境でのSplunkディストロのコレクターのデプロイを実践します。その後、コレクター設定をカスタマイズし、問題のトラブルシューティングを行います。

Tip

このワークショップを最も簡単にナビゲートする方法は以下を使用することです

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）と右（▶️）のカーソルキー

EC2インスタンスへの接続

5 minutes

EC2 インスタンスへ接続

各参加者のために、AWS/EC2にUbuntu Linuxインスタンスを用意しました。

インストラクターから提供されたIPアドレスとパスワードを使用して、以下のいずれかの方法でEC2インスタンスに接続してください

Mac OS / Linux
- ssh splunk@IPアドレス
Windows 10+
- OpenSSHクライアントを使用
以前のバージョンのWindows
- Puttyを使用

OpenTelemetryコレクターのデプロイ

10 minutes

OpenTelemetry コレクターのアンインストール

EC2インスタンスには、すでにSplunk DistributionのOpenTelemetryコレクターの古いバージョンがインストールされている可能性があります。先に進む前に、次のコマンドを使用してアンインストールしましょう

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

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  splunk-otel-collector*
0 upgraded, 0 newly installed, 1 to remove and 167 not upgraded.
After this operation, 766 MB disk space will be freed.
(Reading database ... 157441 files and directories currently installed.)
Removing splunk-otel-collector (0.92.0) ...
(Reading database ... 147373 files and directories currently installed.)
Purging configuration files for splunk-otel-collector (0.92.0) ...
Scanning processes...
Scanning candidates...
Scanning linux images...

Running kernel seems to be up-to-date.

Restarting services...
 systemctl restart fail2ban.service falcon-sensor.service
Service restarts being deferred:
 systemctl restart networkd-dispatcher.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.
Successfully removed the splunk-otel-collector package

OpenTelemetry collector のデプロイ

Linux EC2インスタンスに、Splunk DistributionのOpenTelemetryコレクターの最新バージョンをデプロイしましょう。

これは curl を使用してコレクターバイナリをダウンロードし、特定の引数を指定して実行することで可能です。これらの引数は、データを送信するrealm、使用するアクセストークン、およびデータを送信するデプロイメント環境をコレクターに指示します。

Splunk Observability Cloud におけるデプロイメント環境とは、システムまたはアプリケーションの個別のデプロイメントであり、同じアプリケーションの他のデプロイメントの設定と重複しない設定を行うことができます。

curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh; \
sudo sh /tmp/splunk-otel-collector.sh \
--realm $REALM \
--mode agent \
--without-instrumentation \
--deployment-environment otel-$INSTANCE \
-- $ACCESS_TOKEN

Splunk OpenTelemetry Collector Version: latest
Memory Size in MIB: 512
Realm: us1
Ingest Endpoint: https://ingest.us1.signalfx.com
API Endpoint: https://api.us1.signalfx.com
HEC Endpoint: https://ingest.us1.signalfx.com/v1/log
etc.

詳細については、インストーラースクリプトを使用した Linux 用コレクターのインストールを参照してください。

コレクターが実行中であることを確認

インスタンスでコレクターが正常に実行されていることを確認しましょう。

ステータスコマンドを終了するには、Ctrl + C を押します。

sudo systemctl status splunk-otel-collector

● splunk-otel-collector.service - Splunk OpenTelemetry Collector
     Loaded: loaded (/lib/systemd/system/splunk-otel-collector.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/splunk-otel-collector.service.d
             └─service-owner.conf
     Active: active (running) since Fri 2024-12-20 00:13:14 UTC; 45s ago
   Main PID: 14465 (otelcol)
      Tasks: 9 (limit: 19170)
     Memory: 117.4M
        CPU: 681ms
     CGroup: /system.slice/splunk-otel-collector.service
             └─14465 /usr/bin/otelcol

コレクターログの確認方法

journalctl を使用してコレクターログを表示できます

ログの監視を終了するには、Ctrl + C を押します。

sudo journalctl -u splunk-otel-collector -f -n 100

Dec 20 00:13:14 derek-1 systemd[1]: Started Splunk OpenTelemetry Collector.
Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:483: Set config to /etc/otel/collector/agent_config.yaml
Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:539: Set memory limit to 460 MiB
Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:524: Set soft memory limit set to 460 MiB
Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:373: Set garbage collection target percentage (GOGC) to 400
Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:414: set "SPLUNK_LISTEN_INTERFACE" to "127.0.0.1"
etc.

コレクターの設定

このコレクターが使用している設定はどこで見つけられるでしょうか？

その設定は /etc/otel/collector ディレクトリにあります。コレクターを agent モードでインストールしたため、コレクター設定は agent_config.yaml ファイルにあります。

.NETアプリケーションのデプロイ

10 minutes

前提条件

アプリケーションをデプロイする前に、インスタンスに.NET 8 SDKをインストールする必要があります。

sudo apt-get update && \
  sudo apt-get install -y dotnet-sdk-8.0

Hit:1 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:3 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease
Ign:5 https://splunk.jfrog.io/splunk/otel-collector-deb release InRelease
Hit:6 https://splunk.jfrog.io/splunk/otel-collector-deb release Release
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  aspnetcore-runtime-8.0 aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-host-8.0 dotnet-hostfxr-8.0 dotnet-runtime-8.0 dotnet-targeting-pack-8.0 dotnet-templates-8.0 liblttng-ust-common1
  liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1-8.0
The following NEW packages will be installed:
  aspnetcore-runtime-8.0 aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-host-8.0 dotnet-hostfxr-8.0 dotnet-runtime-8.0 dotnet-sdk-8.0 dotnet-targeting-pack-8.0 dotnet-templates-8.0
  liblttng-ust-common1 liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1-8.0
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 138 MB of archives.
After this operation, 495 MB of additional disk space will be used.
etc.

詳細については、Ubuntu に.NET SDK または.NET Runtime をインストールするを参照してください。

.NET アプリケーションの確認

ターミナルで、アプリケーションディレクトリに移動します

cd ~/workshop/docker-k8s-otel/helloworld

このワークショップでは、シンプルな「Hello World」.NETアプリケーションを使用します。主要なロジックは HelloWorldController.csファイルにあります

public class HelloWorldController : ControllerBase
{
    private ILogger<HelloWorldController> logger;

    public HelloWorldController(ILogger<HelloWorldController> logger)
    {
        this.logger = logger;
    }

    [HttpGet("/hello/{name?}")]
    public string Hello(string name)
    {
        if (string.IsNullOrEmpty(name))
        {
           logger.LogInformation("/hello endpoint invoked anonymously");
           return "Hello, World!";
        }
        else
        {
            logger.LogInformation("/hello endpoint invoked by {name}", name);
            return String.Format("Hello, {0}!", name);
        }
    }
}

.NET アプリケーションのビルドと実行

以下のコマンドを使用してアプリケーションをビルドできます

dotnet build

MSBuild version 17.8.5+b5265ef37 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  helloworld -> /home/splunk/workshop/docker-k8s-otel/helloworld/bin/Debug/net8.0/helloworld.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.04

ビルドが成功したら、次のように実行できます

dotnet run

Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:8080
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/splunk/workshop/docker-k8s-otel/helloworld

実行したら、UbuntuインスタンスへのSSH接続を2つ目のターミナルで開き、curlを使用してアプリケーションにアクセスします

curl http://localhost:8080/hello

Hello, World!

名前を渡すこともできます

curl http://localhost:8080/hello/Tom

Hello, Tom!

次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。

次のステップ

アプリケーションをOpenTelemetryで計装するために使用できる3つの方法は何でしょうか？

オプションの詳細については、Splunk Observability Cloud 用の.NET アプリケーションの計装を参照してください。

OpenTelemetryで.NETアプリケーションを計装する

20 minutes

Splunk Distribution of OpenTelemetry のダウンロード

このワークショップでは、NuGetパッケージを使用せず、Splunk Distribution of OpenTelemetryを手動でインストールします。

最新の splunk-otel-dotnet-install.sh ファイルをダウンロードすることから始めます。これを使用して.NETアプリケーションを計装します

cd ~/workshop/docker-k8s-otel/helloworld

curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O

インストールプロセスの詳細については、Splunk Distribution of OpenTelemetry .NET の手動インストールを参照してください。

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

ターミナルで、以下のようにディストリビューションをインストールします

sh ./splunk-otel-dotnet-install.sh

Downloading v1.8.0 for linux-glibc (/tmp/tmp.m3tSdtbmge/splunk-opentelemetry-dotnet-linux-glibc-x64.zip)...

注意：上記のコマンドを実行する際には、ARCHITECTURE 環境変数を含める必要がある場合があります
ARCHITECTURE=x64 sh ./splunk-otel-dotnet-install.sh

計装の有効化

次に、OpenTelemetry計装を有効化できます

. $HOME/.splunk-otel-dotnet/instrument.sh

デプロイメント環境の設定

デプロイメント環境を設定して、データがSplunk Observability Cloud内の独自の環境に流れるようにしましょう

export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=otel-$INSTANCE

計装を使用したアプリケーションの実行

以下のようにアプリケーションを実行できます

dotnet run

チャレンジ

LinuxインスタンスからC#アプリケーションによってエクスポートされているトレースをどのように確認できるでしょうか？

答えを見るにはここをクリック

これを行う方法は2つあります

dotnet run コマンドの開始時に OTEL_TRACES_EXPORTER=otlp,console を追加することで、トレースがOTLP経由でコレクターに書き込まれるとともに、コンソールにも書き込まれるようになります。

OTEL_TRACES_EXPORTER=otlp,console dotnet run

あるいは、コレクター設定にデバッグエクスポーターを追加し、それをトレースパイプラインに追加することで、トレースがコレクターログに書き込まれるようになります。

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [jaeger, otlp, zipkin]
      processors:
        - memory_limiter
        - batch
        - resourcedetection
      exporters: [otlphttp, signalfx, debug]

アプリケーションへのアクセス

アプリケーションが実行中になったら、2つ目のSSHターミナルを使用してcurlでアクセスします

curl http://localhost:8080/hello

以前と同様に、Hello, World! が返されるはずです。

トレースログを有効にした場合は、以下のようなトレースがコンソールまたはコレクターログに書き込まれているのを確認できるはずです

info: Program[0]
      /hello endpoint invoked anonymously
Activity.TraceId:            c7bbf57314e4856447508cd8addd49b0
Activity.SpanId:             1c92ac653c3ece27
Activity.TraceFlags:         Recorded
Activity.ActivitySourceName: Microsoft.AspNetCore
Activity.DisplayName:        GET /hello/{name?}
Activity.Kind:               Server
Activity.StartTime:          2024-12-20T00:45:25.6551267Z
Activity.Duration:           00:00:00.0006464
Activity.Tags:
    server.address: localhost
    server.port: 8080
    http.request.method: GET
    url.scheme: http
    url.path: /hello
    network.protocol.version: 1.1
    user_agent.original: curl/7.81.0
    http.route: /hello/{name?}
    http.response.status_code: 200
Resource associated with Activity:
    splunk.distro.version: 1.8.0
    telemetry.distro.name: splunk-otel-dotnet
    telemetry.distro.version: 1.8.0
    service.name: helloworld
    os.type: linux
    os.description: Ubuntu 22.04.5 LTS
    os.build_id: 6.8.0-1021-aws
    os.name: Ubuntu
    os.version: 22.04
    host.name: derek-1
    host.id: 20cf15fcc7054b468647b73b8f87c556
    process.owner: splunk
    process.pid: 16997
    process.runtime.description: .NET 8.0.11
    process.runtime.name: .NET
    process.runtime.version: 8.0.11
    container.id: 2
    telemetry.sdk.name: opentelemetry
    telemetry.sdk.language: dotnet
    telemetry.sdk.version: 1.9.0
    deployment.environment: otel-derek-1

Splunk Observability Cloud でのアプリケーションの確認

セットアップが完了したので、トレースがSplunk Observability Cloudに送信されていることを確認しましょう。アプリケーションが初回デプロイされた場合、データが表示されるまでに数分かかる場合があることに注意してください。

APMにナビゲートし、Environmentドロップダウンを使用してあなたの環境（つまり otel-instancename）を選択します。

すべてが正しくデプロイされている場合、サービスのリストに helloworld が表示されるはずです

右側のService Mapをクリックしてサービスマップを表示します。

次に、右側のTracesをクリックして、このアプリケーションでキャプチャされたトレースを確認します。

個別のトレースは以下のように表示されるはずです

次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。

アプリケーションのDocker化

15 minutes

このワークショップの後半では、.NETアプリケーションをKubernetesクラスターにデプロイします。

しかし、どのようにそれを行うのでしょうか？

最初のステップは、アプリケーション用のDockerイメージを作成することです。これはアプリケーションの「Docker化」として知られており、プロセスは Dockerfile の作成から始まります。

しかし、まず重要な用語を定義しましょう。

重要な用語

Docker とは何ですか？

「Docker は、コンテナと呼ばれる緩い分離環境でアプリケーションをパッケージ化して実行する機能を提供します。分離とセキュリティにより、指定されたホスト上で同時に多くのコンテナを実行できます。コンテナは軽量で、アプリケーションの実行に必要なすべてを含んでいるため、ホストにインストールされているものに依存する必要がありません。」

ソース: https://docs.docker.com/get-started/docker-overview/

コンテナとは何ですか？

「コンテナは、アプリのコンポーネントごとの分離されたプロセスです。各コンポーネントは…独自の分離された環境で実行され、マシン上の他のすべてのものから完全に分離されています。」

ソース: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/

コンテナイメージとは何ですか？

「コンテナイメージは、コンテナを実行するためのすべてのファイル、バイナリ、ライブラリ、および設定を含む標準化されたパッケージです。」

Dockerfile

「Dockerfile は、コンテナイメージを作成するために使用されるテキストベースのドキュメントです。実行するコマンド、コピーするファイル、起動コマンドなどに関するイメージビルダーへの指示を提供します。」

Dockerfile の作成

/home/splunk/workshop/docker-k8s-otel/helloworld ディレクトリに Dockerfile という名前のファイルを作成しましょう。

cd /home/splunk/workshop/docker-k8s-otel/helloworld

ファイルの作成にはviまたはnanoを使用できます。viを使用した例を示します

vi Dockerfile

新しく開いたファイルに以下の内容をコピー＆ペーストします

以下のテキストを貼り付ける前に、vi で「i」を押して挿入モードに入ってください。

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["helloworld.csproj", "helloworld/"]
RUN dotnet restore "./helloworld/./helloworld.csproj"
WORKDIR "/src/helloworld"
COPY . .
RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "helloworld.dll"]

vi での変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

これはすべて何を意味するのでしょうか？詳しく見てみましょう。

Dockerfile の詳細解説

この例では、マルチステージDockerfileを使用しており、Dockerイメージ作成プロセスを以下のステージに分けています

Base（ベース）
Build（ビルド）
Publish（パブリッシュ）
Final（最終）

マルチステージアプローチはより複雑ですが、デプロイメント用により軽量なランタイムイメージを作成することができます。以下では、これらの各ステージの目的を説明します。

ベースステージ

ベースステージでは、アプリを実行するユーザー、作業ディレクトリを定義し、アプリにアクセスするために使用されるポートを公開します。これはMicrosoftの mcr.microsoft.com/dotnet/aspnet:8.0 イメージをベースにしています

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

なお、mcr.microsoft.com/dotnet/aspnet:8.0 イメージには.NET runtimeのみが含まれており、 SDKは含まれていないため、比較的軽量です。これはDebian 12 Linux distributionがベースになっています。ASP.NET Core Runtime Dockerイメージの詳細については GitHubで確認できます。

Build ステージ

Dockerfileの次のステージはbuildステージです。このステージでは、 mcr.microsoft.com/dotnet/sdk:8.0 イメージが使用されます。これもDebian 12がベースになっていますが、 runtimeだけでなく完全な.NET SDKが含まれています。

このステージでは .csproj ファイルをbuildイメージにコピーし、その後 dotnet restore を使用してアプリケーションが使用する依存関係をダウンロードします。

次に、アプリケーションコードをbuildイメージにコピーし、 dotnet build を使用してプロジェクトとその依存関係を .dll バイナリのセットにビルドします

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["helloworld.csproj", "helloworld/"]
RUN dotnet restore "./helloworld/./helloworld.csproj"
WORKDIR "/src/helloworld"
COPY . .
RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build

Publish ステージ

3番目のステージはpublishで、これはMicrosoftイメージではなくbuildステージイメージをベースにしています。このステージでは、dotnet publish を使用してアプリケーションとその依存関係をdeployment用にパッケージ化します

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

Final ステージ

4番目のステージは最終ステージで、これはbase ステージイメージをベースにしています（buildとpublishステージよりも軽量）。publishステージイメージからの出力をコピーし、アプリケーションのentry pointを定義します

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "helloworld.dll"]

Docker イメージのビルド

Dockerfile ができたので、これを使用してアプリケーションを含むDockerイメージをビルドできます

docker build -t helloworld:1.0 .

DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            Install the buildx component to build images with BuildKit:
            https://docs.docker.com/go/buildx/

Sending build context to Docker daemon  281.1kB
Step 1/19 : FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
8.0: Pulling from dotnet/aspnet
af302e5c37e9: Pull complete
91ab5e0aabf0: Pull complete
1c1e4530721e: Pull complete
1f39ca6dcc3a: Pull complete
ea20083aa801: Pull complete
64c242a4f561: Pull complete
Digest: sha256:587c1dd115e4d6707ff656d30ace5da9f49cec48e627a40bbe5d5b249adc3549
Status: Downloaded newer image for mcr.microsoft.com/dotnet/aspnet:8.0
 ---> 0ee5d7ddbc3b
Step 2/19 : USER app
etc,

これは、現在のディレクトリの Dockerfile を使用して helloworld:1.0 のタグでイメージをビルドするようDockerに指示します。

以下のコマンドで正常に作成されたことを確認できます

docker images

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
helloworld   1.0       db19077b9445   20 seconds ago   217MB

Docker イメージのテスト

続行する前に、以前に開始したアプリケーションがインスタンス上で実行されていないことを確認してください。

Dockerイメージを使用して以下のようにアプリケーションを実行できます

docker run --name helloworld \
--detach \
--expose 8080 \
--network=host \
helloworld:1.0

注意：--network=host パラメータを含めて、Docker コンテナがインスタンス上のリソースにアクセスできるようにしています。これは後でアプリケーションが localhost 上で実行されているコレクターにデータを送信する必要がある場合に重要です。

Dockerコンテナが実行されていることを確認しましょう

docker ps

$ docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED       STATUS       PORTS     NAMES
5f5b9cd56ac5   helloworld:1.0   "dotnet helloworld.d…"   2 mins ago    Up 2 mins              helloworld

以前と同様にアプリケーションにアクセスできます

curl http://localhost:8080/hello/Docker

Hello, Docker!

おめでとうございます。ここまで到達したということは、.NETアプリケーションのDocker化に成功したということです。

Dockerfileに計装を追加する

10 minutes

アプリケーションを正常にDocker化したので、次にOpenTelemetryによる計装を追加しましょう。

これは、Linuxで実行しているアプリケーションを計装した際の手順と似ていますが、注意すべきいくつかの重要な違いがあります。

Dockerfile の更新

/home/splunk/workshop/docker-k8s-otel/helloworld ディレクトリの Dockerfile を更新しましょう。

Dockerfileで.NETアプリケーションがビルドされた後、以下の操作を行いたいと思います

splunk-otel-dotnet-install.sh をダウンロードして実行するために必要な依存関係を追加する
Splunk OTel .NETインストーラーをダウンロードする
ディストリビューションをインストールする

Dockerfileのビルドステージに以下を追加できます。viでDockerfileを開きましょう

vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile

vi では「i」キーを押して編集モードに入ります ‘NEW CODE’とマークされている行を Dockerfile のビルドステージセクションに貼り付けてください

# CODE ALREADY IN YOUR DOCKERFILE:
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["helloworld.csproj", "helloworld/"]
RUN dotnet restore "./helloworld/./helloworld.csproj"
WORKDIR "/src/helloworld"
COPY . .
RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build

# NEW CODE: add dependencies for splunk-otel-dotnet-install.sh
RUN apt-get update && \
 apt-get install -y unzip

# NEW CODE: download Splunk OTel .NET installer
RUN curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O

# NEW CODE: install the distribution
RUN sh ./splunk-otel-dotnet-install.sh

次に、以下の変更でDockerfileの最終ステージを更新します

ビルドイメージから最終イメージに/root/.splunk-otel-dotnet/をコピーする
entrypoint.shファイルもコピーする
OTEL_SERVICE_NAME と OTEL_RESOURCE_ATTRIBUTES 環境変数を設定する
ENTRYPOINT を entrypoint.sh に設定する

最も簡単な方法は、最終ステージ全体を以下の内容で置き換えることです

重要 Dockerfile の $INSTANCE をあなたのインスタンス名に置き換えてください。インスタンス名は echo $INSTANCE を実行することで確認できます。

# CODE ALREADY IN YOUR DOCKERFILE
FROM base AS final

# NEW CODE: Copy instrumentation file tree
WORKDIR "//home/app/.splunk-otel-dotnet"
COPY --from=build /root/.splunk-otel-dotnet/ .

# CODE ALREADY IN YOUR DOCKERFILE
WORKDIR /app
COPY --from=publish /app/publish .

# NEW CODE: copy the entrypoint.sh script
COPY entrypoint.sh .

# NEW CODE: set OpenTelemetry environment variables
ENV OTEL_SERVICE_NAME=helloworld
ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE'

# NEW CODE: replace the prior ENTRYPOINT command with the following two lines
ENTRYPOINT ["sh", "entrypoint.sh"]
CMD ["dotnet", "helloworld.dll"]

vi での変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

これらすべての変更の後、Dockerfileは以下のようになるはずです

重要このコンテンツを自分の Dockerfile にコピー＆ペーストする場合は、 Dockerfile の $INSTANCE をあなたのインスタンス名に置き換えてください。インスタンス名は echo $INSTANCE を実行することで確認できます。

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["helloworld.csproj", "helloworld/"]
RUN dotnet restore "./helloworld/./helloworld.csproj"
WORKDIR "/src/helloworld"
COPY . .
RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build

# NEW CODE: add dependencies for splunk-otel-dotnet-install.sh
RUN apt-get update && \
 apt-get install -y unzip

# NEW CODE: download Splunk OTel .NET installer
RUN curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O

# NEW CODE: install the distribution
RUN sh ./splunk-otel-dotnet-install.sh

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final

# NEW CODE: Copy instrumentation file tree
WORKDIR "//home/app/.splunk-otel-dotnet"
COPY --from=build /root/.splunk-otel-dotnet/ .

WORKDIR /app
COPY --from=publish /app/publish .

# NEW CODE: copy the entrypoint.sh script
COPY entrypoint.sh .

# NEW CODE: set OpenTelemetry environment variables
ENV OTEL_SERVICE_NAME=helloworld
ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE'

# NEW CODE: replace the prior ENTRYPOINT command with the following two lines
ENTRYPOINT ["sh", "entrypoint.sh"]
CMD ["dotnet", "helloworld.dll"]

entrypoint.sh ファイルの作成

また、/home/splunk/workshop/docker-k8s-otel/helloworld フォルダに entrypoint.sh という名前のファイルを以下の内容で作成する必要があります

vi /home/splunk/workshop/docker-k8s-otel/helloworld/entrypoint.sh

次に、新しく作成したファイルに以下のコードを貼り付けます

#!/bin/sh
# Read in the file of environment settings
. /$HOME/.splunk-otel-dotnet/instrument.sh

# Then run the CMD
exec "$@"

vi での変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

entrypoint.sh スクリプトは、計装に含まれるinstrument.shスクリプトが環境変数をコンテナ起動時に取得するために必要です。これにより、各プラットフォームに対して環境変数が正しく設定されることが保証されます。

「なぜ Linux ホスト上で OpenTelemetry .NET instrumentation を有効化したときのように、 Dockerfile に以下のコマンドを含めるだけではだめなのか？」と疑問に思うかもしれません。
RUN . $HOME/.splunk-otel-dotnet/instrument.sh
この方法の問題点は、各 Dockerfile RUN ステップが新しいコンテナと新しいシェルで実行されることです。あるシェルで環境変数を設定しようとしても、後で見ることはできません。この問題は、ここで行ったようにエントリポイントスクリプトを使用することで解決されます。この問題についての詳細は、こちらのStack Overflow の投稿を参照してください。

Docker イメージのビルド

OpenTelemetry .NET instrumentationを含む新しいDockerイメージをビルドしましょう

docker build -t helloworld:1.1 .

注：以前のバージョンと区別するために、異なるバージョン（1.1）を使用しています。古いバージョンをクリーンアップするには、以下のコマンドでコンテナ ID を取得します
docker ps -a
次に、以下のコマンドでコンテナを削除します
docker rm <old container id> --force
次にコンテナイメージ ID を取得します
docker images | grep 1.0
最後に、以下のコマンドで古いイメージを削除できます
docker image rm <old image id>

アプリケーションの実行

新しいDockerイメージを実行しましょう

docker run --name helloworld \
--detach \
--expose 8080 \
--network=host \
helloworld:1.1

以下を使用してアプリケーションにアクセスできます

curl http://localhost:8080/hello

トラフィックを生成するために上記のコマンドを数回実行しましょう。

1分ほど経過したら、Splunk Observability Cloudに新しいトレースが表示されることを確認します。

あなたの特定の環境でトレースを探すことを忘れないでください。

トラブルシューティング

Splunk Observability Cloudにトレースが表示されない場合は、以下のようにトラブルシューティングを行うことができます。

まず、コレクター設定ファイルを編集用に開きます

sudo vi /etc/otel/collector/agent_config.yaml

次に、トレースパイプラインにデバッグエクスポーターを追加します。これにより、トレースがコレクターログに書き込まれるようになります

service:
  extensions: [health_check, http_forwarder, zpages, smartagent]
  pipelines:
    traces:
      receivers: [jaeger, otlp, zipkin]
      processors:
        - memory_limiter
        - batch
        - resourcedetection
      #- resource/add_environment
      # NEW CODE: デバッグエクスポーターをここに追加
      exporters: [otlphttp, signalfx, debug]

その後、コレクターを再起動して設定変更を適用します

sudo systemctl restart splunk-otel-collector

journalctl を使用してコレクターログを表示できます

ログの追跡を終了するには、Ctrl + C を押します。

sudo journalctl -u splunk-otel-collector -f -n 100

K8sでOpenTelemetryコレクターをインストール

15 minutes

ワークショップパート 1 の振り返り

ワークショップのこの時点で、以下を正常に完了しました

LinuxホストにSplunk distribution of OpenTelemetryコレクターをデプロイ
Splunk Observability Cloudにトレースとメトリクスを送信するよう設定
.NETアプリケーションをデプロイし、OpenTelemetryで計装
.NETアプリケーションをDocker化し、o11y cloudにトレースが流れることを確認

上記のステップを完了していない場合は、ワークショップの残りの部分に進む前に以下のコマンドを実行してください

cp /home/splunk/workshop/docker-k8s-otel/docker/Dockerfile /home/splunk/workshop/docker-k8s-otel/helloworld/
cp /home/splunk/workshop/docker-k8s-otel/docker/entrypoint.sh /home/splunk/workshop/docker-k8s-otel/helloworld/

重要これらのファイルがコピーされたら、/home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile をエディターで開き、Dockerfile の $INSTANCE をあなたのインスタンス名に置き換えてください。インスタンス名は echo $INSTANCE を実行することで確認できます。

ワークショップパート 2 の紹介

ワークショップの次の部分では、Kubernetesでアプリケーションを実行したいと思います。そのため、KubernetesクラスターにSplunk distribution of OpenTelemetryコレクターをデプロイする必要があります。

まず、いくつかの重要な用語を定義しましょう。

重要な用語

Kubernetes とは何ですか？

「Kubernetes は、宣言的な設定と自動化の両方を促進する、コンテナ化されたワークロードとサービスを管理するためのポータブルで拡張可能なオープンソースプラットフォームです。」

Source: https://kubernetes.io/docs/concepts/overview/

Dockerfileに小さな修正を加えた後、アプリケーション用に以前ビルドしたDockerイメージを Kubernetesクラスターにデプロイします。

Helm とは何ですか？

HelmはKubernetes用のパッケージマネージャーです。

「最も複雑な Kubernetes アプリケーションだとしても、定義、インストール、アップグレード役立ちます」

Helm を使用したコレクターのインストール

プロダクト内ウィザードではなくコマンドラインを使用して、コレクターをインストールするための独自の helm コマンドを作成しましょう。

まず、helmリポジトリを追加する必要があります：ます。」

Source: https://helm.sh/

Helmを使用してK8sクラスターにOpenTelemetryコレクターをデプロイします。

Helm の利点

複雑性の管理
- 数十のマニフェストファイルではなく、単一のvalues.yamlファイルを扱う
簡単な更新
- インプレースアップグレード
ロールバックサポート
- helm rollbackを使用してリリースの古いバージョンにロールバック

ホストコレクターのアンインストール

先に進む前に、Linuxホストに先ほどインストールしたコレクターを削除しましょう \

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

Helm を利用して Collector をインストールする

ウィザードの代わりに、コマンドラインを利用してcollectorをインストールします。

まず初めに、Helmリポジトリに登録する必要があります

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart

リポジトリが最新であることを確認します

helm repo update

helmチャートのデプロイメントを設定するために、/home/splunk ディレクトリに values.yaml という名前の新しいファイルを作成しましょう

# swith to the /home/splunk dir
cd /home/splunk
# create a values.yaml file in vi
vi values.yaml

Press ‘i’ to enter into insert mode in vi before pasting the text below.　“i"を押下すると vi はインサートモードになります。ペースト前に押下してください

そして、下記のコードをコピーしてください

logsEngine: otel
agent:
  config:
    receivers:
      hostmetrics:
        collection_interval: 10s
        root_path: /hostfs
        scrapers:
          cpu: null
          disk: null
          filesystem:
            exclude_mount_points:
              match_type: regexp
              mount_points:
                - /var/*
                - /snap/*
                - /boot/*
                - /boot
                - /opt/orbstack/*
                - /mnt/machines/*
                - /Users/*
          load: null
          memory: null
          network: null
          paging: null
          processes: null

vi での変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

次のコマンドを使用してコレクターをインストールできます

  helm install splunk-otel-collector --version 0.136.0 \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="clusterName=$INSTANCE-cluster" \
  --set="environment=otel-$INSTANCE" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.index=splunk4rookies-workshop" \
  -f values.yaml \
  splunk-otel-collector-chart/splunk-otel-collector

NAME: splunk-otel-collector
LAST DEPLOYED: Fri Dec 20 01:01:43 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.

コレクターが実行中であることを確認

以下のコマンドでコレクターが実行されているかどうかを確認できます

kubectl get pods

NAME                                                         READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-8xvk8                            1/1     Running   0          49s
splunk-otel-collector-k8s-cluster-receiver-d54857c89-tx7qr   1/1     Running   0          49s

O11y Cloud で K8s クラスターを確認

Splunk Observability Cloudで、Infrastructure -> Kubernetes -> Kubernetes Clustersにナビゲートし、クラスター名（$INSTANCE-cluster）を検索します

アプリケーションをK8sにデプロイ

15 minutes

Dockerfile の更新

Kubernetesでは、環境変数は通常、Dockerイメージに組み込むのではなく .yaml マニフェストファイルで管理されます。そこで、Dockerfileから以下の2つの環境変数を削除しましょう

vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile

次に、以下の2つの環境変数を削除します

ENV OTEL_SERVICE_NAME=helloworld
ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE'

vi での変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

新しい Docker イメージのビルド

環境変数を除外した新しいDockerイメージをビルドしましょう

cd /home/splunk/workshop/docker-k8s-otel/helloworld

docker build -t helloworld:1.2 .

Note: we’ve used a different version (1.2) to distinguish the image from our earlier version. To clean up the older versions, run the following command to get the container id:
docker ps -a
Then run the following command to delete the container:
docker rm <old container id> --force
Now we can get the container image id:
docker images | grep 1.1
Finally, we can run the following command to delete the old image:
docker image rm <old image id>

Docker イメージを Kubernetes にインポート

通常であれば、DockerイメージをDocker Hubなどのリポジトリにプッシュします。しかし、今回のセッションでは、k3sに直接インポートする回避策を使用します。

cd /home/splunk

# Import the image into k3d
sudo k3d image import helloworld:1.2 --cluster $INSTANCE-cluster

.NET アプリケーションのデプロイ

ヒント：vi で編集モードに入るには「i」キーを押します。変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

.NETアプリケーションをK8sにデプロイするために、/home/splunk に deployment.yaml という名前のファイルを作成しましょう

vi /home/splunk/deployment.yaml

そして以下を貼り付けます

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  selector:
    matchLabels:
      app: helloworld
  replicas: 1
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
        - name: helloworld
          image: docker.io/library/helloworld:1.2
          imagePullPolicy: Never
          ports:
            - containerPort: 8080
          env:
            - name: PORT
              value: "8080"

Kubernetes における Deployment とは？

deployment.yaml ファイルは、deployment リソースを定義するために使用される kubernetes 設定ファイルです。このファイルは Kubernetes でアプリケーションを管理するための基盤となります！deployment 設定は deployment の 望ましい状態 を定義し、Kubernetes が 実際の状態 がそれと一致するよう保証します。これにより、アプリケーション pod の自己修復が可能になり、アプリケーションの簡単な更新やロールバックも可能になります。

次に、同じディレクトリに service.yaml という名前の2つ目のファイルを作成します

vi /home/splunk/service.yaml

そして以下を貼り付けます

apiVersion: v1
kind: Service
metadata:
  name: helloworld
  labels:
    app: helloworld
spec:
  type: ClusterIP
  selector:
    app: helloworld
  ports:
    - port: 8080
      protocol: TCP

Kubernetes における Service とは？

Kubernetes の Service は抽象化レイヤーであり、仲介者のような役割を果たします。Pod にアクセスするための固定 IP アドレスや DNS 名を提供し、時間の経過とともに Pod が追加、削除、または交換されても同じままです。

これらのマニフェストファイルを使用してアプリケーションをデプロイできます

# create the deployment
kubectl apply -f deployment.yaml

# create the service
kubectl apply -f service.yaml

deployment.apps/helloworld created
service/helloworld created

アプリケーションのテスト

アプリケーションにアクセスするには、まずIPアドレスを取得する必要があります

kubectl describe svc helloworld | grep IP:

IP:                10.43.102.103

その後、前のコマンドから返されたCluster IPを使用してアプリケーションにアクセスできます。

例：

curl http://10.43.102.103:8080/hello/Kubernetes

OpenTelemetry の設定

.NET OpenTelemetry計装はすでにDockerイメージに組み込まれています。しかし、データの送信先を指定するためにいくつかの環境変数を設定する必要があります。

先ほど作成した deployment.yaml ファイルに以下を追加します

重要以下の YAML の $INSTANCE をあなたのインスタンス名に置き換えてください。インスタンス名は echo $INSTANCE を実行することで確認できます。

env:
  - name: PORT
    value: "8080"
  - name: NODE_IP
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: "http://$(NODE_IP):4318"
  - name: OTEL_SERVICE_NAME
    value: "helloworld"
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: "deployment.environment=otel-$INSTANCE"

完全な deployment.yaml ファイルは以下のようになります（$INSTANCE ではなくあなたのインスタンス名を使用してください）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  selector:
    matchLabels:
      app: helloworld
  replicas: 1
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
        - name: helloworld
          image: docker.io/library/helloworld:1.2
          imagePullPolicy: Never
          ports:
            - containerPort: 8080
          env:
            - name: PORT
              value: "8080"
            - name: NODE_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: "http://$(NODE_IP):4318"
            - name: OTEL_SERVICE_NAME
              value: "helloworld"
            - name: OTEL_RESOURCE_ATTRIBUTES
              value: "deployment.environment=otel-$INSTANCE"

以下のコマンドで変更を適用します

kubectl apply -f deployment.yaml

deployment.apps/helloworld configured

その後、curl を使用してトラフィックを生成します。

1分ほど経過すると、o11y cloudでトレースが流れているのが確認できるはずです。ただし、より早くトレースを確認したい場合は、以下の方法があります…

チャレンジ

開発者として、トレースIDを素早く取得するか、コンソールフィードバックを見たい場合、deployment.yamlファイルにどのような環境変数を追加できるでしょうか？

答えを見るにはここをクリック

セクション4「.NET ApplicationをOpenTelemetryで計装する」のチャレンジで思い出していただければ、OTEL_TRACES_EXPORTER 環境変数を使ってtraceをconsoleに書き込むトリックをお見せしました。この変数をdeployment.yamlに追加し、アプリケーションを再deployして、helloworldアプリからlogをtailすることで、trace idを取得してSplunk Observability Cloudでtraceを見つけることができます。（ワークショップの次のセクションでは、debug exporterの使用についても説明します。これはK8s環境でアプリケーションをdebugする際の典型的な方法です。）

まず、viでdeployment.yamlファイルを開きます

vi deployment.yaml

次に、OTEL_TRACES_EXPORTER 環境変数を追加します

env:
  - name: PORT
    value: "8080"
  - name: NODE_IP
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: "http://$(NODE_IP):4318"
  - name: OTEL_SERVICE_NAME
    value: "helloworld"
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: "deployment.environment=YOURINSTANCE"
  # NEW VALUE HERE:
  - name: OTEL_TRACES_EXPORTER
    value: "otlp,console"

変更を保存してからアプリケーションを再deployします

kubectl apply -f deployment.yaml

deployment.apps/helloworld configured

helloworldのlogをtailします

kubectl logs -l app=helloworld -f

info: HelloWorldController[0]
      /hello endpoint invoked by K8s9
Activity.TraceId:            5bceb747cc7b79a77cfbde285f0f09cb
Activity.SpanId:             ac67afe500e7ad12
Activity.TraceFlags:         Recorded
Activity.ActivitySourceName: Microsoft.AspNetCore
Activity.DisplayName:        GET hello/{name?}
Activity.Kind:               Server
Activity.StartTime:          2025-02-04T15:22:48.2381736Z
Activity.Duration:           00:00:00.0027334
Activity.Tags:
    server.address: 10.43.226.224
    server.port: 8080
    http.request.method: GET
    url.scheme: http
    url.path: /hello/K8s9
    network.protocol.version: 1.1
    user_agent.original: curl/7.81.0
    http.route: hello/{name?}
    http.response.status_code: 200
Resource associated with Activity:
    splunk.distro.version: 1.8.0
    telemetry.distro.name: splunk-otel-dotnet
    telemetry.distro.version: 1.8.0
    os.type: linux
    os.description: Debian GNU/Linux 12 (bookworm)
    os.build_id: 6.2.0-1018-aws
    os.name: Debian GNU/Linux
    os.version: 12
    host.name: helloworld-69f5c7988b-dxkwh
    process.owner: app
    process.pid: 1
    process.runtime.description: .NET 8.0.12
    process.runtime.name: .NET
    process.runtime.version: 8.0.12
    container.id: 39c2061d7605d8c390b4fe5f8054719f2fe91391a5c32df5684605202ca39ae9
    telemetry.sdk.name: opentelemetry
    telemetry.sdk.language: dotnet
    telemetry.sdk.version: 1.9.0
    service.name: helloworld
    deployment.environment: otel-jen-tko-1b75

次に、別のterminal windowでcurlコマンドを使ってtraceを生成します。logをtailしているconsoleでtrace idが表示されるはずです。Activity.TraceId: の値をコピーして、APMのTrace検索フィールドに貼り付けてください。

OpenTelemetryコレクター設定のカスタマイズ

20 minutes

デフォルト設定を使用してK8sクラスターにSplunk Distribution of OpenTelemetryコレクターをデプロイしました。このセクションでは、コレクター設定をカスタマイズする方法をいくつかの例で説明します。

コレクター設定の取得

コレクター設定をカスタマイズする前に、現在の設定がどのようになっているかをどのように確認するのでしょうか？

Kubernetes環境では、コレクター設定はConfig Mapを使用して保存されます。

以下のコマンドで、クラスターに存在するconfig mapを確認できます

kubectl get cm -l app=splunk-otel-collector

NAME                                                 DATA   AGE
splunk-otel-collector-otel-k8s-cluster-receiver   1      3h37m
splunk-otel-collector-otel-agent                  1      3h37m

なぜ 2 つの config map があるのでしょうか？

次に、以下のようにコレクターエージェントのconfig mapを表示できます

kubectl describe cm splunk-otel-collector-otel-agent

Name:         splunk-otel-collector-otel-agent
Namespace:    default
Labels:       app=splunk-otel-collector
              app.kubernetes.io/instance=splunk-otel-collector
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=splunk-otel-collector
              app.kubernetes.io/version=0.113.0
              chart=splunk-otel-collector-0.113.0
              helm.sh/chart=splunk-otel-collector-0.113.0
              heritage=Helm
              release=splunk-otel-collector
Annotations:  meta.helm.sh/release-name: splunk-otel-collector
              meta.helm.sh/release-namespace: default

Data
====
relay:
----
exporters:
  otlphttp:
    headers:
      X-SF-Token: ${SPLUNK_OBSERVABILITY_ACCESS_TOKEN}
    metrics_endpoint: https://ingest.us1.signalfx.com/v2/datapoint/otlp
    traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp
    (followed by the rest of the collector config in yaml format)

K8s でコレクター設定を更新する方法

Linuxインスタンスでコレクターを実行した以前の例では、コレクター設定は /etc/otel/collector/agent_config.yaml ファイルで利用可能でした。その場合にコレクター設定を変更する必要があれば、単純にこのファイルを編集し、変更を保存してからコレクターを再起動すればよかったのです。

K8sでは、少し異なる動作をします。agent_config.yaml を直接変更する代わりに、 helmチャートをデプロイするために使用される values.yaml ファイルを変更することでコレクター設定をカスタマイズします。

GitHubのvalues.yamlファイルには、利用可能なカスタマイズオプションが記載されています。

例を見てみましょう。

Infrastructure Events Monitoring の追加

最初の例として、K8sクラスターのinfrastructure events monitoringを有効にしましょう。

これにより、charts の Events Feed セクションの一部として Kubernetes イベントを確認できるようになります。 cluster receiver は、kubernetes-events monitor を使用して Smart Agent receiver で設定され、custom イベントを送信します。詳細についてはCollect Kubernetes eventsを参照してください。

これは values.yaml ファイルに以下の行を追加することで実行されます

ヒント：vi での開き方と保存方法は前のステップにあります。

logsEngine: otel
splunkObservability:
  infrastructureMonitoringEventsEnabled: true
agent:

ファイルが保存されたら、以下のコマンドで変更を適用できます

helm upgrade splunk-otel-collector \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="clusterName=$INSTANCE-cluster" \
  --set="environment=otel-$INSTANCE" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.index=splunk4rookies-workshop" \
  -f values.yaml \
splunk-otel-collector-chart/splunk-otel-collector

Release "splunk-otel-collector" has been upgraded. Happy Helming!
NAME: splunk-otel-collector
LAST DEPLOYED: Fri Dec 20 01:17:03 2024
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.

その後、config mapを表示して変更が適用されたことを確認できます

kubectl describe cm splunk-otel-collector-otel-k8s-cluster-receiver

smartagent/kubernetes-events がagent configに含まれていることを確認してください

  smartagent/kubernetes-events:
    alwaysClusterReporter: true
    type: kubernetes-events
    whitelistedEvents:
    - involvedObjectKind: Pod
      reason: Created
    - involvedObjectKind: Pod
      reason: Unhealthy
    - involvedObjectKind: Pod
      reason: Failed
    - involvedObjectKind: Job
      reason: FailedCreate

これらの特定の変更が適用されるのは cluster receiver config map なので、そちらを指定していることに注意してください。

Debug Exporter の追加

collectorに送信されるtraceとlogを確認して、 Splunkに送信する前に検査したいとします。この目的のためにdebug exporterを使用できます。これは OpenTelemetry関連の問題のトラブルシューティングに役立ちます。

values.yamlファイルの下部に以下のようにdebug exporterを追加しましょう

logsEngine: otel
splunkObservability:
  infrastructureMonitoringEventsEnabled: true
agent:
  config:
    receivers: ...
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters:
            - debug
        logs:
          exporters:
            - debug

ファイルが保存されたら、以下のコマンドで変更を適用できます

helm upgrade splunk-otel-collector \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="clusterName=$INSTANCE-cluster" \
  --set="environment=otel-$INSTANCE" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.index=splunk4rookies-workshop" \
  -f values.yaml \
splunk-otel-collector-chart/splunk-otel-collector

Release "splunk-otel-collector" has been upgraded. Happy Helming!
NAME: splunk-otel-collector
LAST DEPLOYED: Fri Dec 20 01:32:03 2024
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.

curlを使用してアプリケーションを数回実行してから、以下のコマンドでagent collectorのlogをtailします

kubectl logs -l component=otel-collector-agent -f

以下のようなtraceがagent collectorのlogに書き込まれているのが確認できるはずです

2024-12-20T01:43:52.929Z info Traces {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 1, "spans": 2}
2024-12-20T01:43:52.929Z info ResourceSpans #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
Resource attributes:
     -> splunk.distro.version: Str(1.8.0)
     -> telemetry.distro.name: Str(splunk-otel-dotnet)
     -> telemetry.distro.version: Str(1.8.0)
     -> os.type: Str(linux)
     -> os.description: Str(Debian GNU/Linux 12 (bookworm))
     -> os.build_id: Str(6.8.0-1021-aws)
     -> os.name: Str(Debian GNU/Linux)
     -> os.version: Str(12)
     -> host.name: Str(derek-1)
     -> process.owner: Str(app)
     -> process.pid: Int(1)
     -> process.runtime.description: Str(.NET 8.0.11)
     -> process.runtime.name: Str(.NET)
     -> process.runtime.version: Str(8.0.11)
     -> container.id: Str(78b452a43bbaa3354a3cb474010efd6ae2367165a1356f4b4000be031b10c5aa)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.language: Str(dotnet)
     -> telemetry.sdk.version: Str(1.9.0)
     -> service.name: Str(helloworld)
     -> deployment.environment: Str(otel-derek-1)
     -> k8s.pod.ip: Str(10.42.0.15)
     -> k8s.pod.labels.app: Str(helloworld)
     -> k8s.pod.name: Str(helloworld-84865965d9-nkqsx)
     -> k8s.namespace.name: Str(default)
     -> k8s.pod.uid: Str(38d39bc6-1309-4022-a569-8acceef50942)
     -> k8s.node.name: Str(derek-1)
     -> k8s.cluster.name: Str(derek-1-cluster)

そして以下のようなlogエントリも確認できます

2024-12-20T01:43:53.215Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 2}
2024-12-20T01:43:53.215Z info ResourceLog #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
Resource attributes:
     -> splunk.distro.version: Str(1.8.0)
     -> telemetry.distro.name: Str(splunk-otel-dotnet)
     -> telemetry.distro.version: Str(1.8.0)
     -> os.type: Str(linux)
     -> os.description: Str(Debian GNU/Linux 12 (bookworm))
     -> os.build_id: Str(6.8.0-1021-aws)
     -> os.name: Str(Debian GNU/Linux)
     -> os.version: Str(12)
     -> host.name: Str(derek-1)
     -> process.owner: Str(app)
     -> process.pid: Int(1)
     -> process.runtime.description: Str(.NET 8.0.11)
     -> process.runtime.name: Str(.NET)
     -> process.runtime.version: Str(8.0.11)
     -> container.id: Str(78b452a43bbaa3354a3cb474010efd6ae2367165a1356f4b4000be031b10c5aa)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.language: Str(dotnet)
     -> telemetry.sdk.version: Str(1.9.0)
     -> service.name: Str(helloworld)
     -> deployment.environment: Str(otel-derek-1)
     -> k8s.node.name: Str(derek-1)
     -> k8s.cluster.name: Str(derek-1-cluster)

ただし、Splunk Observability Cloudに戻ると、アプリケーションからtraceとlogがもはやそこに送信されていないことに気づくでしょう。

なぜそうなったと思いますか？次のセクションで詳しく説明します。

Troubleshoot OpenTelemetry Collector Issues

20 minutes

前のセクションでは、debugエクスポーターをコレクターの設定に追加し、トレースとログのパイプラインの一部にしました。期待通りに、debug出力がエージェントコレクターのログに書き込まれているのが確認できます。

しかし、トレースがo11y cloudに送信されなくなっています。なぜなのかを把握して修正しましょう。

コレクター設定を確認する

values.yaml ファイルを通じてコレクター設定が変更された場合は、 config mapを確認してコレクターに実際に適用された設定を確認することが役立ちます

kubectl describe cm splunk-otel-collector-otel-agent

エージェントコレクター設定のログとトレースのパイプラインを確認しましょう。次のようになっているはずです

  pipelines:
    logs:
      exporters:
      - debug
      processors:
      - memory_limiter
      - k8sattributes
      - filter/logs
      - batch
      - resourcedetection
      - resource
      - resource/logs
      - resource/add_environment
      receivers:
      - filelog
      - fluentforward
      - otlp
    ...
    traces:
      exporters:
      - debug
      processors:
      - memory_limiter
      - k8sattributes
      - batch
      - resourcedetection
      - resource
      - resource/add_environment
      receivers:
      - otlp
      - jaeger
      - smartagent/signalfx-forwarder
      - zipkin

問題がわかりますか？debugエクスポーターのみがトレースとログのパイプラインに含まれています。以前のトレースパイプライン設定にあった otlphttp と signalfx エクスポーターがなくなっています。これが、もうo11y cloudでトレースが見えなくなった理由です。ログパイプラインについても、splunk_hec/platform_logs エクスポーターが削除されています。

どのような特定のエクスポーターが以前含まれていたかをどのように知ったか？それを見つけるには、以前のカスタマイズを元に戻してから、config map を確認してトレースパイプラインに元々何が含まれていたかを見ることもできました。あるいは、 splunk-otel-collector-chart の GitHub リポジトリの例を参照することもでき、これにより Helm チャートで使用されるデフォルトのエージェント設定が分かります。

これらのエクスポーターはどのように削除されたのか？

values.yaml ファイルに追加したカスタマイズを確認しましょう

logsEngine: otel
splunkObservability:
  infrastructureMonitoringEventsEnabled: true
agent:
  config:
    receivers: ...
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters:
            - debug
        logs:
          exporters:
            - debug

helm upgrade を使ってコレクターに values.yaml ファイルを適用したとき、カスタム設定は以前のコレクター設定とマージされました。これが発生すると、リストを含む yaml 設定のセクション、例えばパイプラインセクションのエクスポーターのリストは、values.yaml ファイルに含めたもの（debugエクスポーターのみ）で置き換えられます。

問題を修正しましょう

既存のパイプラインをカスタマイズする場合、設定のその部分を完全に再定義する必要があります。したがって、values.yaml ファイルを次のように更新する必要があります

logsEngine: otel
splunkObservability:
  infrastructureMonitoringEventsEnabled: true
agent:
  config:
    receivers: ...
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters:
            - otlphttp
            - signalfx
            - debug
        logs:
          exporters:
            - splunk_hec/platform_logs
            - debug

変更を適用しましょう

helm upgrade splunk-otel-collector \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="clusterName=$INSTANCE-cluster" \
  --set="environment=otel-$INSTANCE" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.index=splunk4rookies-workshop" \
  -f values.yaml \
splunk-otel-collector-chart/splunk-otel-collector

それからエージェントconfig mapを確認します

kubectl describe cm splunk-otel-collector-otel-agent

今度は、ログとトレースの両方について完全に定義されたエクスポーターパイプラインが表示されるはずです

  pipelines:
    logs:
      exporters:
      - splunk_hec/platform_logs
      - debug
      processors:
      ...
    traces:
      exporters:
      - otlphttp
      - signalfx
      - debug
      processors:
      ...

ログ出力の確認

Splunk Distribution of OpenTelemetry .NETは、ログに使用するアプリケーション（サンプルアプリでも使用している）から、トレースコンテキストで強化されたログを自動的にエクスポートします。

アプリケーションログはトレースメタデータで強化され、その後 OpenTelemetry CollectorのローカルインスタンスにOTLP形式でエクスポートされます。

debugエクスポーターによってキャプチャされたログを詳しく見て、それが発生しているかを確認しましょう。コレクターログをtailするには、次のコマンドを使用できます

kubectl logs -l component=otel-collector-agent -f

ログをtailしたら、curlを使ってさらにトラフィックを生成できます。そうすると次のようなものが表示されるはずです

2024-12-20T21:56:30.858Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 1}
2024-12-20T21:56:30.858Z info ResourceLog #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
Resource attributes:
     -> splunk.distro.version: Str(1.8.0)
     -> telemetry.distro.name: Str(splunk-otel-dotnet)
     -> telemetry.distro.version: Str(1.8.0)
     -> os.type: Str(linux)
     -> os.description: Str(Debian GNU/Linux 12 (bookworm))
     -> os.build_id: Str(6.8.0-1021-aws)
     -> os.name: Str(Debian GNU/Linux)
     -> os.version: Str(12)
     -> host.name: Str(derek-1)
     -> process.owner: Str(app)
     -> process.pid: Int(1)
     -> process.runtime.description: Str(.NET 8.0.11)
     -> process.runtime.name: Str(.NET)
     -> process.runtime.version: Str(8.0.11)
     -> container.id: Str(5bee5b8f56f4b29f230ffdd183d0367c050872fefd9049822c1ab2aa662ba242)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.language: Str(dotnet)
     -> telemetry.sdk.version: Str(1.9.0)
     -> service.name: Str(helloworld)
     -> deployment.environment: Str(otel-derek-1)
     -> k8s.node.name: Str(derek-1)
     -> k8s.cluster.name: Str(derek-1-cluster)
ScopeLogs #0
ScopeLogs SchemaURL:
InstrumentationScope HelloWorldController
LogRecord #0
ObservedTimestamp: 2024-12-20 21:56:28.486804 +0000 UTC
Timestamp: 2024-12-20 21:56:28.486804 +0000 UTC
SeverityText: Information
SeverityNumber: Info(9)
Body: Str(/hello endpoint invoked by {name})
Attributes:
     -> name: Str(Kubernetes)
Trace ID: 78db97a12b942c0252d7438d6b045447
Span ID: 5e9158aa42f96db3
Flags: 1
 {"kind": "exporter", "data_type": "logs", "name": "debug"}

この例では、Trace IDとSpan IDが OpenTelemetry .NET計装によってログ出力に自動的に書き込まれていることがわかります。これにより、 Splunk Observability Cloudでログとトレースを関連付けることができます。

ただし、Helmを使ってK8sクラスターにOpenTelemetry collectorをデプロイし、ログ収集オプションを含める場合、OpenTelemetry collectorはFile Log receiverを使用してコンテナーログを自動的にキャプチャすることを覚えておいてください。

これにより、アプリケーションの重複ログがキャプチャされることになります。例えば、次のスクリーンショットではサービスへの各リクエストに対して2つのログエントリーが表示されています

これをどのように回避しますか？

K8s での重複ログの回避

重複ログをキャプチャしないようにするには、OTEL_LOGS_EXPORTER 環境変数を none に設定して、 Splunk Distribution of OpenTelemetry .NETがOTLPを使用してコレクターにログをエクスポートしないようにできます。これは、deployment.yaml ファイルに OTEL_LOGS_EXPORTER 環境変数を追加することで実行できます

env:
  - name: PORT
    value: "8080"
  - name: NODE_IP
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: "http://$(NODE_IP):4318"
  - name: OTEL_SERVICE_NAME
    value: "helloworld"
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: "deployment.environment=otel-$INSTANCE"
  - name: OTEL_LOGS_EXPORTER
    value: "none"

それから次を実行します

# update the deployment
kubectl apply -f deployment.yaml

OTEL_LOGS_EXPORTER 環境変数を none に設定するのは簡単です。しかし、Trace IDと Span IDはアプリケーションによって生成されたstdoutログに書き込まれないため、ログとトレースを関連付けることができなくなります。

これを解決するには、 /home/splunk/workshop/docker-k8s-otel/helloworld/SplunkTelemetryConfigurator.cs で定義されている例のような、カスタムロガーを定義する必要があります。

次のように Program.cs ファイルを更新することで、これをアプリケーションに含めることができます

using SplunkTelemetry;
using Microsoft.Extensions.Logging.Console;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

SplunkTelemetryConfigurator.ConfigureLogger(builder.Logging);

var app = builder.Build();

app.MapControllers();

app.Run();

その後、カスタムログ設定を含む新しいDockerイメージをビルドします

cd /home/splunk/workshop/docker-k8s-otel/helloworld

docker build -t helloworld:1.3 .

それから更新されたイメージをKubernetesにインポートします

cd /home/splunk

# Import the image into k3d
sudo k3d image import helloworld:1.3 --cluster $INSTANCE-cluster

最後に、deployment.yaml ファイルを更新してコンテナーイメージの1.3バージョンを使用する必要があります

spec:
  containers:
    - name: helloworld
      image: docker.io/library/helloworld:1.3

それから変更を適用します

# update the deployment
kubectl apply -f deployment.yaml

これで重複したログエントリーが排除されたことがわかります。そして残りのログエントリーはJSONとしてフォーマットされ、spanとtrace IDが含まれています

Summary

2 minutes

このワークショップでは、以下の概念についてハンズオンで体験しました

LinuxホストにSplunk Distribution of the OpenTelemetry Collectorをデプロイする方法。
Splunk Distribution of OpenTelemetry .NETで.NETアプリケーションを計装する方法。
.NETアプリケーションを「Docker化」し、Splunk Distribution of OpenTelemetry .NETで計装する方法。
Helmを使用してKubernetesクラスターにSplunk Distribution of the OpenTelemetry Collectorをデプロイする方法。
コレクター設定をカスタマイズして問題をトラブルシューティングする方法。

他の言語と環境でOpenTelemetryがどのように計装されるかを確認するには、 Splunk OpenTelemetry Examples GitHub リポジトリをご覧ください。

将来このワークショップを独自に実行するには、これらの手順を参照して、Splunk ShowのSplunk4Rookies - Observability ワークショップテンプレートを使用してEC2インスタンスをプロビジョニングしてください。

O11y Cloud で問題を解決する

2 minutes Author Derek Mitchell

このワークショップでは、以下の内容をハンズオン形式で体験します：

OpenTelemetry Collector をデプロイし、Collectorの設定をカスタマイズする
アプリケーションをデプロイし、OpenTelemetry で計装する
OpenTelemetry SDK を使用してタグがどのようにキャプチャされるかを確認する
Troubleshooting MetricSet を作成する
Tag Spotlight を使用して問題をトラブルシューティングし、根本原因を特定する

それでは始めましょう！

Tip

このワークショップを最も簡単にナビゲートする方法は以下の通りです：

このページの右上にある左右の矢印（< | >）を使用する
キーボードの左（◀️）および右（▶️）カーソルキーを使用する

EC2 インスタンスへの接続

5 minutes

EC2 インスタンスに接続する

各参加者用にAWS/EC2でUbuntu Linuxインスタンスを準備しています。インストラクターから提供されたIPアドレスとパスワードを使用して、以下のいずれかの方法でEC2インスタンスに接続してください：

macOS / Linux
- ssh splunk@IP address
Windows 10+
- OpenSSHクライアントを使用
Windowsの以前のバージョン
- Puttyを使用

ファイルの編集

ワークショップでは vi を使用してファイルを編集します。簡単な使い方を説明します。

ファイルを編集用に開くには：

vi <filename>

ファイルを編集するには、i を押して Insert mode に切り替え、通常通りテキストを入力します。Esc を押すと Command mode に戻ります。
エディタを終了せずに変更を保存するには、Esc を押してコマンドモードに戻り、:w と入力します。
変更を保存せずにエディタを終了するには、Esc を押してコマンドモードに戻り、:q! と入力します。
変更を保存してエディタを終了するには、Esc を押してコマンドモードに戻り、:wq と入力します。

vi の包括的な説明については An introduction to the vi editor を参照してください。

別のエディタを使用したい場合は、代わりに nano を使用できます：

nano <filename>

OpenTelemetry Collector のデプロイと設定のカスタマイズ

15 minutes

「データを取り込む」ための最初のステップは、OpenTelemetry Collectorをデプロイすることです。Collectorは環境内のテレメトリデータを受信して処理し、Splunk Observability Cloudにエクスポートします。

このワークショップではKubernetesを使用し、Helmを使用してK8sクラスターにCollectorをデプロイします。

Helm とは？

HelmはKubernetes用のパッケージマネージャーで、以下のような利点があります：

複雑さの管理
- 多数のマニフェストファイルではなく、単一のvalues.yamlファイルで対応
簡単なアップデート
- インプレースアップグレード
ロールバックのサポート
- helm rollbackを使用するだけで、リリースの古いバージョンにロールバック可能

Helm を使用して Collector をインストールする

正しいディレクトリに移動し、スクリプトを実行してCollectorをインストールしましょう：

cd /home/splunk/workshop/tagging
./1-deploy-otel-collector.sh

"splunk-otel-collector-chart" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "splunk-otel-collector-chart" chart repository
Update Complete. ⎈Happy Helming!⎈
NAME: splunk-otel-collector
LAST DEPLOYED: Mon Dec 23 18:47:38 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.

スクリプトの実行には1分程度かかる場合があります。

このスクリプトはどのようにしてCollectorをインストールしたのでしょうか？まず、~./profile ファイルに設定された環境変数が読み込まれていることを確認しました：

重要：以下のコマンドは 1-deploy-otel-collector.sh スクリプトによって既に実行されているため、実行する必要はありません。

source ~/.profile

次に、splunk-otel-collector-chart Helmチャートをインストールし、最新の状態であることを確認しました：

  helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
  helm repo update

最後に、helm install を使用してCollectorをインストールしました：

  helm install splunk-otel-collector --version 0.136.0 \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="clusterName=$INSTANCE-k3s-cluster" \
  --set="environment=tagging-workshop-$INSTANCE" \
  splunk-otel-collector-chart/splunk-otel-collector \
  -f otel/values.yaml

helm install コマンドは values.yaml ファイルを参照していることに注意してください。このファイルは Collector の設定をカスタマイズするために使用されます。詳細は後述します。

Collector が実行中であることを確認する

以下のコマンドでCollectorが実行中かどうかを確認できます：

kubectl get pods

NAME                                                            READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-kfvjb                               1/1     Running   0          2m33s
splunk-otel-collector-certmanager-7d89558bc9-2fqnx              1/1     Running   0          2m33s
splunk-otel-collector-certmanager-cainjector-796cc6bd76-hz4sp   1/1     Running   0          2m33s
splunk-otel-collector-certmanager-webhook-6959cd5f8-qd5b6       1/1     Running   0          2m33s
splunk-otel-collector-k8s-cluster-receiver-57569b58c8-8ghds     1/1     Running   0          2m33s
splunk-otel-collector-operator-6fd9f9d569-wd5mn                 2/2     Running   0          2m33s

K8s クラスターが O11y Cloud に存在することを確認する

Splunk Observability Cloudで、Infrastructure → Kubernetes → Kubernetes Clusters に移動し、クラスター名（$INSTANCE-k3s-cluster）を検索します：

Collector の設定を取得する

Collectorの設定をカスタマイズする前に、現在の設定がどのようになっているかを確認するにはどうすればよいでしょうか？

Kubernetes環境では、Collectorの設定はConfig Mapを使用して保存されています。

以下のコマンドで、クラスター内に存在するconfig mapを確認できます：

kubectl get cm -l app=splunk-otel-collector

NAME                                                 DATA   AGE
splunk-otel-collector-otel-k8s-cluster-receiver   1      3h37m
splunk-otel-collector-otel-agent                  1      3h37m

次に、以下のようにしてCollectorエージェントのconfig mapを表示できます：

kubectl describe cm splunk-otel-collector-otel-agent

Name:         splunk-otel-collector-otel-agent
Namespace:    default
Labels:       app=splunk-otel-collector
              app.kubernetes.io/instance=splunk-otel-collector
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=splunk-otel-collector
              app.kubernetes.io/version=0.113.0
              chart=splunk-otel-collector-0.113.0
              helm.sh/chart=splunk-otel-collector-0.113.0
              heritage=Helm
              release=splunk-otel-collector
Annotations:  meta.helm.sh/release-name: splunk-otel-collector
              meta.helm.sh/release-namespace: default

Data
====
relay:
----
exporters:
  otlphttp:
    headers:
      X-SF-Token: ${SPLUNK_OBSERVABILITY_ACCESS_TOKEN}
    metrics_endpoint: https://ingest.us1.signalfx.com/v2/datapoint/otlp
    traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp
    (followed by the rest of the collector config in yaml format)

K8s で Collector の設定を更新する方法

K8sでは values.yaml ファイルを使用してCollectorの設定をカスタマイズできます。

values.yaml ファイルで利用可能なカスタマイズオプションの包括的なリストについては、このファイルを参照してください。

例を見てみましょう。

Debug Exporter を追加する

Collectorに送信されるトレースを確認したいとします。この目的にはdebug exporterを使用できます。これはOpenTelemetry関連の問題のトラブルシューティングに役立ちます。

vi または nano を使用して values.yaml ファイルを編集できます。ここではviを使用した例を示します：

vi /home/splunk/workshop/tagging/otel/values.yaml

以下のテキストをコピーして values.yaml ファイルの末尾に貼り付けて、debug exporterを追加します：

以下のテキストを追加する前に、vi で ‘i’ を押してインサートモードに入ってください。

    # NEW CONTENT
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters:
            - otlphttp
            - signalfx
            - debug

これらの変更後、values.yaml ファイルは以下の内容を含むはずです：

splunkObservability:
  profilingEnabled: true
  infrastructureMonitoringEventsEnabled: true
certmanager:
  enabled: true
operator:
  enabled: true
operatorcrds:
  install: true

agent:
  config:
    receivers:
      kubeletstats:
        insecure_skip_verify: true
        auth_type: serviceAccount
        endpoint: ${K8S_NODE_IP}:10250
        metric_groups:
          - container
          - pod
          - node
          - volume
        k8s_api_config:
          auth_type: serviceAccount
        extra_metadata_labels:
          - container.id
          - k8s.volume.type
    extensions:
      zpages:
        endpoint: 0.0.0.0:55679
    # NEW CONTENT
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters:
            - otlphttp
            - signalfx
            - debug

vi で変更を保存するには、esc キーを押してコマンドモードに入り、:wq! と入力してから enter/return キーを押します。

ファイルを保存したら、以下のコマンドで変更を適用できます：

cd /home/splunk/workshop/tagging

helm upgrade splunk-otel-collector  \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="environment=tagging-workshop-$INSTANCE" \
splunk-otel-collector-chart/splunk-otel-collector \
-f otel/values.yaml

Release "splunk-otel-collector" has been upgraded. Happy Helming!
NAME: splunk-otel-collector
LAST DEPLOYED: Mon Dec 23 19:08:08 2024
NAMESPACE: default
STATUS: deployed
REVISION: 2
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.

values.yaml ファイルを通じてCollectorの設定を変更した場合は、 config mapを確認して、Collectorに適用された実際の設定を確認することが有用です：

kubectl describe cm splunk-otel-collector-otel-agent

期待通り、debug exporterがtracesパイプラインに追加されたことが確認できます：

  traces:
    exporters:
    - otlphttp
    - signalfx
    - debug

debug exporterの出力については、クラスターにアプリケーションをデプロイしてトレースのキャプチャを開始した後に確認します。

サンプルアプリケーションのデプロイと OpenTelemetry による計装

15 minutes

この時点で、K8sクラスターにOpenTelemetry Collectorをデプロイし、インフラストラクチャメトリクスの収集に成功しています。

次のステップは、サンプルアプリケーションをデプロイし、 OpenTelemetryで計装してトレースをキャプチャすることです。

Pythonで書かれたマイクロサービスベースのアプリケーションを使用します。ワークショップをシンプルに保つため、 credit check serviceとcredit processor serviceの2つのサービスに焦点を当てます。

アプリケーションのデプロイ

時間を節約するため、両方のサービスのDockerイメージを既に構築してDocker Hubで公開しています。以下のコマンドで、K8sクラスターにcredit check serviceをデプロイできます：

kubectl apply -f /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml

deployment.apps/creditcheckservice created
service/creditcheckservice created

次に、credit processor serviceをデプロイしましょう：

kubectl apply -f /home/splunk/workshop/tagging/creditprocessorservice/creditprocessorservice-dockerhub.yaml

deployment.apps/creditprocessorservice created
service/creditprocessorservice created

最後に、トラフィックを生成するロードジェネレーターをデプロイしましょう：

kubectl apply -f /home/splunk/workshop/tagging/loadgenerator/loadgenerator-dockerhub.yaml

deployment.apps/loadgenerator created

アプリケーションの詳細を確認する

このセクションでは、アプリケーションの概要を説明します。アプリケーションの完全なソースコードを確認したい場合は、GitHub の Observability Workshop リポジトリを参照してください。

OpenTelemetry による計装

credit check serviceとcredit processor serviceのビルドに使用されるDockerfileを見ると、 OpenTelemetryで既に計装されていることがわかります。例として、 /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/Dockerfile を見てみましょう：

FROM python:3.11-slim

# Set working directory
WORKDIR /app

# Copy requirements over
COPY requirements.txt .

RUN apt-get update && apt-get install --yes gcc python3-dev

ENV PIP_ROOT_USER_ACTION=ignore

# Install Python dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Copy main app
COPY main.py .

# Bootstrap OTel
RUN splunk-py-trace-bootstrap

# Set the entrypoint command to run the application
CMD ["splunk-py-trace", "python3", "main.py"]

splunk-py-trace-bootstrap が含まれていることがわかります。これは、アプリケーションで使用されるサポートされているパッケージにOpenTelemetryの計装をインストールします。また、splunk-py-trace がアプリケーションを起動するコマンドの一部として使用されていることもわかります。

/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/requirements.txt ファイルを確認すると、パッケージのリストに splunk-opentelemetry[all] が含まれていることがわかります。

最後に、このサービスのデプロイに使用したKubernetesマニフェスト（/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml）を確認すると、コンテナに環境変数が設定されており、OTLPデータのエクスポート先を OpenTelemetryに伝えていることがわかります：

  env:
    - name: PORT
      value: "8888"
    - name: NODE_IP
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: "http://$(NODE_IP):4317"
    - name: OTEL_SERVICE_NAME
      value: "creditcheckservice"
    - name: OTEL_PROPAGATORS
      value: "tracecontext,baggage"

これだけで、サービスをOpenTelemetryで計装できます！

アプリケーションの詳細を確認する

アプリケーションでいくつかのカスタムタグをキャプチャしていますが、これについては後ほど詳しく見ていきます。その前に、タグの概念とそれが重要な理由について説明します。

タグとは？

タグは、トレース内のスパンに関する追加のメタデータを提供するキーと値のペアで、Splunk APM に送信するスパンのコンテキストを充実させることができます。

例えば、決済処理アプリケーションでは以下を追跡できると便利です：

使用された決済方法（クレジットカード、ギフトカードなど）
決済をリクエストした顧客のID

これにより、決済処理中にエラーやパフォーマンスの問題が発生した場合、トラブルシューティングに必要なコンテキストを得ることができます。

一部のタグはOpenTelemetry Collectorで追加できますが、このワークショップで扱うタグはより詳細なもので、アプリケーション開発者がOpenTelemetry SDKを使用して追加します。

なぜタグはそれほど重要なのか？

タグは、アプリケーションを真にオブザーバブルにするために不可欠です。トレースにコンテキストを追加することで、なぜ一部のユーザーは素晴らしい体験を得て、他のユーザーはそうでないのかを理解する助けになります。また、 Splunk Observability Cloud の強力な機能は、タグを活用して根本原因に素早くたどり着くことを支援します。

先に進む前に用語について説明します。このワークショップでは tags（タグ）について説明しますが、これは Splunk Observability Cloud で使用する用語です。OpenTelemetry では代わりに attributes（属性）という用語を使用します。そのため、このワークショップ全体でタグが言及されている場合、それは属性と同義として扱ってください。

タグはどのようにキャプチャされるのか？

Pythonアプリケーションでタグをキャプチャするには、まず /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/main.py ファイルの先頭に import文を追加してtraceモジュールをインポートします：

import requests
from flask import Flask, request
from waitress import serve
from opentelemetry import trace  # <--- ADDED BY WORKSHOP
...

次に、現在のスパンへの参照を取得して、属性（別名タグ）を追加できるようにします：

def credit_check():
    current_span = trace.get_current_span()  # <--- ADDED BY WORKSHOP
    customerNum = request.args.get('customernum')
    current_span.set_attribute("customer.num", customerNum)  # <--- ADDED BY WORKSHOP
...

とても簡単ですよね？credit check serviceで合計4つのタグをキャプチャしており、最終的な結果は以下のようになります：

def credit_check():
    current_span = trace.get_current_span()  # <--- ADDED BY WORKSHOP
    customerNum = request.args.get('customernum')
    current_span.set_attribute("customer.num", customerNum)  # <--- ADDED BY WORKSHOP

    # Get Credit Score
    creditScoreReq = requests.get("http://creditprocessorservice:8899/getScore?customernum=" + customerNum)
    creditScoreReq.raise_for_status()
    creditScore = int(creditScoreReq.text)
    current_span.set_attribute("credit.score", creditScore)  # <--- ADDED BY WORKSHOP

    creditScoreCategory = getCreditCategoryFromScore(creditScore)
    current_span.set_attribute("credit.score.category", creditScoreCategory)  # <--- ADDED BY WORKSHOP

    # Run Credit Check
    creditCheckReq = requests.get("http://creditprocessorservice:8899/runCreditCheck?customernum=" + str(customerNum) + "&score=" + str(creditScore))
    creditCheckReq.raise_for_status()
    checkResult = str(creditCheckReq.text)
    current_span.set_attribute("credit.check.result", checkResult)  # <--- ADDED BY WORKSHOP

    return checkResult

トレースデータを確認する

Splunk Observability Cloudでトレースデータを確認する前に、以下のコマンドでエージェントCollectorのログをtailして、debug exporterがキャプチャした内容を確認しましょう：

kubectl logs -l component=otel-collector-agent -f

ヒント：CTRL+C を使用してログのtailを停止します。

エージェントCollectorのログに以下のようなトレースが書き込まれているはずです：

InstrumentationScope opentelemetry.instrumentation.flask 0.44b0
Span #0
    Trace ID       : 9f9fc109903f25ba57bea9b075aa4833
    Parent ID      : 
    ID             : 6d71519f454f6059
    Name           : /check
    Kind           : Server
    Start time     : 2024-12-23 19:55:25.815891965 +0000 UTC
    End time       : 2024-12-23 19:55:27.824664949 +0000 UTC
    Status code    : Unset
    Status message : 
Attributes:
     -> http.method: Str(GET)
     -> http.server_name: Str(waitress.invalid)
     -> http.scheme: Str(http)
     -> net.host.port: Int(8888)
     -> http.host: Str(creditcheckservice:8888)
     -> http.target: Str(/check?customernum=30134241)
     -> net.peer.ip: Str(10.42.0.19)
     -> http.user_agent: Str(python-requests/2.31.0)
     -> net.peer.port: Str(47248)
     -> http.flavor: Str(1.1)
     -> http.route: Str(/check)
     -> customer.num: Str(30134241)
     -> credit.score: Int(443)
     -> credit.score.category: Str(poor)
     -> credit.check.result: Str(OK)
     -> http.status_code: Int(200)

トレースに、コードでキャプチャした credit.score や credit.score.category などのタグ（属性とも呼ばれる）が含まれていることに注目してください。次のセクションで、 Splunk Observability Cloudでトレースを分析してパフォーマンス問題の根本原因を見つける際に、これらを使用します。

Troubleshooting MetricSet を作成する

5 minutes

タグのインデックス作成

Tag Spotlight などの Splunk Observability Cloud の高度な機能を使用するには、まず1つ以上のタグをインデックスする必要があります。

これを行うには、Settings -> MetricSets に移動し、APM タブが選択されていることを確認します。次に + Add Custom MetricSet ボタンをクリックします。

以下の詳細を入力して credit.score.category タグをインデックスしましょう（注意：ワークショップの参加者全員が同じ組織を使用しているため、このステップはインストラクターが代わりに行います）：

Start Analysis をクリックして続行します。

分析が実行されている間、タグは Pending MetricSets のリストに表示されます。

分析が完了したら、Actions 列のチェックマークをクリックします。

Troubleshooting MetricSet と Monitoring MetricSet の違い

このタグをインデックスするために、Troubleshooting MetricSet と呼ばれるものを作成したことにお気づきかもしれません。Troubleshooting MetricSet（TMS）は、Tag Spotlight などの機能を使用してこのタグに関する問題をトラブルシューティングできるため、このように名付けられています。

また、選択しなかった Monitoring MetricSet（MMS）という別のオプションがあることにもお気づきかもしれません。Monitoring MetricSetはトラブルシューティングを超えて、タグをアラートやダッシュボードに使用できます。このワークショップではこの機能については詳しく説明しませんが、ぜひご自身で探索することをお勧めする強力な機能です。

Tag Spotlight を使用して問題をトラブルシューティングする

15 minutes

APM データを確認する

キャプチャしたAPMデータの一部を確認して、アプリケーションのパフォーマンスを見てみましょう。

APM に移動し、Environment ドロップダウンを使用して環境を選択します（例：tagging-workshop-instancename）。

サービスのリストに creditprocessorservice と creditcheckservice が表示されているはずです：

右側の Service Map をクリックしてサービスマップを表示します。creditcheckservice が creditprocessorservice を呼び出しており、平均応答時間が少なくとも3秒であることがわかります：

次に、右側の Traces をクリックして、このアプリケーションでキャプチャされたトレースを確認します。一部のトレースは比較的高速（数ミリ秒程度）に実行される一方、他のトレースは数秒かかることがわかります。

実行時間の長いトレースの1つをクリックします。この例では、トレースに5秒かかり、ほとんどの時間が creditprocessorservice の一部である /runCreditCheck 操作の呼び出しに費やされていることがわかります：

しかし、なぜ一部のトレースは遅く、他のトレースは比較的速いのでしょうか？

トレースを閉じてTrace Analyzerに戻ります。Errors only を on に切り替えると、一部のトレースにエラーがあることにも気づくでしょう：

エラートレースの1つを見ると、creditprocessorservice が otherservice という別のサービスを呼び出そうとしたときにエラーが発生していることがわかります。しかし、なぜ一部のリクエストは otherservice への呼び出しを行い、他のリクエストは行わないのでしょうか？

一部のリクエストがなぜ遅く実行され、一部のリクエストがなぜエラーになるのかを特定するために、トレースを1つずつ確認して問題の背後にあるパターンを見つけようとすることもできます。

Splunk Observability Cloud は、問題の根本原因を見つけるためのより良い方法を提供します。次にこれを確認しましょう。

Tag Spotlight を使用する

credit.score.category タグをインデックスしたので、Tag Spotlight と一緒に使用してアプリケーションをトラブルシューティングできます。

APM に移動し、右側の Tag Spotlight をクリックします。Service ドロップダウンから creditcheckservice サービスが選択されていることを確認します（まだ選択されていない場合）。

Tag Spotlight を使用すると、impossible のスコアになるクレジットスコアリクエストの100%にエラーがあることがわかります。一方、他のすべてのクレジットスコアタイプのリクエストにはまったくエラーがありません！

これは Tag Spotlight の威力を示しています！この機能がなければ、このパターンを見つけるのは時間がかかります。数百のトレースを手動で確認してパターンを特定する必要があり（それでも見つかる保証はありません）。

エラーを確認しましたが、レイテンシはどうでしょうか？Requests & errors distribution ドロップダウンをクリックして Latency distribution に変更しましょう。

重要：Cards display の横にある設定アイコンをクリックして、P50 と P99 のメトリクスを追加します。

ここでは、poor クレジットスコアのリクエストが遅く実行されていることがわかります。P50、P90、P99の時間は約3秒で、これはユーザーが待つには長すぎ、他のリクエストよりもはるかに遅いです。

また、exceptional クレジットスコアの一部のリクエストも遅く実行されていることがわかります。P99の時間は約5秒ですが、P50の応答時間は比較的速いです。

Dynamic Service Maps を使用する

リクエストに関連付けられたクレジットスコアカテゴリがパフォーマンスとエラー率に影響を与える可能性があることがわかったので、インデックスされたタグを活用する別の機能を確認しましょう：Dynamic Service Maps です。

Dynamic Service Mapsを使用すると、特定のサービスをタグ別に分解できます。例えば、APM をクリックし、次に Service Map をクリックしてサービスマップを表示しましょう。

creditcheckservice をクリックします。次に、右側のメニューで Breakdown というドロップダウンをクリックし、credit.score.category タグを選択します。

この時点で、サービスマップは動的に更新され、creditcheckservice に到達するリクエストのパフォーマンスがクレジットスコアカテゴリ別に分解されて表示されます：

このビューにより、good と fair のクレジットスコアのパフォーマンスは優れている一方、poor と exceptional のスコアははるかに遅く、impossible のスコアはエラーになることが明確にわかります。

発見事項

Tag Spotlight により、このサービスを担当するエンジニアがさらに調査すべきいくつかの興味深いパターンが明らかになりました：

なぜすべての impossible クレジットスコアリクエストがエラーになるのか？
なぜすべての poor クレジットスコアリクエストが遅く実行されるのか？
なぜ一部の exceptional リクエストが遅く実行されるのか？

SREとして、このコンテキストをエンジニアリングチームに伝えることは、彼らの調査に非常に役立ちます。サービスが「時々遅い」と単に伝えるよりも、はるかに迅速に問題を追跡できるからです。

興味があれば、creditprocessorservice のソースコードを確認してください。impossible、poor、exceptionalのクレジットスコアを持つリクエストは異なる方法で処理されており、そのため我々が発見したエラー率とレイテンシの違いが生じていることがわかります。

アプリケーションで見られた動作は、モダンなクラウドネイティブアプリケーションでは一般的なものです。サービスに渡される異なる入力が異なるコードパスにつながり、その一部がパフォーマンスの低下やエラーを引き起こします。例えば、実際のクレジットチェックサービスでは、低いクレジットスコアになるリクエストは、リスクをさらに評価するために別のダウンストリームサービスに送信される場合があり、高いスコアになるリクエストよりも遅く実行されたり、より高いエラー率に遭遇したりする可能性があります。

まとめ

2 minutes

このワークショップでは、以下の概念についてハンズオン形式で学びました：

Helmを使用して Splunk Distribution of the OpenTelemetry Collector をデプロイする方法
OpenTelemetry でアプリケーションを計装する方法
OpenTelemetry SDKを使用してアプリケーションから関心のあるタグをキャプチャする方法
Troubleshooting MetricSets を使用して Splunk Observability Cloud でタグをインデックスする方法
Tag Spotlight と Dynamic Service Map 機能を使用して Splunk Observability Cloud でタグを活用し、「未知の未知」を発見する方法

このワークショップで共有したベストプラクティスに沿ってタグを収集することで、Splunk Observability Cloud に送信するデータからさらに多くの価値を得ることができます。このワークショップを完了した今、自分のアプリケーションからタグの収集を開始するために必要な知識を身につけました！

今日からタグのキャプチャを始めるには、サポートされている各言語でタグを追加する方法を確認し、次にTag Spotlightで分析できるように Troubleshooting MetricSets を作成する方法を確認してください。さらにヘルプが必要な場合は、Splunk エキスパートに問い合わせてください。

また、他の言語や環境がOpenTelemetryでどのように計装されているかを確認するには、 Splunk OpenTelemetry Examples GitHub リポジトリを参照してください。

Tip for Workshop Facilitator(s)

ワークショップが完了したら、以前に credit.score.category タグ用に作成したAPM MetricSetを削除することを忘れないでください。

Ingest Processor for Observability Cloud

Author Tim Hard

インフラストラクチャとアプリケーション環境がますます複雑になるにつれて、それらが生成するデータ量は大幅に増加し続けています。このデータ量と種類の増加により、実用的なインサイトを得ることが困難になり、問題の特定やトラブルシューティングの効率に影響を与える可能性があります。さらに、このデータを保存してアクセスするコストは急上昇する可能性があります。多くのデータソース、特にログとイベントは、システム運用への重要な可視性を提供します。しかし、ほとんどの場合、効果的な監視とアラートに実際に必要なのは、これらの膨大なログからのわずかな詳細情報のみです。

一般的な課題:

インフラストラクチャとアプリケーション環境の複雑性の増加
これらの環境から生成されるデータ量の大幅な増加
大量のデータから実用的なインサイトを得ることの困難さ
膨大なデータの保存とアクセスに関連する高いコスト
ログとイベントは重要な可視性を提供するが、多くの場合、必要な詳細情報はわずか

これらの課題に対処するために、Splunk Ingest Processorは強力な新機能を提供します：ログイベントをメトリクスに変換する機能です。メトリクスは保存と処理がより効率的であり、問題の迅速な特定を可能にし、それによって平均検出時間（MTTD）を短縮します。元のログやイベントを保持する必要がある場合は、S3などの安価なストレージソリューションに保存できるため、データ取り込みと検索に必要な計算の全体的なコストを削減できます。

ソリューション:

可能な場合はログイベントをメトリクスに変換する
必要に応じて元のログまたはイベントを安価なストレージソリューションに保持する
保持されたログへのアクセスと分析にフェデレーテッド検索を活用する

成果:

メトリクスはより効率的に保存および処理される
問題のより迅速な特定により、平均検出時間（MTTD）を短縮
データ取り込みと計算の全体的なコストの削減
監視効率とリソース最適化の向上
運用コストを削減しながらシステム運用への高い可視性を維持

このワークショップでは、Ingest ProcessorとSplunk Observability Cloudを使用して、上記で説明した課題にどのように対処できるかを実際に体験する機会があります。

Tip

このワークショップを進める最も簡単な方法は以下を使用することです：

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）および右（▶️）カーソルキー

はじめに

この テクニカル なSplunk Observability Cloud向けIngest Processor¹ ワークショップでは、Splunk Enterprise CloudでIngest Processorを実際に操作する機会があります。

ワークショップモジュールを簡素化するために、事前設定されたSplunk Enterprise Cloudインスタンスが提供されます。

このインスタンスは、Ingest Processorパイプラインを作成するためのすべての要件が事前に設定されています。

このワークショップでは、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスをSplunk Observability Cloudに送信するメリットを紹介します。このテクニカルワークショップを終える頃には、Splunk Enterprise CloudにおけるIngest Processorの主要な機能と能力、およびIngest Processorパイプライン内の宛先としてSplunk Observability Cloudを使用する価値について十分に理解できるようになります。

事前設定された Splunk Enterprise Cloud インスタンスにアクセスする方法については、以下の手順を参照してください。

Ingest Processor は、Splunk Cloud Platformデプロイメント内で動作するデータ処理機能です。Ingest Processorを使用して、データフローの設定、データ形式の制御、インデックス作成前の変換ルールの適用、および宛先へのルーティングを行います。 ↩︎

ワークショップ環境への接続方法

Splunk Enterprise CloudインスタンスのURLを取得する方法
Splunk Observability Cloudワークショップ組織にアクセスする方法

1. Splunk Cloud インスタンス

このワークショップ全体で使用される3つのインスタンスが、すでにプロビジョニングされています：

Splunk Enterprise Cloud
Splunk Ingest Processor (SCS Tenant)
Splunk Observability Cloud

Splunk Enterprise CloudとIngest Processorインスタンスは Splunk Show でホストされています。ワークショップに招待された場合、Splunk Show のイベントへの招待メールを受け取っているはずです。または、ワークショップの開始時にイベントへのリンクが提供されます。

splunk.com の認証情報を使用してSplunk Showにログインしてください。このワークショップのイベントが表示されるはずです。イベントを開いて、Splunk CloudおよびIngest Processorインスタンスの詳細を確認してください。

Note

Splunk Showイベントの詳細に記載されている User Id をメモしてください。この番号は、Kubernetesデータの検索とフィルタリングに使用する sourcetype に含まれます。これは共有環境であるため、他の参加者のデータに影響を与えないよう、提供された参加者番号のみを使用してください。

2. Splunk Observability Cloud インスタンス

Splunk Observability Cloudワークショップ組織にアクセスするためのメールも受け取っているはずです（スパムフォルダを確認する必要があるかもしれません）。メールを受け取っていない場合は、ワークショップのインストラクターにお知らせください。環境にアクセスするには、Join Now ボタンをクリックしてください。

Important

ワークショップ開始時刻前にイベントにアクセスした場合、インスタンスがまだ利用できない可能性があります。ご心配なく、ワークショップが始まると提供されます。

さらに、Splunk Observability Cloudワークショップ組織に招待されています。招待には環境へのリンクが含まれています。まだSplunk Observability Cloudアカウントをお持ちでない場合は、作成を求められます。すでにお持ちの場合は、インスタンスにログインすると、利用可能な組織にワークショップ組織が表示されます。

Ingest Processor の仕組み

システムアーキテクチャ

Ingest Processorサービスの主要コンポーネントには、Ingest Processorサービスとデータ処理をサポートするSPL2パイプラインが含まれます。以下の図は、Ingest Processorソリューションのコンポーネントがどのように連携するかの概要を示しています：

Ingest Processor サービス

Ingest Processorサービスは、Splunkがホストするクラウドサービスです。これはデータ管理エクスペリエンスの一部であり、さまざまなデータ取り込みと処理のユースケースに対応するサービスセットです。

Ingest Processorサービスを使用して、以下のことができます：

各Ingest Processorが受信したデータをどのように処理してルーティングするかを決定するSPL2パイプラインを作成して適用する
処理したいデータの種類を識別し、Ingest Processorがそのデータを個別のイベントに分割およびマージする方法を決定するソースタイプを定義する
Ingest Processorが処理済みデータを送信する宛先への接続を作成する

パイプライン

パイプラインは、SPL2で記述されたデータ処理命令のセットです。パイプラインを作成する際、どのデータを処理するか、どのように処理するか、結果をどこに送信するかを指定する専用のSPL2ステートメントを記述します。パイプラインを適用すると、Ingest Processorはそれらの命令を使用して、Splunkフォワーダー、HTTPクライアント、ロギングエージェントなどのデータソースから受信したすべてのデータを処理します。

各パイプラインは、Ingest Processorが受信するすべてのデータのサブセットを選択して処理します。たとえば、受信データからソースタイプ cisco_syslog のイベントを選択し、Splunk Cloud Platformの指定されたインデックスに送信するパイプラインを作成できます。この選択されたデータのサブセットはパーティションと呼ばれます。詳細については、Partitions を参照してください。

Ingest Processorソリューションは、IngestProcessor プロファイルの一部であるコマンドと関数のみをサポートしています。Ingest Processor用のパイプラインを記述するために使用できる特定のSPL2コマンドと関数の詳細については、Ingest Processor pipeline syntax を参照してください。IngestProcessor プロファイルが他のSPL2プロファイルと比較して異なるコマンドと関数をどのようにサポートするかの概要については、SPL2 Search Reference の以下のページを参照してください：

Ingest Pipeline の作成

シナリオ概要

このシナリオでは、組織のSplunk Enterprise Cloud環境の管理を担当するSplunk管理者の役割を担います。最近、社内のアプリケーションチームと協力して、重要なマイクロサービスアプリケーションを監視するために、OpenTelemetryを使用してSplunk APMとInfrastructure MonitoringでKubernetes環境を計装しました。

Kubernetes環境からのログも収集され、Splunk Enterprise Cloudに送信されています。これらのログには以下が含まれます：

Podログ（アプリケーションログ）
Kubernetes Events
Kubernetes Clusterログ
- Control Plane Nodeログ
- Worker Nodeログ
- Auditログ

Splunk管理者として、収集しているデータが最適化されていることを確認し、可能な限り効率的な方法で分析できるようにしたいと考えています。このアプローチを採用することで、トラブルシューティングが加速され、ライセンスの効率的な利用が確保されます。

これを達成する1つの方法は、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスの宛先としてSplunk Observability Cloudを使用することです。これにより、ログの収集がより効率的になるだけでなく、新しく作成されたメトリクスをSplunk Observabilityで使用できるようになり、Splunk APMデータ（トレース）やSplunk Infrastructure Monitoringデータと相関させて、追加のトラブルシューティングコンテキストを提供できます。Splunk Observability Cloudはストリーミングメトリクスパイプラインを使用しているため、メトリクスに対してリアルタイムでアラートを設定でき、問題の特定を高速化できます。さらに、Metrics Pipeline Management機能を使用して、集約、不要なフィールドの削除、重要度の低いまたは不要なメトリクスのアーカイブによってデータをさらに最適化できます。

次のステップでは、Kubernetes AuditログをObservability Cloudに送信されるメトリクスに変換するIngest Processor Pipelineを作成します。

Splunk Cloud へのログイン

このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。開始する前に、Splunk Showイベントの詳細に記載されているSplunk CloudおよびIngest Processor SCS Tenant環境にアクセスする必要があります。

前提条件: Splunk Enterprise Cloudへのログイン

1. Splunk Showイベントの詳細に記載されている Ingest Processor Cloud Stack URLを開きます。

2. Connection infoで Stack URL リンクをクリックして、Splunk Cloudスタックを開きます。

3. admin ユーザー名とパスワードを使用してSplunk Cloudにログインします。

4. ログイン後、プロンプトが表示されたら、利用規約に同意して OK をクリックします。

5. Splunk Showイベントの詳細に戻り、Ingest Processor SCS Tenantを選択します。

6. Console URL をクリックして Ingest Processor SCS Tenant にアクセスします。

Note

Single Sign-On (SSO) Splunk Data Managementサービス（‘SCS Tenant’）とSplunk Cloud環境の間でSingle Sign-on (SSO) が設定されているため、すでにSplunk Cloudスタックにログインしている場合は、Splunk Data Managementサービスにも自動的にログインされます。認証情報の入力を求められた場合は、Splunk ShowイベントのSplunk Cloud Stackに記載されている認証情報を使用してください（‘Splunk Cloud Stack’ セクションに記載されています）。

Kubernetes Audit ログの確認

このセクションでは、収集されているKubernetes Auditログを確認します。イベントが非常に充実していることがわかります。これにより、チャート作成が非効率になる可能性があります。これに対処するために、Ingest ProcessorでIngest Pipelineを作成し、これらのイベントをSplunk Observability Cloudに送信されるメトリクスに変換します。これにより、イベントをより効率的にチャート化し、Splunk Observability Cloudのリアルタイムストリーミングメトリクスを活用できるようになります。

演習: Ingest Pipelineの作成

1. Splunk Showワークショップの詳細に記載されているURLを使用して、Ingest Processor Cloud Stack インスタンスを開きます。

2. Apps → Search and Reporting に移動します。

3. 検索バーに、以下のSPL検索文字列を入力します。

Note

USER_ID をSplunk Showインスタンス情報に記載されているUser IDに置き換えてください。

### Replace USER_ID with the User ID provided in your Splunk Show instance information
index=main sourcetype="kube:apiserver:audit:USER_ID"

4. Enter を押すか、緑色の虫眼鏡をクリックして検索を実行します。

Note

これで、環境のKubernetes Auditログが表示されるはずです。イベントがかなり充実していることに注目してください。利用可能なフィールドを探索し、どの情報がメトリクスとディメンションの良い候補になるか考え始めてください。自問してください：どのフィールドをチャート化したいか、それらのフィールドをどのようにフィルタリング、グループ化、または分割したいか？

Ingest Pipeline の作成

このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。

演習: Ingest Pipelineの作成

1. Splunk Showイベントで提供された接続情報を使用して、Ingest Processor SCS Tenant を開きます。

Note

Ingest Processor SCS Tenant を開いた際、ウェルカムページに移動した場合は、Splunk Cloud Platform の下にある Launch をクリックして、Ingest Pipelineを設定するData Managementページに移動してください。

2. Splunk Data Managementコンソールから Pipelines → New pipeline → Ingest Processor pipeline を選択します。

3. Ingest Processor設定ページの Get started ステップで、Blank Pipeline を選択し、Next をクリックします。

4. Ingest Processor設定ページの Define your pipeline’s partition ステップで、Partition by sourcetype を選択します。= equals Operatorを選択し、値として kube:apiserver:audit:USER_ID を入力します（USER_IDを割り当てられたUser IDに置き換えてください）。Apply をクリックします。

5. Next をクリックします。

6. Ingest Processor設定ページの Add sample data ステップで、Capture new snapshot を選択します。Snapshot nameに k8s_audit_USER_ID と入力し（USER_IDを割り当てられたUser IDに置き換えてください）、Capture をクリックします。

7. 新しく作成したスナップショット（k8s_audit_USER_ID）が選択されていることを確認し、Next をクリックします。

8. Ingest Processor設定ページの Select a metrics destination ステップで、show_o11y_org を選択します。Next をクリックします。

9. Ingest Processor設定ページの Select a data destination ステップで、splunk_indexer を選択します。Specify how you want your events to be routed to an index の下で、Default を選択します。Done をクリックします。

10. Pipeline search field で、デフォルトの検索を以下に置き換えます。

Note

メトリクス名の UNIQUE_FIELD を、Observability Cloud でメトリクスを識別するために使用する一意の値（イニシャルなど）に置き換えてください。

/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/
/* Import logs_to_metrics */
import logs_to_metrics from /splunk/ingest/commands
$pipeline =
| from $source
| thru [
        //define the metric name, type, and value for the Kubernetes Events
        //
        // REPLACE UNIQUE_FIELD WITH YOUR INITIALS
        //
        | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time
        | into $metrics_destination
    ]
| eval index = "kube_logs"
| into $destination;

SPL2が初めてですか？

SPL2クエリが行っていることの内訳は以下の通りです：

まず、Kubernetesイベントをメトリクスに変換するために使用される組み込みの logs_to_metrics コマンドをインポートしています。
右側に表示されている、kube:apiserver:audit sourcetypeからの任意のイベントであるソースデータを使用しています。
次に、thru コマンドを使用して、ソースデータセットを次のコマンド（この場合は logs_to_metrics）に書き込みます。
メトリクス名（k8s_audit）、メトリクスタイプ（counter）、値、タイムスタンプがすべてメトリクスに提供されていることがわかります。イベントが発生した回数をカウントしたいため、このメトリクスには値として1を使用しています。
次に、into $metrics_destintation コマンドを使用してメトリクスの宛先を選択します。これはSplunk Observability Cloud組織です。
最後に、生のログイベントを別の宛先（この場合は別のインデックス）に送信できるため、アクセスが必要になった場合に保持されます。

11. 右上隅の Preview ボタンをクリックするか、CTRL+Enter（MacではCMD+Enter）を押します。Previewing $pipeline ドロップダウンから $metrics_destination を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。

12. 右上隅の Save pipeline ボタンをクリックします。パイプライン名に Kubernetes Audit Logs2Metrics USER_ID と入力し、Save をクリックします。

13. 保存をクリックすると、新しく作成したパイプラインを適用するかどうか尋ねられます。Yes, apply をクリックします。

Note

Ingest Pipelineは現在Splunk Observability Cloudにメトリクスを送信しているはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。

次のステップでは、Splunk Observability Cloudで作成したメトリクスを表示して、パイプラインが動作していることを確認します。

Observability Cloud でのメトリクス確認

Kubernetes Auditログをメトリクスに変換してSplunk Observability Cloudに送信するIngest Pipelineが設定されたので、メトリクスが利用可能になっているはずです。メトリクスが収集されていることを確認するには、以下の手順を完了してください：

演習: Splunk Observability Cloudでのメトリクス確認

1. ワークショップ用に招待された Splunk Observability Cloud 組織にログインします。右上隅の + アイコン → Chart をクリックして、新しいチャートを作成します。

2. 新しく作成したチャートの Plot Editor で、Ingest Pipeline の設定時に使用したメトリクス名を入力します。

Info

Ingest Pipelineで作成したメトリクスが表示されるはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。

次のステップでは、Ingest Pipelineを更新してメトリクスにディメンションを追加し、アラートとトラブルシューティングのための追加コンテキストを得られるようにします。

パイプラインの更新とメトリクスの可視化

コンテキストの重要性

前のセクションでは、生のKubernetes Auditログを確認し、それらをメトリクスに変換してSplunk Observability Cloudに送信するIngest Processor Pipelineを作成しました。

このパイプラインが定義されたことで、Splunk Observability Cloudで新しいメトリクスを収集しています。これは素晴らしいスタートですが、特定の期間におけるKubernetes Auditイベントの総数を示す単一のメトリクスしか表示されません。イベントタイプ、ユーザー、レスポンスステータスなどでメトリクスを分割できるようにディメンションを追加すると、はるかに価値が高くなります。

このセクションでは、Ingest Processor Pipelineを更新して、収集されているメトリクスにKubernetes Auditログからの追加ディメンションを含めます。これにより、Auditログの特定の側面をさらにフィルタリング、グループ化、可視化、アラート設定できるようになります。メトリクスを更新した後、ログに関連付けられたさまざまなタイプのアクションのステータスを示す新しいダッシュボードを作成します。

Ingest Pipeline の更新

演習: Ingest Pipelineの更新

1. 前のステップで作成したIngest Pipelineの設定ページに戻ります。

2. 生のKubernetes Auditログからメトリクスにディメンションを追加するには、パイプライン用に作成したSPL2クエリの logs_to_metrics 部分を以下に置き換えて更新します：

Note

メトリクス名フィールド（name="k8s_audit_UNIQUE_FIELD"）を、元のパイプラインで指定した名前に更新してください。

| logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb}

Note

SPL2クエリの dimensions フィールドを使用して、生のイベントからのディメンションをSplunk Observability Cloudに送信されるメトリクスに追加できます。この場合、イベントのレスポンスステータス、名前空間、Kubernetesリソース、ユーザー、およびverb（実行されたアクション）を追加しています。これらのディメンションを使用して、より詳細なダッシュボードとアラートを作成できます。

Splunk Observability Cloudでコンテキスト伝播と関連コンテンツを活用できるように、サービス全体で共通のタグを追加することを検討してください。

更新されたパイプラインは以下のようになります：

/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/
/* Import logs_to_metrics */
import logs_to_metrics from /splunk/ingest/commands
$pipeline =
| from $source
| thru [
        //define the metric name, type, and value for the Kubernetes Events
        //
        // REPLACE UNIQUE_FIELD WITH YOUR INITIALS
        //
        | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb}
        | into $metrics_destination
    ]
| eval index = "kube_logs"
| into $destination;

3. 右上隅の Preview ボタンをクリックするか、CTRL+Enter（MacではCMD+Enter）を押します。Previewing $pipeline ドロップダウンから $metrics_destination を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。

4. プレビューテーブルのdimensions列にディメンションが表示されていることを確認します。テーブルをクリックすると、dimensionsオブジェクト全体を表示できます。

5. 右上隅の Save pipeline ボタンをクリックします。「You are editing an active pipeline」モーダルで Save をクリックします。

Note

このパイプラインはすでにアクティブであるため、行った変更はすぐに有効になります。追加したディメンションを使用して、メトリクスは複数のメトリクス時系列に分割されるはずです。

次のステップでは、Kubernetes Auditイベントからの異なるディメンションを使用して可視化を作成します。

Kubernetes Audit イベントメトリクスの可視化

メトリクスにディメンションが追加されたので、イベントの verb ディメンションを使用して、さまざまなKubernetesアクションの健全性を示すチャートを作成します。

演習: Kubernetes Auditイベントメトリクスの可視化

1. 前のセクションで作成したチャートを閉じた場合は、右上隅の + アイコン → Chart をクリックして、新しいチャートを作成します。

2. 新しく作成したチャートの Plot Editor で、メトリクス名フィールドに k8s_audit* と入力します。ここでワイルドカードを使用して、取り込まれているすべてのメトリクスを表示できるようにします。

3. 1つから多くのメトリクスへの変化に注目してください。これは、パイプラインを更新してディメンションを含めた時点からの変化です。このメトリクスが利用可能になったので、アクションにエラーが関連付けられているかどうかを示すようにチャートを調整しましょう。

まず、response_status フィールドで利用可能なHTTPレスポンスコードを使用して、成功しなかったKubernetesイベントのみにフィルタリングします。レスポンスコードが 409（競合を示す、たとえばすでに存在するリソースを作成しようとした場合）または 503（リクエストに対してAPIが応答しなかった場合）のイベントのみが必要です。

4. チャートのプロットエディタで Add filter をクリックし、フィールドに response_status を使用し、値として 409.0 と 503.0 を選択します。

次に、resource、action、および response status でグループ化されたイベントの総数を計算する関数をチャートに追加します。これにより、どのアクションと関連するリソースにエラーがあったかを正確に確認できます。これで、成功しなかったKubernetesイベントのみを見ています。

5. Add analytics → Sum → Sum:Aggregation をクリックし、Group by フィールドに resource、action、および response_status を追加します。

6. 上部のボタンにあるチャートタイプを使用して、チャートを heatmap に変更します。Plot editor の隣にある Chart options をクリックします。Group by セクションで response_status を選択し、次に action を選択します。Color threshold を Auto から Fixed に変更します。青い + button をクリックして、別のしきい値を追加します。Down arrow を Yellow に、Middle を orange に変更します。Up arrow は red のままにします。middle threshold に 5 を、upper threshold に 20 を入力します。

7. チャートの右上隅にある青い Save as… ボタンをクリックします。チャートの名前を入力します（例：Kubernetes Audit Logs - Conflicts and Failures）。

8. Choose a dashboard で New dashboard を選択します。

9. 後で簡単に見つけられるように、イニシャルを含むダッシュボード名を入力します。Save をクリックします。

10. 作成した新しいダッシュボードが選択されていることを確認し、Ok をクリックします。

これで、作成したチャートを含む新しいKubernetes Audit Eventsダッシュボードに移動するはずです。Kubernetesクラスターで実行されているアプリケーションからのアプリケーションエラーとレスポンスタイム、またはpod phase、podメモリ使用率などの他のKubernetesメトリクスなど、環境内の他のメトリクスから新しいチャートを追加できます。これにより、クラスターイベントからアプリケーションの健全性まで、Kubernetes環境の相関ビューが得られます。

チャートの可視化ボックスの右上にある3つのドット ... を使用して、このチャートのコピーを作成します。

UIの右上にある + アイコンを使用して、作業中の同じダッシュボードに貼り付けます。

貼り付けたチャートをクリックして、可視化を Column チャートに変更します。

SUMを resource、namespace のみに変更します（フィルターは問題のあるコードのみにフィルタリングします）。

Chart optionsでタイトルを Kubernetes Audit Logs - Conflicts by Namespace に変更します。

Save をクリックして閉じます。

演習: Kubernetes Auditログに基づくディテクターの作成

Conflicts by Namespaceチャートで、小さなベルアイコンをクリックし、New detector from chartを選択します。

名前を選択し、Create alert rule をクリックします。

Alert conditionで Static Threshold をクリックし、Proceed to Alert Settings をクリックします。

Threshold に 20 を入力します。

このアラートの受信者は選択しないので、Activate をクリックし、Activate Alert Rule と Save を選択します。

右上の Save を最後にもう一度クリックして、ディテクターを保存します。

ダッシュボードに戻ると、チャートに関連付けられたディテクターが、チャート上の点灯したベルアイコンで示されているのが確認できます。

演習: Splunk Cloud - Dashboard Studioで時系列データを可視化する

時系列メトリクスがSplunk Observability Cloudデータストアに取り込まれたので、Splunk Cloudでこれらの時系列メトリクスを簡単に可視化できます！

Splunk Cloudインスタンスで Dashboards に移動し、Create New Dashboard を選択します。

ダッシュボードのタイトル、権限、Dashboard Studio を選択し、任意のLayout Modeを選択します。 Create をクリックします。

Dashboard Studioでチャートアイコンをクリックし、Column を選択します。

Select data source で Create splunk observability cloud metric search を選択します。

新しいデータソースの名前を選択し、Search for metric or metadata の下にある Content Import リンクをクリックします。

チャートのURLをコピーして Content URL フィールドに貼り付けます。

Import をクリックします。

チャートのサイズをダッシュボードに合わせて調整します。

チャートの Configuration の右側にある Interactions を展開し、Add Interaction をクリックします。

Splunk ObservabilityのダッシュボードからURLをコピーします。

On click で Link to custom URL を選択し、ソースデータに簡単に戻れるようにSplunk Observability CloudのダッシュボードのURLを追加します。また、使いやすいナビゲーションのために Open in new tab を選択します。

右上の Save をクリックしてダッシュボードを保存します。

チャートのColumnまたは名前をハイライトしてクリックします。

Splunk Observabilityに戻ることが通知されます。Continue をクリックします。

これで、Splunk Cloudから対応するSplunk Observabilityダッシュボードに戻りました。

まとめ

このワークショップでは、Splunk Ingest Pipelines を使用して詳細なログイベントを実用的なメトリクスに変換することで、Kubernetesログ管理を最適化するプロセス全体を体験しました。まず、Kubernetes Auditログをメトリクスに効率的に変換するパイプラインを定義し、重要な情報を保持しながらデータ量を大幅に削減しました。次に、生のログイベントが長期保持とより深い分析のためにS3に安全に保存されることを確認しました。

次に、生のイベントから主要なディメンションを追加してこれらのメトリクスを強化する方法を示し、特定のアクションとリソースにドリルダウンできるようにしました。エラーに焦点を当てるためにメトリクスをフィルタリングし、リソースとアクションごとに分類するチャートを作成しました。これにより、問題が発生している場所をリアルタイムで正確に特定できるようになりました。

Splunk Observability Cloud のリアルタイムアーキテクチャにより、これらのメトリクスは問題が検出された瞬間にアラートをトリガーでき、平均検出時間（MTTD）を大幅に短縮できます。さらに、このチャートを新規または既存のダッシュボードに簡単に保存して、重要なメトリクスの継続的な可視性と監視を確保する方法を示しました。

このアプローチの価値は明確です：Ingest Processor を使用してログをメトリクスに変換することで、データ処理を効率化し、ストレージコストを削減するだけでなく、Splunk Observability Cloud を使用してリアルタイムで問題を監視し対応する能力も得られます。これにより、コンプライアンスやより深い分析のために元のログを保持してアクセスする能力を維持しながら、問題解決の高速化、システム信頼性の向上、およびより効率的なリソース利用が実現します。

Happy Splunking!

Splunk Observability Cloud による Cisco AI Pods のモニタリング

2 minutes Author Derek Mitchell

Cisco の AI 対応 PODs は、ハードウェアとソフトウェアの最高の技術を組み合わせ、多様なニーズに合わせた堅牢でスケーラブルかつ効率的な AI 対応インフラストラクチャを構築します。

Splunk Observability Cloud は、このインフラストラクチャ全体と、このスタック上で実行されるすべてのアプリケーションコンポーネントに対する包括的な可視性を提供します。

Cisco AI POD 環境向けに Splunk Observability Cloud を構成する手順は完全に文書化されています（詳細はこちらを参照してください）。

ただし、インストール手順を練習するために Cisco AI POD 環境にアクセスできるとは限りません。

このワークショップでは、実際の Cisco AI POD にアクセスすることなく、Splunk Observability Cloud で Cisco AI PODs をモニタリングするために使用されるいくつかの技術をデプロイし、操作するハンズオン体験を提供します。以下の内容が含まれます：

Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイを練習します。
インフラストラクチャメトリクスを取り込むために、コレクターに Prometheus receiverを追加する練習をします。
クラスターへの Weaviate ベクトルデータベースのデプロイを練習します。
大規模言語モデル（LLM）と連携する Python サービスを OpenTelemetry でインストルメントする練習をします。
LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。

注意：ワークショップセットアップセクションは、ワークショップ主催者のみが実行する必要があります

ヒント

このワークショップを最も簡単にナビゲートする方法は以下の通りです：

このページの右上にある左右の矢印（ < | > ）を使用する
キーボードの左（◀️）および右（▶️）カーソルキーを使用する

ワークショップセットアップ

このセクションには、ワークショップ主催者がワークショップをセットアップするために実行する手順が含まれています：

AWS アカウントのセットアップ
OpenShift の前提条件
AWS ROSA を使用して、GPU ベースのワーカーノードを持つ Red Hat OpenShift クラスターをデプロイします。
NVIDIA NIM Operator と NVIDIA GPU Operator をデプロイします。
NVIDIA NIM を使用して 大規模言語モデル（LLM） をクラスターにデプロイします。
適切な権限を持つ各ワークショップユーザー用の OpenShift ログインとネームスペースを作成します。
Splunk OpenTelemetry Collector の Cluster Receiver コンポーネントをインストールします。
クラスターに Weaviate ベクトルデータベース をデプロイします。
Portworx Prometheus exporter を模倣するサービスをデプロイします。

AWSセットアップ

10 minutes

AWSでRed Hat OpenShiftサービスを有効にする

AWSアカウントにOpenShiftをデプロイするには、まずAWSコンソールを使用してRed Hat OpenShiftサービスを有効にする必要があります。

次に、AWSアカウントをRed Hatアカウントに接続する手順に従ってください。

EC2インスタンスのプロビジョニング

Red Hatクラスターをデプロイするために使用するEC2インスタンスをプロビジョニングしましょう。これにより、Mac OSでROSAコマンドラインインターフェースを実行する際の制限を回避できます。

このワークショップの作成時にはUbuntu 24.04 LTSを使用したt3.xlargeインスタンスタイプを使用しましたが、より小さなインスタンスタイプも使用できます。

インスタンスが起動したら、sshで接続してください。

GitHubリポジトリのクローン

GitHubリポジトリをEC2インスタンスにクローンします：

git clone https://github.com/splunk/observability-workshop.git

cd observability-workshop/workshop/cisco-ai-pods

OpenShiftの前提条件

15 minutes

以下の手順は、AWSにOpenShiftクラスターをデプロイする前に必要です。

Red Hatログインの作成

最初に行う必要があるのは、Red Hatのアカウントを作成することです。こちらのフォームに記入して作成できます。

AWS CLIのインストール

以前プロビジョニングしたEC2インスタンスにAWS CLIをインストールするには、以下のコマンドを実行します：

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install

以下のコマンドを使用して、正常にインストールされたことを確認します：

aws --version

以下のような結果が返されるはずです：

aws-cli/2.30.5 Python/3.13.7 Linux/6.14.0-1011-aws exe/x86_64.ubuntu.24

お好みの方法でAWSアカウントにログインしてください。ガイダンスについてはドキュメントを参照してください。例えば、aws configureコマンドを実行してログインできます。

aws ec2 describe-instancesなどのコマンドを実行して、正常にログインできていることを確認してください。

次に、以下のコマンドでアカウントIDを確認します：

aws sts get-caller-identity

ELB (Elastic Load Balancing)のサービスロールが存在するかどうかを確認します：

aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"

ロールが存在しない場合は、以下のコマンドを実行して作成します：

aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"

ROSA CLIのインストール

デプロイにはROSAコマンドラインインターフェース (CLI)を使用します。手順はRed Hatドキュメントに基づいています。

お使いのオペレーティングシステム用のROSA CLIの最新リリースはこちらからダウンロードできます。

または、以下のコマンドを使用してCLIバイナリをEC2インスタンスに直接ダウンロードすることもできます：

curl -L -O https://mirror.openshift.com/pub/cgw/rosa/latest/rosa-linux.tar.gz

コンテンツを解凍します：

tar -xvzf rosa-linux.tar.gz

結果のファイル(rosa)をパスに含まれている場所に移動します。例えば：

sudo mv rosa /usr/local/bin/rosa

以下のコマンドを実行してRed Hatアカウントにログインし、コマンド出力の指示に従ってください：

rosa login --use-device-code

OpenShift CLI (oc)のインストール

以下のコマンドを使用して、OpenShift CLIバイナリをEC2インスタンスに直接ダウンロードできます：

curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz

コンテンツを解凍します：

tar -xvzf openshift-client-linux.tar.gz

結果のファイル(ocとkubectl)をパスに含まれている場所に移動します。例えば：

sudo mv oc /usr/local/bin/oc
sudo mv kubectl /usr/local/bin/kubectl

アカウント全体のロールとポリシーの作成

以下のコマンドを使用して、必要なアカウント全体のロールとポリシーを作成します：

rosa create account-roles --mode auto

ROSA HCP用のAWS VPCの作成

OpenShiftクラスターをデプロイするために、Hosted Control Plane (HCP)デプロイオプションを使用します。これを行うには、以下のコマンドを使用してAWSアカウントに新しいVPCを作成する必要があります：

注意: リージョンを環境に合わせて更新してください。

rosa create network network-template --param Region=us-east-2 --param Name=rosa-network-stack --template-dir='.'

重要: このコマンドの結果として作成されたサブネットIDをメモしておいてください。クラスターを作成する際に必要になります。また、ネットワークを削除する場合に後で必要になるCloudFormationスタック名もメモしておいてください。

注意: デフォルトでは、各AWSリージョンはElastic IPアドレスが5つに制限されています。「The maximum number of addresses has been reached.」というエラーが発生した場合は、AWSに連絡してこの制限の引き上げをリクエストするか、ROSA用のVPCを作成するために別のAWSリージョンを選択する必要があります。

OpenID Connect設定の作成

Red Hat OpenShift Service on AWSクラスターを作成する前に、以下のコマンドでOpenID Connect (OIDC)設定を作成しましょう：

rosa create oidc-config --mode=auto --yes

重要: 作成されたoidc-provider idをメモしておいてください。

AWSにOpenShiftクラスターをデプロイする

25 minutes

OpenShiftクラスターのデプロイ

ROSA CLIを使用してOpenShiftクラスターをデプロイします。

まず、いくつかの環境変数を設定する必要があります：

注意: EXPORTコマンドを実行する前に、サブネットIDとOIDC IDを入力してください。

export CLUSTER_NAME=rosa-test
export AWS_REGION=us-east-2
export AWS_INSTANCE_TYPE=g5.4xlarge
export SUBNET_IDS=<comma separated list of subnet IDs from earlier rosa create network command>
export OIDC_ID=<the oidc-provider id returned from the rosa create oidc-config command>
export OPERATOR_ROLES_PREFIX=rosa-test-a6x9

以下のコマンドを使用して、OIDC設定用のオペレーターロールを作成します：

注意: プロンプトが表示されたら、デフォルト値をそのまま使用してください。

rosa create operator-roles --hosted-cp --prefix $OPERATOR_ROLES_PREFIX --oidc-config-id $OIDC_ID

次に、以下のようにしてクラスターを作成できます：

rosa create cluster \
    --cluster-name $CLUSTER_NAME \
    --mode auto \
    --hosted-cp \
    --sts \
    --create-admin-user \
    --operator-roles-prefix $OPERATOR_ROLES_PREFIX \
    --oidc-config-id $OIDC_ID \
    --subnet-ids $SUBNET_IDS \
    --compute-machine-type $AWS_INSTANCE_TYPE \
    --replicas 2 \
    --region $AWS_REGION \
    --tags "splunkit_environment_type:non-prd,splunkit_data_classification:private"

g5.4xlargeインスタンスタイプを指定していることに注意してください。これには、このワークショップの後半で使用するNVIDIA GPUが含まれています。このインスタンスタイプは比較的高価で、執筆時点で1時間あたり約$1.64であり、2つのレプリカをリクエストしているため、クラスターの実行時間に注意してください。コストはすぐに蓄積されます。

クラスターの準備ができたかどうかを確認するには、以下を実行します：

rosa describe cluster -c $CLUSTER_NAME

クラスターのインストールログを監視するには、以下を実行します：

rosa logs install -c $CLUSTER_NAME --watch

OpenShiftクラスターへの接続

以下のコマンドを使用して、oc CLIをOpenShiftクラスターに接続します：

注意: rosa describe cluster -c $CLUSTER_NAMEコマンドを実行し、結果のAPI Server URLを以下のコマンドに代入してから実行してください。例えば、サーバー名はhttps://api.rosa-test.aaa.bb.openshiftapps.com:443のようになります。

 oc login <API Server URL> -u cluster-admin

クラスターに接続したら、ノードが起動して実行されていることを確認します：

oc get nodes

NAME                                       STATUS   ROLES    AGE   VERSION
ip-10-0-1-184.us-east-2.compute.internal   Ready    worker   14m   v1.31.11
ip-10-0-1-50.us-east-2.compute.internal    Ready    worker   20m   v1.31.11

NVIDIA NIM Operatorのデプロイ

20 minutes

NVIDIA GPU Operator は、Kubernetesクラスター内でGPUをプロビジョニングするために必要なすべてのNVIDIAソフトウェアコンポーネントのデプロイ、設定、管理を自動化するKubernetes Operatorです。

NVIDIA NIM Operator は、このワークショップで以前作成したOpenShiftクラスターなどのKubernetes環境でLLMをデプロイするために使用されます。

このワークショップのセクションでは、OpenShiftクラスターにNVIDIA GPUとNIM Operatorの両方をデプロイするために必要な手順を説明します。

NVIDIA NGCアカウントの作成

LLMをダウンロードしてNVIDIA NIM Operatorを使用してデプロイするには、NVIDIA GPU CLOUD (NGC)アカウントが必要です。こちらから登録してアカウントを作成できます。

NVIDIA Developer Programへの登録

NVIDIA Developer Programに登録すると、このワークショップの後半でLLMをデプロイするために使用するNVIDIA NIMにアクセスできます。

NGCのNVIDIAサブスクリプションリストにNVIDIA Developer Programが表示されていることを確認してください：

NGC APIキーの生成

NGCウェブサイトにログインしたら、画面右上のユーザーアカウントアイコンをクリックし、Setupを選択します。

次に、Generate API Keyをクリックし、手順に従ってください。キーがNGC CatalogとSecrets Managerサービスに関連付けられていることを確認してください。

生成されたキーは安全な場所に保存してください。このワークショップの後半で使用します。

NGC APIキーの生成に関する詳細については、NVIDIAドキュメントを参照してください。

Node Feature Discovery Operatorのインストール

このセクションの手順は、CLIを使用したNFD Operatorのインストールに基づいています。

以下のスクリプトを実行して、Node Feature Discovery Operatorをインストールします：

cd nvidia
./install-nfd-operator.sh

Operatorのデプロイが成功したことを確認するには、以下を実行します：

oc get pods

NAME                                      READY   STATUS    RESTARTS   AGE
nfd-controller-manager-7f86ccfb58-vgr4x   2/2     Running   0          10m

NodeFeatureDiscovery CRの作成

このセクションの手順は、CLIを使用したNodeFeatureDiscovery CRの作成に基づいています。

以下のスクリプトを実行して、Node Feature Discovery CRを作成します：

./create-nfd-cr.sh

NVIDIA GPU Operatorのインストール

このセクションの手順は、OpenShiftへのNVIDIA GPU Operatorのインストールに基づいています。

以下のスクリプトを実行して、NVIDIA GPU Operatorをインストールします：

./install-nvidia-gpu-operator.sh

インストールプランが作成されるまで待ちます：

oc get installplan -n nvidia-gpu-operator

NAME            CSV                              APPROVAL   APPROVED
install-mmlxq   gpu-operator-certified.v25.3.4   Manual     false

以下のコマンドでインストールプランを承認します：

INSTALL_PLAN=$(oc get installplan -n nvidia-gpu-operator -oname)
oc patch $INSTALL_PLAN -n nvidia-gpu-operator --type merge --patch '{"spec":{"approved":true }}'

installplan.operators.coreos.com/install-rc9xq patched

クラスターポリシーの作成

このセクションの手順は、CLIを使用したクラスターポリシーの作成に基づいています。

./create-cluster-policy.sh

NVIDIA GPU Operatorのインストール確認

以下のコマンドを使用して、NVIDIA GPU Operatorが正常にインストールされたことを確認します：

oc get pods,daemonset -n nvidia-gpu-operator

NAME                                                      READY   STATUS      RESTARTS      AGE
pod/gpu-feature-discovery-sblkn                           1/1     Running     0             5m5s
pod/gpu-feature-discovery-zpt94                           1/1     Running     0             4m58s
pod/gpu-operator-6579bc6fdc-cp28l                         1/1     Running     0             23m
pod/nvidia-container-toolkit-daemonset-qfcl9              1/1     Running     0             5m5s
pod/nvidia-container-toolkit-daemonset-zbwb6              1/1     Running     0             4m59s
pod/nvidia-cuda-validator-f7tl2                           0/1     Completed   0             78s
pod/nvidia-cuda-validator-t7n9g                           0/1     Completed   0             71s
pod/nvidia-dcgm-exporter-gk66x                            1/1     Running     0             4m59s
pod/nvidia-dcgm-exporter-w8kr8                            1/1     Running     2 (52s ago)   5m5s
pod/nvidia-dcgm-lrnzr                                     1/1     Running     0             4m58s
pod/nvidia-dcgm-tvrdm                                     1/1     Running     0             5m5s
pod/nvidia-device-plugin-daemonset-d62nk                  1/1     Running     0             5m5s
pod/nvidia-device-plugin-daemonset-fnv4j                  1/1     Running     0             4m59s
pod/nvidia-driver-daemonset-418.94.202509100653-0-5xbvq   2/2     Running     0             5m48s
pod/nvidia-driver-daemonset-418.94.202509100653-0-hmkdl   2/2     Running     0             5m48s
pod/nvidia-node-status-exporter-2kqwr                     1/1     Running     0             5m44s
pod/nvidia-node-status-exporter-n8d9s                     1/1     Running     0             5m44s
pod/nvidia-operator-validator-r2nm2                       1/1     Running     0             5m5s
pod/nvidia-operator-validator-w2fpn                       1/1     Running     0             4m59s

NAME                                                           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                                                                         AGE
daemonset.apps/gpu-feature-discovery                           2         2         2       2            2           nvidia.com/gpu.deploy.gpu-feature-discovery=true                                                                      5m45s
daemonset.apps/nvidia-container-toolkit-daemonset              2         2         2       2            2           nvidia.com/gpu.deploy.container-toolkit=true                                                                          5m48s
daemonset.apps/nvidia-dcgm                                     2         2         2       2            2           nvidia.com/gpu.deploy.dcgm=true                                                                                       5m46s
daemonset.apps/nvidia-dcgm-exporter                            2         2         2       2            2           nvidia.com/gpu.deploy.dcgm-exporter=true                                                                              5m46s
daemonset.apps/nvidia-device-plugin-daemonset                  2         2         2       2            2           nvidia.com/gpu.deploy.device-plugin=true                                                                              5m47s
daemonset.apps/nvidia-device-plugin-mps-control-daemon         0         0         0       0            0           nvidia.com/gpu.deploy.device-plugin=true,nvidia.com/mps.capable=true                                                  5m47s
daemonset.apps/nvidia-driver-daemonset-418.94.202509100653-0   2         2         2       2            2           feature.node.kubernetes.io/system-os_release.OSTREE_VERSION=418.94.202509100653-0,nvidia.com/gpu.deploy.driver=true   5m48s
daemonset.apps/nvidia-mig-manager                              0         0         0       0            0           nvidia.com/gpu.deploy.mig-manager=true                                                                                5m45s
daemonset.apps/nvidia-node-status-exporter                     2         2         2       2            2           nvidia.com/gpu.deploy.node-status-exporter=true                                                                       5m44s
daemonset.apps/nvidia-operator-validator                       2         2         2       2            2           nvidia.com/gpu.deploy.operator-validator=true                                                                         5m48s

Operator SDKのインストール

このセクションの手順は、GitHubリリースからのインストールに基づいています。

リリースバイナリのダウンロード

プラットフォーム情報を設定します：

export ARCH=$(case $(uname -m) in x86_64) echo -n amd64 ;; aarch64) echo -n arm64 ;; *) echo -n $(uname -m) ;; esac)
export OS=$(uname | awk '{print tolower($0)}')

お使いのプラットフォーム用のバイナリをダウンロードします：

export OPERATOR_SDK_DL_URL=https://github.com/operator-framework/operator-sdk/releases/download/v1.41.1
curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_${OS}_${ARCH}

ダウンロードしたバイナリの検証

keyserver.ubuntu.comからoperator-sdkリリースのGPGキーをインポートします：

gpg --keyserver keyserver.ubuntu.com --recv-keys 052996E2A20B5C7E

チェックサムファイルとその署名をダウンロードし、署名を検証します：

curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt
curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt.asc
gpg -u "Operator SDK (release) <cncf-operator-sdk@cncf.io>" --verify checksums.txt.asc

以下のような出力が表示されるはずです：

gpg: assuming signed data in 'checksums.txt'
gpg: Signature made Fri 30 Oct 2020 12:15:15 PM PDT
gpg:                using RSA key ADE83605E945FA5A1BD8639C59E5B47624962185
gpg: Good signature from "Operator SDK (release) <cncf-operator-sdk@cncf.io>" [ultimate]

チェックサムが一致することを確認します：

grep operator-sdk_${OS}_${ARCH} checksums.txt | sha256sum -c -

以下のような出力が表示されるはずです：

operator-sdk_linux_amd64: OK

リリースバイナリをPATHにインストールする

chmod +x operator-sdk_${OS}_${ARCH} && sudo mv operator-sdk_${OS}_${ARCH} /usr/local/bin/operator-sdk

NGC CLIのインストール

このセクションの手順は、NGC CLIインストールに基づいています。

Download CLIをクリックしてバイナリを含むzipファイルをダウンロードし、権限のあるディレクトリにzipファイルを転送してから解凍してバイナリを実行します。また、実行権限のあるディレクトリに移動し、以下のコマンドを実行することで、コマンドラインからダウンロード、解凍、インストールを行うこともできます：

wget --content-disposition https://api.ngc.nvidia.com/v2/resources/nvidia/ngc-apps/ngc_cli/versions/4.3.0/files/ngccli_linux.zip -O ngccli_linux.zip && unzip ngccli_linux.zip

ダウンロード中にファイルが破損していないことを確認するために、バイナリのmd5ハッシュを確認します：

find ngc-cli/ -type f -exec md5sum {} + | LC_ALL=C sort | md5sum -c ngc-cli.md5

ダウンロード中にファイルが破損していないことを確認するために、バイナリのSHA256ハッシュを確認します。以下のコマンドを実行します：

sha256sum ngccli_linux.zip

リソースのリリースノートにも記載されている以下の値と比較してください：

5f01eff85a66c895002f3c87db2933c462f3b86e461e60d515370f647b4ffc21

値を確認した後、NGC CLIバイナリを実行可能にし、現在のディレクトリをパスに追加します：

chmod u+x ngc-cli/ngc
echo "export PATH=\"\$PATH:$(pwd)/ngc-cli\"" >> ~/.bash_profile && source ~/.bash_profile

コマンドを実行できるように、NGC CLIを設定する必要があります。

以下のコマンドを入力し、プロンプトが表示されたらAPIキーを入力してください：

ngc config set

NGC APIキーを含む環境変数を定義します：

export NGC_API_KEY=<your NGC API key>

NVIDIA NIM Operatorのインストール

このセクションの手順は、operator-sdkを使用したRed Hat OpenShiftへのNIM Operatorのインストール（開発専用）に基づいています。

以下のスクリプトを実行して、NIM Operatorをインストールします：

./install-nim-operator.sh

コントローラーPodが実行されていることを確認します：

oc get pods -n nvidia-nim-operator

NAME                                                              READY   STATUS      RESTARTS   AGE
ec60a4439c710b89fc2582f5384382b4241f9aee62bb3182b8d128e69dx54dc   0/1     Completed   0          61s
ghcr-io-nvidia-k8s-nim-operator-bundle-latest-main                1/1     Running     0          71s
k8s-nim-operator-86d478b55c-w5cf5                                 1/1     Running     0          50s

LLMのデプロイ

20 minutes

このセクションでは、NVIDIA NIM Operatorを使用して、2つのLarge Language ModelsをOpenShiftクラスターにデプロイします。

Namespaceの作成

oc create namespace nim-service

NGC APIキーを使用したSecretの追加

NVIDIA NGCからコンテナイメージをダウンロードするためのDockerレジストリSecretを追加します：

oc create secret -n nim-service docker-registry ngc-secret \
    --docker-server=nvcr.io \
    --docker-username='$oauthtoken' \
    --docker-password=$NGC_API_KEY

モデルプーラーコンテナがNVIDIA NGCからモデルをダウンロードするために使用する汎用Secretを追加します：

oc create secret -n nim-service generic ngc-api-secret \
    --from-literal=NGC_API_KEY=$NGC_API_KEY

LLMのデプロイ

以下のコマンドを実行して、NIMCacheとNIMServiceを作成します：

oc apply -n nim-service -f nvidia-llm.yaml

Persistent Volumeが作成され、Persistent Volume Claimが正常にバインドされたことを確認します：

注意: これには数分かかる場合があります

oc get pv,pvc -n nim-service

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
persistentvolume/pvc-1af12c04-29ad-497f-b018-7d9a3aea3019   100Gi      RWO            Delete           Bound    openshift-monitoring/prometheus-data-prometheus-k8s-1   gp3-csi        <unset>                          4h15m
persistentvolume/pvc-9c389d79-13fb-4169-9d99-a77efd6e7919   100Gi      RWO            Delete           Bound    openshift-monitoring/prometheus-data-prometheus-k8s-0   gp3-csi        <unset>                          4h15m
persistentvolume/pvc-a603b8a7-1445-4b03-945a-3ed68338834c   50Gi       RWO            Delete           Bound    nim-service/meta-llama-3-2-1b-instruct-pvc              gp3-csi        <unset>                          114s

NAME                                                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/meta-llama-3-2-1b-instruct-pvc   Bound    pvc-a603b8a7-1445-4b03-945a-3ed68338834c   50Gi       RWO            gp3-csi        <unset>                 7m8s

NIMCacheがReadyであることを確認します：

oc get nimcache.apps.nvidia.com -n nim-service

NAME                         STATUS   PVC                              AGE
meta-llama-3-2-1b-instruct   Ready    meta-llama-3-2-1b-instruct-pvc   9m50s

NIMServiceがReadyであることを確認します：

oc get nimservices.apps.nvidia.com -n nim-service

NAME                         STATUS   AGE
meta-llama-3-2-1b-instruct   Ready    11m

LLMのテスト

LLMが期待通りに動作していることを確認しましょう。

curlコマンドにアクセスできるPodを起動します：

oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh

次に、以下のコマンドを実行してLLMにプロンプトを送信します：

curl -X "POST" \
 'http://meta-llama-3-2-1b-instruct.nim-service:8000/v1/chat/completions' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
        "model": "meta/llama-3.2-1b-instruct",
        "messages": [
        {
          "content":"What is the capital of Canada?",
          "role": "user"
        }],
        "top_p": 1,
        "n": 1,
        "max_tokens": 1024,
        "stream": false,
        "frequency_penalty": 0.0,
        "stop": ["STOP"]
      }'

{
  "id": "chatcmpl-2ccfcd75a0214518aab0ef0375f8ca21",
  "object": "chat.completion",
  "created": 1758919002,
  "model": "meta/llama-3.2-1b-instruct",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "reasoning_content": null,
        "content": "The capital of Canada is Ottawa.",
        "tool_calls": []
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "total_tokens": 50,
    "completion_tokens": 8,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null
}

Embeddingsモデルのデプロイ

また、クラスターにembeddingsモデルをデプロイします。これは、このワークショップの後半でRetrieval Augmented Generation (RAG)を実装するために使用されます。

以下のコマンドを実行して、embeddingsモデルをデプロイします：

oc apply -n nim-service -f nvidia-embeddings.yaml

NIMServiceがReadyであることを確認します：

oc get nimservices.apps.nvidia.com llama-32-nv-embedqa-1b-v2 -n nim-service

NAME                        STATUS   AGE
llama-32-nv-embedqa-1b-v2   Ready    82s

Embeddingsモデルのテスト

embeddingsモデルが期待通りに動作していることを確認しましょう。

curlコマンドにアクセスできるPodを起動します：

oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh

次に、以下のコマンドを実行してLLMにプロンプトを送信します：

  curl -X POST http://llama-32-nv-embedqa-1b-v2.nim-service:8000/v1/embeddings \
  -H 'Accept: application/json' \
  -H "Content-Type: application/json" \
  -d '{
    "input": ["What is the capital of France?"],
    "model": "nvidia/llama-3.2-nv-embedqa-1b-v2",
    "input_type": "query",
    "encoding_format": "float",
    "truncate": "NONE"
  }'

{"object":"list","data":[{"index":0,"embedding":[-0.016632080078125,0.041259765625,-0.0156707763671875,0.032379150390625,0.045074462890625,0.0169830322265625,-0.03546142578125,-0.0003402233123779297,-0.038909912109375,-0.0023651123046875,-0.0001741647720336914,-0.01377105712890625,-0.01200103759765625,-0.00659942626953125,0.002536773681640625,0.0185394287109375,0.01546478271484375,0.0216827392578125,0.0139923095703125,-0.0121612548828125,-0.015869140625,0.005313873291015625,-0.020599365234375,0.02984619140625,-0.031982421875,0.0005679130554199219,-0.021697998046875,-0.0305938720703125,0.027618408203125,0.005340576171875,0.011993408203125,0.0135345458984375,-0.015625,0.036651611328125,-0.0210113525390625,0.0033321380615234375,0.033172607421875,-0.009552001953125,0.0226287841796875,0.01448822021484375,-0.05474853515625,-0.00861358642578125,-0.01513671875,-0.028656005859375,-0.0095977783203125,-0.025146484375,-0.0352783203125,0.03106689453125,-0.00726318359375,0.0157623291015625,0.01319122314453125,-0.005218505859375,-0.0013561248779296875,0.01277923583984375,-0.007328033447265625,0.01486968994140625,-0.05413818359375,-0.022125244140625,-0.015869140625,-0.00917816162109375,0.0186309814453125,-0.00814056396484375,-0.04730224609375,0.01406097412109375,-0.0248260498046875,0.0094757080078125,0.0309600830078125,0.0196533203125,-0.0270843505859375,-0.01113128662109375,-0.0056915283203125,-0.01154327392578125,0.037750244140625,-0.0028896331787109375,-0.00376129150390625,0.03692626953125,0.020416259765625,0.00200653076171875,0.0396728515625,0.004985809326171875,-0.04425048828125,-0.034820556640625,-0.0102386474609375,0.0218505859375,0.003604888916015625,0.00940704345703125,0.01468658447265625,0.0089111328125,-0.0032196044921875,-0.043243408203125,0.015411376953125,-0.00653839111328125,-0.01128387451171875,-0.052734375,0.032684326171875,-0.0101470947265625,-0.018218994140625,-0.003955841064453125,0.007648468017578125,-0.02044677734375,-0.0285186767578125,0.0153350830078125,0.03692626953125,0.0147247314453125,0.01043701171875,0.0007462501525878906,0.0261077880859375,0.024169921875,-0.040283203125,-0.005828857421875,0.00736236572265625,-0.00909423828125,0.00920867919921875,-0.00243377685546875,-0.03204345703125,-0.0232696533203125,0.01131439208984375,-0.0192413330078125,-0.025482177734375,-0.0267333984375,-0.03350830078125,-0.0008440017700195312,-0.040496826171875,0.0281982421875,-0.03533935546875,-0.0005216598510742188,0.061859130859375,0.0439453125,-0.00656890869140625,0.004627227783203125,-0.05615234375,0.027801513671875,-0.0027790069580078125,-0.011322021484375,-0.00841522216796875,0.027191162109375,-0.0018453598022460938,-0.00560760498046875,0.020263671875,-0.0295867919921875,0.03759765625,-0.00951385498046875,0.014190673828125,-0.039764404296875,-0.0199127197265625,-0.007427215576171875,-0.021392822265625,0.00946807861328125,0.03955078125,0.0015478134155273438,0.0227203369140625,0.020843505859375,-0.00531768798828125,0.0087432861328125,-0.01617431640625,0.002574920654296875,0.0104217529296875,0.01215362548828125,0.00970458984375,0.003803253173828125,0.005451202392578125,-0.001972198486328125,-0.01171875,-0.0216217041015625,0.033355712890625,-0.007137298583984375,0.00890350341796875,-0.01293182373046875,0.0189666748046875,-0.0168609619140625,-0.0153350830078125,0.0113525390625,-0.0123443603515625,0.046905517578125,0.0082244873046875,-0.019500732421875,0.004482269287109375,0.01007080078125,0.0037708282470703125,0.053619384765625,0.0171051025390625,-0.0305023193359375,-0.0240478515625,0.007648468017578125,-0.03973388671875,0.00847625732421875,-0.0207061767578125,-0.025115966796875,0.0168914794921875,0.03619384765625,0.00720977783203125,0.00803375244140625,0.022064208984375,-0.01111602783203125,-0.0024890899658203125,0.0047760009765625,-0.02374267578125,-0.0197296142578125,0.0203704833984375,0.00572967529296875,0.0254058837890625,0.0186920166015625,-0.022796630859375,-0.02191162109375,-0.0182952880859375,-0.00365447998046875,-0.01262664794921875,-0.0128326416015625,0.0157318115234375,-0.004596710205078125,0.033843994140625,0.01313018798828125,0.00656890869140625,0.0004596710205078125,-0.020355224609375,0.03411865234375,0.00034546852111816406,0.0205230712890625,0.02960205078125,-0.0157318115234375,-0.051483154296875,-0.0255584716796875,0.039825439453125,0.0258636474609375,0.038238525390625,-0.03424072265625,0.0188140869140625,0.03216552734375,-0.048126220703125,-0.0227203369140625,0.0032215118408203125,-0.0156097412109375,-0.003170013427734375,0.01444244384765625,-0.0232086181640625,0.002437591552734375,0.012451171875,-0.0066680908203125,0.01158905029296875,0.026397705078125,-0.00373077392578125,0.008087158203125,-0.00798797607421875,-0.0173187255859375,-0.013580322265625,0.033660888671875,-0.0028629302978515625,0.046295166015625,0.0299530029296875,-0.0159759521484375,-0.005580902099609375,0.0015277862548828125,0.01123046875,0.0031585693359375,-0.01151275634765625,0.00814056396484375,-0.0369873046875,0.0267181396484375,0.0013856887817382812,0.028656005859375,0.01409149169921875,0.035614013671875,-0.01189422607421875,-0.01190185546875,-0.053619384765625,0.037139892578125,-0.02288818359375,-0.024139404296875,0.01678466796875,-0.01020050048828125,-0.0222930908203125,-0.01059722900390625,0.044525146484375,0.006526947021484375,0.006084442138671875,-0.0015411376953125,-0.040618896484375,0.027801513671875,-0.00839996337890625,-0.01126861572265625,-0.01000213623046875,0.01197052001953125,-0.01062774658203125,-0.0155487060546875,0.011688232421875,0.01044464111328125,-0.0528564453125,0.031005859375,-0.0007734298706054688,8.52346420288086e-6,-0.00894927978515625,-0.005870819091796875,0.04254150390625,-0.03216552734375,0.0215911865234375,-0.01029205322265625,-0.01015472412109375,-0.036285400390625,0.0111083984375,0.0018520355224609375,-0.01177215576171875,0.01256561279296875,-0.004901885986328125,-0.006866455078125,-0.0084381103515625,-0.01160430908203125,-0.044891357421875,0.00632476806640625,0.0015001296997070312,-0.0016727447509765625,-0.013031005859375,-0.01404571533203125,-0.035888671875,-0.013397216796875,-0.0006346702575683594,0.00981903076171875,-0.0134735107421875,-0.022705078125,-0.02606201171875,-0.018402099609375,-0.046966552734375,-0.012542724609375,0.0183563232421875,0.0179901123046875,-0.0225067138671875,0.02801513671875,-0.032379150390625,-0.0079803466796875,0.0070953369140625,0.017333984375,0.026611328125,-0.03778076171875,-0.023590087890625,-0.005245208740234375,0.024383544921875,-0.02105712890625,0.020843505859375,0.033905029296875,0.0225372314453125,0.00942230224609375,0.0005245208740234375,-0.0284881591796875,0.01499176025390625,-0.0124664306640625,-0.0267333984375,0.023040771484375,0.01265716552734375,-0.0026264190673828125,0.00955963134765625,-0.0036773681640625,-0.0394287109375,0.015716552734375,-0.01300048828125,0.0187225341796875,-0.01275634765625,-0.0273590087890625,0.045562744140625,-0.00913238525390625,-0.004268646240234375,-0.005107879638671875,-0.026702880859375,0.0015077590942382812,-0.02862548828125,0.0003228187561035156,0.0099334716796875,-0.0305328369140625,-0.0362548828125,0.0114898681640625,-0.00025653839111328125,-0.0022735595703125,0.0106201171875,0.01090240478515625,0.00992584228515625,0.00998687744140625,-0.00634002685546875,0.00711822509765625,-0.02337646484375,-0.01367950439453125,-0.006389617919921875,-0.006000518798828125,0.01027679443359375,-0.00838470458984375,0.004673004150390625,0.002841949462890625,0.014404296875,-0.02838134765625,0.023834228515625,-0.00823974609375,-0.038970947265625,0.003002166748046875,-0.04510498046875,-0.0265655517578125,-0.0036182403564453125,-0.046661376953125,-0.01062774658203125,-0.05804443359375,-0.02117919921875,-0.029815673828125,0.036712646484375,-0.0069122314453125,0.0079345703125,0.0164794921875,-0.007534027099609375,-0.01111602783203125,0.0135650634765625,-0.0017242431640625,0.009490966796875,-0.0222320556640625,0.043853759765625,0.054718017578125,-0.003208160400390625,-0.004199981689453125,0.01529693603515625,-0.007190704345703125,0.00637054443359375,-0.004749298095703125,-0.0217132568359375,-0.0093841552734375,-0.0335693359375,-0.0017490386962890625,0.0081939697265625,0.0247802734375,0.0148468017578125,0.026763916015625,0.002079010009765625,0.0292816162109375,0.04705810546875,0.02166748046875,-0.0120697021484375,0.01050567626953125,0.0131988525390625,0.0169525146484375,0.0291595458984375,-0.00270843505859375,-0.0095062255859375,-0.0211944580078125,-0.035980224609375,0.006805419921875,0.002735137939453125,0.043731689453125,-0.01515960693359375,0.0010576248168945312,-0.00913238525390625,0.001293182373046875,-0.00027489662170410156,-0.00868988037109375,0.007389068603515625,0.0023212432861328125,-0.01528167724609375,0.017852783203125,-0.03643798828125,0.045623779296875,-0.0030364990234375,-0.0271453857421875,0.0268402099609375,-0.0033473968505859375,0.0186920166015625,-0.0225067138671875,0.0125732421875,-0.01386260986328125,-0.0218658447265625,0.01248931884765625,0.025848388671875,0.021453857421875,0.008056640625,0.025421142578125,0.01224517822265625,0.0208740234375,-0.003856658935546875,-0.021209716796875,-0.00545501708984375,-0.0254058837890625,0.04388427734375,0.0204315185546875,-0.0072174072265625,-0.0110626220703125,0.0007481575012207031,-0.0022411346435546875,-0.046905517578125,-0.028472900390625,0.0196533203125,0.014129638671875,0.0130615234375,-0.01288604736328125,-0.03607177734375,-0.01568603515625,-0.00814056396484375,-0.01499176025390625,0.0112152099609375,-0.00360870361328125,0.024688720703125,-0.0189361572265625,-0.007122039794921875,0.00634002685546875,-0.00626373291015625,-0.000766754150390625,0.0193939208984375,-0.002841949462890625,0.041717529296875,-0.00016701221466064453,-0.043365478515625,-0.023773193359375,0.0283660888671875,0.0245208740234375,-0.055450439453125,0.01096343994140625,-0.0180511474609375,0.0189056396484375,0.0164947509765625,-0.033111572265625,0.0262603759765625,0.0294189453125,0.00084686279296875,0.0279388427734375,-0.003910064697265625,0.002910614013671875,0.00890350341796875,-0.033843994140625,0.004856109619140625,0.00033974647521972656,-0.056549072265625,-0.0110626220703125,-0.0178375244140625,0.006381988525390625,0.018798828125,0.0205230712890625,-0.05609130859375,-0.01023101806640625,-0.001201629638671875,-0.02227783203125,0.01910400390625,0.006931304931640625,0.0017032623291015625,-0.01849365234375,-0.0249786376953125,-0.0176849365234375,0.007389068603515625,-0.01025390625,0.036407470703125,-0.0275421142578125,0.021514892578125,-0.0198822021484375,-0.0189056396484375,-0.0156402587890625,0.01025390625,0.02197265625,-0.007740020751953125,-0.034515380859375,0.0011262893676757812,0.024566650390625,0.0229339599609375,0.004810333251953125,-0.01171875,-0.0238189697265625,0.021392822265625,0.0008301734924316406,0.019378662109375,-0.00894927978515625,-0.01496124267578125,0.01558685302734375,-0.0229339599609375,0.00020587444305419922,-0.0202178955078125,0.0298919677734375,0.00969696044921875,-0.0011949539184570312,-0.007144927978515625,-0.0198211669921875,0.0030422210693359375,-0.037811279296875,-0.039306640625,-0.027587890625,-0.0274810791015625,0.025390625,-0.0333251953125,-0.0062103271484375,-0.016876220703125,0.002651214599609375,-0.0020275115966796875,0.042144775390625,0.013092041015625,0.01690673828125,0.0268707275390625,0.0082244873046875,0.066650390625,0.0053253173828125,0.08526611328125,-0.0146331787109375,-0.0261688232421875,-0.04266357421875,0.004474639892578125,-0.005229949951171875,-0.01806640625,0.00479888916015625,0.00183868408203125,-0.01030731201171875,0.0028285980224609375,-0.0239410400390625,0.0166778564453125,0.0006723403930664062,-0.00923919677734375,-0.00504302978515625,0.0159759521484375,-0.0248260498046875,0.03179931640625,-0.01517486572265625,-0.0006771087646484375,-0.0117645263671875,0.016510009765625,0.00168609619140625,-0.016387939453125,0.0421142578125,-0.00951385498046875,-0.00388336181640625,-0.04559326171875,-0.0194091796875,0.043853759765625,-0.007541656494140625,0.0275421142578125,-0.005645751953125,0.003803253173828125,-0.01438140869140625,0.018218994140625,-0.006381988525390625,-0.012664794921875,-0.011962890625,0.035186767578125,0.0225067138671875,-0.005321502685546875,-0.007659912109375,0.0022792816162109375,-0.00830078125,-0.0092926025390625,-0.0278778076171875,-0.00011402368545532227,0.0027523040771484375,0.0082855224609375,0.0175933837890625,0.0029430389404296875,0.0721435546875,0.01525115966796875,-0.059967041015625,-0.0626220703125,0.0222625732421875,-0.05810546875,-0.01192474365234375,-0.0056610107421875,0.0173492431640625,-0.0008497238159179688,-0.01050567626953125,-0.01558685302734375,0.0032196044921875,0.00745391845703125,-0.05029296875,0.00310516357421875,0.0333251953125,-0.01166534423828125,-0.0347900390625,-0.00830078125,0.01305389404296875,0.01030731201171875,0.017730712890625,-0.007415771484375,-0.00287628173828125,0.01197052001953125,-0.004016876220703125,-0.038421630859375,0.000743865966796875,-0.006237030029296875,0.0511474609375,-0.003826141357421875,-0.00838470458984375,-0.007572174072265625,0.00522613525390625,0.01514434814453125,0.00557708740234375,-0.035186767578125,0.0077056884765625,-0.0330810546875,-0.0043487548828125,-0.0307464599609375,-0.00670623779296875,0.01395416259765625,-0.0247039794921875,-0.03399658203125,0.0176849365234375,-0.00827789306640625,-0.0132293701171875,0.011016845703125,0.00740814208984375,-0.022735595703125,0.01110076904296875,-0.0127105712890625,-0.01074981689453125,-0.04150390625,-0.05438232421875,-0.0014743804931640625,-0.00507354736328125,-0.05291748046875,-0.0126800537109375,0.032135009765625,0.0266571044921875,-0.0240020751953125,-0.0033702850341796875,0.0021076202392578125,0.0206756591796875,0.01454925537109375,-0.00954437255859375,0.0178680419921875,0.004734039306640625,-0.0014028549194335938,0.0109710693359375,-0.0200042724609375,-0.030029296875,0.04022216796875,-0.0190887451171875,0.028594970703125,0.0205841064453125,-0.0028095245361328125,0.0024242401123046875,-0.0151214599609375,0.0025386810302734375,-0.006633758544921875,0.01265716552734375,-0.019073486328125,0.0030384063720703125,-0.024871826171875,-0.01148223876953125,0.00914764404296875,-0.004367828369140625,-0.0186920166015625,0.021514892578125,-0.027435302734375,0.00736236572265625,0.037872314453125,-0.00222015380859375,0.0041351318359375,-0.0224151611328125,-0.0255279541015625,0.03271484375,-0.0242919921875,0.0097198486328125,-0.02008056640625,-0.01003265380859375,-0.0215606689453125,-0.00974273681640625,-0.0428466796875,-0.0343017578125,-0.0006017684936523438,-0.0230865478515625,0.020782470703125,0.01134490966796875,0.0107421875,-0.0165863037109375,-0.0043487548828125,0.0165252685546875,0.0276947021484375,0.0051116943359375,0.03497314453125,0.0288848876953125,0.0205230712890625,-0.0099029541015625,0.0014505386352539062,-0.045074462890625,-0.0226898193359375,0.002422332763671875,0.0013151168823242188,-0.0031642913818359375,-0.0247344970703125,0.013885498046875,-0.002410888671875,0.046051025390625,0.0328369140625,0.04193115234375,0.006710052490234375,-0.004138946533203125,-0.031768798828125,0.024658203125,0.00417327880859375,-0.01116943359375,0.0097198486328125,-0.021270751953125,0.0285491943359375,0.02581787109375,0.0167083740234375,0.0206298828125,0.009185791015625,0.00794219970703125,-0.0022792816162109375,0.004337310791015625,-0.01166534423828125,-0.01227569580078125,0.00905609130859375,0.0156707763671875,-0.04217529296875,0.025054931640625,-0.01058197021484375,0.0171356201171875,0.001369476318359375,0.003917694091796875,-0.00817108154296875,0.026123046875,0.0200042724609375,-0.0294189453125,0.032440185546875,-0.0297393798828125,-0.0109100341796875,-0.00856781005859375,0.0034465789794921875,0.0186920166015625,0.0199737548828125,-0.03558349609375,-0.025146484375,-0.009307861328125,0.0081024169921875,0.0131378173828125,0.0117340087890625,0.0063018798828125,0.0000546574592590332,0.01898193359375,-0.0167694091796875,0.01666259765625,0.0374755859375,0.02374267578125,-0.0103912353515625,0.01207733154296875,-0.032989501953125,-0.004108428955078125,-0.0026798248291015625,0.01166534423828125,0.0257568359375,-0.056732177734375,0.0282745361328125,-0.0034351348876953125,-0.007415771484375,0.0081634521484375,0.029998779296875,0.0019369125366210938,-0.0014734268188476562,0.004573822021484375,0.04296875,0.025665283203125,-0.0121307373046875,0.029266357421875,0.016815185546875,-0.002536773681640625,-0.015045166015625,-0.0211334228515625,0.0020351409912109375,0.008087158203125,-0.004528045654296875,-0.0172882080078125,0.023712158203125,0.0305633544921875,0.0213470458984375,-0.0154266357421875,-0.035675048828125,0.0002543926239013672,0.01149749755859375,0.00833892822265625,0.01506805419921875,0.019500732421875,-0.01265716552734375,0.01947021484375,0.0242767333984375,-0.017486572265625,-0.01294708251953125,-0.012603759765625,-0.0093994140625,-0.00226593017578125,0.020355224609375,-0.0369873046875,0.0166168212890625,0.034332275390625,-0.0240631103515625,-0.03558349609375,0.036376953125,-0.009246826171875,0.0041656494140625,0.0439453125,-0.023284912109375,0.004749298095703125,-0.0232391357421875,-0.0105743408203125,-0.01030731201171875,-0.01318359375,0.0220184326171875,0.005840301513671875,0.0217437744140625,-0.01007080078125,0.01398468017578125,0.0019063949584960938,-0.011383056640625,-0.00424957275390625,-0.0208282470703125,0.012237548828125,0.01526641845703125,0.00959014892578125,0.027191162109375,0.001735687255859375,0.0177154541015625,-0.01139068603515625,0.0218963623046875,0.03814697265625,-0.018951416015625,0.011016845703125,-0.01287078857421875,0.046875,-0.007415771484375,0.01198577880859375,-0.02532958984375,0.00311279296875,0.018524169921875,0.005390167236328125,-0.01435089111328125,0.0018949508666992188,0.0421142578125,0.0045928955078125,-0.006099700927734375,0.007049560546875,0.00502777099609375,-0.00963592529296875,0.00894927978515625,-0.034515380859375,-0.0035114288330078125,-0.0142974853515625,-0.034515380859375,-0.02142333984375,0.017608642578125,-0.014892578125,-0.01244354248046875,-0.017486572265625,0.00013899803161621094,0.00011283159255981445,-0.00756072998046875,-0.0132293701171875,0.0108489990234375,0.0305328369140625,-0.001163482666015625,-0.002880096435546875,-0.0007386207580566406,0.00370025634765625,0.00797271728515625,-0.010528564453125,-0.0073089599609375,-0.0279693603515625,-0.01343536376953125,-0.005908966064453125,-0.0003764629364013672,0.053955078125,0.0237884521484375,-0.053497314453125,-0.01165771484375,-0.037628173828125,0.0099639892578125,-0.02386474609375,0.032958984375,0.0239715576171875,0.0016231536865234375,-0.033111572265625,0.0007448196411132812,0.0245819091796875,-0.0094757080078125,-0.03131103515625,-0.02459716796875,0.021453857421875,0.01398468017578125,-0.0017442703247070312,0.054107666015625,0.0193328857421875,0.0057373046875,0.03485107421875,0.0258636474609375,0.004131317138671875,-0.02239990234375,-0.002368927001953125,0.01102447509765625,-0.017181396484375,0.01454925537109375,-0.0119781494140625,-0.0017871856689453125,-0.0166778564453125,0.008544921875,-0.0135345458984375,-0.03192138671875,0.0030956268310546875,-0.0279083251953125,0.0235595703125,-0.017974853515625,0.0108184814453125,0.0031032562255859375,-0.003093719482421875,-0.014129638671875,0.01361083984375,-0.03619384765625,-0.00826263427734375,0.033477783203125,-0.004150390625,0.0157012939453125,0.0011501312255859375,0.059844970703125,-0.01555633544921875,0.031219482421875,0.0177001953125,-0.0307464599609375,0.01264190673828125,0.0291290283203125,0.01045989990234375,-0.0097503662109375,0.01226806640625,0.00598907470703125,0.01849365234375,-0.02801513671875,-0.0112152099609375,-0.006011962890625,-0.006664276123046875,0.00928497314453125,0.0002186298370361328,-0.0012874603271484375,-0.0233001708984375,-0.0065155029296875,-0.0220947265625,-0.00310516357421875,0.049041748046875,-0.04925537109375,0.0262451171875,-0.0028095245361328125,-0.0091400146484375,0.0240631103515625,-0.002864837646484375,0.0120391845703125,-0.021942138671875,0.0347900390625,0.023834228515625,-0.0134429931640625,0.00028228759765625,0.0277557373046875,0.03082275390625,0.006237030029296875,-0.015350341796875,-0.005039215087890625,0.0145416259765625,0.01226806640625,-0.01474761962890625,-0.004917144775390625,-0.005733489990234375,-0.010986328125,0.0223236083984375,0.0224609375,-0.035736083984375,-0.008544921875,-0.0009150505065917969,-0.0119476318359375,0.0178070068359375,-0.005352020263671875,-0.01558685302734375,-0.0208740234375,-0.0160675048828125,0.0069122314453125,-0.0357666015625,0.01319122314453125,-0.00457000732421875,0.00502777099609375,-0.0006170272827148438,0.0032196044921875,-0.008209228515625,0.0026721954345703125,-0.022705078125,0.01666259765625,-0.0217132568359375,-0.024017333984375,-0.00527191162109375,0.0005908012390136719,0.0028228759765625,-0.0205841064453125,-0.05108642578125,0.02947998046875,-0.00861358642578125,-0.035552978515625,-0.0090484619140625,-0.044464111328125,-0.0284881591796875,0.004901885986328125,0.00669097900390625,0.020538330078125,0.01218414306640625,0.01477813720703125,0.0011930465698242188,0.027587890625,-0.037811279296875,0.0273284912109375,-0.0006680488586425781,0.0179901123046875,0.047393798828125,0.033355712890625,-0.018646240234375,-0.031585693359375,-0.0190887451171875,0.0059051513671875,-0.005916595458984375,0.0247802734375,0.00881195068359375,-0.004108428955078125,-0.0091552734375,0.021697998046875,-0.0207061767578125,0.0207977294921875,-0.048095703125,-0.01544189453125,0.015533447265625,0.0228424072265625,0.0255126953125,-0.0172119140625,-0.0450439453125,0.0005936622619628906,0.0027103424072265625,0.03704833984375,-0.018218994140625,-0.00972747802734375,0.0067901611328125,-0.000598907470703125,-0.00482940673828125,-0.00786590576171875,0.0011510848999023438,0.0364990234375,-0.0128631591796875,-0.0198822021484375,0.0000896453857421875,-0.022735595703125,0.01479339599609375,-0.0034351348876953125,0.0120086669921875,0.0070037841796875,-0.01971435546875,0.04010009765625,0.0034389495849609375,-0.0109100341796875,0.01395416259765625,0.03509521484375,0.01096343994140625,-0.0209808349609375,-0.0009293556213378906,-0.00043487548828125,0.005519866943359375,-0.016448974609375,0.032470703125,0.0284881591796875,0.0144195556640625,-0.0307464599609375,0.0217437744140625,-0.0303497314453125,-0.05926513671875,0.01444244384765625,-0.01264190673828125,0.040313720703125,-0.012603759765625,-0.0178375244140625,-0.04339599609375,0.01222991943359375,-0.0025005340576171875,-0.010406494140625,-0.003086090087890625,-0.0214385986328125,0.01045989990234375,0.005886077880859375,-0.0175933837890625,0.04840087890625,-0.0168914794921875,0.01800537109375,-0.01354217529296875,-0.01383209228515625,0.04083251953125,0.034271240234375,0.021514892578125,0.04022216796875,0.0231781005859375,-0.01110076904296875,-0.0224151611328125,0.0021991729736328125,-0.01206207275390625,-0.01557159423828125,0.0548095703125,0.02618408203125,0.023956298828125,-0.00994110107421875,-0.004299163818359375,0.007030487060546875,-0.0113372802734375,0.0140228271484375,-0.01084136962890625,0.010711669921875,-0.0236358642578125,0.01776123046875,0.04461669921875,-0.0460205078125,-0.012969970703125,0.0078277587890625,-0.040313720703125,-0.004344940185546875,-0.00681304931640625,-0.00937652587890625,0.00601959228515625,-0.0086669921875,0.038238525390625,-0.00726318359375,-0.00667572021484375,-0.0282745361328125,-0.01448822021484375,-0.004566192626953125,0.002193450927734375,0.0408935546875,-0.018951416015625,-0.0347900390625,-0.0038661956787109375,0.0011167526245117188,0.00603485107421875,0.004985809326171875,0.004299163818359375,0.009552001953125,-0.04736328125,0.018310546875,0.004238128662109375,0.028839111328125,-0.02349853515625,0.00798797607421875,0.021270751953125,-0.01384735107421875,-0.02392578125,0.03662109375,0.0032825469970703125,0.056182861328125,-0.007129669189453125,-0.0014019012451171875,0.030426025390625,-0.017974853515625,-0.0118560791015625,0.0104827880859375,-0.0132293701171875,0.01959228515625,-0.0006871223449707031,-0.038055419921875,0.03125,0.01332855224609375,0.0675048828125,0.0005002021789550781,0.0117950439453125,0.0179901123046875,-0.0034618377685546875,-0.029205322265625,0.0136871337890625,-0.01409149169921875,-0.020111083984375,-0.06976318359375,-0.03985595703125,-0.020965576171875,0.002532958984375,-0.000797271728515625,0.00029206275939941406,-0.04278564453125,0.01293182373046875,-0.0178375244140625,-0.01496124267578125,-0.0289154052734375,-0.00551605224609375,-0.0135498046875,-0.0019350051879882812,-0.0008111000061035156,0.032958984375,0.005794525146484375,-0.00988006591796875,0.0147247314453125,0.0008878707885742188,-0.0347900390625,0.04827880859375,0.03656005859375,0.0005245208740234375,0.0078887939453125,0.0218048095703125,0.0177764892578125,0.02093505859375,-0.028656005859375,0.0273284912109375,-0.038818359375,0.01300811767578125,0.0174102783203125,0.01216888427734375,-0.0258941650390625,0.028778076171875,-0.024658203125,0.00337982177734375,-0.00594329833984375,-0.00948333740234375,0.036773681640625,-0.006595611572265625,-0.01033782958984375,0.001506805419921875,-0.03656005859375,-0.0239105224609375,0.041229248046875,-0.04071044921875,-0.0152435302734375,0.0151214599609375,0.037994384765625,-0.01058197021484375,-0.01062774658203125,0.002964019775390625,0.0294189453125,0.01041412353515625,0.038299560546875,-0.036163330078125,-0.036346435546875,-0.00850677490234375,-0.0098876953125,-0.051788330078125,0.02398681640625,-0.0219268798828125,0.023406982421875,0.008941650390625,0.010772705078125,-0.0265960693359375,-0.0099639892578125,-0.00727081298828125,0.0234222412109375,0.0023441314697265625,-0.01409912109375,0.01169586181640625,0.0023250579833984375,-0.0189208984375,-0.01013946533203125,-0.01739501953125,-0.0309295654296875,-0.00823974609375,0.029205322265625,0.01111602783203125,-0.01509857177734375,-0.01160430908203125,0.0173187255859375,0.0169830322265625,-0.00464630126953125,0.0253448486328125,0.0095062255859375,-0.0179443359375,0.0223846435546875,-0.0219879150390625,-0.0004260540008544922,-0.025421142578125,-0.007659912109375,-0.01485443115234375,-0.0166168212890625,0.011444091796875,0.0185394287109375,-0.02984619140625,0.061767578125,0.0189971923828125,-0.016693115234375,0.002613067626953125,-0.01242828369140625,0.0262298583984375,0.029388427734375,-0.0711669921875,-0.0263519287109375,0.01184844970703125,0.00977325439453125,-0.0232696533203125,-0.0131072998046875,0.00910186767578125,0.0251617431640625,0.04644775390625,-0.00033926963806152344,0.00894927978515625,0.01216888427734375,-0.00942230224609375,0.01220703125,0.002918243408203125,0.0167694091796875,0.0286865234375,0.01436614990234375,-0.02581787109375,-0.0123138427734375,-0.0143890380859375,0.0200042724609375,-0.020660400390625,-0.017791748046875,-0.006740570068359375,0.02484130859375,-0.028472900390625,-0.0142364501953125,-0.007534027099609375,0.021697998046875,-0.013580322265625,-0.003910064697265625,0.01214599609375,-0.01267242431640625,-0.005466461181640625,0.0239410400390625,0.01348876953125,0.0171661376953125,-0.00982666015625,-0.009613037109375,0.0189208984375,-0.01146697998046875,-0.01364898681640625,-0.021820068359375,-0.017181396484375,0.0097503662109375,-0.0240478515625,0.031829833984375,0.0172271728515625,0.01308441162109375,0.006938934326171875,0.0212249755859375,-0.007843017578125,-0.041839599609375,0.003757476806640625,-0.01332855224609375,-0.0081024169921875,-0.0252227783203125,0.0125732421875,0.00164794921875,-0.009490966796875,-0.0182647705078125,-0.03497314453125,-0.0187225341796875,-0.001026153564453125,-0.06793212890625,-0.05291748046875,-0.0297393798828125,-0.005031585693359375,-0.026519775390625,-0.00891876220703125,0.0096893310546875,-0.0189056396484375,0.01444244384765625,-0.0270233154296875,-0.0010528564453125,0.006771087646484375,-0.00942230224609375,0.03399658203125,-0.0203094482421875,-0.004795074462890625,0.0025959014892578125,0.01538848876953125,-0.00620269775390625,-0.035675048828125,-0.01142120361328125,0.0011234283447265625,-0.0278778076171875,0.00807952880859375,-0.017547607421875,0.0211639404296875,0.037139892578125,-0.0108642578125,-0.0287017822265625,-0.0008664131164550781,-0.00862884521484375,-0.006320953369140625,-0.00901031494140625,-0.012451171875,0.017913818359375,0.005092620849609375,-0.04345703125,-0.027801513671875,0.023040771484375,0.007328033447265625,-0.013916015625,-0.007678985595703125,-0.0031185150146484375,0.01546478271484375,0.02020263671875,-0.01259613037109375,0.0040130615234375,0.005023956298828125,0.00421142578125,-0.0018835067749023438,0.0369873046875,-0.0006284713745117188,0.007049560546875,-0.0213165283203125,-0.02215576171875,-0.05023193359375,-0.006420135498046875,0.001811981201171875,0.01995849609375,0.007694244384765625,-0.0081329345703125,-0.0347900390625,0.01042938232421875,-0.03131103515625,0.0312042236328125,-0.00971221923828125,-0.0352783203125,0.021209716796875,-0.009490966796875,0.00710296630859375,-0.004848480224609375,-0.01030731201171875,0.0037136077880859375,0.0234222412109375,0.004337310791015625,-0.03436279296875,0.0008835792541503906,-0.036712646484375,0.007740020751953125,0.003978729248046875,-0.0178985595703125,-0.0027065277099609375,0.035491943359375,0.01148223876953125,0.01496124267578125,-0.0025386810302734375,0.014404296875,0.007572174072265625,0.016876220703125,-0.0023212432861328125,0.002727508544921875,-0.005374908447265625,0.01690673828125,-0.020599365234375,-0.00002384185791015625,0.0305328369140625,-0.052734375,0.01496124267578125,0.0039215087890625,-0.00762176513671875,0.031585693359375,-0.01617431640625,-0.01222991943359375,0.00873565673828125,-0.033966064453125,0.01061248779296875,-0.0209197998046875,-0.0198516845703125,0.035247802734375,0.0244598388671875,0.0082550048828125,-0.00787353515625,-0.01544952392578125,0.01302337646484375,-0.0166168212890625,-0.0147247314453125,0.02618408203125,-0.0158233642578125,-0.0394287109375,0.0151214599609375,-0.004146575927734375,-0.035369873046875,0.045928955078125,0.04241943359375,0.01354217529296875,0.0343017578125,-0.007183074951171875,0.0129241943359375,-0.004955291748046875,0.025299072265625,0.01538848876953125,-0.0054779052734375,-0.00630950927734375,-0.010711669921875,0.043914794921875,-0.004856109619140625,0.05169677734375,-0.020111083984375,0.023406982421875,-0.0021114349365234375,-0.039215087890625,-0.01314544677734375,-0.0036773681640625,0.01031494140625,-0.00981903076171875,0.01366424560546875,0.0101776123046875,0.0274658203125,-0.0386962890625,0.0194244384765625,-0.04803466796875,0.033172607421875,0.0269775390625,-0.0176849365234375,-0.0016927719116210938,-0.02783203125,0.0015516281127929688,0.01325225830078125,-0.028472900390625,0.01470947265625,0.036773681640625,-0.038482666015625,-0.0009303092956542969,0.0236053466796875,-0.00498199462890625,0.0165557861328125,0.00003445148468017578,-0.03741455078125,-0.0517578125,-0.0090179443359375,-0.033966064453125,-0.0170440673828125,0.0013637542724609375,-0.04473876953125,-0.059478759765625,-0.0165557861328125,-0.047119140625,-0.033721923828125,0.018890380859375,0.00160980224609375,0.050811767578125,-0.0221099853515625,0.0306396484375,-0.01096343994140625,-0.007175445556640625,0.01580810546875,-0.00650787353515625,-0.00467681884765625,0.0256500244140625,0.006931304931640625,0.00316619873046875,-0.0170745849609375,-0.003265380859375,0.00554656982421875,-0.0166473388671875,0.0006661415100097656,0.0297393798828125,-0.00568389892578125,0.01043701171875,-0.03863525390625,0.01531982421875,0.021087646484375,0.002185821533203125,0.00977325439453125,-0.028594970703125,-0.0166473388671875,-0.00018537044525146484,-0.0014066696166992188,0.014312744140625,0.025299072265625,-0.0149383544921875,0.001495361328125,0.03692626953125,0.00438690185546875,0.05572509765625,-0.00350189208984375,0.0156402587890625,0.005992889404296875,-0.005748748779296875,-0.01739501953125,0.017059326171875,0.0006203651428222656,-0.0163726806640625,-0.0203704833984375,-0.005962371826171875,0.006130218505859375,-0.00022983551025390625,-0.014007568359375,-0.0025844573974609375,-0.0171356201171875,0.0130157470703125,-0.005809783935546875,0.0174560546875,-0.0196075439453125,-0.017486572265625,-0.035369873046875,0.0016012191772460938,-0.02008056640625,-0.0213775634765625,0.04119873046875,-0.0125732421875,-0.00983428955078125,0.01010894775390625,-0.01099395751953125,-0.009613037109375,-0.01091766357421875,0.0032520294189453125,-0.004924774169921875,-0.041656494140625,0.01227569580078125,0.011077880859375,-0.040740966796875,0.002017974853515625,-0.0193023681640625,0.014739990234375,-0.0018491744995117188,0.008636474609375,0.017791748046875,-0.0012598037719726562,-0.004123687744140625,-0.006511688232421875,-0.0179443359375,-0.03619384765625,-0.0009822845458984375,0.0066680908203125,-0.0012950897216796875,0.0031185150146484375,-0.05401611328125,0.0266876220703125,-0.035308837890625,-0.0234375,0.0234222412109375,-0.037384033203125,0.002349853515625,0.01290130615234375,-0.0321044921875,0.019622802734375,-0.052337646484375,-0.00556182861328125,0.005496978759765625,0.0078125,0.010101318359375,-0.0055084228515625,0.021087646484375,0.016754150390625,0.0192413330078125,-0.024261474609375,0.0457763671875,-0.0185394287109375,0.0007729530334472656,0.0173187255859375,0.0224456787109375,0.0283355712890625,0.00576019287109375,0.04150390625,-0.005279541015625,0.01000213623046875,0.01496124267578125,0.003604888916015625,-0.033447265625,0.013824462890625,-0.0014410018920898438,-0.0225067138671875,-0.0017547607421875,0.0235443115234375,0.0171966552734375,0.0234375,-0.00482177734375,-0.0062103271484375,0.01885986328125,-0.003917694091796875,0.0172119140625,0.0240478515625,-0.006069183349609375,-0.0166015625,-0.00955963134765625,-0.01861572265625,0.0198822021484375,-0.046875,-0.0011920928955078125,-0.00972747802734375,0.01349639892578125,-0.00629425048828125,-0.0087738037109375,0.01393890380859375,0.0006022453308105469,-0.007038116455078125,-0.017181396484375,-0.00965118408203125,0.0133514404296875,-0.0025787353515625,0.017547607421875,-0.0276641845703125,0.018890380859375,0.01517486572265625,-0.0311737060546875,-0.016815185546875,0.00264739990234375,-0.0214080810546875,0.0181884765625,-0.01145172119140625,-0.0011072158813476562,0.02880859375,0.00782012939453125,-0.0238037109375,0.039031982421875,-0.00690460205078125,0.0018301010131835938,0.0305023193359375,0.005344390869140625,-0.003803253173828125,-0.033782958984375,0.01241302490234375,0.0206146240234375,0.00766754150390625,0.0177459716796875,-0.002201080322265625,-0.01444244384765625,0.031402587890625,-0.04498291015625,-0.02203369140625,-0.017486572265625,0.031341552734375,0.032562255859375,-0.031951904296875,0.0182037353515625,-0.01207733154296875,0.0235748291015625,0.0391845703125,0.00971221923828125,0.029388427734375,-0.038360595703125,0.025726318359375,-0.0040435791015625,0.020233154296875,0.0009427070617675781,0.0347900390625,-0.0226287841796875,0.01318359375,0.01505279541015625,0.01042938232421875,-0.011749267578125,-0.022705078125,-0.006938934326171875,0.008087158203125,-0.00205230712890625,-0.018463134765625,0.02960205078125,-0.0309600830078125,-0.024749755859375,0.004817962646484375,-0.01258087158203125,0.00850677490234375,-0.00560760498046875,-0.021881103515625,-0.004638671875,0.0244903564453125,-0.020416259765625,0.02655029296875,-0.0226287841796875,0.030029296875,0.024139404296875,0.03497314453125,0.0161285400390625,0.0206756591796875,-0.040924072265625,0.01042938232421875,0.048126220703125,0.006565093994140625,-0.00260162353515625,0.037139892578125,0.0006361007690429688,-0.01007843017578125,0.0282745361328125,-0.013702392578125,0.044525146484375,-0.006237030029296875,0.034637451171875,0.0285186767578125,0.0124053955078125,-0.034423828125,0.0007100105285644531,-0.045501708984375,-0.0219268798828125,-0.00836181640625,-0.03704833984375,-0.07000732421875,0.006748199462890625,-0.0036602020263671875,0.00751495361328125,-0.0162353515625,-0.0137176513671875,0.0227203369140625,0.001644134521484375,-0.028656005859375,-0.00397491455078125,-0.0088043212890625,-0.0007772445678710938,0.035797119140625,0.0389404296875,0.0380859375,-0.005031585693359375,0.0059967041015625,-0.016815185546875,-0.0027980804443359375,0.0127410888671875,0.03399658203125,-0.0003867149353027344,0.00679779052734375,-0.0079193115234375,-0.02294921875,0.023101806640625,0.0009560585021972656,0.042694091796875,-0.031768798828125,-0.00247955322265625,0.0197296142578125,0.0196075439453125,-0.0229339599609375,-0.0250396728515625,-0.0006723403930664062,0.011871337890625,0.0308990478515625,0.002803802490234375,0.003803253173828125,-0.0112762451171875,0.0016689300537109375,-0.040985107421875,0.0175933837890625,0.029083251953125,-0.00962066650390625,-0.0384521484375,-0.006683349609375,0.00439453125,0.0269012451171875,0.02252197265625,-0.027587890625,0.003749847412109375,-0.004119873046875,-0.015228271484375,-0.031036376953125,-0.0042724609375,-0.043853759765625,-0.0016918182373046875,-0.015411376953125,0.03643798828125,-0.03814697265625,0.020599365234375,-0.007030487060546875,-0.02532958984375,-0.0216522216796875,0.0016412734985351562,0.00982666015625,0.0205230712890625,0.02484130859375,0.0078887939453125,-0.0261077880859375,0.0247039794921875,-0.01251983642578125,0.0090789794921875,0.013092041015625,0.0082550048828125,0.006603240966796875,-0.00423431396484375,0.01424407958984375,0.01349639892578125,-0.02264404296875,0.0236358642578125,-0.001506805419921875,0.007030487060546875,-0.01727294921875,-0.0249481201171875,-0.00611114501953125,0.0177459716796875,-0.0077056884765625,0.023773193359375,0.01357269287109375,0.012237548828125,0.0338134765625,-0.029022216796875,0.02880859375,-0.0018472671508789062,-0.024139404296875,-0.032989501953125,0.055084228515625,0.02984619140625,0.040618896484375,0.0006160736083984375,0.03814697265625,0.022552490234375,-0.01071929931640625,0.0250091552734375,0.033782958984375,0.00806427001953125,-0.005443572998046875,-0.00899505615234375,-0.00969696044921875,0.01045989990234375,0.037384033203125,0.01308441162109375,-0.01435089111328125,-0.0032367706298828125,0.0186004638671875,-0.0330810546875,-0.014617919921875,0.01088714599609375,-0.00847625732421875,0.02984619140625,-0.0283355712890625,0.023162841796875,0.019134521484375,-0.01218414306640625,-0.033966064453125,-0.028839111328125,-0.022552490234375,-0.02001953125,0.005214691162109375,-0.01418304443359375,0.0035915374755859375,-0.011993408203125,0.0076751708984375,-0.0098876953125,-0.002002716064453125,-0.0008831024169921875,-0.01294708251953125,-0.05120849609375,0.0008082389831542969,0.0205535888671875,-0.0017843246459960938,0.006366729736328125,0.0137939453125,0.060699462890625,-0.0177459716796875,-0.005641937255859375,0.0170440673828125,0.0026397705078125,0.009857177734375,-0.024658203125,0.006175994873046875,0.04205322265625,0.0253143310546875,0.00972747802734375,0.0031375885009765625,-0.022064208984375,0.0006480216979980469,-0.004180908203125,-0.00794219970703125,-0.015106201171875,-0.00901031494140625,-0.00812530517578125,-0.01406097412109375,-0.0247039794921875,-0.0221405029296875,0.025543212890625,0.037353515625,-0.01702880859375,-0.0021762847900390625,0.0237274169921875,0.016632080078125,-0.0335693359375,0.002178192138671875,-0.022705078125,-0.011810302734375,0.01666259765625,0.0287628173828125,-0.02313232421875,-0.011199951171875,0.026702880859375,-0.0195770263671875,0.0278778076171875,0.0106658935546875,-0.0199432373046875,-0.035919189453125,0.028656005859375,0.0009784698486328125,-0.004291534423828125,-0.0309906005859375,0.03277587890625,0.011260986328125,0.0112457275390625,-0.034698486328125,-0.01111602783203125,0.0309906005859375,0.042236328125],"object":"embedding"}],"model":"nvidia/llama-3.2-nv-embedqa-1b-v2","usage":{"prompt_tokens":10,"total_tokens":10}}

ユーザーのセットアップ

5 minutes

このセクションでは、ワークショップの各参加者用にユーザーを作成し、それぞれに Namespace とリソースクォータを割り当てます。

ユーザーの Namespace とリソースクォータの作成

cd user-setup
./create-namespaces.sh

ユーザーの作成

参加者の認証情報を含む HTPasswd ファイルを作成し、ROSA が管理する HTPasswd IdP をカスタムのものに置き換えます。

./create-users.sh

cluster-admin ユーザーの再作成と再ログイン

cluster-admin ユーザーを再作成し、再度ログインします。

rosa create admin -c rosa-test
oc login <Cluster API URL> --username cluster-admin --password <cluster admin password>

ユーザーへのロールの追加

各ユーザーに自分の Namespace のみへのアクセス権を付与します。

./add-role-to-users.sh

注意: 以下のようなエラーが表示された場合、安全に無視できます。

Warning: User 'participant1' not found
clusterrole.rbac.authorization.k8s.io/admin added: "participant1"

ログインのテスト

OpenShift CLI のインストール

ローカルマシンからログインをテストするには、OpenShift CLI をインストールする必要があります。

MacOS の場合、Homebrew パッケージマネージャーを使用して OpenShift CLI をインストールできます。

brew install openshift-cli

その他のインストールオプションについては、OpenShift のドキュメントを参照してください。

ワークショップユーザーとしてログイン

ローカルマシンからワークショップユーザーの1人としてログインしてみます。

oc login https://api.<cluster-domain>:443 -u participant1 -p 'TempPass123!'

以下のように表示されるはずです。

Login successful.

You have one project on this server: "workshop-participant-1"

LLM へのアクセスの確認

ワークショップユーザーアカウントから LLM にアクセスできることを確認します。

curl コマンドを使用できる Pod を起動します。

oc run curl --rm -it --image=curlimages/curl:latest \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "curl",
        "image": "curlimages/curl:latest",
        "stdin": true,
        "tty": true,
        "command": ["sh"],
        "resources": {
          "limits": {
            "cpu": "50m",
            "memory": "100Mi"
          },
          "requests": {
            "cpu": "50m",
            "memory": "100Mi"
          }
        }
      }]
    }
  }'

次に、以下のコマンドを実行して LLM にプロンプトを送信します。

curl -X "POST" \
 'http://meta-llama-3-2-1b-instruct.nim-service:8000/v1/chat/completions' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
        "model": "meta/llama-3.2-1b-instruct",
        "messages": [
        {
          "content":"What is the capital of Canada?",
          "role": "user"
        }],
        "top_p": 1,
        "n": 1,
        "max_tokens": 1024,
        "stream": false,
        "frequency_penalty": 0.0,
        "stop": ["STOP"]
      }'

{
  "id": "chatcmpl-2ccfcd75a0214518aab0ef0375f8ca21",
  "object": "chat.completion",
  "created": 1758919002,
  "model": "meta/llama-3.2-1b-instruct",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "reasoning_content": null,
        "content": "The capital of Canada is Ottawa.",
        "tool_calls": []
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "total_tokens": 50,
    "completion_tokens": 8,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null
}

OpenTelemetry Collector のインストール

5 minutes

このセクションでは、clusterReceiver のみを有効にした OpenTelemetry Collector をインストールします（ワークショップ参加者は自分の Namespace に独自のエージェントをインストールします）。次に、この Collector のインストールによって作成された ClusterRole を、各ワークショップ参加者の Namespace にバインドします。

OpenTelemetry Collector のインストール

まず、Collector 用の新しいプロジェクトを作成し、そのプロジェクトに切り替えます。

oc new-project admin-otel

Splunk OpenTelemetry Collector for Kubernetes の Helm チャートリポジトリを追加します。

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart

リポジトリが最新であることを確認します。

helm repo update

./admin-otel-collector/admin-otel-collector-values.yaml ファイルを確認します。このファイルを使用して OpenTelemetry Collector をインストールします。

Collector のデータ送信先となる Splunk 環境を設定するための環境変数を設定します。

export CLUSTER_NAME=ai-pod-workshop-admin
export ENVIRONMENT_NAME=ai-pod-workshop-admin
export SPLUNK_ACCESS_TOKEN=<your access token for Splunk Observability Cloud>
export SPLUNK_REALM=<your realm for Splunk Observability Cloud i.e. us0, us1, eu0, etc.>
export SPLUNK_HEC_URL=<HEC endpoint to send logs to Splunk platform i.e. https://<hostname>:443/services/collector/event>
export SPLUNK_HEC_TOKEN=<HEC token to send logs to Splunk platform>
export SPLUNK_INDEX=splunk4rookies-workshop

次に、以下のコマンドを使用して Collector をインストールします。

helm install splunk-otel-collector \
  --set="clusterName=$CLUSTER_NAME" \
  --set="environment=$ENVIRONMENT_NAME" \
  --set="splunkObservability.accessToken=$SPLUNK_ACCESS_TOKEN" \
  --set="splunkObservability.realm=$SPLUNK_REALM" \
  --set="splunkPlatform.endpoint=$SPLUNK_HEC_URL" \
  --set="splunkPlatform.token=$SPLUNK_HEC_TOKEN" \
  --set="splunkPlatform.index=$SPLUNK_INDEX" \
  -f ./admin-otel-collector/admin-otel-collector-values.yaml \
  -n admin-otel \
  splunk-otel-collector-chart/splunk-otel-collector

以下のコマンドを実行して、すべての Collector Pod が実行中であることを確認します。

oc get pods -n admin-otel

NAME                                                          READY   STATUS    RESTARTS   AGE
splunk-otel-collector-k8s-cluster-receiver-7b7f5cdc5b-rhxsj   1/1     Running   0          6m40s

各ワークショップ参加者のサービスアカウント作成と ClusterRole へのバインド

for i in {1..30}; do
  ns="workshop-participant-$i"

  oc get ns "$ns" >/dev/null 2>&1 || continue
  oc -n "$ns" create sa splunk-otel-collector 2>/dev/null || true

  oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: splunk-otel-collector-${ns}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: splunk-otel-collector
subjects:
- kind: ServiceAccount
  name: splunk-otel-collector
  namespace: ${ns}
EOF
done

また、各 Namespace の ServiceAccount に SecurityContextConstraint（SCC）を付与する必要があります。

for i in {1..30}; do
  ns="workshop-participant-$i"
  oc get ns "$ns" >/dev/null 2>&1 || continue
  oc -n "$ns" adm policy add-scc-to-user splunk-otel-collector -z splunk-otel-collector
done

ベクターデータベースのデプロイ

10 minutes

このステップでは、OpenShift クラスターにベクターデータベースをデプロイし、ワークショップ参加者が使用するテストデータを投入します。

ベクターデータベースのデプロイ

このワークショップでは、オープンソースのベクターデータベースである Weaviate をデプロイします。

まず、Weaviate の Helm チャートを含む Weaviate Helm リポジトリを追加します。

helm repo add weaviate https://weaviate.github.io/weaviate-helm
helm repo update

weaviate/weaviate-values.yaml ファイルには、Weaviate ベクターデータベースのデプロイに使用する設定が含まれています。

Weaviate が Prometheus receiverでスクレイピングできるメトリクスを公開するように、以下の環境変数を TRUE に設定しています。

  PROMETHEUS_MONITORING_ENABLED: true
  PROMETHEUS_MONITORING_GROUP: true

追加のカスタマイズオプションについては、Weaviate のドキュメントを参照してください。

新しい Namespace を作成します。

oc create namespace weaviate

以下のコマンドを実行して、Weaviate が特権コンテナを実行できるようにします。

注意: この方法は本番環境では推奨されません。

oc adm policy add-scc-to-user privileged -z default -n weaviate

次に、Weaviate をデプロイします。

helm upgrade --install \
  "weaviate" \
  weaviate/weaviate \
  --namespace "weaviate" \
  --values ./weaviate/weaviate-values.yaml

ベクターデータベースへのデータ投入

Weaviate が起動したので、ワークショップでカスタムアプリケーションと共に使用するデータを追加します。

この作業に使用するアプリケーションは、LangChain Playbook for NeMo Retriever Text Embedding NIM に基づいています。

./load-embeddings/k8s-job.yaml の設定に従い、NVIDIA H200 Tensor Core GPU のデータシートをベクターデータベースにロードします。

このドキュメントには、大規模言語モデルが学習していない NVIDIA H200 GPU に関する情報が含まれています。ワークショップの次のパートでは、ベクターデータベースにロードされたこのドキュメントのコンテキストを使用して、LLM が質問に回答するアプリケーションを構築します。

OpenShift クラスターに Kubernetes Job をデプロイしてエンベディングをロードします。このプロセスが1回だけ実行されるようにするために、Pod ではなく Kubernetes Job を使用します。

oc create namespace llm-app
oc apply -f ./load-embeddings/k8s-job.yaml

注意: エンベディングを Weaviate にロードする Python アプリケーションの Docker イメージをビルドするために、以下のコマンドを実行しました。
cd workshop/cisco-ai-pods/load-embeddings
docker build --platform linux/amd64 -t derekmitchell399/load-embeddings:1.0 .
docker push derekmitchell399/load-embeddings:1.0

Portworx メトリクスエンドポイントのデプロイ

10 minutes

このステップでは、Portworx メトリクスエンドポイントを模倣する Python サービスをデプロイします。これはワークショップで Pure Storage のモニタリングを設定する際に使用します。

Portworx メトリクスエンドポイントのデプロイ

以下のコマンドを実行して、Portworx メトリクスエンドポイントサービスをデプロイします。

oc new-project portworx
oc apply -f ./portworx/k8s.yaml -n portworx

Portworx メトリクスエンドポイントのテスト

Portworx メトリクスエンドポイントが期待通りに動作していることを確認します。

curl コマンドを使用できる Pod を起動します。

oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh

次に、以下のコマンドを実行してエンドポイントにリクエストを送信します。

curl http://portworx-metrics-sim.portworx:17001/metrics

# HELP px_cluster_cpu_percent Percentage of CPU Used
# TYPE px_cluster_cpu_percent gauge
px_cluster_cpu_percent{cluster="ocp-pxclus-32430549-ad99-4839-bf9b-d6beb8ddc2d6",clusterUUID="e870909b-6150-4d72-87cb-a012630e42ae",node="worker2.flashstack.local",nodeID="f63312a2-0884-4878-be4e-51935613aa80"} 1.91
...

クリーンアップ

5 minutes

クリーンアップ手順

ワークショップが完了したら、このセクションの手順に従って OpenShift クラスターをアンインストールします。

以下のコマンドを実行して、クラスター ID、クラスター固有の Operator ロールの Amazon Resource Names（ARN）、および OIDC プロバイダーのエンドポイント URL を取得します。

rosa describe cluster --cluster=$CLUSTER_NAME

以下のコマンドを使用してクラスターを削除します。

rosa delete cluster --cluster=$CLUSTER_NAME --watch

クラスター固有の Operator IAM ロールを削除します。

注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。

rosa delete operator-roles --prefix $OPERATOR_ROLES_PREFIX

OIDC プロバイダーを削除します。

注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。

rosa delete oidc-provider --oidc-config-id $OIDC_ID

ネットワークを削除します。

注意: 以下のコマンドを実行する前に、ネットワークの作成に使用した CloudFormation スタックの名前を追加してください。

aws cloudformation delete-stack --region $AWS_REGION --stack-name <stack name i.e. rosa-network-stack-nnnnnnnnnnn>

AWS アカウントから Red Hat OpenShift Service を完全に削除したい場合は、OpenShift のドキュメントを参照してください。

ワークショップ

このセクションには、ワークショップ参加者が実行する手順が含まれています：

Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイを練習します。
インフラストラクチャメトリクスを取り込むために、コレクターに Prometheus receiverを追加する練習をします。
クラスター内の Weaviate ベクトルデータベースのモニタリングを練習します。
Prometheus を使用した Pure Storage メトリクスの収集を練習します。
大規模言語モデル（LLM）と連携する Python サービスを OpenTelemetry でインストルメントする練習をします。
LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。

ワークショップ環境の概要

5 minutes

Cisco の AI 対応 POD は、最先端のハードウェアとソフトウェアを組み合わせて、堅牢でスケーラブルかつ効率的な AI インフラストラクチャを提供します。 Splunk Observability Cloud は、インフラストラクチャからアプリケーションコンポーネントまで、このスタック全体に対する包括的な可視性を提供します。

このハンズオンワークショップでは、OpenTelemetry と Prometheus を使用して AI インフラストラクチャをモニタリングする方法を学びます。実際の Cisco AI POD へのアクセスは不要です。現実的な環境でモニタリング技術のデプロイと設定に関する実践的な経験を得ることができます。

ラボ環境

このワークショップでは、AWS 上で動作する共有の OpenShift クラスター を使用します。このクラスターには NVIDIA GPU と NVIDIA AI Enterprise ソフトウェアが搭載されています。

デプロイ済みのインフラストラクチャ

ワークショップの講師が、以下の共有コンポーネントをワークショップ環境にデプロイ済みです。

NVIDIA NIM モデル:
- meta/llama-3.2-1b-instruct - ユーザーのプロンプトを処理
- nvidia/llama-3.2-nv-embedqa-1b-v2 - エンベディングを生成
Weaviate - セマンティック検索と検索取得のためのベクトルデータベース
Prometheus exporter - 本番環境の AI POD で一般的な Pure Storage メトリクスをシミュレート

ワークスペース

各参加者は共有クラスター内の専用 Namespace を割り当てられ、独立した作業のための隔離された環境が確保されます。

ワークショップの内容

ワークショップ中、各参加者は以下のタスクを実行します。

自分の Namespace に OpenTelemetry Collector をデプロイおよび設定する
クラスターインフラストラクチャとのオブザーバビリティデータ収集を統合する
NVIDIA NIM モデルを活用する Python アプリケーション をデプロイする
Splunk Observability Cloud を使用してアプリケーションのパフォーマンスとインフラストラクチャメトリクスをモニタリングする

Prometheus とは

Prometheus は通常、ストレージとアラートに使用されるフルスタックモニタリングシステムを指しますが、このワークショップでは Prometheus エコシステムのデータ標準に焦点を当てます。

このワークショップでは Prometheus Exporter を活用します。これは、コンポーネントの内部ヘルスを標準化されたメトリクスエンドポイント（例: http://localhost:9100/metrics）に変換する小さなユーティリティです。

フル構成の Prometheus サーバーを使用してこのデータを収集する代わりに、OpenTelemetry Collector を使用します。Prometheus receiver を使用することで、Collector はこれらのエンドポイントを スクレイプ でき、広くサポートされている業界フォーマットを使用してリッチなテレメトリデータを収集できます。

OpenShift クラスターへの接続

5 minutes

EC2 インスタンスへの接続

各参加者用に AWS/EC2 上に Ubuntu Linux インスタンスを用意しています。

講師から提供された IP アドレスとパスワードを使用して、以下のいずれかの方法で EC2 インスタンスに接続します。

Mac OS / Linux
- ssh splunk@IP address
Windows 10+
- OpenSSH クライアントを使用
それ以前のバージョンの Windows
- Putty を使用

ワークショップ参加者番号の設定

講師が各参加者に 1 から 30 までの番号を割り当てます。この番号を環境変数に保存してください。ワークショップ全体を通して使用するため、番号を覚えておいてください。

export PARTICIPANT_NUMBER=<your participant number>

OpenShift CLI のインストール

OpenShift クラスターにアクセスするために、OpenShift CLI をインストールする必要があります。

以下のコマンドを使用して、OpenShift CLI バイナリを EC2 インスタンスに直接ダウンロードします。

curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz

コンテンツを展開します。

tar -xvzf openshift-client-linux.tar.gz

生成されたファイル（oc と kubectl）を、パスに含まれている場所に移動します。例えば以下のようにします。

sudo mv oc /usr/local/bin/oc
sudo mv kubectl /usr/local/bin/kubectl

OpenShift クラスターへの接続

Kube config ファイルが splunk ユーザーによって変更可能であることを確認します。

chmod 600 /home/splunk/.kube/config

ワークショップ主催者から提供されたクラスター API URL とパスワードを使用して、OpenShift クラスターにログインします。

oc login https://api.<cluster-domain>:443 -u participant$PARTICIPANT_NUMBER -p '<password>'

OpenShift クラスターに接続されていることを確認します。

oc whoami --show-server

https://api.***.openshiftapps.com:443

OpenTelemetry Collector のデプロイ

10 minutes

このセクションでは、OpenShift の Namespace に OpenTelemetry Collector をデプロイします。 Collector は、クラスター内で動作するインフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、結果のデータを Splunk Observability Cloud に送信します。

OpenTelemetry Collector のデプロイ

Helm がインストールされていることを確認する

以下のコマンドを実行して、Helm がインストールされていることを確認します。

helm version

version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37d847793e", GitTreeState:"clean", GoVersion:"go1.24.11"}

インストールされていない場合は、以下のコマンドを実行します。

sudo apt-get install curl gpg apt-transport-https --yes
curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

Splunk OpenTelemetry Collector Helm Chart の追加

Splunk OpenTelemetry Collector for Kubernetes の Helm chart リポジトリを追加します。

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart

リポジトリが最新であることを確認します。

helm repo update

環境変数の設定

Collector がデータを送信する Splunk 環境を設定するための環境変数を設定します。

export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
export CLUSTER_NAME=ai-pod-$USER_NAME
export ENVIRONMENT_NAME=ai-pod-$USER_NAME
export SPLUNK_INDEX=splunk4rookies-workshop

環境名が設定されていることを確認します：

echo $ENVIRONMENT_NAME

ai-pod-workshop-participant-1

Collector のデプロイ

ワークショップディレクトリに移動します。

cd ~/workshop/cisco-ai-pods

以下のコマンドを使用して、自分の Namespace に Collector をインストールします。

{ [ -z "$CLUSTER_NAME" ] || \
  [ -z "$ENVIRONMENT_NAME" ] || \
  [ -z "$USER_NAME" ]; } && \
  echo "Error: Missing variables" || \
  helm upgrade --install splunk-otel-collector \
  --set="clusterName=$CLUSTER_NAME" \
  --set="environment=$ENVIRONMENT_NAME" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.index=$SPLUNK_INDEX" \
  -f ./otel-collector/otel-collector-values.yaml \
  -n $USER_NAME \
  splunk-otel-collector-chart/splunk-otel-collector

注意: Missing variables というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を追加してください:
export PARTICIPANT_NUMBER=<your participant number>
export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
export CLUSTER_NAME=ai-pod-$USER_NAME
export ENVIRONMENT_NAME=ai-pod-$USER_NAME
export SPLUNK_INDEX=splunk4rookies-workshop

以下のコマンドを実行して、Collector の Pod が実行中であることを確認します。

watch -n 1 oc get pods

NAME                                                          READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-58rwm                             1/1     Running   0          6m40s
splunk-otel-collector-agent-8dndr                             1/1     Running   0          6m40s

注意: OpenShift 環境では、Collector が起動して Running 状態に移行するまで約 3 分かかります。

Splunk Observability Cloud で Collector データを確認する

Splunk Observability Cloud で自分のクラスターが表示されることを確認します。Infrastructure Monitoring -> Kubernetes -> Kubernetes Clusters に移動し、k8s.cluster.name にクラスター名（例: ai-pod-workshop-participant-1）でフィルターを追加します。

NVIDIA コンポーネントのモニタリング

10 minutes

このセクションでは、OpenTelemetry Collector で Prometheus receiverを使用して、OpenShift クラスターで動作している NVIDIA コンポーネントをモニタリングします。まず、Collector の設定ファイルが保存されているディレクトリに移動します。

cd otel-collector

NVIDIA DCGM Exporter メトリクスの取得

NVIDIA DCGM exporter は OpenShift クラスターで動作しています。これは Splunk に送信できる GPU メトリクスを公開します。

これを行うために、Collector のデプロイ時に使用した otel-collector-values.yaml ファイルを編集して、Collector の設定をカスタマイズしましょう。

kubeletstats receiverの直下に、以下の内容を追加します。

      receiver_creator/nvidia:
        # Name of the extensions to watch for endpoints to start and stop.
        watch_observers: [ k8s_observer ]
        receivers:
          prometheus/dcgm:
            config:
              config:
                scrape_configs:
                  - job_name: gpu-metrics
                    scrape_interval: 60s
                    static_configs:
                      - targets:
                          - '`endpoint`:9400'
            rule: type == "pod" && labels["app"] == "nvidia-dcgm-exporter"

これにより、Collector は app=nvidia-dcgm-exporter というラベルを持つ Pod を検索します。このラベルを持つ Pod が見つかると、その Pod のポート 9400 に接続し、デフォルトのメトリクスエンドポイント（/v1/metrics）をスクレイプします。

なぜ Prometheus receiverだけでなく receiver_creator receiverを使用するのでしょうか?
Prometheus receiverは、事前に定義されたエンドポイントからメトリクスをスクレイプする静的な設定を使用します。
receiver_creator receiverは、ランタイム情報に基づいてreceiver（Prometheus receiverを含む）を動的に作成でき、スケーラブルで柔軟なスクレイプ設定を可能にします。
receiver_creator を使用すると、動的な環境で複数の Prometheus スクレイプターゲットの管理を自動化し、設定を簡素化できます。

この新しいreceiverが使用されるようにするために、otel-collector-values.yaml ファイルに新しいパイプラインも追加する必要があります。

以下のコードをファイルの末尾に追加します。

    service:
      pipelines:
        metrics/nvidia-metrics:
          exporters:
            - signalfx
          processors:
            - memory_limiter
            - batch
            - resourcedetection
            - resource
          receivers:
            - receiver_creator/nvidia

次のセクションで、NVIDIA に関連するもう 1 つの Prometheus receiverを追加します。

NVIDIA NIM メトリクスの取得

meta-llama-3-2-1b-instruct 大規模言語モデルは、NVIDIA NIM を使用して OpenShift クラスターにデプロイされました。Collector でスクレイプできる Prometheus エンドポイントが含まれています。以下を otel-collector-values.yaml ファイルの、先ほど追加した prometheus/dcgm receiverの直下に追加しましょう。

          prometheus/nim-llm:
            config:
              config:
                scrape_configs:
                  - job_name: nim-for-llm-metrics
                    scrape_interval: 60s
                    metrics_path: /v1/metrics
                    static_configs:
                      - targets:
                          - '`endpoint`:8000'
            rule: type == "pod" && labels["app"] == "meta-llama-3-2-1b-instruct"

これにより、Collector は app=meta-llama-3-2-1b-instruct というラベルを持つ Pod を検索します。このラベルを持つ Pod が見つかると、その Pod のポート 8000 に接続し、/v1/metrics メトリクスエンドポイントをスクレイプします。

このreceiverは receiver_creator/nvidia receiverの一部として既に取得されるため、パイプラインを変更する必要はありません。

filter processorの追加

Prometheus エンドポイントのスクレイプは、大量のメトリクスを生成することがあり、カーディナリティが高くなる場合があります。

Splunk に送信するメトリクスを正確に定義する filter processor を追加しましょう。具体的には、ダッシュボードのチャートまたはアラートディテクターで使用されているメトリクスのみを送信します。

以下のコードを otel-collector-values.yaml ファイルの、exporters セクションの後、receivers セクションの前に追加します。

    processors:
      filter/metrics_to_be_included:
        metrics:
          # Include only metrics used in charts and detectors
          include:
            match_type: strict
            metric_names:
              - DCGM_FI_DEV_FB_FREE
              - DCGM_FI_DEV_FB_USED
              - DCGM_FI_DEV_GPU_TEMP
              - DCGM_FI_DEV_GPU_UTIL
              - DCGM_FI_DEV_MEM_CLOCK
              - DCGM_FI_DEV_MEM_COPY_UTIL
              - DCGM_FI_DEV_MEMORY_TEMP
              - DCGM_FI_DEV_POWER_USAGE
              - DCGM_FI_DEV_SM_CLOCK
              - DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION
              - DCGM_FI_PROF_DRAM_ACTIVE
              - DCGM_FI_PROF_GR_ENGINE_ACTIVE
              - DCGM_FI_PROF_PCIE_RX_BYTES
              - DCGM_FI_PROF_PCIE_TX_BYTES
              - DCGM_FI_PROF_PIPE_TENSOR_ACTIVE
              - generation_tokens_total
              - go_info
              - go_memstats_alloc_bytes
              - go_memstats_alloc_bytes_total
              - go_memstats_buck_hash_sys_bytes
              - go_memstats_frees_total
              - go_memstats_gc_sys_bytes
              - go_memstats_heap_alloc_bytes
              - go_memstats_heap_idle_bytes
              - go_memstats_heap_inuse_bytes
              - go_memstats_heap_objects
              - go_memstats_heap_released_bytes
              - go_memstats_heap_sys_bytes
              - go_memstats_last_gc_time_seconds
              - go_memstats_lookups_total
              - go_memstats_mallocs_total
              - go_memstats_mcache_inuse_bytes
              - go_memstats_mcache_sys_bytes
              - go_memstats_mspan_inuse_bytes
              - go_memstats_mspan_sys_bytes
              - go_memstats_next_gc_bytes
              - go_memstats_other_sys_bytes
              - go_memstats_stack_inuse_bytes
              - go_memstats_stack_sys_bytes
              - go_memstats_sys_bytes
              - go_sched_gomaxprocs_threads
              - gpu_cache_usage_perc
              - gpu_total_energy_consumption_joules
              - http.server.active_requests
              - num_request_max
              - num_requests_running
              - num_requests_waiting
              - process_cpu_seconds_total
              - process_max_fds
              - process_open_fds
              - process_resident_memory_bytes
              - process_start_time_seconds
              - process_virtual_memory_bytes
              - process_virtual_memory_max_bytes
              - promhttp_metric_handler_requests_in_flight
              - promhttp_metric_handler_requests_total
              - prompt_tokens_total
              - python_gc_collections_total
              - python_gc_objects_collected_total
              - python_gc_objects_uncollectable_total
              - python_info
              - request_finish_total
              - request_success_total
              - system.cpu.time
              - e2e_request_latency_seconds
              - time_to_first_token_seconds
              - time_per_output_token_seconds
              - request_prompt_tokens
              - request_generation_tokens

先ほど追加した metrics/nvidia-metrics パイプラインに filter/metrics_to_be_included processorが含まれていることを確認します。

    service:
      pipelines:
        metrics/nvidia-metrics:
          exporters:
            - signalfx
          processors:
            - memory_limiter
            - filter/metrics_to_be_included
            - batch
            - resourcedetection
            - resource
          receivers:
            - receiver_creator/nvidia

変更の確認

修正した otel-collector-values.yaml ファイルの内容を otel-collector-values-with-nvidia.yaml ファイルと比較してください。yaml ファイルではインデントが重要であり、正確である必要があることを忘れないでください。

diff otel-collector-values.yaml otel-collector-values-with-nvidia.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

ベクターデータベースのモニタリング

5 minutes

このステップでは、Weaviate ベクターデータベースをモニタリングするために Prometheus receiverを設定します。

ベクターデータベースとは？

ベクターデータベース は、テキストや画像などの情報の 意味的な意味 を捉えた数値的な「ベクター埋め込み」としてデータを保存し、インデックス化します。従来のデータベースとは異なり、完全一致ではなく概念的に関連するデータポイントを見つける 類似性検索 に優れています。

ベクターデータベースはどのように使用されるのか？

ベクターデータベースは、Large Language Models（LLM）を活用するアプリケーションで広く使用されている Retrieval Augmented Generation（RAG） と呼ばれるパターンにおいて重要な役割を果たします。

パターンは以下の通りです：

エンドユーザーがアプリケーションに質問します
アプリケーションはその質問を受け取り、ベクター埋め込みを計算します
アプリケーションは類似性検索を実行し、ベクターデータベース内の関連ドキュメントを探します
アプリケーションは元の質問と関連ドキュメントをコンテキストとして LLM に送信します
LLM はコンテキストを確認し、アプリケーションにレスポンスを返します

Prometheus で Weaviate メトリクスを取得する

OpenTelemetry Collector の設定を変更して、Weaviate の Prometheus メトリクスをスクレイプしましょう。

otel-collector-values.yaml ファイルに追加の Prometheus receiverクリエーターセクションを追加します。receiver_creator/nvidia セクションの後、pipelines セクションの前に追加してください：

      receiver_creator/weaviate:
        # Name of the extensions to watch for endpoints to start and stop.
        watch_observers: [ k8s_observer ]
        receivers:
          prometheus/weaviate:
            config:
              config:
                scrape_configs:
                  - job_name: weaviate-metrics
                    scrape_interval: 60s
                    static_configs:
                      - targets:
                          - '`endpoint`:2112'
            rule: type == "pod" && labels["app"] == "weaviate"

Weaviate のメトリクスが filter/metrics_to_be_included filter processorの設定にも追加されていることを確認する必要があります：

    processors:
      filter/metrics_to_be_included:
        metrics:
          # Include only metrics used in charts and detectors
          include:
            match_type: strict
            metric_names:
              - DCGM_FI_DEV_FB_FREE
              - ...
              - object_count
              - vector_index_size
              - vector_index_operations
              - vector_index_tombstones
              - vector_index_tombstone_cleanup_threads
              - vector_index_tombstone_cleanup_threads
              - requests_total
              - objects_durations_ms_sum
              - objects_durations_ms_count
              - batch_delete_durations_ms_sum
              - batch_delete_durations_ms_count

注意: object_count から始まる新しいメトリクスのみを追加してください。

また、設定ファイルに Resource processorを追加します。filter/metrics_to_be_included processorの後、receivers セクションの前に以下の設定を追加してください：

      resource/weaviate:
        attributes:
          - key: weaviate.instance.id
            from_attribute: service.instance.id
            action: insert

このprocessorは、Weaviate メトリクスの service.instance.id プロパティを取得し、weaviate.instance.id という新しいプロパティにコピーします。これにより、Splunk Observability Cloud で標準的な OpenTelemetry プロパティとして使用される service.instance.id を持つ他のメトリクスと、Weaviate メトリクスをより簡単に区別できるようになります。

Weaviate メトリクス用の新しいメトリクスパイプラインも追加する必要があります（Weaviate 以外のメトリクスに weaviate.instance.id メトリクスが追加されないように、別のパイプラインを使用する必要があります）。以下をファイルの末尾に追加してください：

        metrics/weaviate:
          exporters:
            - signalfx
          processors:
            - memory_limiter
            - filter/metrics_to_be_included
            - resource/weaviate
            - batch
            - resourcedetection
            - resource
          receivers:
            - receiver_creator/weaviate

変更した otel-collector-values.yaml ファイルの内容を otel-collector-values-with-weaviate.yaml ファイルと比較してください。yaml ファイルではインデントが重要であり、正確である必要があることを忘れないでください：

diff otel-collector-values.yaml otel-collector-values-with-weaviate.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

ストレージのモニタリング

5 minutes

このステップでは、ストレージをモニタリングするために Prometheus receiverを設定します。

Cisco AI PODs はどのようなストレージを使用しているか？

Cisco AI PODs には、Pure Storage、VAST、NetApp など、さまざまなストレージオプションがあります。

このワークショップでは Pure Storage に焦点を当てます。

Pure Storage メトリクスをどのように取得するか？

Pure Storage を使用する Cisco AI PODs は、Kubernetes に永続ストレージを提供する Portworx というテクノロジーも使用しています。

Portworx には Prometheus receiverでスクレイプできるメトリクスエンドポイントがあります。

Prometheus でストレージメトリクスを取得する

OpenTelemetry Collector の設定を変更して、Prometheus receiverで Portworx メトリクスをスクレイプしましょう。

otel-collector-values.yaml ファイルに追加の Prometheus receiver creatorセクションを追加します。receiver_creator/weaviate セクションの後、pipelines セクションの前に追加してください：

      receiver_creator/storage:
        # Name of the extensions to watch for endpoints to start and stop.
        watch_observers: [ k8s_observer ]
        receivers:
          prometheus/portworx:
            config:
              config:
                scrape_configs:
                  - job_name: portworx-metrics
                    static_configs:
                      - targets:
                          - '`endpoint`:17001'
                          - '`endpoint`:17018'
            rule: type == "pod" && labels["app"] == "portworx-metrics-sim"

Portworx メトリクスが filter/metrics_to_be_included filter processorの設定にも追加されていることを確認する必要があります：

    processors:
      filter/metrics_to_be_included:
        metrics:
          # Include only metrics used in charts and detectors
          include:
            match_type: strict
            metric_names:
              - DCGM_FI_DEV_FB_FREE
              - ...
              - px_cluster_cpu_percent
              - px_cluster_disk_total_bytes
              - px_cluster_disk_utilized_bytes
              - px_cluster_status_nodes_offline
              - px_cluster_status_nodes_online
              - px_volume_read_latency_seconds
              - px_volume_reads_total
              - px_volume_readthroughput
              - px_volume_write_latency_seconds
              - px_volume_writes_total
              - px_volume_writethroughput

注意: px_cluster_cpu_percent から始まる新しいメトリクスのみを追加してください。

Portworx メトリクス用の新しいメトリクスパイプラインも追加する必要があります。以下をファイルの末尾に追加してください：

        metrics/storage:
          exporters:
            - signalfx
          processors:
            - memory_limiter
            - filter/metrics_to_be_included
            - batch
            - resourcedetection
            - resource
          receivers:
            - receiver_creator/storage

変更した otel-collector-values.yaml ファイルの内容を otel-collector-values-with-portworx.yaml ファイルと比較してください。yaml ファイルではインデントが重要であり、正確である必要があることを忘れないでください：

diff otel-collector-values.yaml otel-collector-values-with-portworx.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

AI POD ダッシュボードの確認

10 minutes

このセクションでは、Splunk Observability Cloud の AI POD ダッシュボードを確認し、NVIDIA、Pure Storage、および Weaviate からのデータが期待通りに取得されていることを確認します。

OpenTelemetry Collector の設定を更新する

以下の Helm コマンドを実行して、Collector の設定変更を適用できます：

{ [ -z "$CLUSTER_NAME" ] || \
  [ -z "$ENVIRONMENT_NAME" ] || \
  [ -z "$USER_NAME" ]; } && \
  echo "Error: Missing variables" || \
  helm upgrade splunk-otel-collector \
  --set="clusterName=$CLUSTER_NAME" \
  --set="environment=$ENVIRONMENT_NAME" \
  --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
  --set="splunkObservability.realm=$REALM" \
  --set="splunkPlatform.endpoint=$HEC_URL" \
  --set="splunkPlatform.token=$HEC_TOKEN" \
  --set="splunkPlatform.index=$SPLUNK_INDEX" \
  -f ./otel-collector-values.yaml \
  -n $USER_NAME \
  splunk-otel-collector-chart/splunk-otel-collector

注意: Missing variables というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を追加してください：
export PARTICIPANT_NUMBER=<your participant number>
export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
export CLUSTER_NAME=ai-pod-$USER_NAME
export ENVIRONMENT_NAME=ai-pod-$USER_NAME
export SPLUNK_INDEX=splunk4rookies-workshop

AI POD 概要ダッシュボードタブの確認

Splunk Observability Cloud で Dashboards に移動し、Built-in dashboard groups に含まれている Cisco AI PODs Dashboard を検索してください。ダッシュボードが OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです：

Pure Storage ダッシュボードタブの確認

PURE STORAGE タブに移動し、ダッシュボードが OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです：

Weaviate Infrastructure Navigator の確認

Weaviate は AI POD にデフォルトで含まれていないため、すぐに使える AI POD ダッシュボードには含まれていません。代わりに、Infrastructure Navigator の1つを使用して Weaviate のパフォーマンスデータを確認できます。

Splunk Observability Cloud で Infrastructure -> AI Frameworks -> Weaviate に移動してください。対象の k8s.cluster.name でフィルタリングし、以下の例のように Navigator が表示されていることを確認してください：

LLM アプリケーションの確認

15 minutes

ワークショップの最後のステップでは、instruct モデルと embeddings モデルを使用するアプリケーションを OpenShift クラスターにデプロイします。

LangChain とは？

LLM とやり取りするほとんどのアプリケーションと同様に、このアプリケーションは Python で書かれています。また、LLM を活用したアプリケーションの開発を簡素化するオープンソースのオーケストレーションフレームワークである LangChain を使用しています。

アプリケーション概要

LLM への接続

アプリケーションはまず、使用する2つの LLM に接続します：

meta/llama-3.2-1b-instruct：ユーザーのプロンプトへの応答に使用
nvidia/llama-3.2-nv-embedqa-1b-v2：埋め込みの計算に使用

# connect to a LLM NIM at the specified endpoint, specifying a specific model
llm = ChatNVIDIA(base_url=INSTRUCT_MODEL_URL, model="meta/llama-3.2-1b-instruct")

# Initialize and connect to a NeMo Retriever Text Embedding NIM (nvidia/llama-3.2-nv-embedqa-1b-v2)
embeddings_model = NVIDIAEmbeddings(model="nvidia/llama-3.2-nv-embedqa-1b-v2",
                                   base_url=EMBEDDINGS_MODEL_URL)

なぜ2つのモデルがあるのでしょうか？以下のたとえが参考になります：
Embedding モデルは「図書館員」です（適切な本を見つける手助けをします）
Instruct モデルは「作家」です（本を読み、答えを書きます）

プロンプトテンプレートの定義

アプリケーションは次に、meta/llama-3.2-1b-instruct LLM とのやり取りで使用するプロンプトテンプレートを定義します：

prompt = ChatPromptTemplate.from_messages([
    ("system",
        "You are a helpful and friendly AI!"
        "Your responses should be concise and no longer than two sentences."
        "Do not hallucinate. Say you don't know if you don't have this information."
        "Answer the question using only the context"
        "\n\nQuestion: {question}\n\nContext: {context}"
    ),
    ("user", "{question}")
])

LLM に対して、答えがわからない場合はわからないと言うように明示的に指示していることに注目してください。これはハルシネーションを最小限に抑えるのに役立ちます。また、LLM が質問に答えるために使用できるコンテキストを提供するためのプレースホルダーもあります。

ベクターデータベースへの接続

アプリケーションは次に、NVIDIA のデータシートドキュメントが事前に格納されたベクターデータベースに接続します：

    weaviate_client = weaviate.connect_to_custom(
        http_host=os.getenv('WEAVIATE_HTTP_HOST'),
        http_port=os.getenv('WEAVIATE_HTTP_PORT'),
        http_secure=False,
        grpc_host=os.getenv('WEAVIATE_GRPC_HOST'),
        grpc_port=os.getenv('WEAVIATE_GRPC_PORT'),
        grpc_secure=False
    )

    vector_store = WeaviateVectorStore(
        client=weaviate_client,
        embedding=embeddings_model,
        index_name="CustomDocs",
        text_key="page_content"
    )

チェーンの定義

アプリケーションは LCEL（LangChain Expression Language） を使用してチェーンを定義します。|（パイプ）記号はアセンブリラインのように機能し、あるステップの出力が次のステップの入力になります。

    chain = (
        {
            "context": vector_store.as_retriever(),
            "question": RunnablePassthrough()
        }
        | prompt
        | llm
        | StrOutputParser()
    )

これをステップごとに分解してみましょう：

ステップ1：入力マップ {…}：プロンプトの材料を準備しています。
- context：ベクターストアをリトリーバーに変換します。これはユーザーの質問に基づいて、NVIDIA データシートから最も関連性の高いスニペットを見つける検索エンジンのように機能します。
- question：RunnablePassthrough() を使用して、ユーザーの元の質問がそのままプロンプトに渡されるようにします。
- 注意：これらのキー（context と question）は、先ほど定義したプロンプトテンプレートの {context} と {question} プレースホルダーに直接対応しています。
ステップ2：prompt：これは指示書です。context と question を受け取り、プロンプトテンプレートを使用してフォーマットします（例：「コンテキストのみを使用して質問に答えてください…」）。
ステップ3：llm：これは「エンジン」です（GPT-4 のようなもの）。フォーマットされたプロンプトを読み取り、レスポンスを生成します。
ステップ4：StrOutputParser()：デフォルトでは、AI モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列が返されるようになります。

チェーンの実行

最後に、アプリケーションはエンドユーザーの質問を入力として渡してチェーンを実行します：

    response = chain.invoke(question)

これが「スタート」ボタンです。エンドユーザーの質問をパイプラインの最初に投入すると、リトリーバー、プロンプト、LLM を経由して、最終的に答えが出力されます。

LLM アプリケーションの計装

10 minutes

OpenTelemetry によるアプリケーションの計装

計装パッケージ

アプリケーションからメトリクス、トレース、およびログを取得するために、OpenTelemetry で計装を行いました。これには、requirements.txt ファイルに以下のパッケージを追加する必要がありました（最終的に pip install でインストールされます）:

splunk-opentelemetry==2.8.0

また、このアプリケーションのコンテナイメージをビルドするために使用する Dockerfile に、追加の OpenTelemetry 計装パッケージをインストールする以下の記述を追加しました:

# Add additional OpenTelemetry instrumentation packages
RUN opentelemetry-bootstrap --action=install

次に、Dockerfile の ENTRYPOINT を変更し、アプリケーション実行時に opentelemetry-instrument を呼び出すようにしました:

ENTRYPOINT ["opentelemetry-instrument", "flask", "run", "-p", "8080", "--host", "0.0.0.0"]

最後に、この LangChain アプリケーションから OpenTelemetry で収集されるトレースとメトリクスを強化するために、追加の Splunk 計装パッケージを追加しました:

splunk-otel-instrumentation-langchain==0.1.4
splunk-otel-util-genai==0.1.4

環境変数

OpenTelemetry でアプリケーションを計装するために、アプリケーションのデプロイに使用する Kubernetes マニフェストファイルにいくつかの環境変数も含めました:

  env:
    - name: OTEL_SERVICE_NAME
      value: "llm-app"
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: "http://splunk-otel-collector-agent:4317"
    - name: OTEL_EXPORTER_OTLP_PROTOCOL
      value: "grpc"
      # filter out health check requests to the root URL
    - name: OTEL_PYTHON_EXCLUDED_URLS
      value: "^(https?://)?[^/]+(/)?$"
    - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS
      value: "httpx,requests"
    - name: OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT
      value: "true"
    - name: OTEL_LOGS_EXPORTER
      value: "otlp"
    - name: OTEL_PYTHON_LOG_CORRELATION
      value: "true"
    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
      value: "delta"
    - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED
      value: "true"
    - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
      value: "true"
    - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE
      value: "SPAN_AND_EVENT"
    - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS
      value: "span_metric_event,splunk"
    - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS_EVALUATION
      value: "replace-category:SplunkEvaluationResults"
    - name: SPLUNK_PROFILER_ENABLED
      value: "true"

OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT および OTEL_INSTRUMENTATION_GENAI_* 環境変数は、使用している LangChain 計装に固有のものです。

LLM アプリケーションのデプロイ

10 minutes

LLM アプリケーションのデプロイ

以下のコマンドを使用して、このアプリケーションを OpenShift クラスターにデプロイします:

cd ~/workshop/cisco-ai-pods
oc apply -f ./llm-app/k8s-manifest.yaml

注意: この Python アプリケーションの Docker イメージをビルドするために、以下のコマンドを実行しました:
cd workshop/cisco-ai-pods/llm-app
docker build --platform linux/amd64 -t ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0 .
docker push ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0

LLM アプリケーションのテスト

アプリケーションが期待どおりに動作していることを確認しましょう。

curl コマンドにアクセスできる Pod を起動します:

oc run curl --rm -it --image=curlimages/curl:latest \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "curl",
        "image": "curlimages/curl:latest",
        "stdin": true,
        "tty": true,
        "command": ["sh"],
        "resources": {
          "limits": {
            "cpu": "50m",
            "memory": "100Mi"
          },
          "requests": {
            "cpu": "50m",
            "memory": "100Mi"
          }
        }
      }]
    }
  }'

次に、以下のコマンドを実行して LLM に質問を送信します:

curl -X "POST" \
 'http://llm-app:8080/askquestion' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
    "question": "How much memory does the NVIDIA H200 have?"
  }'

The NVIDIA H200 has 141GB of HBM3e memory, which is twice the capacity of the NVIDIA H100 Tensor Core GPU with 1.4X more memory bandwidth.

メトリクス、トレース、およびログの確認

10 minutes

Splunk Observability Cloud でトレースデータを表示する

Splunk Observability Cloud で APM に移動し、Service Map を選択します。お使いの環境名が選択されていることを確認してください（例: ai-pod-workshop-participant-1）。以下のようなサービスマップが表示されるはずです:

右側のメニューで Traces をクリックします。次に、実行時間の長いトレースを1つ選択します。以下の例のように表示されるはずです:

このトレースは、ユーザーの質問（例: 「How much memory does the NVIDIA H200 have?」）に対する回答を返すために、アプリケーションが実行したすべてのインタラクションを示しています。

例えば、アプリケーションが Weaviate ベクトルデータベースで質問に関連するドキュメントを検索するために類似度検索を実行した箇所を確認できます。

また、ベクトルデータベースから取得したコンテキストを含め、アプリケーションが LLM に送信するプロンプトをどのように作成したかも確認できます:

注意: トレースウォーターフォールビューで chat と invoke_workflow の AI インタラクションが表示されない場合、または右側に AI details タブが表示されない場合は、有効化が必要な superpowers についてインストラクターに確認してください。

最後に、LLM からのレスポンス、所要時間、および使用された入力トークンと出力トークンの数を確認できます:

メトリクスが Splunk に送信されていることを確認する

Splunk Observability Cloud で Dashboards に移動し、Built-in dashboard groups に含まれる Cisco AI PODs Dashboard を検索します。 NIM FOR LLMS タブに移動し、お使いの OpenShift クラスター名でダッシュボードがフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されているはずです:

まとめ

5 minutes

まとめ

このワークショップをお楽しみいただけたことを願っています。本ワークショップでは、Splunk Observability Cloud を使用して Cisco AI PODs をモニタリングするために使用されるいくつかの技術を、ハンズオン形式でデプロイおよび操作する体験を提供しました。具体的には、以下の内容を体験していただきました:

GPU ベースのワーカーノードを持つ RedHat OpenShift クラスターでの作業。
NVIDIA NIM Operator および NVIDIA GPU Operator での作業。
NVIDIA NIM を使用してクラスターにデプロイされた Large Language Models (LLMs) での作業。
Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイ。
インフラストラクチャメトリクスを取り込むための Prometheus receiverの Collector への追加。
クラスター内の Weaviate ベクトルデータベースのモニタリング。
Prometheus を使用した Pure Storage メトリクスのモニタリング設定。
Large Language Models (LLMs) と対話する Python サービスの OpenTelemetry による計装。
LLM と対話するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報の理解。

Splunk4Ninjas AppDynamics

2 minutes

はじめに

Splunk AppDynamicsは、ビジネスクリティカルなアプリケーション向けのフルスタックパフォーマンス監視ソリューションであり、以下の機能を提供します

従来型、ハイブリッド、クラウドネイティブなど、環境を問わない一貫したエンドツーエンドのアプリケーション監視
クラウド移行の加速と、デプロイ先を問わないエンタープライズグレードのエンドツーエンドインサイト
パフォーマンス問題がビジネス上の問題になる前に迅速に解決できる統合監視（3クリックで根本原因を特定）

従来型、クラウド、またはハイブリッドデプロイメントにおいて、AppDynamicsプラットフォームの既存の人員、プロセス、トレーニングを活用することで、総所有コストを最適化できます。

ワークショップ概要

このワークショップでは、Splunk AppDynamicsの基本について説明します。Splunk AppDynamicsを使用して、アプリケーションサービス、Webアプリケーション、データベースなどの健全性を監視する方法を紹介します。このワークショップを完了すると、以下のことができるようになります

AppDynamics Java APM Agentのダウンロードとインストール
Controllerでの収集設定の構成
アプリケーションのパフォーマンス健全性の監視とトラブルシューティング
AppDynamicsがキャプチャしたデータに基づくAppDynamics監視サービスでのアラート監視
サーバーの健全性監視と問題のトラブルシューティング
BRUMを使用したブラウザベースアプリケーションの健全性監視
データベースパフォーマンスの監視とトラブルシューティング
Splunk AppDynamics Business IQによるユーザーに関するより深いインサイトの取得

今後追加予定の内容

ヘルスルールに関するセクションの追加（既存のヘルスルールの確認方法、新規ヘルスルールの作成方法）
Application Security

Application Performance Monitoring (APM)

2 minutes

目標

このラボでは、AppDynamicsを使用してアプリケーションサービスの健全性を監視する方法を学びます。このワークショップの他のラボを開始する前に、まずこのラボを完了する必要があります。

このラボを完了すると、以下のことができるようになります

AppDynamics Java APM Agentをダウンロードする
AppDynamics Java APM Agentをインストールする
サンプルアプリケーションに負荷を発生させる
AppDynamics APMの基本概念を理解する
Controllerで収集設定を構成する
アプリケーションの健全性を監視する
アプリケーションのパフォーマンス問題をトラブルシューティングして根本原因を特定する
AppDynamicsがキャプチャしたデータに基づいてAppDynamicsの監視サービスでアラートを監視する

ワークショップ環境

ワークショップ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。ここにAppDynamicsエージェントをインストールするホストであり、以降はApplication VMと呼びます。

Controller

このワークショップでは AppDynamics SE Lab Controller を使用します。

Application VM

Supercar TraderはJavaベースのWebアプリケーションです。

Supercar-Traderコレクションの目的は、AppDynamics Controllerのための動的なトラフィック（Business Transactions）を生成することです。

1. Java Agent のダウンロード

この演習では、WebブラウザからAppDynamics Controllerにアクセスし、Java APMエージェントをダウンロードします。

Controller へのログイン

Ciscoの資格情報を使用して AppDynamics SE Lab Controller にログインします。

アプリケーションの設定

左側のナビゲーションパネルで Overview を選択します
Getting Started タブをクリックします
Getting Started Wizard ボタンをクリックします

Javaアプリケーションタイプを選択します

Java Agent のダウンロード

JVMタイプとして Sun/JRockit - Legacy を選択します
Controller接続のデフォルト設定を受け入れます
Set Application and Tier で Create a new Application: を選択します
アプリケーション名として Supercar-Trader-YOURINITIALS を入力します
新しいTierとして Web Portal を入力します
Node Nameとして Web-Portal_Node-01 を入力します
Continue をクリックします
Click Here to Download をクリックします

Warning

アプリケーション名は一意である必要があります。アプリケーション名にイニシャルを追加するか、一意の識別子を追加してください

ブラウザにエージェントがローカルファイルシステムにダウンロードされていることを示すプロンプトが表示されます。ファイルがダウンロードされた場所と完全なファイル名をメモしておいてください。

2. Java Agent のインストール

この演習では、以下のアクションを実行します

JavaエージェントファイルをEC2インスタンスにアップロードする
ファイルを特定のディレクトリに解凍する
JavaエージェントのXML設定ファイルを更新する（オプション）
Apache Tomcatの起動スクリプトを変更してJavaエージェントを追加する

Application VM への Java Agent のアップロード

この時点で、このワークショップで使用するEC2インスタンスに関する情報を受け取っているはずです。EC2インスタンスのIPアドレス、インスタンスにSSH接続するために必要なユーザー名とパスワードを確認してください。

ローカルマシンでターミナルウィンドウを開き、Javaエージェントファイルがダウンロードされたディレクトリに移動します。以下のコマンドを使用してファイルをEC2インスタンスにアップロードします。これには時間がかかる場合があります。

インスタンスのIPアドレスまたはパブリックDNSを更新してください。
ファイル名を正確なバージョンに合わせて更新してください。

cd ~/Downloads
scp -P 2222 AppServerAgent-22.4.0.33722.zip splunk@i-0b6e3c9790292be66.splunk.show:/home/splunk

(splunk@44.247.206.254) Password:
AppServerAgent-22.4.0.33722.zip                                                                    100%   22MB 255.5KB/s   01:26

Java Agent の解凍

インストラクターから割り当てられたインスタンスとパスワードを使用してEC2インスタンスにSSH接続します。

ssh -P 2222 splunk@i-0b6e3c9790292be66.splunk.show

Javaエージェントバンドルを新しいディレクトリに解凍します。

cd /opt/appdynamics
mkdir javaagent
cp /home/splunk/AppServerAgent-*.zip /opt/appdynamics/javaagent
cd /opt/appdynamics/javaagent
unzip AppServerAgent-*.zip

Tip

ControllerのGetting Started Wizardを使用してJavaエージェントを事前設定しました。AppDynamics Portalからエージェントをダウンロードした場合は、JavaエージェントのXML設定ファイルを手動で更新する必要があります。

Javaエージェントの設定プロパティを設定するには、主に3つの方法があります。これらは以下の順序で優先されます

システム環境変数
コマンドラインで渡されるJVMプロパティ
controller-info.xml ファイル内のプロパティ

Tomcat Server への Java Agent の追加

まず、Tomcatサーバーが実行されていないことを確認します

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

次に、catalinaスクリプトを変更してJavaエージェントの環境変数を設定します。

cd /usr/local/apache/apache-tomcat-9/bin
nano catalina.sh

125行目（最初のコメントの後）に以下の行を追加してファイルを保存します

export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/appdynamics/javaagent/javaagent.jar"

サーバーを再起動します

./startup.sh

Tomcatサーバーが実行されていることを確認します。これには数分かかる場合があります

curl localhost:8080

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <title>Apache Tomcat/9.0.50</title>
        <link href="favicon.ico" rel="icon" type="image/x-icon" />
        <link href="tomcat.css" rel="stylesheet" type="text/css" />
    </head>

    <body>
        <div id="wrapper"
....

3. アプリケーション負荷の生成

この演習では、以下のアクションを実行します

サンプルアプリが実行されていることを確認する
サンプルアプリケーションの負荷生成を開始する
Controllerでトランザクション負荷を確認する

サンプルアプリケーションが実行されていることの確認

サンプルアプリケーションのホームページには、以下の形式のURLを使用してWebブラウザからアクセスできます。EC2インスタンスのIPアドレスに置き換えて、ブラウザのナビゲーションバーにURLを入力してください。

http://[ec2-ip-address]:8080/Supercar-Trader/home.do

Supercar Traderアプリケーションのホームページが表示されるはずです。

負荷生成の開始

EC2インスタンスにSSH接続し、負荷生成を開始します。すべてのスクリプトが実行されるまで数分かかる場合があります。

cd /opt/appdynamics/lab-artifacts/phantomjs
./start_load.sh

Cleaning up artifacts from previous load...
Starting home-init-01
Waiting for additional JVMs to initialize... 1
Waiting for additional JVMs to initialize... 2
Waiting for additional JVMs to initialize... 3
Waiting for additional JVMs to initialize... 4
Waiting for additional JVMs to initialize... 5
Waiting for additional JVMs to initialize... 6
Waiting for additional JVMs to initialize... 7
Waiting for additional JVMs to initialize... 8
Waiting for additional JVMs to initialize... 9
Waiting for additional JVMs to initialize... 10
Waiting for additional JVMs to initialize... 11
Waiting for additional JVMs to initialize... 12
Waiting for additional JVMs to initialize... 13
Waiting for additional JVMs to initialize... 14
Waiting for additional JVMs to initialize... 15
Waiting for additional JVMs to initialize... 16
Waiting for additional JVMs to initialize... 17
Waiting for additional JVMs to initialize... 18
Waiting for additional JVMs to initialize... 19
Waiting for additional JVMs to initialize... 20
Starting slow-query-01
Starting slow-query-02
Starting slow-query-03
Starting slow-query-04
Starting sessions-01
Starting sessions-02
Starting sell-car-01
Starting sell-car-02
Starting sessions-03
Starting sessions-04
Starting search-01
Starting request-error-01
Starting mem-leak-insurance
Finished starting load generator scripts                                                                100%   22MB 255.5KB/s   01:26

Controller でのトランザクション負荷の確認

WebブラウザでGetting Started Wizardがまだ開いている場合、エージェントが接続され、Controllerがデータを受信していることが確認できるはずです。

Continue をクリックすると、Application Flow Map に移動します（以下のFlow Mapの画像にジャンプできます）。

Controllerのブラウザウィンドウを以前に閉じた場合は、Controllerに再度ログインしてください。

Overviewページ（ランディングページ）から、左側のナビゲーションパネルの Applications タブをクリックします。
Applications ページでは、アプリケーションを手動で検索するか、右上の検索バーを使用して検索を絞り込むことができます。

アプリケーション名をクリックすると、Application Flow Map に移動します。12分後にすべてのアプリケーションコンポーネントが表示されるはずです。

12分経ってもすべてのアプリケーションコンポーネントが表示されない場合は、さらに数分待ってからブラウザタブを更新してください。

エージェントのダウンロード手順で、TomcatサーバーのTier名とNode名を割り当てました。

<tier-name>Web-Portal</tier-name>
<node-name>Web-Portal_Node-01</node-name>

他の4つのサービスのTier名とNode名がどのように割り当てられたか疑問に思うかもしれません。サンプルアプリケーションは、最初のTomcat JVMから4つの追加JVMを動的に作成し、4つのサービスそれぞれのJVM起動コマンドに -Dプロパティとしてこれらのプロパティを渡すことでTier名とNode名を割り当てます。JVM起動コマンドラインに含まれる -Dプロパティは、Javaエージェントの controller-info.xml ファイルで定義されたプロパティよりも優先されます。

動的に起動された4つのサービスそれぞれに使用されるJVM起動パラメータを確認するには、EC2インスタンスのターミナルウィンドウで以下のコマンドを実行します。

ps -ef | grep appdynamics.agent.tierName

splunk     47131   46757  3 15:34 pts/1    00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Api-Services -Dappdynamics.agent.nodeName=Api-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.api.ApiService
splunk     47133   46757  2 15:34 pts/1    00:08:11 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Inventory-Services -Dappdynamics.agent.nodeName=Inventory-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.inventory.InventoryService
splunk     47151   46757  1 15:34 pts/1    00:04:58 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Insurance-Services -Dappdynamics.agent.nodeName=Insurance-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx68m -XX:MaxPermSize=256m supercars.services.insurance.InsuranceService
splunk     47153   46757  3 15:34 pts/1    00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Enquiry-Services -Dappdynamics.agent.nodeName=Enquiry-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.enquiry.EnquiryService
splunk    144789   46722  0 20:09 pts/1    00:00:00 grep --color=auto appdynamics.agent.tierName

フローマップにすべてのコンポーネントが表示されると、Insurance-Services Tierによって呼び出される3つのHTTPバックエンドを表すHTTPクラウドアイコンが表示されるはずです。

以下の手順に従って、3つのHTTPバックエンドのグループ化を解除します。

3 HTTP backendsとラベル付けされたHTTPクラウドアイコンを右クリックします
ドロップダウンメニューから Ungroup Backends を選択します

HTTPバックエンドのグループ化が解除されると、以下の画像のように3つすべてのHTTPバックエンドが表示されます。

4. AppDynamics の基本概念

このセクションでは、Splunk AppDynamics APM機能の基本概念について学びます。このセクションを終了すると、以下の概念を理解できるようになります

Application Flow Maps
Business Transactions (BTs)
Snapshots
Call Graphs

Flow Maps

AppDynamicsアプリエージェントは、最も一般的なアプリケーションフレームワークとサービスを自動的に検出します。組み込みのアプリケーション検出および設定を使用して、エージェントはアプリケーションデータとメトリクスを収集し、Flow Mapsを構築します。

AppDynamicsはすべてのトランザクションを自動的にキャプチャしてスコアリングします。Flow Mapsは、選択した時間枠のコンテキストで、監視対象のアプリケーション環境のコンポーネントとアクティビティを動的に視覚化して表示します。

Flow Mapのさまざまな機能に慣れてください。

さまざまなレイアウトオプションを試してみてください（Flow Map上の各アイコンをクリックしてドラッグして位置を変更することもできます）。
スライダーとマウスのスクロールホイールを使用してズームレベルを調整してみてください。
Transaction Scorecardを確認してください。
Flow Mapを編集するオプションを探索してください。

Flow Mapsの詳細についてはこちらをご覧ください。

Business Transactions

AppDynamicsモデルでは、Business Transactionはリクエスト（通常はユーザーリクエスト）のデータ処理フローを表します。現実世界では、アプリケーション内の多くの異なるコンポーネントが相互作用して、以下のようなタイプのリクエストを処理するサービスを提供します

eコマースアプリケーションでは、ユーザーのログイン、商品の検索、カートへの商品追加
コンテンツポータルでは、スポーツ、ビジネス、エンターテインメントニュースなどのコンテンツのリクエスト
株式取引アプリケーションでは、株価の取得、株式の売買などの操作

AppDynamicsはBusiness Transactionsを中心にパフォーマンス監視を行うため、ユーザーの視点からアプリケーションコンポーネントのパフォーマンスに集中できます。コンポーネントがすぐに利用可能かどうか、またはパフォーマンスの問題が発生しているかどうかをすばやく特定できます。たとえば、ユーザーがログインできるか、チェックアウトできるか、データを表示できるかを確認できます。ユーザーの応答時間と、問題が発生した場合の原因を確認できます。

Business Transactionsの詳細についてはこちらとこちらをご覧ください。

Business Transactions の確認

以下の手順に従って、Business Transactionsが自動的に検出されていることを確認します。

左側のメニューで Business Transactions オプションをクリックします。
Business Transactionsのリストとそのパフォーマンスを確認します。

Snapshots

AppDynamicsは、計装された環境内のすべてのBusiness Transactionの実行を監視し、メトリクスはそれらすべての実行を反映します。ただし、トラブルシューティングの目的で、AppDynamicsは問題が発生しているトランザクションの特定のインスタンスのスナップショット（詳細な診断情報を含む）を取得します。

以下の手順に従って、トランザクションスナップショットが自動的に収集されていることを確認します。

左側のメニューで Application Dashboard オプションをクリックします。
Transaction Snapshots タブをクリックします。
Exe Time (ms) 列をクリックして、実行時間が最も長いスナップショットでソートします。
Business Transactionスナップショットをダブルクリックしてスナップショットビューアを表示します

トランザクションスナップショットは、単一のトランザクション呼び出しの処理フローをクロスティアビューで表示します。

Potential Issues パネルは、遅いメソッドと遅いリモートサービスコールを強調表示し、パフォーマンス問題の根本原因を調査するのに役立ちます。

Drill Downs と Call Graphs

Call graphsとdrill downsは、Tierでのトランザクション実行に関する重要な情報を提供します。これには、最も遅いメソッド、エラー、リモートサービスコールが含まれます。drill downには、部分的または完全なcall graphが含まれる場合があります。Call graphsは、特定のTierでのBusiness Transactionの処理をコードレベルで表示します。

Business TransactionスナップショットのFlow Mapで、Drill DownリンクがあるTierは、AppDynamicsがそのTierのcall graphを取得したことを示しています。

以下の手順に従って、トランザクションスナップショットのcall graphにドリルダウンします。

左側のPotential Issuesリストで遅いコールをクリックします。
Drill Down into Call Graph をクリックします。

call graphビューには、以下の詳細が表示されます。

メソッド実行シーケンスは、このノードでBusiness Transactionの処理に参加したクラスとメソッドの名前を、制御フローの進行順序で表示します。
各メソッドについて、処理に費やされた時間と割合、およびソースコード内の行番号を確認でき、トランザクションのパフォーマンスに影響を与えている可能性のあるコード内の場所を特定できます。
call graphは、データベースクエリやWebサービスコールなど、他のコンポーネントへの発信コールを行うメソッドのexit callリンクを表示します。

Transaction Snapshotsの詳細についてはこちらをご覧ください。

Call Graphsの詳細についてはこちらをご覧ください。

5. Controller 設定の構成

この演習では、以下のタスクを完了します

Business Transaction設定を調整する
Call Graph設定を調整する
Business Transactionの変更を確認する

Business Transaction 設定の調整

前の演習で、Business Transactionsが自動検出されていることを確認しました。Business Transactionの自動検出ルールを最適な状態に調整したい場合があります。これは、古いApache Strutsフレームワーク上に構築されたサンプルアプリケーションの場合に当てはまります。

以下の画像で強調表示されているBusiness Transactionsは、各ペアにStruts Action（.execute）とServletタイプ（.jsp）があることを示しています。これら2種類のトランザクションが1つに統合されるように、トランザクション検出ルールの設定を調整します。

AppDynamics UIに時間枠セレクターが表示されている場合、表示されるビューは選択した時間枠のコンテキストを表します。事前定義された時間枠の1つを選択するか、表示したい特定の日付と時間範囲でカスタム時間枠を作成できます。

過去1時間の時間枠を選択します。
マウスを青いアイコンの上に移動して、トランザクションのEntry Point Typeを確認します。

以下の手順に従ってトランザクション検出を最適化します

左下のメニューで Configuration オプションをクリックします。
Instrumentation リンクをクリックします。
Instrumentationメニューから Transaction Detection を選択します。
Java Auto Discovery Rule を選択します。
Edit をクリックします。
Rule Editorで Rule Configuration タブを選択します。
Struts Action セクションのすべてのボックスのチェックを外します。
Web Service セクションのすべてのボックスのチェックを外します。
下にスクロールしてServlet設定を見つけます。
Enable Servlet Filter Detection ボックスにチェックを入れます（Servlet設定では3つのボックスすべてにチェックが入っている必要があります）。
Save をクリックして変更を保存します。

Transaction Detection Rulesの詳細についてはこちらをご覧ください。

Call Graph 設定の調整

以下に示すCall Graph Settingsウィンドウで、トランザクションスナップショット内のcall graphsでキャプチャされるデータを制御できます。このステップでは、各SQLクエリのパラメータが完全なクエリと共にキャプチャされるようにSQL Capture設定を変更します。以下の手順に従ってSQL Capture設定を変更できます。

Instrumentationウィンドウから Call Graph Settings タブを選択します。これは、前の演習で移動した Instrumentation 設定内にあります。
設定内で Java タブが選択されていることを確認します。
SQL Capture Settings が表示されるまで下にスクロールします。
Capture Raw SQL オプションをクリックします。
Save をクリックします。

Call Graph設定の詳細についてはこちらをご覧ください。

Business Transaction の変更の確認

新しいBusiness Transactionsが以前のトランザクションを置き換えるまでに最大30分かかる場合があります。新しいトランザクションが検出されると、Business Transactionsのリストは以下の例のようになります。

左側のメニューで Business Transactions をクリックします。
時間範囲ピッカーを調整して last 15 minutes を確認します

6. 遅いトランザクションのトラブルシューティング

この演習では、以下のタスクを完了します

アプリケーションダッシュボードとフローマップを監視する
遅いトランザクションスナップショットをトラブルシューティングする

アプリケーションダッシュボードとフローマップの監視

前の演習では、Application Flow Mapの基本的な機能をいくつか見てきました。Application DashboardとFlow Mapを使用してアプリケーション内の問題を即座に特定する方法をより深く見ていきましょう。

Health Rule Violations、Node Healthの問題、およびBusiness Transactionsの健全性は、選択した時間枠についてこのエリアに常に表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。
Transaction Scorecardは、正常、遅い、非常に遅い、停止、エラーのあるトランザクションの数と割合を表示します。スコアカードには、例外タイプの高レベルのカテゴリも表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。
異なるアプリケーションコンポーネントを接続する青い線のいずれかを左クリック（シングルクリック）すると、2つのコンポーネント間のインタラクションの概要が表示されます。
Tierの色付きリング内を左クリック（シングルクリック）すると、Flow Mapに留まりながらそのTierに関する詳細情報が表示されます。
ダッシュボードの下部にある3つのチャート（Load、Response Time、Errors）のいずれかの時系列にマウスを合わせると、記録されたメトリクスの詳細が表示されます。

次に、Dynamic Baselinesとダッシュボードの下部にあるチャートのオプションを見てみましょう。

チャートのメトリクスを、各メトリクスに対して自動的に計算されたDynamic Baselineと比較します。
Dynamic Baselineは、以下の画像に示すように、負荷と応答時間のチャートに青い点線で表示されます。
ダッシュボードの下部にある3つのチャートのいずれかでスパイクを強調表示するには、マウスボタンを押したまま左から右にドラッグします。
マウスボタンを離し、ポップアップメニューの3つのオプションのいずれかを選択します。

AppDynamics独自のDynamic Baseliningの精度は時間の経過とともに向上し、アプリケーション、そのコンポーネント、およびビジネストランザクションの状態を正確に把握できるようになります。これにより、事態が深刻な状態になる前にプロアクティブにアラートを受け取り、エンドユーザーに影響が及ぶ前に対処できます。

AppDynamics Dynamic Baselinesの詳細についてはこちらをご覧ください。

遅いトランザクションスナップショットのトラブルシューティング

以下の手順に従って、Business Transactionsを確認し、非常に遅いトランザクションが最も多いものを見つけましょう。

左側のメニューで Business Transactions オプションをクリックします。
View Options ボタンをクリックします。
以下の画像と一致するようにオプションのボックスのチェックを入れたり外したりします
/Supercar-Trader/car.doという名前のBusiness Transactionを見つけ、そのBusiness TransactionのVery Slow Transactionsの数をクリックして、非常に遅いトランザクションスナップショットにドリルダウンします。

Tip

/Supercar-Trader/car.do BTにVery Slow Transactionsがない場合は、それがあるBusiness Transactionを見つけて、その列の数字をクリックしてください。今後のスクリーンショットは若干異なる場合がありますが、概念は同じです。

![Very Slow Transaction](images/very-slow-transaction.png)

非常に遅いトランザクションスナップショットのリストが表示されるはずです。以下に示すように、最も応答時間が長いスナップショットをダブルクリックします。

トランザクションスナップショットビューアが開くと、この特定のトランザクションの一部であったすべてのコンポーネントのフローマップビューが表示されます。このスナップショットは、トランザクションが以下のコンポーネントを順番に通過したことを示しています。
- Web-Portal Tier
- Api-Services Tier
- Enquiry-Services Tier
- MySQL Database
左側のPotential Issuesパネルは、遅いメソッドと遅いリモートサービスを強調表示します。Potential Issuesパネルを使用してcall graphに直接ドリルダウンすることもできますが、この例ではスナップショット内のFlow Mapを使用して完全なトランザクションを追跡します。
スナップショットのFlow Mapに表示されているWeb-Portal Tierの Drill Down をクリックします。

開いたタブにはWeb-Portal Tierのcall graphが表示されます。ほとんどの時間がアウトバウンドHTTPコールによるものであることがわかります。
ブロックをクリックして、問題が発生しているセグメントにドリルダウンします。HTTPリンクをクリックしてダウンストリームコールの詳細を表示します。

ダウンストリームコールの詳細パネルは、Web-Portal TierがApi-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してApi-Services Tierに進みます。
Drill Down into Downstream Call をクリックします。

次に開くタブにはApi-Services Tierのcall graphが表示されます。時間の100%がアウトバウンドHTTPコールによるものであることがわかります。
HTTPリンクをクリックしてダウンストリームコールの詳細パネルを開きます。

ダウンストリームコールの詳細パネルは、Api-Services TierがEnquiry-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してEnquiry-Services Tierに進みます。
Drill Down into Downstream Call をクリックします。

次に開くタブにはEnquiry-Services Tierのcall graphが表示されます。トランザクションに問題を引き起こしたデータベースへのJDBCコールがあったことがわかります。
最も時間がかかったJDBCリンクをクリックして、JDBCコールの詳細パネルを開きます。

JDBC exitコールの詳細パネルには、最も時間がかかった特定のクエリが表示されます。SQLパラメータ値とともに完全なSQLステートメントを確認できます。

まとめ

このラボでは、まずBusiness Transactionsを使用して、トラブルシューティングが必要な非常に遅いトランザクションを特定しました。次に、call graphを調べて、遅延を引き起こしているコードの特定の部分を特定しました。その後、ダウンストリームサービスとデータベースにドリルダウンして、遅延の根本原因をさらに分析しました。最後に、パフォーマンスの問題の原因となっている非効率なSQLクエリを正確に特定することに成功しました。この包括的なアプローチは、AppDynamicsがトランザクションのボトルネックを効果的に分離して解決するのにどのように役立つかを示しています。

7. エラーと例外のトラブルシューティング

この演習では、アプリケーション内のエラーを効果的に検出および診断して根本原因を特定する方法を学びます。さらに、パフォーマンスが低下しているか、エラーが発生している特定のノードを特定し、これらのパフォーマンスの問題を解決するためのトラブルシューティング手法を適用する方法を探ります。このハンズオン体験により、アプリケーションの健全性を維持し、最適なパフォーマンスを確保する能力が向上します。

アプリケーション内の特定のエラーの検出

AppDynamicsを使用すると、アプリケーション内のエラーと例外を簡単に見つけることができます。Errors ダッシュボードを使用して、エラーのあるトランザクションスナップショットを確認し、最も頻繁に発生している例外を見つけることができます。エラーを迅速に特定することで、アプリケーションの安定性とユーザーエクスペリエンスを向上させる修正の優先順位付けに役立ちます。例外のタイプと頻度を理解することで、最も影響の大きい問題に集中できます。

左側のメニューで Troubleshoot オプションをクリックします。
左側のメニューで Errors オプションをクリックします。これにより、エラーのあるBusiness Transactionsをすばやく特定できるErrorsダッシュボードに移動します。
いくつかのエラートランザクションスナップショットを調べます。スナップショットを確認すると、エラーが発生したときの正確なコンテキストとフローを確認できます。
Exceptions タブをクリックして、タイプ別にグループ化された例外を表示します。例外タイプ別にグループ化することで、繰り返し発生する問題とパターンを特定できます。

Exceptions タブには、アプリケーション内で最も多く発生している例外のタイプが表示されるため、最も影響の大きいものの修正を優先できます。
Exceptions per minute と Exception count（6）を確認して、エラーの頻度を把握します。高頻度の例外は、即座に対応が必要な重大な問題を示していることが多いです。
例外が発生している Tier を確認して、アプリケーションアーキテクチャ内で問題を特定します。影響を受けているTierを知ることで、根本原因を絞り込むことができます。
MySQLIntegrityConstraintViolationExceptionタイプをダブルクリックして、より深くドリルダウンします。
この例外タイプが発生したスナップショットを示す概要ダッシュボードを確認します。
Stack Traces for this Exception というラベルのタブには、この例外タイプによって生成された一意のスタックトレースの集約リストが表示されます。スタックトレースは、エラーを引き起こしている正確なコードパスを提供し、デバッグに不可欠です。
スナップショットをダブルクリックして開き、コンテキスト内でエラーを確認します。これにより、トランザクションフローとエラーが発生した場所が表示されます。

例外画面からエラースナップショットを開くと、スナップショットはエラーが発生したスナップショット内の特定のセグメントで開きます。
赤いテキストで表示されているexitコールに注目してください。これはエラーまたは例外を示しています。
exitコールにドリルインして、詳細なエラー情報を表示します。
Error Details をクリックして、完全なスタックトレースを表示します。完全なスタックトレースは、開発者がバグを追跡して修正するために不可欠です。

Tip

エラー処理と例外について詳しく知りたい場合は、次のリンクの公式AppDynamicsドキュメントを参照してください：こちら

ノードの問題のトラブルシューティング

ノードの健全性は、アプリケーションのパフォーマンスと可用性に直接影響します。ノードの問題を早期に検出することで、停止を防ぎ、スムーズな運用を確保できます。AppDynamicsはUI全体で視覚的なインジケーターを提供し、問題をすばやく特定しやすくしています。

Application Dashboardの3つのエリアでノードの問題のインジケーターを確認できます。

Application Dashboard でノードの問題の視覚的なインジケーターを確認します。色の変化とアイコンは、問題に対する即座のアラートを提供します。
Events パネルには、Node Healthに関連するものを含むHealth Rule Violationsが表示されます。
Node Health パネルには、ノードで発生している重大または警告の問題の数が表示されます。Node Health パネルのNode Healthリンクをクリックして、Tiers & Nodes dashboard にドリルダウンします。
または、左側のメニューで Tiers & Nodes をクリックして Tiers & Nodes dashboard にアクセスすることもできます。
Grid Viewに切り替えて、整理されたノードのリストを表示します。Grid viewを使用すると、警告のあるノードをスキャンして見つけやすくなります。
Insurance-Services_Node-01ノードの警告アイコンをクリックします。
Health Rule Violationsのサマリーを確認し、違反の説明をクリックします。
Details ボタンをクリックして詳細を表示します。

Health Rule Violation 詳細ビューアには以下が表示されます
違反の現在の状態。
違反が発生していた時間のタイムライン。
違反の詳細と、それをトリガーした条件。
View Dashboard During Health Rule Violation をクリックして、問題発生時のノードメトリクスを確認します。違反とパフォーマンスメトリクスを関連付けることで、診断に役立ちます。

View Dashboard During Health Rule Violation ボタンをクリックすると、デフォルトでNodeダッシュボードの Server タブが開きます。
AppDynamics Server Visibility Monitoringエージェントをまだインストールしていない場合、ノードのホストのリソースメトリクスは表示されません。これらのメトリクスは次のラボで確認できます。AppDynamics Javaエージェントは、JMX経由でJVMからメモリメトリクスを収集します。
以下の手順でJVMヒープデータを調査します。
Memory タブをクリックします。
現在のヒープ使用率を確認します。
発生しているMajor Garbage Collectionsに注目します。

注：Memory画面の表示に問題がある場合は、別のブラウザを試してください（FirefoxはWindows、Linux、Macで正しくレンダリングされるはずです）。

![Memory Dashboard](images/memory-dashboard.png)

外側のスクロールバーを使用して、画面の下部までスクロールします。
PS Old Gen のメモリ使用量が高い場合は、メモリリークまたは非効率なガベージコレクションの潜在的な兆候として注意してください。メモリ圧力を早期に特定することで、停止を防ぐことができます。

NodeとJVMの監視の詳細についてはこちらとこちらをご覧ください。

まとめ

このラボでは、AppDynamicsを効果的に使用してアプリケーションエラーとノードの健全性の問題を特定およびトラブルシューティングする方法を学びました。まず、Errorsダッシュボードを使用して特定のエラーと例外を見つけ、その頻度、タイプ、およびアプリケーションへの影響を理解しました。エラースナップショットとスタックトレースにドリルダウンして、障害の根本原因を特定しました。

次に、Application Dashboardの視覚的なインジケーターを解釈し、Health Rule Violationsを調査することで、ノードの健全性監視を探りました。ガベージコレクションとヒープ使用量に関連する潜在的なパフォーマンスボトルネックを検出するために、JVMメモリメトリクスを分析する方法を学びました。

これらのスキルを組み合わせることで、アプリケーションのパフォーマンスと信頼性を維持するためのプロアクティブな監視と迅速なトラブルシューティングが可能になります。

Server Visibility Monitoring

2 minutes

前提条件

このラボはApplication Performance Monitoringラボの続きです。アプリケーションが実行中であり、過去1時間にわたって負荷がかかっていることを確認してください。必要に応じて、Generate Application Loadセクションに戻ってロードジェネレーターを再起動してください。

目標

このラボでは、AppDynamics Server Visibility MonitoringとService Availability Monitoringについて学びます。

このラボを完了すると、以下のことができるようになります

AppDynamics Server Visibility Agentをダウンロードする
AppDynamics Server Visibility Agentをインストールする
サーバーの健全性を監視する
エージェントの拡張ハードウェアメトリクスを理解する
アプリケーションパフォーマンスに影響を与えている基盤インフラストラクチャの問題を迅速に確認する

ワークショップ環境

ラボ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降はApplication VMと呼びます。

Controller

このワークショップでは AppDynamics SE Lab Controller を使用します。

Application VM

Supercar TraderはJavaベースのWebアプリケーションです。

Supercar-Traderコレクションの目的は、AppDynamics Controllerに対して動的なトラフィック（ビジネストランザクション）を生成することです。

Machine Agent のデプロイ

5 minutes

この演習では、以下のアクションを実行します

Machine Agentをインストールするスクリプトを実行する
Machine Agentを設定する
Machine Agentを起動する

注意

スクリプトを使用してMachine AgentをEC2インスタンスにダウンロードします。通常は https://accounts.appdynamics.com/ にログインしてMachine Agentをダウンロードする必要がありますが、アクセス制限の可能性があるため、ポータルから直接ダウンロードするスクリプトを使用します。AppDynamicsポータルにアクセスでき、Machine Agentをダウンロードしたい場合は、以下のステップに従ってダウンロードし、APMラボのInstall Agentセクションで使用したステップを参照してVMにSCPしてください。

AppDynamics Portal にログインします
左側のメニューで Downloads をクリックします
Type で Machine Agent を選択します
Operating System で Linux を選択します
Machine Agent Bundle - 64-bit linux (zip) を見つけて Download ボタンをクリックします
Install Agentセクションのステップに従って、ダウンロードしたファイルをEC2インスタンスにSCPします
zipファイルを /opt/appdynamics/machineagentディレクトリに解凍し、このラボの設定セクションに進みます

インストールスクリプトの実行

以下のコマンドを使用して、スクリプトが配置されているディレクトリに移動します。スクリプトはMachine Agentをダウンロードして解凍します。

cd /opt/appdynamics/lab-artifacts/machineagent/

以下のコマンドを使用してインストールスクリプトを実行します。

chmod +x install_machineagent.sh
./install_machineagent.sh

以下の画像のような出力が表示されるはずです。

Server Agent の設定

Java Agentの “controller-info.xml” から以下の設定プロパティ値を取得し、次のステップで使用できるようにしておきます。

cat /opt/appdynamics/javaagent/conf/controller-info.xml

controller-host
controller-port
controller-ssl-enabled
account-name
account-access-key

Machine Agentの “controller-info.xml” ファイルを編集し、Java Agent設定ファイルから取得した以下のプロパティの値を挿入します。

controller-host
controller-port
controller-ssl-enabled
account-name
account-access-key

“sim-enabled” プロパティをtrueに設定してファイルを保存する必要があります。ファイルは以下の画像のようになります。

cd /opt/appdynamics/machineagent/conf
nano controller-info.xml

Server Visibility Agent の起動

以下のコマンドを使用して、Server Visibility Agentを起動し、起動したことを確認します。

cd /opt/appdynamics/machineagent/bin
nohup ./machine-agent &
ps -ef | grep machine

以下の画像のような出力が表示されるはずです。

サーバーの健全性を監視する

2 minutes

この演習では、以下のタスクを完了します

Server Mainダッシュボードを確認する
Server Processesダッシュボードを確認する
Server Volumesダッシュボードを確認する
Server Networkダッシュボードを確認する
サーバーとアプリケーションのコンテキスト間を移動する

Server Main Dashboard の確認

Machine Agentがインストールされたので、Server Visibilityモジュールで利用可能な機能のいくつかを見てみましょう。Application Dashboard から Servers タブをクリックし、以下のステップに従ってサーバーメインダッシュボードにドリルダウンします。

左側のメニューで Servers タブをクリックします。
サーバーの左側にある checkbox をチェックします。
View Details をクリックします。

これでサーバーダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

選択した監視対象サーバーの主要なパフォーマンスメトリクスのチャートを表示します。これには以下が含まれます

サーバーの可用性
CPU、メモリ、ネットワーク使用率
サーバープロパティ
ディスク、パーティション、ボリュームのメトリクス
CPUリソースとメモリを消費している上位10プロセス

Server Mainダッシュボードについて詳しくはこちらをご覧ください。

ダッシュボードの Top Pane を確認します。以下の情報が表示されます

Host Id: Splunk AppDynamics Controllerで一意のサーバー IDです
Health: サーバーの全体的な健全性を表示します
Hierarchy: サーバーをグループ化するための任意の階層です。詳細についてはこちらのドキュメントをご覧ください

サーバーの健全性アイコンをクリックして Violations & Anomalies パネルを表示します。パネルを確認して潜在的な問題を特定します
Current Health Rule Evaluation Status をクリックして、このサーバーに対して現在アラートが発生している問題があるかどうかを確認します

CPU Usage too high ルールをクリックします
Edit Health Rule をクリックします。Edit Health Rule パネルが開きます

このパネルではHealth Ruleを設定できます。別のラボでHealth Ruleの作成とカスタマイズについて詳しく説明します。ここでは既存のルールを確認するだけにします。

Warning Criteria をクリックします

この例では、CPUが5%を超えたときに警告条件が設定されていることがわかります。これが、Health Ruleが正常な状態ではなく警告を表示している理由です。Edit Health Rule パネルをキャンセルして Server Dashboard に戻ります。

Server Processes Dashboard の確認

Processes タブをクリックします。
View Options をクリックして異なるデータカラムを選択します。表示可能なKPIを確認します。

これでサーバープロセスダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

選択した期間中にアクティブなすべてのプロセスを表示します。プロセスはServerMonitoring.ymlファイルで指定されたクラスごとにグループ化されます。
Command Lineカラムのプロセスエントリにマウスを合わせると、このプロセスを開始したフルコマンドラインを表示できます。
プロセスクラスを展開して、そのクラスに関連するプロセスを確認できます。
View Optionsを使用して、チャートに表示するカラムを設定できます。
表示されるメトリクスの期間を変更できます。
カラムをソートキーとして使用してチャートをソートできます。スパークラインチャート（CPU TrendとMemory Trend）ではソートできません。
CPUとメモリの使用傾向を一目で確認できます。

Server Processesダッシュボードについて詳しくはこちらをご覧ください。

Server Volumes Dashboard の確認

Volumes タブをクリックします。

これでサーバーボリュームダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

ボリュームのリスト、使用率、およびディスク、パーティション、またはボリュームで利用可能な総ストレージ容量を確認できます。
ディスク使用量とI/O使用率、レート、1秒あたりの操作数、待機時間を確認できます。
収集および表示されるメトリクスの期間を変更できます。
チャート上の任意のポイントをクリックして、その時点のメトリクス値を確認できます。

Server Volumesダッシュボードについて詳しくはこちらをご覧ください。

Server Network Dashboard の確認

Network タブをクリックします。

これで Server Network ダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

各ネットワークインターフェースのMAC、IPv4、IPv6アドレスを確認できます。
ネットワークインターフェースが有効かどうか、機能しているかどうか、イーサネットケーブルが接続された動作状態、全二重または半二重モードで動作しているか、ネットワークインターフェースが渡すことができる最大プロトコルデータユニットの最大転送単位（MTU）またはサイズ（バイト単位）、Mbit/sec単位のイーサネット接続速度を確認できます。
ネットワークスループット（キロバイト/秒）とパケットトラフィックを表示できます。
表示されるメトリクスの期間を変更できます。
チャート上の任意のポイントにマウスを合わせると、その時点のメトリクス値を確認できます。

Server Networkダッシュボードについて詳しくはこちらをご覧ください。

サーバーと APM の相関

3 minutes

サーバーとアプリケーションのコンテキスト間の移動

Server Visibility Monitoringエージェントは、同じホスト上で実行されているSplunk AppDynamics APMエージェントと自動的に関連付けられます。

Server Visibilityを有効にすると、アプリケーションのコンテキストでサーバーパフォーマンスメトリクスにアクセスできます。さまざまな方法でサーバーとアプリケーションのコンテキストを切り替えることができます。以下のステップに従って、サーバーメインダッシュボードからサーバー上で実行されているNodeの1つに移動します。

Dashboard タブをクリックしてメインのServer Dashboardに戻ります。
APM Correlation リンクをクリックします。

リストされているTierの1つで下矢印をクリックします。
TierのNodeリンクをクリックします。

これで Node Dashboard に移動しました。

Server タブをクリックして関連するホストメトリクスを確認します。

Server Visibility Monitoringエージェントがインストールされている場合、ホストメトリクスは関連するNodeのコンテキスト内で常に利用可能です。

サーバーとアプリケーションのコンテキスト間の移動について詳しくはこちらをご覧ください。

Business iQ

2 minutes

目標

このラーニングラボでは、AppDynamics Business iQについて学習します。

このラボを完了すると、以下のことができるようになります

新しいエージェントレスAnalytics Java Agent（v 4.5.15以降）でAnalyticsを有効化する。
HTTPデータコレクターを設定する。
メソッド呼び出しデータコレクターを設定する。
ダッシュボードコンポーネントを理解する。
ビジネスダッシュボードを構築する。

ワークショップ環境

ラボ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降Controllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降Application VMと呼びます。

Controller VM

Application VM

ラボの前提条件

3 minutes

この演習では、以下のタスクを完了します

WebブラウザからAppDynamics Controllerにアクセスする。
アプリケーションへのトランザクション負荷を確認する。
必要に応じてアプリケーションとトランザクション負荷を再起動する。

Controllerへのログイン

Ciscoの認証情報を使用してAppDynamics SE Lab Controllerにログインします。

アプリケーションへのトランザクション負荷の確認

アプリケーションフローマップを確認します

last 1 hourの時間枠を選択します。
フローマップに5つの異なるTierが表示されていることを確認します。
過去1時間にわたって一貫した負荷があったことを確認します。

ビジネストランザクションのリストを確認します

左メニューの Business Transactions オプションをクリックします。
下記に示す11個のビジネストランザクションが表示されていることを確認します。
過去1時間に何らかの呼び出し数があることを確認します。

注意: Calls 列が表示されない場合は、View Options ツールバーボタンをクリックしてその列を表示できます。

Nodeのエージェントステータスを確認します

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
各Nodeの App Agent Status が過去1時間で90%以上であることを確認します。

必要に応じてアプリケーションと負荷生成の再起動

前のステップで実行した確認のいずれかが検証できなかった場合は、Application VMにSSH接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。

以下のコマンドを使用して、実行中のApache Tomcatインスタンスを停止します。

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

以下のコマンドを使用して、まだ実行中のアプリケーションJVMがないか確認します。

ps -ef | grep Supercar-Trader

まだ実行中のアプリケーションJVMが見つかった場合は、以下のコマンドを使用して残りのJVMを終了します。

sudo pkill -f Supercar-Trader

以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待ちます。

cd /opt/appdynamics/lab-artifacts/phantomjs
./stop_load.sh

Tomcatサーバーを再起動します

cd /usr/local/apache/apache-tomcat-9/bin
./startup.sh

2分待ってから、以下のコマンドを使用してApache Tomcatがポート8080で実行されていることを確認します。

curl localhost:8080

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <title>Apache Tomcat/9.0.50</title>
        <link href="favicon.ico" rel="icon" type="image/x-icon" />
        <link href="tomcat.css" rel="stylesheet" type="text/css" />
    </head>

    <body>
        <div id="wrapper"
....

以下のコマンドを使用して、アプリケーションの負荷生成を開始します。

cd /opt/appdynamics/lab-artifacts/phantomjs
./start_load.sh

以下の画像のような出力が表示されるはずです。

アプリケーションでAnalyticsを有効化

2 minutes

Analyticsは以前、Machine Agentにバンドルされた別のエージェントが必要でした。しかし、現在Analyticsはエージェントレスで、Controller 4.5.16以降の.NET Agent 20.10以降およびJava Agent 4.5.15以降のAPM Agentに組み込まれています。

この演習では、WebブラウザからAppDynamics Controllerにアクセスし、エージェントレスAnalyticsを有効化します。

Controllerへのログイン

Ciscoの認証情報を使用してAppDynamics SE Lab Controllerにログインします。

Analytics設定への移動

** 画面左上の Analytics タブを選択します。
** 左側の Configuration タブを選択します。
** Transaction Analytics - Configuration タブを選択します。
** アプリケーション Supercat-Trader-YOURINITIALS の横にあるチェックボックスをオンにします。
** Save ボタンをクリックします。

Transaction Summaryの検証

Analyticsがそのアプリケーションで機能し、トランザクションが表示されていることを確認します。

左メニューの Analytics tab タブを選択します。
Home タブを選択します。
Transactions from でアプリケーション Supercar-Trader-YOURINITIALS にフィルターします。

HTTPデータコレクターの設定

2 minutes

データコレクターを使用すると、ビジネストランザクションとTransaction Analyticsデータをアプリケーションデータで補完できます。アプリケーションデータは、ビジネストランザクションのパフォーマンス問題にコンテキストを追加できます。例えば、パフォーマンス問題の影響を受けたビジネストランザクションの特定のパラメータや戻り値（特定のユーザー、注文、製品など）を表示します。

HTTPデータコレクターは、ビジネストランザクションで交換されるHTTPメッセージのURL、パラメータ値、ヘッダー、Cookieをキャプチャします。

この演習では、以下のタスクを実行します

すべてのHTTPデータコレクターを有効化する。
関連するHTTPデータコレクターを観察して選択する。
HTTPパラメータを使用してAnalyticsでビジネスデータをキャプチャする。
HTTPパラメータのAnalyticsを検証する。

すべてのHTTPデータコレクターの有効化

最初に、すべてのHTTPデータコレクターをキャプチャして、Analyticsにキャプチャしてダッシュボードで使用できる有用なパラメータを把握します。

Tip

このステップは本番環境ではなく、UAT環境で実行することを強く推奨します。

画面左上の Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
左側の Configuration タブを選択します。
Instrumentation リンクをクリックします。
Data Collectors タブを選択します。
HTTP Request Data Collectors の Add ボタンをクリックします。

次に、すべてのHTTPパラメータをキャプチャするHTTPデータコレクターを設定します。Transaction Analyticsに必要な正確なパラメータを特定するまで、オーバーヘッドを避けるためにTransaction Snapshotsでのみ有効にします。

Name に All HTTP Param を指定します。
Enable Data Collector for で Transaction Snapshots のチェックボックスをオンにします。
Transaction Analyticsは有効にしないでください。
HTTP Parametersセクションで + Add をクリックします。
新しいパラメータのDisplay Nameに All を指定します。
HTTP Parameter nameにアスタリスク * を指定します。
Save をクリックします。

“Ok"をクリックしてデータコレクターを確認します。
/Supercar-Trader/sell.do トランザクションを有効にします。
Save をクリックします。

HTTPパラメータを使用したAnalyticsでのビジネスデータのキャプチャ

次に、HTTPデータコレクターを再度設定しますが、今回は有用なHTTPパラメータのみをキャプチャしてTransaction Analyticsで有効にします。新しいHTTP Data Collectorを追加します：Application -> Configuration -> Instrumentation -> Data Collectorタブ -> HTTP Request Data Collectors セクションで Add をクリックします。

Nameに CarDetails を指定します。
Transaction Snapshots を有効にします。
Transaction Analytics を有効にします。
HTTP Parametersセクションで + Add をクリックします。
新しいパラメータのDisplay Nameに CarPrice_http を指定します。
HTTP Parameter nameに carPrice を指定します。
以下に示すように、残りのCarパラメータについても同様に繰り返します。
Save をクリックします。
Ok をクリックしてData Collectorの実装を確認します。

/Supercar-Trader/sell.do トランザクションを有効にします。
Save をクリックします。

All HTTP Param コレクターをクリックして選択し、Delete ボタンをクリックして削除します。

HTTPパラメータのAnalyticsの検証

次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。

画面左上の Analytics タブを選択します。
Searches タブを選択します。
+ Add ボタンをクリックし、新しい Drag and Drop Search を作成します。

+ Add Criteria をクリックします。
Application を選択し、アプリケーション名 Supercar-Trader-YOURINITIALS を検索します。
Fields パネルで、Business Parameters がCustom HTTP Request Dataのフィールドとして表示されていることを確認します。
CarPrice_http のチェックボックスをオンにし、フィールドにデータがあることを確認します。

メソッドデータコレクターの設定

2 minutes

メソッド呼び出しデータコレクターは、メソッド引数、変数、戻り値などのコードデータをキャプチャします。HTTPデータコレクターに十分なビジネスデータがない場合でも、コード実行からこれらの情報をキャプチャできます。

この演習では、以下のタスクを実行します

メソッドを発見する。
ディスカバリーセッションを開く。
メソッドパラメータを発見する。
コード内のオブジェクトにドリルダウンする。
メソッド呼び出しデータコレクターを作成する。
メソッド呼び出しデータコレクターのAnalyticsを検証する。

ディスカバリーセッションを開く

ソースコードからメソッドやパラメータを特定するアプリケーション開発者がいない場合があります。しかし、AppDynamicsから直接アプリケーションメソッドとオブジェクトを発見するアプローチがあります。

画面左上の Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
Configuration タブを選択します。
Instrumentation リンクをクリックします。
Transaction Detection タブを選択します。
右側の Live Preview Button をクリックします。

Start Discovery Session ボタンをクリックします。
ポップアップウィンドウで Web-Portal Node を選択します。調査しているメソッドが実行されているのと同じNodeである必要があります。
Ok をクリックします。

右側のトグルで Tools を選択します。
ドロップダウンリストで Classes/Methods を選択します。
Search セクションで Classes with nameを選択します。
テキストボックスにクラス名 supercars.dataloader.CarDataLoader を入力します。クラス名を見つけるには、コールグラフを検索するか、理想的にはソースコードで見つけます。
Apply をクリックして一致するクラスメソッドを検索します。
結果が表示されたら、検索に一致するクラスを展開します。
同じメソッド saveCar を探します。

saveCar メソッドは入力パラメータとして CarForm オブジェクトを取ることに注意してください。

オブジェクトへのドリルダウン

メソッドを見つけたら、そのパラメータを調べて車の詳細プロパティを取得できる場所を見つけます。

saveCar メソッドは入力パラメータとして複合オブジェクト CarForm を取ることがわかりました。このオブジェクトにはアプリケーションWebページで入力されたフォームデータが保持されます。次に、そのオブジェクトを検査して、車の詳細をどのように取得できるかを見つける必要があります。

テキストボックスに入力オブジェクトのクラス名 supercars.form.CarForm を入力します。
Apply をクリックしてクラスメソッドを検索します。
結果が表示されたら、検索に一致する supercars.form.CarForm クラスを展開します。
必要な車の詳細を返すメソッドを探します。price、model、colorなどの get メソッドが見つかります。

メソッド呼び出しデータコレクターの作成

前の演習で得た知見を使用して、実行時に実行中のコードから車の詳細を直接取得するメソッド呼び出しデータコレクターを設定できます。

Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
Configuration タブを選択します。
Instrumentation リンクをクリックします。
Data Collectors タブを選択します。
Method Invocation Data Collectors の Add をクリックします。

車の詳細をキャプチャするメソッド呼び出しデータコレクターを作成します。

Name に SellCarMI-YOURINITIALS を指定します。
Transaction Snapshots を有効にします。
Transaction Analytics を有効にします。
with a Class Name that を選択します。
Class Name に supercars.dataloader.CarDataLoader を追加します。
Method Name に saveCar を追加します。

観察したように、SaveCarメソッドのインデックス0の入力パラメータはクラス CarForm のオブジェクトであり、そのオブジェクト内には getPrice() などの車の詳細プロパティを返すGetterメソッドがあります。

MIDCでその値をどのように取得したかを説明すると、以下のようになります

MIDCパネルの下部にある Add をクリックして、収集する新しいデータを指定します。
Display Nameに CarPrice_MIDC を指定します。
Collect Data Fromで、CarForm Object である Method Parameter of Index 0 を選択します。
Operation on Method Parameter で Use Getter Chain を選択します。CarForm内のメソッドを呼び出して車の詳細を返します。
次に、価格を返す CarForm クラス内のGetterメソッド getPrice() を指定します。
Save をクリックします。

color、modelなど、データを収集したいすべてのプロパティについて、上記の手順を繰り返します。

MIDC を保存し、"/Supercar-Trader/sell.do" ビジネストランザクションに適用します。

MIDCの実装にはJVMの再起動が必要です

EC2インスタンスにSSH接続します。
Tomcatサーバーをシャットダウンします。

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

まだ実行中のアプリケーションJVMが見つかった場合は、以下のコマンドを使用して残りのJVMを終了します。

sudo pkill -f Supercar-Trader

Tomcatサーバーを再起動します。

./startup.sh

Tomcatサーバーが実行されていることを確認します。これには数分かかる場合があります。

curl localhost:8080

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <title>Apache Tomcat/9.0.50</title>
        <link href="favicon.ico" rel="icon" type="image/x-icon" />
        <link href="tomcat.css" rel="stylesheet" type="text/css" />
    </head>

    <body>
        <div id="wrapper"
....

MDパラメータのAnalyticsの検証

Webサイトにアクセスし、Sell Carページでフォームを数回送信して手動で負荷をかけます。

次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。

Analytics タブを選択します。
Searches タブを選択し、新しい Drag and Drop Search を追加します。
+ Add ボタンをクリックし、新しい Drag and Drop Search を作成します。
+ Add Criteria をクリックします。
Application を選択し、アプリケーション名 Supercar-Trader-YOURINITIALS を検索します。
Business Parameters が Custom Method Data のフィールドとして表示されていることを確認します。
CarPrice Field にデータがあることを確認します。

まとめ

これで、実行時にNodeからSell Carトランザクションのビジネスデータをキャプチャしました。このデータは、AppDynamicsのAnalyticsおよびダッシュボード機能で使用でき、ビジネスにより多くのコンテキストを提供し、ITがビジネスに与える影響を測定できます。

ダッシュボードコンポーネント

2 minutes

ダッシュボードを構築する機能は、AppDynamicsの機能と価値の重要なコンポーネントです。この演習では、魅力的なダッシュボードを構築するために使用できるダッシュボードコンポーネントのいくつかを操作します。

新しいダッシュボードの作成

Dashboard & Reports タブを選択します。
Create Dashboard をクリックします。
SuperCar-Dashboard-YOURINITIALS などのダッシュボード名を入力します。
Canvas Type として Absolute Layout を選択します。
OK をクリックします。

新しく作成した空のダッシュボードを開きます。次に、さまざまなウィジェットタイプを追加します。

ダッシュボードコンポーネント：カスタムウィジェットビルダー

カスタムウィジェットビルダーは、数値ビュー、時系列、円グラフなど、データの表現を生成できる非常に柔軟なツールです。AppDynamics ADクエリ言語に基づいています。

ウィジェットを作成するには、以下の手順に従います

ダッシュボードの左上隅にある Edit Mode を切り替えます。
Add Widget をクリックします。
左側の Analytics タブを選択します。
Custom Widget Builder をクリックします。

カスタムウィジェットビルダーでは、多くのチャートタイプを作成できます。情報をドラッグアンドドロップするか、Advancedペインでクエリを作成できます。

ここでは、数値チャート、棒グラフ、円グラフについて説明します。

数値チャート

演習： エラーによって影響を受けた金額を定量化することで、ITパフォーマンスがビジネス収益に与える影響を示すことができます。

Numeric チャートタイプを選択します。
Applicationフィールドにフィルターを追加し、アプリケーション名 Supercar-Trader-YOURINITIALS を選択します。
/Supercar-Trader/sell.do ビジネストランザクションにフィルターを追加します。
User Experienceフィールドにフィルターを追加し、Error のみを選択してエラーの影響を表示します。
左側のパネルで CarPrice_MIDC フィールドを見つけ、Y軸にドラッグアンドドロップします。SUMがモデルごとの合計価格をキャプチャするために使用される集計であることに注意してください。
見やすくするためにフォントの色を赤に変更します。
Save をクリックします。

User ExperienceフィルターをNORMAL、SLOW、VERY SLOWのみに変更することで、正常に処理された金額についても同様のことができます。

また、Analyticsモジュールでカスタムメトリクスを作成し、影響を受けた金額がベースライン以上かどうかを示すヘルスルールを定義することで、このメトリクスをベースライン化することもできます。通貨のラベルを追加することもできます。

棒グラフ

演習： 次に、影響を受けた車種のトップを視覚化する棒グラフを作成します。このチャートは、User Experienceで分類されたすべての SellCar トランザクションの車種を表示します。

+ Add Widget、Analytics、Custom Widger Builder をクリックして新しいウィジェットを作成します。
Column チャートタイプを選択します。
以下のフィルターを追加します：Application = Supercar-Trader-YOURINITIALS およびBusiness Transaction = /Supercar-Trader/sell.do。
X軸に CarModel_MIDC と User Experience を追加します。
Save をクリックします。

このチャートタイプは、ニーズに応じて調整できます。例えば、X軸を顧客タイプ、会社、組織などでグループ化できます。以下の例を参照してください。

円グラフ

次に、sellCar トランザクションによって報告されたすべての車種とモデルごとの価格の合計を表示する円グラフを作成します。これにより、アプリケーションで最も需要の高いモデルが表示されます。

新しいウィジェットを作成します。
Pie チャートタイプを選択します。
以下のフィルターを追加します：Application = Supercar-Trader-YOURINITIALS およびBusiness Transaction = /Supercar-Trader/sell.do。
X軸に CarModel_MIDC を追加します。
Y軸に CarPrice_MIDC を追加します。SUM がモデルごとの合計価格をキャプチャするために使用される集計であることに注意してください。
タイトルに Sold by Car Model を追加します。
Save をクリックします。

円グラフウィジェットのその他の使用例については、以下の例を参照してください。

ダッシュボードコンポーネント：コンバージョンファネル

コンバージョンファネルは、複数のステップからなるプロセスを通じたユーザーまたはイベントのフローを視覚化するのに役立ちます。これにより、より成功した収束のためにどのステップを最適化できるかをより良く理解できます。また、コンバージョンファネルを使用して各ステップのITパフォーマンスを調べ、ユーザーエクスペリエンスへの影響とユーザー離脱の原因を理解することもできます。

ファネルは、その特定の順序でこのパスを実行したユーザーに基づいてフィルタリングされており、ステップごとの総訪問数ではないことに注意してください。

ファネル作成の最初のステップは、ファネルを通じた各ユーザーナビゲーションを表すことができるトランザクションの一意の識別子を選択することです。通常、Session IDはファネルの各ステップを通じて永続するため、最良の選択です。

Session IDはトランザクションからキャプチャできます。ファネルトランザクションのカウンターとして使用するには、SessionId データコレクターが必要です。

Javaアプリケーションの場合、AppDynamicsにはデフォルトのHTTPデータコレクターでSession IDをキャプチャする機能があります。有効になっていることを確認し、すべてのビジネストランザクションに適用してすべてのトランザクションでSession IDをキャプチャします。

Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
左側の Configuration タブを選択します。
Instrumentation をクリックします。
Data Collectors タブを選択します。
Default HTTP Request Request Data Collectors を編集します。
Transaction Analytics を選択します。
SessionID が選択されていることを確認します。
Save をクリックします。

次に、/Supercar-Trader/home.do ページから複数回ナビゲートして負荷をかけます。その後、アプリケーションの /Supercar-Trader/sell.do ページに直接ナビゲートします。

ダッシュボードに戻ってファネルウィジェットを作成します。

Edit スライダーを切り替えます。
Add Widget をクリックします。
Analytics タブを選択します。
Funnel Analysis をクリックします。
ドロップダウンリストから Transactions を選択します。
Count Distinct of でドロップダウンリストから uniqueSessionId を選択します。
Add Step をクリックします。Home Page と名前を付けます。
Add Criteria をクリックします。以下の条件を追加します：Application: Supercar-Trader-YOURINITIALS & Business Transactions: /Supercar-Trader/home.do。
Add Step をクリックします。SellCar Page と名前を付けます。
Add Criteria をクリックします。以下の条件を追加します：Application: Supercar-Trader-YOURINITIALS & Business Transactions: /Supercar-Trader/sell.do。
右側のパネルで Show Health チェックボックスを選択して、フローマップでトランザクションの正常性を視覚化します。
Save をクリックします。

ダッシュボードを構築する

20 minutes

演習 - 独自のダッシュボードを構築する

このラーニングラボの締めくくりとして、前の演習でメソッド呼び出しデータコレクターを使用してキャプチャしたビジネスデータとダッシュボードコンポーネントの理解を使用して、ITビジネスインパクトダッシュボードを構築します。

以下の例を参照し、同じデータとウィジェットを使用して独自のダッシュボードを構築してください。

おめでとうございます！BusinessIQ Fundamentalsラーニングラボを完了しました！

Browser Real User Monitoring (BRUM)

2 minutes

目標

このラーニングラボでは、AppDynamicsを使用してブラウザベースのアプリケーションの正常性を監視する方法を学習します。

このラボを完了すると、以下のことができるようになります

Controllerでブラウザアプリケーションを作成する
Browser Real User Monitoring (BRUM) エージェントを設定してWebアプリケーションの正常性を監視する
パフォーマンス問題をトラブルシューティングし、ブラウザ側またはサーバー側のどちらで発生したかにかかわらず根本原因を見つける

ワークショップ環境

ワークショップ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降Controllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降Application VMと呼びます。

Controller

このワークショップでは、AppDynamics SE Lab Controllerを使用します。

Application VM

Supercar TraderはJavaベースのWebアプリケーションです。

Supercar-Traderコレクションの目的は、AppDynamics Controllerの動的なトラフィック（ビジネストランザクション）を生成することです。

BRUMラボの前提条件

2 minutes

この演習では、以下のタスクを完了します

WebブラウザからAppDynamics Controllerにアクセスする。
アプリケーションへのトランザクション負荷を確認する。
必要に応じてアプリケーションとトランザクション負荷を再起動する。

Controllerへのログイン

Ciscoの認証情報を使用してAppDynamics SE Lab Controllerにログインします。

アプリケーションへのトランザクション負荷の確認

アプリケーションフローマップを確認します

last 1 hourの時間枠を選択します。
フローマップに5つの異なるTierが表示されていることを確認します。
過去1時間にわたって一貫した負荷があったことを確認します。

ビジネストランザクションのリストを確認します

左メニューの Business Transactions オプションをクリックします。
下記に示す11個のビジネストランザクションが表示されていることを確認します。
過去1時間に何らかの呼び出し数があることを確認します。

注意: Calls 列が表示されない場合は、View Options ツールバーボタンをクリックしてその列を表示できます。

Nodeのエージェントステータスを確認します

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
各Nodeの App Agent Status が過去1時間で90%以上であることを確認します。

必要に応じてアプリケーションと負荷生成の再起動

以下のコマンドを使用して、実行中のApache Tomcatインスタンスを停止します。

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

以下のコマンドを使用して、まだ実行中のアプリケーションJVMがないか確認します。

ps -ef | grep Supercar-Trader

まだ実行中のアプリケーションJVMが見つかった場合は、以下のコマンドを使用して残りのJVMを終了します。

sudo pkill -f Supercar-Trader

以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待ちます。

cd /opt/appdynamics/lab-artifacts/phantomjs
./stop_load.sh

Tomcatサーバーを再起動します

cd /usr/local/apache/apache-tomcat-9/bin
./startup.sh

2分待ってから、以下のコマンドを使用してApache Tomcatがポート8080で実行されていることを確認します。

sudo netstat -tulpn | grep LISTEN

以下の画像のような出力が表示され、ポート8080がApache Tomcatによって使用されていることが確認できるはずです。

以下のコマンドを使用して、アプリケーションの負荷生成を開始します。

cd /opt/appdynamics/lab-artifacts/phantomjs
./start_load.sh

以下の画像のような出力が表示されるはずです。

ブラウザアプリケーションの作成

2 minutes

この演習では、以下のタスクを完了します

WebブラウザからAppDynamics Controllerにアクセスする。
ControllerでBrowser Applicationを作成する。
Browser Applicationを設定する。

Controllerへのログイン

Ciscoの認証情報を使用してAppDynamics SE Lab Controllerにログインします。

ControllerでのBrowser Applicationの作成

以下の手順に従って、新しいブラウザアプリケーションを作成します。

Note

下記のステップ5で、ブラウザアプリケーションに一意の名前を作成することが非常に重要です。

トップメニューの User Experience タブをクリックします。
User Experience の下にある Browser Apps オプションをクリックします。
Add App をクリックします。
Create an Application manually オプションを選択します。
Supercar-Trader-Web-<your_initials_or_name>-<four_random_numbers> の形式でブラウザアプリケーションの一意の名前を入力します。
- 例1: Supercar-Trader-Web-JFK-3179
- 例2: Supercar-Trader-Web-JohnSmith-0953
OK をクリックします。

これで Supercar-Trader-Web-##-#### アプリケーションの Browser App Dashboard が表示されるはずです。

左メニューの Configuration タブをクリックします。
Instrumentation オプションをクリックします。

以下の手順に従って、ブラウザ監視エージェントによってキャプチャされるデータと一緒にIPアドレスが保存されるようにデフォルト設定を変更します。

Settings タブをクリックします。
右側のスクロールバーを使用して画面の下部までスクロールします。
Store IP Address チェックボックスをオンにします。
Save をクリックします。

Browser RUM用のController UIの設定について詳しくは、こちらをご覧ください。

エージェントインジェクションの設定

3 minutes

この演習では、以下のタスクを完了します

JavaScript Agentインジェクションを有効化する。
インジェクション用のビジネストランザクションを選択する。

JavaScript Agentインジェクションの有効化

AppDynamicsはJavaScript Agentをインジェクトするさまざまな方法をサポートしていますが、このラボではAuto-Injection方式を使用します。以下の手順に従ってJavaScript Agentの自動インジェクションを有効化します。

左メニューの Applications タブをクリックし、Supercar-Trader-##アプリケーションにドリルダウンします。
下部にある左メニューの Configuration タブをクリックします。
User Experience App Integration オプションをクリックします。

JavaScript Agent Injection タブをクリックします。
Enable をクリックして青色に切り替えます。
Supercar-Trader-Web-##-#### が選択されたブラウザアプリであることを確認します。前のセクションで作成したアプリケーションを選択してください。
Enable JavaScript Injection の下にある Enable チェックボックスをオンにします。
Save をクリックします。

Auto-Injectionが潜在的なビジネストランザクションを検出するまで数分かかります。この間に、以下の手順でBusiness Transaction Correlationを有効化します。新しいAPMエージェントでは、これは自動的に行われます。

Business Transaction Correlation タブをクリックします。
Manually Enable Business Transactions セクションの下にある Enable ボタンをクリックします。
Save をクリックします。

インジェクション用のビジネストランザクションの選択

以下の手順に従って、Auto-Injection用のビジネストランザクションを選択します。

JavaScript Agent Injection タブをクリックします。
検索ボックスに .do と入力します。
すべての9つのBTが表示されるまで Refresh List リンクをクリックします。
右側のリストボックスからすべてのビジネストランザクションを選択します。
矢印ボタンをクリックして左側のリストボックスに移動します。
すべてのビジネストランザクションが左側のリストボックスに移動されていることを確認します。
Save をクリックします。

JavaScript Agentの自動インジェクションの設定について詳しくは、こちらをご覧ください。

ブラウザアプリケーションに負荷が表示され始めるまで数分待ちます。

監視とトラブルシューティング - パート1

2 minutes

この演習では、以下のタスクを完了します

Browser Application Overviewダッシュボードをレビューする
Browser Application Geoダッシュボードをレビューする
Browser Application Usage Statsダッシュボードをレビューする
Supercar-Traderアプリケーションのウェブページをナビゲートする

Browser Application Overviewダッシュボードのレビュー

User Experienceダッシュボードに移動し、以下の手順に従ってブラウザアプリケーションのOverviewダッシュボードにドリルダウンします。

左メニューの User Experience タブをクリックします。
Webアプリケーション Supercar-Trader-Web-##-### を検索します。
Details をクリックするか、アプリケーション名をダブルクリックします。

Overviewダッシュボードには、設定可能なウィジェットのセットが表示されます。デフォルトのウィジェットには、アプリケーションパフォーマンスの一般的な高レベル指標を含む複数のグラフとリストが含まれています

End User Response Time Distribution
End User Response Time Trend
Total Page Requests by Geo
End User Response Time by Geo
Top 10 Browsers
Top 10 Devices
Page Requests per Minute
Top 5 Pages by Total Requests
Top 5 Countries by Total Page Requests

ダッシュボードの機能を探索します。

+ をクリックして、ダッシュボードに追加するグラフとウィジェットを選択します。
任意のウィジェットの右下隅をクリックしてドラッグしてサイズを変更します。
任意のウィジェットの枠線部分を選択して、ダッシュボード上で移動して配置します。
任意のウィジェットのタイトルをクリックして、詳細ダッシュボードにドリルダウンします。
任意のウィジェットの右上隅にある X をクリックしてダッシュボードから削除します。

ダッシュボードウィジェットのレイアウトに加えた変更は自動的に保存されます。

Browser Application Overviewダッシュボードについて詳しくは、こちらをご覧ください。

Browser Application Geoダッシュボードのレビュー

Geoダッシュボードは、ページロードに基づいて地理的な場所ごとに主要なパフォーマンスメトリクスを表示します。ダッシュボード全体に表示されるメトリクスは、マップまたはグリッドで現在選択されているリージョンのものです。マップビューは、右側のパネルに表示されるキータイミングメトリクスの国に対してラベル付きの負荷円を表示します。ただし、一部の国とリージョンはグリッドビューでのみ表示されます。

Browser Application Geoダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Geo Dashboard オプションをクリックします。
負荷円の1つをクリックしてリージョンにドリルダウンします。
リージョンの1つにカーソルを合わせてリージョンの詳細を表示します。
ズームスライダーを使用してズームレベルを調整します。
Configuration をクリックしてマップオプションを探索します。
グリッドビューとマップビューを切り替えます。

Browser Application Geoダッシュボードについて詳しくは、こちらをご覧ください。

Browser Application Usage Statsダッシュボードのレビュー

Usage Stats ダッシュボードは、ユーザーのブラウザタイプとデバイス/プラットフォームに基づいて集約されたページロード使用データを表示します。

Browser Application Usage Statsダッシュボードは、以下のことを発見するのに役立ちます

合計エンドユーザー応答時間の面で最も遅いブラウザ。
応答ページをレンダリングするのに最も遅いブラウザ。
エンドユーザーの大半が使用しているブラウザ。
特定の国やリージョンでエンドユーザーの大半が使用しているブラウザ。

Browser Application Usage Statsダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Usage Stats オプションをクリックします。
Show Versions オプションをクリックします。
負荷ごとにさまざまなブラウザとバージョンを確認します。
円グラフのセクションにカーソルを合わせて詳細を確認します。

以下の手順を使用して、ブラウザとバージョンごとのその他のメトリクスを探索します。

右側のスクロールバーを使用してページの下部までスクロールします。
ブラウザとバージョンごとの利用可能なメトリクスを探索します。
国ごとの利用可能なメトリクスを探索します。

Devicesダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Devices オプションをクリックします。
デバイス別の負荷の内訳を確認します。
円グラフのセクションにカーソルを合わせて詳細を確認します。
デバイス別の利用可能なパフォーマンスメトリクスを探索します。

Browser Application Usage Statsダッシュボードについて詳しくは、こちらをご覧ください。

Supercar-TraderアプリケーションのWebページのナビゲート

Browser Real User Monitoringエージェントを設定し、最初の一連の機能を探索したので、Supercar-TraderアプリケーションのWebページをナビゲートして追加の負荷を生成し、ユニークなブラウザセッションを記録しましょう。

Webブラウザでアプリのメインページを開きます。以下の例のURLでは、Application VMのIPアドレスまたは完全修飾ドメイン名を置き換えてください。

http://[application-vm-ip-address]:8080/Supercar-Trader/home.do

アプリケーションのホームページが表示されるはずです。

利用可能なフェラーリのリストを開きます。

トップメニューの Supercars タブをクリックします。
フェラーリのロゴをクリックします。

フェラーリのリストが表示されるはずです。

最初のフェラーリの画像をクリックします。

View Enquiries をクリックします。
Enquire をクリックします。

車に関する問い合わせを送信します。

問い合わせフォームのフィールドに適切なデータを入力します。
Submit をクリックします。

車を検索し、サイトの閲覧を続けます。

トップメニューの Search タブをクリックします。
検索ボックスに文字 A を入力し、Search をクリックします。
残りのタブをクリックしてWebサイトを探索します。

監視とトラブルシューティング - パート2

2 minutes

この演習では、以下のタスクを完了します

作成したBrowser Sessionをレビューする。
Pages & AJAX Requestsダッシュボードをレビューする。
特定のBase Pageのダッシュボードをレビューする。
Browser Snapshotをトラブルシューティングする。

作成したBrowser Sessionのレビュー

セッションは、ユーザーがアプリケーションとやり取りする体験を分析するための時間ベースのコンテキストと考えることができます。ブラウザセッションを調べることで、アプリケーションがどのように動作しているか、ユーザーがどのようにアプリケーションとやり取りしているかを理解できます。これにより、UIの変更やサーバー側のパフォーマンスの最適化など、アプリケーションをより適切に管理および改善できます。

Sessionsダッシュボードに移動し、前の演習でWebアプリケーションのページをナビゲートして作成したブラウザセッションを見つけます。以下の手順に従います。

Note

Webアプリケーションの最後のページにアクセスしてからブラウザセッションがセッションリストに表示されるまで、10分程度待つ必要がある場合があります。10分経ってもセッションが表示されない場合は、使用中のJava Agentのバージョンに問題がある可能性があります。

左メニューの Sessions タブをクリックします。
Session FieldsリストでIPアドレスのチェックをオンにします。
IPアドレスで作成したセッションを見つけます。
セッションをクリックし、View Details をクリックします。

作成したセッションを見つけて開いたら、以下の手順に従ってセッションビューのさまざまな機能を探索します。

注意: ステップ5に示されているように、セッション内のどのページにも View Snapshot リンクがない場合があります。後でこの演習で、リンクがあるセッションを見つけて探索します。

Session Summary リンクをクリックしてサマリーデータを表示します。
左側に表示されているページをクリックすると、右側にそのページの詳細が表示されます。
左側のリストで選択したページの完全名を常に確認できます。
ウォーターフォールビューの水平の青いバーをクリックすると、そのアイテムの詳細が表示されます。
一部のページには、サーバー側でキャプチャされた相関スナップショットへのリンクがある場合があります。
設定アイコンをクリックして、ページリストに表示される列を変更します。

Browser RUM Sessionsについて詳しくは、こちらをご覧ください。

Pages & AJAX Requestsダッシュボードのレビュー

Pages & AJAX Requestsダッシュボードに移動し、そこにあるオプションを確認し、以下の手順に従って特定のBase Pageダッシュボードを開きます。

左メニューの Pages & AJAX Requests タブをクリックします。
ツールバーのオプションを探索します。
localhost:8080/supercar-trader/car.do ページをクリックします。
Details をクリックしてBase Pageダッシュボードを開きます。

特定のBase Pageのダッシュボードのレビュー

Base Pageダッシュボードの上部には、Controller UIの右上隅にあるタイムフレームドロップダウンで選択された期間全体のEnd User Response Time、Load、Cache Hits、Page Views with JS errorsなどの主要なパフォーマンス指標が表示されます。Cache Hitsは、ソースからではなくCDNなどのキャッシュから取得されたリソースを示します。

Timing Breakdownセクションには、ページロードプロセスの各側面に必要な平均時間を表示するウォーターフォールグラフが表示されます。各メトリクスが何を測定するかについての詳細情報は、左側の名前にカーソルを合わせると定義がポップアップ表示されます。より詳細な情報については、Browser RUM Metricsを参照してください。

以下の手順に従って、localhost:8080/supercar-trader/car.do Base Pageの詳細を確認します。

タイムフレームドロップダウンを last 2 hours に変更します。
主要なパフォーマンス指標を探索します。
ウォーターフォールビューのメトリクスを探索します。
垂直スクロールバーを使用してページを下にスクロールします。
すべてのKPI Trendsのグラフを探索します。

Base Pageダッシュボードについて詳しくは、こちらをご覧ください。

Browser Snapshotのトラブルシューティング

Note

アプリケーションにブラウザスナップショットがない場合があり、その場合はワークフロー全体を実行できません。このセクションを別のデモアプリケーションで実行したい場合は、ブラウザアプリケーション AD-Ecommerce-Browser に切り替えることができます。

Browser Snapshotsリストダッシュボードに移動し、以下の手順に従って特定のBrowser Snapshotを開きます。

Browser Snapshots オプションをクリックします。
End User Response Time 列ヘッダーを2回クリックして、最も長い応答時間を上部に表示します。
左から3番目の列にグレーまたは青のアイコンがあるブラウザスナップショットをクリックします。
Details をクリックしてブラウザスナップショットを開きます。

ブラウザスナップショットを開いたら、詳細を確認し、以下の手順に従って長い応答時間の根本原因を見つけます。

ウォーターフォールビューを確認して、応答時間がどこで影響を受けたかを理解します。
Server Time メトリクスが長くなっていることに注意してください。Server Time のラベルにカーソルを合わせてその意味を理解します。
ブラウザスナップショットに自動的にキャプチャされ相関付けられたサーバー側トランザクションをクリックします。
View Details をクリックして、関連するサーバー側スナップショットを開きます。

相関するサーバー側スナップショットを開いたら、以下の手順を使用してパフォーマンス低下の根本原因を特定します。

ブラウザで費やされたトランザクション時間の割合が最小限であることがわかります。
ブラウザとWeb-Portal Tier間のタイミングは、ブラウザからの初期接続から完全な応答が返されるまでを表しています。
JDBCコールが最も時間がかかっていたことがわかります。
Drill Down をクリックして、Enquiry-Services Tier内のコードレベルビューを確認します。

Enquiry-Services Tierのスナップショットセグメントを開くと、データベースへのJDBCコールがトランザクションの問題を引き起こしていたことがわかります。

最も時間がかかった JDBC リンクをクリックして、JDBCコールの詳細パネルを開きます。
JDBC exit callの詳細パネルには、最も時間がかかった特定のクエリが表示されます。
完全なSQLステートメントとSQLパラメータ値を確認できます。

Browser Snapshotsについて詳しくは、こちらとこちらをご覧ください。

Database Monitoring

2 minutes

目標

このラボでは、AppDynamics Database Visibility Monitoringについて学びます。

このラボを完了すると、以下のことができるようになります

AppDynamics Database Visibility Agentのダウンロード
AppDynamics Database Visibility Agentのインストール
ControllerでのDatabase Collectorの構成
データベースの健全性監視
データベースパフォーマンス問題のトラブルシューティング

ワークショップ環境

ラボ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降はApplication VMと呼びます。

Controller VM

このワークショップでは AppDynamics SE Lab Controller を使用します。

Application VM

Supercar TraderはJavaベースのWebアプリケーションです。

Supercar-Traderコレクションの目的は、AppDynamics Controller向けに動的なトラフィック（ビジネストランザクション）を生成することです。

ラボの前提条件

3 minutes

この演習では、以下のタスクを完了します

WebブラウザからAppDynamics Controllerにアクセスする
アプリケーションへのトランザクション負荷を確認する
必要に応じてアプリケーションとトランザクション負荷を再起動する

Controller へのログイン

Ciscoの認証情報を使用して AppDynamics SE Lab Controller にログインします。

アプリケーションへのトランザクション負荷の確認

アプリケーションフローマップを確認します

last 1 hour の時間枠を選択します。
フローマップに5つの異なるティアが表示されていることを確認します。
過去1時間にわたって一貫した負荷があったことを確認します。

ビジネストランザクションのリストを確認します

左メニューの Business Transactions オプションをクリックします。
以下に示す11個のビジネストランザクションが表示されていることを確認します。
過去1時間にいくらかの呼び出し回数があることを確認します。

注意: Calls 列が表示されていない場合は、View Options ツールバーボタンをクリックしてその列を表示できます。

ノードのエージェントステータスを確認します

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
過去1時間の各ノードの App Agent Status が90%を超えていることを確認します。

必要に応じてアプリケーションと負荷生成を再起動

前のステップで行った確認のいずれかが検証できなかった場合は、Application VM にSSH接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。

以下のコマンドを使用して、実行中のApache Tomcatインスタンスを停止します。

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

以下のコマンドを使用して、まだ実行中のアプリケーションJVMがないか確認します。

ps -ef | grep Supercar-Trader

まだ実行中のアプリケーションJVMがある場合は、以下のコマンドを使用して残りのJVMを停止します。

sudo pkill -f Supercar-Trader

以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待ちます。

cd /opt/appdynamics/lab-artifacts/phantomjs
./stop_load.sh

Tomcatサーバーを再起動します

cd /usr/local/apache/apache-tomcat-9/bin
./startup.sh

2分間待ってから、以下のコマンドを使用してApache Tomcatがポート8080で実行されていることを確認します。

sudo netstat -tulpn | grep LISTEN

以下の画像のような出力が表示され、ポート8080がApache Tomcatによって使用されていることが確認できます。

以下のコマンドを使用して、アプリケーションの負荷生成を開始します。

cd /opt/appdynamics/lab-artifacts/phantomjs
./start_load.sh

以下の画像のような出力が表示されます。

Database Agent のダウンロード

2 minutes

この演習では、WebブラウザからAppDynamics Controllerにアクセスし、Database Visibilityエージェントをダウンロードします。

Controller へのログイン

Ciscoの認証情報を使用して AppDynamics SE Lab Controller にログインします。

Database Agent のダウンロード

画面左上のHomeタブを選択します。
Getting Started タブを選択します。
Getting Started Wizard をクリックします。

Databases をクリックします。

Database Agent のダウンロード

Select Database Typeドロップダウンメニューから MySQL を選択します。
Controller接続のデフォルト設定を受け入れます。
Click Here to Download をクリックします。

Database Visibility Agentファイルをローカルファイルシステムに保存します。

ブラウザから、以下の画像のようにエージェントファイルをローカルファイルシステムに保存するよう求められます（OSによって表示が異なる場合があります）。

Database Agent のインストール

2 minutes

AppDynamics Database Agentは、データベースインスタンスとデータベースサーバーのパフォーマンスメトリクスを収集するスタンドアロンのJavaプログラムです。Database Agentは、Java 1.8以上が動作する任意のマシンにデプロイできます。そのマシンは、AppDynamics Controllerと監視対象のデータベースインスタンスへのネットワークアクセスが必要です。

16 GBのメモリを搭載した標準的なマシンで実行されるDatabase Agentは、約25個のデータベースを監視できます。より大きなマシンでは、Database Agentは最大200個のデータベースを監視できます。

この演習では、以下のタスクを実行します

Database VisibilityエージェントファイルをApplication VMにアップロードする
ファイルシステムの特定のディレクトリにファイルを解凍する
Database Visibilityエージェントを起動する

Application VM への Database Agent のアップロード

この時点で、このワークショップで使用するEC2インスタンスに関する情報を受け取っているはずです。EC2インスタンスのIPアドレス、SSH接続に必要なユーザー名とパスワードを確認してください。

ローカルマシンでターミナルウィンドウを開き、Database Agentファイルがダウンロードされたディレクトリに移動します。以下のコマンドを使用して、ファイルをEC2インスタンスにアップロードします。これには時間がかかる場合があります。Windows OSを使用している場合は、WinSCPなどのプログラムを使用する必要があるかもしれません。

IPアドレスまたはパブリックDNSをインスタンスに合わせて更新してください。
ファイル名を正確なバージョンに合わせて更新してください。

cd ~/Downloads
scp -P 2222 db-agent-*.zip splunk@i-0267b13f78f891b64.splunk.show:/home/splunk

splunk@i-0267b13f78f891b64.splunk.show's password:
db-agent-25.7.0.5137.zip                                                                                                                               100%   70MB   5.6MB/s   00:12

Database Agent のインストール

Database Agentのzipファイルを解凍するディレクトリ構造を作成します。

cd /opt/appdynamics
mkdir dbagent

以下のコマンドを使用して、Database Agentのzipファイルをディレクトリにコピーし、ファイルを解凍します。Database Agentファイルの名前は、以下の例とは若干異なる場合があります。

cp ~/db-agent-*.zip /opt/appdynamics/dbagent/
cd /opt/appdynamics/dbagent
unzip db-agent-*.zip

Database Visibility エージェントの起動

以下のコマンドを使用して、Database Agentを起動し、起動したことを確認します。

DB エージェント名にイニシャルを追加してください。これは次のセクションで使用します。例：DBMon-Lab-Agent-IO

cd /opt/appdynamics/dbagent
nohup java -Dappdynamics.agent.maxMetrics=300000 -Ddbagent.name=DBMon-Lab-Agent-YOURINITIALS -jar db-agent.jar &
ps -ef | grep db-agent

以下の画像のような出力が表示されます。

Database Collector の構成

2 minutes

Database Collector の構成

Database Agent Collectorは、Database Agent内で実行され、データベースインスタンスとデータベースサーバーのパフォーマンスメトリクスを収集するプロセスです。1つのコレクターは1つのデータベースインスタンスのメトリクスを収集します。1つのDatabase Agentで複数のコレクターを実行できます。Database AgentがControllerに接続されると、Controllerで1つ以上のコレクターを構成できます。

この演習では、以下のタスクを実行します

WebブラウザからAppDynamics Controllerにアクセスする
ControllerでDatabase Collectorを構成する
Database Collectorがデータを収集していることを確認する

Controller へのログイン

Ciscoの認証情報を使用して AppDynamics SE Lab Controller にログインします。

Controller での Database Collector の構成

以下の手順に従って、クエリリテラルの設定を変更し、コレクター構成に移動します。

左メニューの Databases タブをクリックします。
左下の Configuration タブをクリックします。
Remove literals from the queries のチェックボックスのチェックを外します。
Collectors オプションをクリックします。

以下の手順に従って、新しいDatabase Collectorを構成します。

Add ボタンをクリックします。
データベースタイプとして MySQL を選択します。
Database Agentとして DBMon-Lab-Agent を選択し、以下のパラメータを入力します。
Collector Name: Supercar-MySQL-YOURINITIALS
Hostname or IP Address: localhost
Listener Port: 3306

Username: root
Password: Welcome1!

Advanced Options の下にある Monitor Operating System チェックボックスを選択します。
オペレーティングシステムとして Linux を選択し、以下のパラメータを入力します。
SSH Port: 22
Username: splunk
Password: EC2 インスタンスに SSH 接続するためにインストラクターから提供されたパスワード
OK をクリックしてコレクターを保存します。

Database Collector がデータを収集していることの確認

コレクターが実行されてデータを送信するまで10分間待ってから、以下の手順に従ってDatabase Collectorがデータベースに接続し、データベースメトリクスを収集していることを確認します。

左メニューの Databases タブをクリックします。
前のセクションで作成したCollectorを検索します：Supercar-MySQL-YOURINITIALS
ステータスが緑色で、エラーが表示されていないことを確認します。
Supercar-MySQLリンクをクリックしてデータベースの詳細を表示します。

注意：コレクターを構成してから Top 10 SQL Wait States と Queries タブのクエリが表示されるまで、最大18分かかる場合があります。

Database Collectorの構成の詳細については、こちらを参照してください。

監視とトラブルシューティング - パート1

2 minutes

監視とトラブルシューティング - パート1

この演習では、以下のタスクを実行します

データベースとサーバーのパフォーマンス全体ダッシュボードの確認
メインデータベースダッシュボードの確認
データベースアクティビティウィンドウのレポートの確認

データベースとサーバーのパフォーマンス全体ダッシュボードの確認

データベースとサーバーのパフォーマンス全体ダッシュボードでは、各データベースの健全性を一目で確認できます。

Filters：健全性、負荷、データベースの時間、またはタイプでフィルタリングするオプションを探索できます。
Actions：このウィンドウのデータを .csv形式のファイルでエクスポートします。
View Options：スパークチャートのオン/オフを切り替えます。
View：カードビューとリストビューを切り替えます。
Sort：ソートオプションを表示します。
Supercar-MySQL：メインデータベースダッシュボードにドリルダウンします。

メインデータベースダッシュボードの確認

メインデータベースダッシュボードには、以下を含むデータベースの主要なインサイトが表示されます

データベースを実行しているサーバーの健全性
指定された時間期間中の合計呼び出し回数
任意の時点での呼び出し回数
指定された時間期間中にSQL文の実行に費やされた合計時間
上位10件のクエリ待機状態
平均接続数
データベースタイプまたはベンダー
ダッシュボードの機能を探索します

ヘルスステータスの円をクリックして、サーバーの健全性の詳細を確認します

Green（緑）：サーバーは正常
Yellow（黄）：警告レベルの違反があるサーバー
Red（赤）：重大レベルの違反があるサーバー

データベースタイプまたはベンダーは常にここに表示されます。
指定された時間期間中にSQL文の実行に費やされた合計時間を確認します。
指定された時間期間中の合計実行回数を確認します。
チャート上の時系列にマウスを合わせて、記録されたメトリクスの詳細を確認します。

データポイントの上部にあるオレンジ色の円をクリックすると、選択した時間の前後15分のクエリ実行時間と待機状態を表示する時間比較レポートが表示されます。

チャートに表示されるスパイクを強調表示するには、マウスの左ボタンを押したまま左から右にドラッグします。
構成ボタンをクリックして、上位10件から不要な待機状態を除外します。
各待機状態のラベルにマウスを合わせて、より詳細な説明を確認します。
選択した時間期間中にクエリを実行しているアクティブな接続の平均数を確認します。

選択した時間期間のDBサーバーのOSメトリクスを表示するには

右側のスクロールバーを使用してダッシュボードの下部にスクロールします
CPU
Memory
Disk IO
Network IO

データベースアクティビティウィンドウのレポートの確認

Database Visibilityのデータベースアクティビティウィンドウには、最大9種類のレポートがあります。利用可能なレポートは、監視対象のデータベースプラットフォームによって異なります。この演習では、最も一般的な3つのレポートを確認します。

Wait State Report
Top Activity Report
Query Wait State Report

Wait State Report

このレポートは、データベース内のWait Events（待機状態）の時系列データを表示します。各待機状態は色分けされており、Y軸は秒単位の時間を表示します。このレポートは、テーブル形式でもデータを表示し、各SQL文の各待機状態に費やされた時間を強調表示します。

最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。たとえば、db file sequential readsは、インデックスのセグメントヘッダー競合またはディスク競合が原因である可能性があります。

Top Activity Report

このレポートは、データベースSQL文の上位の時間を時系列ビューで表示します。このレポートは、テーブル形式でもデータを表示し、上位10件のSQL文それぞれがデータベースで費やした時間を強調表示します。

このレポートを使用して、どのSQL文が最もデータベース時間を使用しているかを確認します。これにより、特定のSQL文がシステム全体のパフォーマンスに与える影響を判断でき、データベースパフォーマンスに最も影響を与えている文にチューニングの努力を集中させることができます。

Query Wait State Report

このレポートは、上位（10、50、100、200）クエリの待機時間を表示します。このレポートは、テーブル形式でもデータを表示し、各クエリが異なる待機状態で費やしている時間を強調表示します。列を使用して、異なる待機状態でクエリをソートします。

データベースアクティビティウィンドウのレポートの詳細については、こちらを参照してください。

監視とトラブルシューティング - パート2

クエリダッシュボードの確認

Queriesウィンドウには、データベースで最も時間を消費しているSQL文とストアドプロシージャが表示されます。クエリの重みをSQL待機時間などの他のメトリクスと比較して、チューニングが必要なSQLを特定できます。

Queries タブ：クエリウィンドウを表示します。
Top Queries ドロップダウン：上位5、10、100、または200件のクエリを表示します。
Filter by Wait States：クエリリストをフィルタリングする待機状態を選択できます。
Group Similar：同じ構文を持つクエリをグループ化します。
Weight (%) が最も大きいクエリをクリックします。
View Query Details：クエリの詳細にドリルダウンします。

コストの高いクエリの詳細確認

Database Queriesウィンドウでデータベースで最も時間を費やしている文を特定したら、それらのSQL文をチューニングするのに役立つ詳細をさらに掘り下げることができます。データベースインスタンスのQuery Detailsウィンドウには、Database Queriesウィンドウで選択したクエリの詳細が表示されます。

Resource consumption over time：クエリがリソースを使用してデータベースで費やした時間、実行回数、および消費したCPU時間を表示します。
Wait states：選択したSQL文をデータベースが処理するのにかかる時間に寄与するアクティビティです。最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。
Components Executing Similar Queries：このクエリに類似したクエリを実行しているノードを表示します。
Business Transactions Executing Similar Queries：このクエリに類似したクエリを実行しているJavaビジネストランザクションを表示します。

右側の外側のスクロールバーを使用して下にスクロールします。
Clients：選択したSQL文を実行したマシンと、各マシンが文の実行に要した合計時間の割合を表示します。
Sessions：各データベースインスタンスの使用状況のセッションです。
Query Active in Database：このSQLによってアクセスされたスキーマを表示します。
Users：このクエリを実行したユーザーを表示します。
Query Hashcode：データベースサーバーがキャッシュ内でこのSQL文をより迅速に見つけるための一意のIDを表示します。
Query：選択したSQL文の完全な構文を表示します。Queryカードの右上隅にある鉛筆アイコンをクリックして、識別しやすいようにクエリ名を編集できます。
Execution Plan：クエリ実行プランウィンドウを表示します。

コストの高いクエリのトラブルシューティング

Database Query Execution Planウィンドウは、クエリに最も効率的な実行プランを決定するのに役立ちます。問題のある可能性のあるクエリを発見したら、EXPLAIN PLAN文を実行して、データベースが作成した実行プランを確認できます。

クエリの実行プランは、クエリがインデックスの使用を最適化し、効率的に実行されているかどうかを示します。この情報は、実行が遅いクエリのトラブルシューティングに役立ちます。

Execution Plan タブをクリックします。
Type 列の結合タイプが各テーブルでALLであることに注目してください。
結合タイプの1つにマウスを合わせて、結合タイプの説明を確認します。
Extras 列のエントリを調べます。
各エントリにマウスを合わせて、エントリの説明を確認します。

次に、Object Browserを使用してテーブルのインデックスを調査しましょう。

Object Browser オプションをクリックして、テーブルのスキーマの詳細を表示します。
Database オプションをクリックします。
supercars スキーマをクリックして、テーブルのリストを展開します。
CARS テーブルをクリックして、テーブルの詳細を表示します。
CAR_ID列が主キーとして定義されていることがわかります。

外側のスクロールバーを使用してページを下にスクロールします。
テーブルに定義された主キーインデックスに注目してください。

MANUFACTURER テーブルをクリックして、その詳細を表示します。
MANUFACTURER_ID 列が主キーとして定義されていないことに注目してください。
ページを下にスクロールして、テーブルにインデックスが定義されていないことを確認します。

MANUFACTURER_ID列には、テーブルに対するクエリのパフォーマンスを向上させるためにインデックスを作成する必要があります。異なるクエリを分析した場合、根本的な問題は異なる可能性がありますが、このラボで示される最も一般的な問題は、クエリがMANUFACTURERテーブルとの結合を実行しているか、そのテーブルを直接クエリしていることが原因です。

SmartAgent Deployment

2 minutes

はじめに

AppDynamics Smart Agent は、インフラストラクチャの包括的な監視機能を提供する軽量でインテリジェントなエージェントです。このセクションでは、4つの異なるデプロイアプローチについて説明します。これにより、組織のニーズと既存のツールに最適な方法を選択できます。

Smart Agent とは

Smart Agentは、AppDynamicsの次世代監視エージェントであり、以下を提供します

統合監視：インフラストラクチャ、アプリケーション、サービスを単一のエージェントで監視
軽量設計：最小限のリソースフットプリント
自動検出：アプリケーションを自動的に検出して監視
ネイティブ計装：アプリケーションパフォーマンスへの深い可視性
柔軟なデプロイ：複数のインストールと管理オプション

デプロイアプローチ

このセクションでは、Smart Agentを大規模にデプロイするための4つの異なるアプローチについて説明します

1. リモートインストール（smartagentctl）

SSH経由でデプロイするための smartagentctl CLIツールを使用する最も直接的なアプローチです。

最適な用途：

中程度の数のホストへの迅速なデプロイ
既存のCI/CDインフラストラクチャがない環境
テストおよび概念実証シナリオ
デプロイプロセスの直接制御

主な機能：

SSHベースの直接デプロイ
シンプルなYAML構成
追加のツールが不要
同時実行のサポート

2. Jenkins 自動化

完全なライフサイクル管理のためのJenkinsパイプラインを使用したエンタープライズグレードのデプロイです。

最適な用途：

すでにJenkinsを使用している組織
複雑なデプロイワークフロー
承認ゲートが必要な環境
既存のCI/CDパイプラインとの統合

主な機能：

パラメータ化されたパイプライン
数千のホストへのバッチ処理
完全なライフサイクル管理
集中ログとレポート

3. GitHub Actions 自動化

セルフホストランナーを使用したGitHub Actionsワークフローによる最新のCI/CDアプローチです。

最適な用途：

バージョン管理にGitHubを使用しているチーム
クラウドネイティブ環境
GitOpsワークフロー
Webベースの管理を好む分散チーム

主な機能：

11の専用ワークフロー
VPC内のセルフホストランナー
GitHubシークレット統合
スケーラビリティのための自動バッチ処理

4. Ansible 自動化

Infrastructure as CodeのためのAnsibleプレイブックを使用した構成管理アプローチです。

最適な用途：

構成管理にAnsibleを使用しているチーム
宣言的なインフラストラクチャ定義
フリート全体での一貫した状態管理

主な機能：

Infrastructure as Code（IaC）
冪等性のあるプレイブック
インベントリ管理
ロールベースの構成

適切なアプローチの選択

要素	リモートインストール	Jenkins	GitHub Actions	Ansible
セットアップの複雑さ	低	中	中	低
スケーラビリティ	良好（数百ホスト）	優秀（数千）	優秀（数千）	優秀（数千）
前提条件	SSH アクセスのみ	Jenkins サーバー	GitHub アカウント	Ansible Control Node
学習曲線	最小	中程度	中程度	低/中程度
自動化レベル	手動実行	完全自動化	完全自動化	完全自動化
最適なユースケース	迅速なデプロイ	エンタープライズ CI/CD	モダン DevOps	Infrastructure as Code

すべてのアプローチに共通する機能

どのデプロイ方法を選択しても、すべてのアプローチで以下の項目が提供されます

✅ リモートホストへの SSH ベースのデプロイ
✅ より高速なデプロイのための 同時実行
✅ 完全なライフサイクル管理（インストール、開始、停止、アンインストール）
✅ コントローラー設定の 構成管理
✅ エラー処理 とログ
✅ 数百から数千のホストへの スケーラビリティ

ワークショップ構成

各デプロイアプローチには専用のセクションがあります

リモートインストール - CLIベースの直接デプロイ
Jenkins 自動化 - パイプラインベースのエンタープライズデプロイ
GitHub Actions - 最新のワークフローベースのデプロイ
Ansible 自動化 - Infrastructure as Codeデプロイ

ニーズに応じて、1つまたはすべてのアプローチに従うことができます。

Tip

Smart Agentのデプロイが初めての場合は、より自動化されたソリューションに進む前に、基本を理解するために リモートインストール アプローチから始めることをお勧めします。

前提条件

いずれのデプロイアプローチに進む場合でも、以下の項目を確認してください

コントローラーアクセスを持つAppDynamicsアカウント
アカウント名とアクセスキー
SSHアクセスを持つターゲットホスト
ホストからAppDynamics Controllerへのネットワーク接続
ターゲットホストでの適切な権限

次のステップ

お好みのデプロイアプローチを選択し、そのセクションに進んでください

シンプルに始める：基礎を学ぶためにリモートインストールから始める
Jenkins でスケール：エンタープライズグレードの自動化のためにJenkinsに移行
GitHub でモダン化：クラウドネイティブワークフローのためにGitHub Actionsを採用
Ansible で自動化：宣言的な構成管理のためにAnsibleを使用

各セクションでは、Smart Agentを大規模にデプロイするための完全なハンズオンガイダンスを提供します。

リモートインストール

2 minutes

はじめに

このワークショップでは、smartagentctl コマンドラインツールを使用して、複数のリモートホストに同時に AppDynamics Smart Agent をインストールおよび管理する方法を紹介します。このアプローチは、JenkinsやGitHub Actionsなどの追加の自動化ツールを必要とせずに、SSHベースのリモート実行を使用してサーバーフリートにSmart Agentを迅速にデプロイするのに最適です。

学習内容

このワークショップでは、以下の方法を学びます

remote.yaml ファイルを使用した リモートホストの構成
config.ini を使用した Smart Agent 設定の構成
SSH経由で複数のホストに同時に Smart Agent をデプロイ
インフラストラクチャ全体でリモートから エージェントの開始と停止
すべてのリモートホストでの エージェントステータスの確認
一般的なインストールと接続の問題の トラブルシューティング

主な機能

🚀 SSH による直接デプロイ - 追加の自動化プラットフォームが不要
🔄 完全なライフサイクル管理 - エージェントのインストール、開始、停止、アンインストール
🏗️ Configuration as Code - YAMLおよびINIベースの構成ファイル
🔐 セキュア - SSHキーベースの認証
📈 同時実行 - 並列デプロイのための構成可能な同時実行性
🎛️ シンプルな CLI - 使いやすいsmartagentctlコマンドラインインターフェース

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                  Remote Installation Architecture                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Control Node (smartagentctl) ──▶ SSH Connection               │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップには以下が含まれます

前提条件 - 必要なアクセス、ツール、権限
構成 - config.ini と remote.yaml のセットアップ
インストールと起動 - リモートホストへのSmart Agentのデプロイと起動
トラブルシューティング - 一般的な問題と解決策

前提条件

smartagentctlがインストールされたControl Node
すべてのリモートホストへのSSHアクセス
認証用に構成されたSSH秘密鍵
Control Nodeでのsudo権限
SSHが有効になっているリモートホスト
AppDynamicsアカウントの認証情報

利用可能なコマンド

smartagentctl ツールは、以下のリモート操作をサポートしています

start --remote - リモートホストにSmart Agentをインストールして起動
stop --remote - リモートホストのSmart Agentを停止
status --remote - リモートホストのSmart Agentステータスを確認
install --remote - 起動せずにSmart Agentをインストール
uninstall --remote - リモートホストからSmart Agentを削除
--service フラグ - systemdサービスとしてインストール

すべてのコマンドは、詳細なログのための --verbose フラグをサポートしています。

Tip

このワークショップを進める最も簡単な方法は以下を使用することです

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）と右（▶️）のカーソルキー

1. 前提条件

リモートホストにSmart Agentをインストールする前に、以下の前提条件が満たされていることを確認してください

必要なアクセス

SSH アクセス：Smart Agentをインストールする予定のすべてのリモートホストへのSSHアクセスが必要です
SSH 秘密鍵：認証用に構成されたSSH秘密鍵
Sudo 権限：Control Nodeユーザーはsmartagentctlを実行するためにsudo権限が必要です
リモート SSH：リモートホストでSSHが有効になっており、アクセス可能である必要があります

ディレクトリ構造

Smart Agentのインストールディレクトリは、Control Nodeに設定されている必要があります

cd /home/ubuntu/appdsm

ディレクトリには以下が含まれます

smartagentctl - SmartAgentを管理するためのコマンドラインユーティリティ
smartagent - SmartAgentバイナリ
config.ini - メイン構成ファイル
remote.yaml - リモートホスト構成ファイル
conf/ - 追加の構成ファイル
lib/ - 必要なライブラリ

AppDynamics アカウント情報

AppDynamicsアカウントから以下の情報が必要です

Controller URL：AppDynamics SaaSコントローラーエンドポイント（例：fso-tme.saas.appdynamics.com）
Account Name：AppDynamicsアカウント名
Account Access Key：AppDynamicsアカウントアクセスキー
Controller Port：通常、HTTPS接続の場合は443

ターゲットホストの要件

リモートホストは以下の要件を満たす必要があります

オペレーティングシステム：Ubuntu/Linuxベースのシステム
SSH サーバー：SSHデーモンが実行中で接続を受け入れている状態
ユーザーアカウント：適切な権限を持つユーザーアカウント（通常はroot）
ネットワークアクセス：AppDynamics Controllerに到達できること
ディスク容量：Smart Agentのインストールに十分な容量（通常100MB未満）

セキュリティに関する考慮事項

続行する前に、以下のセキュリティベストプラクティスを確認してください

SSH キー：強力なSSHキーを使用（RSA 4096ビットまたはED25519）
アクセスキー：AccountAccessKeyを安全に保管
ホストキー検証：本番環境では、ホストキーの検証を計画
SSL/TLS：コントローラー通信には常にSSL/TLSを使用
ログファイル：機密情報を含むログファイルへのアクセスを制限

前提条件の確認

SSH 接続の確認

リモートホストへのSSH接続をテストします

ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@<remote-host-ip>

SSH キーのパーミッションの確認

SSHキーに適切なパーミッションがあることを確認します

chmod 600 /home/ubuntu/.ssh/id_rsa

ネットワーク接続の確認

リモートホストが相互に、およびインターネットに到達できることを確認します

ping <remote-host-ip>

Sudo アクセスの確認

sudo権限があることを確認します

sudo -v

すべての前提条件が満たされていれば、構成を開始する準備ができています。

2. 構成

Smart Agentのリモートインストールには、2つの主要な構成ファイルが必要です：Smart Agent設定用の config.ini と、リモートホストと接続パラメータを定義する remote.yaml です。

構成ファイルの概要

両方の構成ファイルは、Smart Agentのインストールディレクトリに配置する必要があります

cd /home/ubuntu/appdsm

構成する2つのファイル

config.ini - すべてのリモートホストにデプロイされるSmart Agent構成
remote.yaml - リモートホストとSSH接続設定

config.ini - Smart Agent 構成

config.ini ファイルには、すべてのリモートホストにデプロイされるメインのSmart Agent構成が含まれています。

場所： /home/ubuntu/appdsm/config.ini

Controller 構成

AppDynamics Controller接続を構成します

ControllerURL    = fso-tme.saas.appdynamics.com
ControllerPort   = 443
FMServicePort    = 443
AccountAccessKey = your-access-key-here
AccountName      = your-account-name
EnableSSL        = true

主要パラメータ：

ControllerURL：AppDynamics SaaSコントローラーエンドポイント
ControllerPort：コントローラーのHTTPSポート（デフォルト：443）
FMServicePort：Flow Monitoringサービスポート
AccountAccessKey：AppDynamicsアカウントアクセスキー
AccountName：AppDynamicsアカウント名
EnableSSL：SSL/TLS暗号化を有効にする（本番環境では true にする必要があります）

Common Configuration

エージェントのIDとポーリング動作を定義します

[CommonConfig]
AgentName            = smartagent
PollingIntervalInSec = 300
Tags                 = environment:production,region:us-east
ServiceName          = my-application

パラメータ：

AgentName：エージェントの名前識別子
PollingIntervalInSec：エージェントがデータをポーリングする頻度（秒単位）
Tags：エージェントを分類するためのカスタムタグ（カンマ区切り）
ServiceName：論理グループ化のためのオプションのサービス名

Telemetry 設定

ログとプロファイリングを構成します

[Telemetry]
LogLevel  = DEBUG
LogFile   = /opt/appdynamics/appdsmartagent/log.log
Profiling = false

パラメータ：

LogLevel：ログの詳細度（DEBUG、INFO、WARN、ERROR）
LogFile：リモートホストでログが書き込まれるパス
Profiling：パフォーマンスプロファイリングを有効にする（true/false）

TLS クライアント設定

プロキシとTLS設定を構成します

[TLSClientSetting]
Insecure        = false
AgentHTTPProxy  =
AgentHTTPSProxy =
AgentNoProxy    =

パラメータ：

Insecure：TLS証明書の検証をスキップ（本番環境では推奨されません）
AgentHTTPProxy：HTTPプロキシサーバー URL（必要な場合）
AgentHTTPSProxy：HTTPSプロキシサーバー URL（必要な場合）
AgentNoProxy：プロキシをバイパスするホストのカンマ区切りリスト

Auto Discovery

自動アプリケーション検出を構成します

[AutoDiscovery]
RunAutoDiscovery          = false
ExcludeLabels             = process.cpu.usage,process.memory.usage
ExcludeProcesses          =
ExcludeUsers              =
AutoDiscoveryTimeInterval = 4h
AutoInstall               = false

パラメータ：

RunAutoDiscovery：アプリケーションを自動的に検出する（true/false）
ExcludeLabels：検出から除外するメトリクス
ExcludeProcesses：監視から除外するプロセス名
ExcludeUsers：監視から除外するユーザーアカウント
AutoDiscoveryTimeInterval：検出を実行する頻度（例：4h、30m）
AutoInstall：検出されたアプリケーションを自動的にインストール

Task Configuration

ネイティブ計装を構成します

[TaskConfig]
NativeEnable        = true
UserPortalUserName  =
UserPortalPassword  =
UserPortalAuth      = none
AutoUpdateLdPreload = true

パラメータ：

NativeEnable：ネイティブ計装を有効にする
AutoUpdateLdPreload：LD_PRELOAD設定を自動的に更新

remote.yaml - リモートホスト構成

remote.yaml ファイルは、Smart Agentがインストールされるリモートホストと接続パラメータを定義します。

場所： /home/ubuntu/appdsm/remote.yaml

構成例

max_concurrency: 4
remote_dir: "/opt/appdynamics/appdsmartagent"
protocol:
  type: ssh
  auth:
    username: ubuntu
    private_key_path: /home/ubuntu/.ssh/id_rsa
    privileged: true
    ignore_host_key_validation: true
    known_hosts_path: /home/ubuntu/.ssh/known_hosts
hosts:
  - host: "172.31.1.243"
    port: 22
    user: root
    group: root
  - host: "172.31.1.48"
    port: 22
    user: root
    group: root
  - host: "172.31.1.142"
    port: 22
    user: root
    group: root
  - host: "172.31.1.5"
    port: 22
    user: root
    group: root

グローバル設定

max_concurrency： 同時に処理するホストの最大数

デフォルト：4
多くのホストへの高速デプロイのために増加
ネットワークまたはリソースの制約がある場合は減少

remote_dir： リモートホストのインストールディレクトリ

デフォルト：/opt/appdynamics/appdsmartagent
絶対パスである必要があります
ユーザーは書き込み権限を持っている必要があります

Protocol 構成

type： 接続プロトコル

値：ssh

auth.username： 認証用のSSHユーザー名

例：ubuntu、ec2-user、centos
リモートホストで構成されているユーザーと一致する必要があります

auth.private_key_path： SSH秘密鍵へのパス

絶対パスである必要があります
キーはアクセス可能で適切なパーミッション（600）を持っている必要があります

auth.privileged： 昇格した権限でエージェントを実行

true：root/systemdサービスとしてインストール
false：ユーザープロセスとしてインストール
推奨：本番デプロイでは true

auth.ignore_host_key_validation： SSHホストキー検証をスキップ

true：検証をスキップ（テストに便利）
false：ホストキーを検証（本番環境で推奨）

auth.known_hosts_path： SSH known_hostsファイルへのパス

デフォルト：/home/ubuntu/.ssh/known_hosts
ホストキー検証が有効な場合に使用

ホスト定義

各ホストエントリには以下が必要です

host： リモートマシンのIPアドレスまたはホスト名

IPv4、IPv6、またはホスト名が使用可能
Control Nodeから到達可能である必要があります

port： SSHポート

デフォルト：22
SSHが非標準ポートで実行されている場合は変更

user： Smart Agentプロセスを所有するユーザーアカウント

システム全体のインストールでは通常 root
ユーザー固有のインストールでは通常のユーザーも可能

group： Smart Agentプロセスを所有するグループ

通常はユーザーと一致（例：root）

ホストの追加

追加のリモートホストを追加するには、hosts リストに追加します

hosts:
  - host: "10.0.1.10"
    port: 22
    user: root
    group: root
  - host: "10.0.1.11"
    port: 22
    user: root
    group: root

Tip

必要な数だけホストを追加できます。max_concurrency 設定で並列処理されるホスト数を制御します。

構成の確認

インストールを進める前に、構成ファイルを確認してください

remote.yaml の確認

cat /home/ubuntu/appdsm/remote.yaml

以下を確認します

すべてのホストIPアドレスが正しいこと
SSHキーパスが有効であること
リモートディレクトリパスが適切であること

config.ini の確認

cat /home/ubuntu/appdsm/config.ini

以下を確認します

Controller URLとアカウント情報が正しいこと
ログファイルパスが有効であること
設定が環境要件に一致していること

YAML 構文の検証

YAMLファイルが正しくフォーマットされていることを確認します

python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"

コマンドがエラーなしで完了すれば、YAML構文は有効です。

構成ファイルの準備ができたら、インストールを進めることができます。

3. インストールと起動

設定ファイルの準備ができたら、smartagentctl コマンドラインツールを使用してリモートホストにSmart Agentをインストールし、起動できます。

インストールプロセスの概要

インストールプロセスは以下の手順で構成されます

接続: 定義されたすべてのホストへのSSH接続を確立します
転送: Smart Agentのバイナリと設定をリモートホストにコピーします
インストール: 各ホストの /opt/appdynamics/appdsmartagent/ にSmart Agentをインストールします
起動: 各リモートホストでSmart Agentプロセスを起動します
ログ出力: コンソールとログファイルに詳細な進捗を出力します

ステップ1: インストールディレクトリに移動

Smart Agentのインストールディレクトリに移動します

cd /home/ubuntu/appdsm

ステップ2: 設定ファイルの確認

インストールを開始する前に、設定ファイルが正しく設定されていることを確認します

リモートホスト設定の確認

cat remote.yaml

すべてのホストIPアドレス、ポート、SSH設定が正しいことを確認します。

エージェント設定の確認

cat config.ini

コントローラーURL、アカウント認証情報、その他の設定が正確であることを確認します。

ステップ3: リモートホストで Smart Agent を起動

以下のコマンドを実行して、remote.yaml で定義されたすべてのリモートホストでSmart Agentを起動します

sudo ./smartagentctl start --remote --verbose

コマンドの内訳

sudo: 特権操作に必要です
./smartagentctl: 制御ユーティリティ
start: Smart Agentを起動するコマンド
--remote: リモートホストにデプロイ（remote.yaml から読み取り）
--verbose: 詳細なデバッグログを有効化

注意

--verbose フラグの使用を強く推奨します。インストールの進捗に関する詳細な出力が提供され、問題の特定に役立ちます。

ステップ4: インストールの監視

--verbose フラグにより、以下の詳細な出力が提供されます

SSH接続ステータス
ファイル転送の進捗
各ホストでのインストール手順
エージェントの起動ステータス
エラーや警告

期待される出力

以下のような出力が表示されます

Starting Smart Agent deployment to remote hosts...
Connecting to 172.31.1.243:22...
Connection successful: 172.31.1.243
Transferring Smart Agent binaries...
Installing Smart Agent on 172.31.1.243...
Starting Smart Agent on 172.31.1.243...
Smart Agent started successfully on 172.31.1.243

Connecting to 172.31.1.48:22...
...

ステップ5: インストールの確認

インストールが完了したら、リモートホストでSmart Agentが実行されていることを確認します。

リモートでのステータス確認

statusコマンドを使用してすべてのリモートホストを確認します

sudo ./smartagentctl status --remote --verbose

各ホストに問い合わせて、Smart Agentが実行中かどうかを報告します。

コントロールノードのログ確認

コントロールノードのログを確認します

tail -f /home/ubuntu/appdsm/log.log

リモートホストにSSHで接続して確認

リモートホストにSSHで接続して直接確認することもできます

ssh ubuntu@172.31.1.243
tail -f /opt/appdynamics/appdsmartagent/log.log
ps aux | grep smartagent

その他のコマンド

起動せずにインストールのみ実行

Smart Agentを起動せずにインストールのみ行います

sudo ./smartagentctl install --remote --verbose

バイナリと設定をコピーしますが、エージェントプロセスは起動しません。

Smart Agent の停止

すべてのリモートホストでSmart Agentを停止します

sudo ./smartagentctl stop --remote --verbose

システムサービスとしてインストール

Smart Agentをsystemdサービスとしてインストールします（本番環境で推奨）

sudo ./smartagentctl start --remote --verbose --service

サービスとしてインストールした場合

システム起動時にSmart Agentが自動的に起動します
systemctl コマンドで管理できます
システムログとの統合が向上します

Smart Agent のアンインストール

リモートホストからSmart Agentを完全に削除します

sudo ./smartagentctl uninstall --remote --verbose

警告

uninstallコマンドはリモートホストからすべてのSmart Agentファイルを削除します。重要な設定ファイルやログファイルのバックアップがあることを確認してください。

AppDynamics Controller での確認

リモートホストでSmart Agentを起動した後

AppDynamics Controller にログイン: コントローラーURLに移動します
Servers に移動: Controller UIのServersセクションを確認します
エージェントの確認: Smart Agentがリストに表示されます
Metric の確認: 各ホストからMetricが収集されていることを確認します

期待されるタイムライン

エージェントの登録: エージェントは通常、起動後1～2分以内にControllerに表示されます
初期 Metric: 最初のMetricは通常5分以内に到着します
完全なデータ: 最初のポーリング間隔後に完全なデータ収集が開始されます（config.ini で設定）

ログファイルの場所

ログはコントロールノードとリモートホストの両方に書き込まれます

場所	パス	説明
コントロールノード	`/home/ubuntu/appdsm/log.log`	インストールとデプロイのログ
リモートホスト	`/opt/appdynamics/appdsmartagent/log.log`	エージェントのランタイムログ

同時実行数について

remote.yaml の max_concurrency 設定は並列実行を制御します

低い値（1-2）: 逐次処理、低速だが安全
デフォルト（4）: ほとんどの環境に適したバランス
高い値（8以上）: 多数のホストへの高速デプロイ、より多くのリソースが必要

例: 12台のホストで max_concurrency: 4 の場合

第1バッチ: ホスト1-4を同時に処理
第2バッチ: ホスト5-8を同時に処理
第3バッチ: ホスト9-12を同時に処理

各リモートホストでの処理内容

startコマンドを実行すると、各リモートホストで以下の処理が行われます

ディレクトリの作成: /opt/appdynamics/appdsmartagent/ を作成します
ファイル転送: smartagent バイナリ、config.ini、ライブラリをコピーします
権限の設定: 適切なファイル権限を設定します
プロセスの起動: Smart Agentプロセスを起動します
確認: プロセスが実行中であることを確認します

次のステップ

Smart Agentのインストールと起動が正常に完了した後

AppDynamics Controller UIにエージェントが表示されることを確認します
Metricが収集されていることを確認します
必要に応じてアプリケーションモニタリングを設定します
アラートとDashboardを設定します
エージェントの正常性とパフォーマンスを監視します

問題が発生した場合は、トラブルシューティングセクションに進みます。

4. トラブルシューティング

このセクションでは、Smart Agentをリモートホストにデプロイする際に発生する一般的な問題とその解決方法について説明します。

SSH接続の問題

問題: リモートホストに接続できない

症状:

接続タイムアウトエラー
“Permission denied” メッセージ
ホストキー検証の失敗

解決方法:

1. SSHキーの権限を確認

SSHキーには正しい権限が必要です:

chmod 600 /home/ubuntu/.ssh/id_rsa
chmod 644 /home/ubuntu/.ssh/id_rsa.pub
chmod 700 /home/ubuntu/.ssh

2. SSH接続を手動でテスト

各リモートホストへの接続をテストします:

ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@172.31.1.243

これが失敗する場合、問題はsmartagentctlではなくSSH設定にあります。

3. リモートホストの到達性を確認

ネットワーク接続性を確認します:

ping 172.31.1.243
telnet 172.31.1.243 22

4. SSHユーザーの確認

remote.yaml のユーザー名がSSHユーザーと一致していることを確認します:

protocol:
  auth:
    username: ubuntu  # Must match your SSH user

5. Known Hosts の確認

ホストキー検証が有効な場合、ホストがknown_hostsに登録されていることを確認します:

ssh-keyscan 172.31.1.243 >> /home/ubuntu/.ssh/known_hosts

または、remote.yaml でホストキー検証を一時的に無効化します:

protocol:
  auth:
    ignore_host_key_validation: true

警告

ホストキー検証の無効化はテスト目的でのみ使用してください。本番環境では必ず有効にしてください。

権限の問題

問題: インストール中に権限が拒否される

症状:

ディレクトリ作成時の “Permission denied”
/opt/appdynamics/ への書き込み不可
権限不足エラー

解決方法:

1. コントロールノードでのSudoアクセスを確認

sudo -v

2. Privileged 設定を確認

remote.yaml で privileged: true が設定されていることを確認します:

protocol:
  auth:
    privileged: true

3. リモートユーザーの権限を確認

リモートユーザーにはsudo権限またはroot権限が必要です。リモートホストでテストします:

ssh ubuntu@172.31.1.243
sudo mkdir -p /opt/appdynamics/test
sudo rm -rf /opt/appdynamics/test

4. リモートディレクトリの権限を確認

カスタムインストールディレクトリを使用している場合、書き込み可能であることを確認します:

ssh ubuntu@172.31.1.243
ls -la /opt/appdynamics/

エージェントが起動しない

問題: エージェントのインストールは成功するが起動しない

症状:

インストールはエラーなく完了
リモートホストでエージェントプロセスが実行されていない
コントロールノードのログにエラーなし

解決方法:

1. リモートホストのログを確認

リモートホストにSSHで接続してエージェントのログを確認します:

ssh ubuntu@172.31.1.243
tail -100 /opt/appdynamics/appdsmartagent/log.log

以下を示すエラーメッセージを探します:

設定エラー
ネットワーク接続の問題
依存関係の不足

2. エージェントプロセスの確認

エージェントプロセスが実行中かどうかを確認します:

ssh ubuntu@172.31.1.243
ps aux | grep smartagent

実行されていない場合、手動で起動を試みます:

ssh ubuntu@172.31.1.243
cd /opt/appdynamics/appdsmartagent
sudo ./smartagent

3. 設定ファイルの確認

config.ini が正しく転送されたことを確認します:

ssh ubuntu@172.31.1.243
cat /opt/appdynamics/appdsmartagent/config.ini

以下を確認します:

コントローラーURLが正しいこと
アカウント認証情報が有効であること
必須フィールドがすべて入力されていること

4. コントローラーへの接続テスト

リモートホストからAppDynamics Controllerへの接続を確認します:

ssh ubuntu@172.31.1.243
curl -I https://fso-tme.saas.appdynamics.com

5. システムリソースの確認

リモートホストに十分なリソースがあることを確認します:

ssh ubuntu@172.31.1.243
df -h  # Check disk space
free -m  # Check memory

設定エラー

問題: 無効な設定

症状:

YAML解析エラー
無効な設定パラメーターエラー
設定エラーでエージェントが起動に失敗

解決方法:

1. YAML構文の検証

remote.yaml のYAML構文エラーを確認します:

python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"

一般的なYAMLの問題:

インデントの誤り（タブではなくスペースを使用）
コロンの欠落
引用符で囲まれていない特殊文字

2. INIファイル形式の確認

config.ini の構文エラーを確認します:

cat /home/ubuntu/appdsm/config.ini

一般的なINIの問題:

セクションヘッダーの欠落（例: [CommonConfig]）
無効なパラメーター名
等号の欠落

3. コントローラー認証情報の検証

AppDynamicsの認証情報が正しいことを確認します:

ControllerURL: https:// や /controller を含めないこと
AccountAccessKey: 完全なアクセスキーであること
AccountName: アカウント名と正確に一致すること

正しい形式の例:

ControllerURL    = fso-tme.saas.appdynamics.com
AccountAccessKey = abc123xyz789
AccountName      = fso-tme

エージェントが Controller に表示されない

問題: エージェントが起動するが Controller UI に表示されない

症状:

リモートホストでエージェントプロセスが実行中
エージェントログにエラーなし
Controller UIにエージェントが表示されない

解決方法:

1. 初期登録を待つ

エージェントが起動してからControllerに表示されるまで1～5分かかる場合があります。

2. コントローラー設定の確認

エージェントがコントローラーに到達できることを確認します:

ssh ubuntu@172.31.1.243
ping fso-tme.saas.appdynamics.com
curl -I https://fso-tme.saas.appdynamics.com

3. エージェントログで接続エラーを確認

コントローラー接続エラーを確認します:

ssh ubuntu@172.31.1.243
grep -i "error\|fail\|controller" /opt/appdynamics/appdsmartagent/log.log

4. SSL/TLS設定の確認

config.ini でSSLが有効になっていることを確認します:

EnableSSL = true

5. ファイアウォールルールの確認

リモートホストからControllerへのアウトバウンドHTTPS（ポート443）が許可されていることを確認します。

6. アカウント認証情報の確認

Controller UIでAccountAccessKeyとAccountNameが正しいことを再確認します:

AppDynamics Controllerにログインします
Settings > Licenseに移動します
アカウント名とアクセスキーを確認します

パフォーマンスとスケーリングの問題

問題: デプロイが遅い、またはタイムアウトする

症状:

デプロイに時間がかかりすぎる
多数のホストへのデプロイ時にタイムアウトエラー
システムリソースの枯渇

解決方法:

1. 同時実行数の調整

問題が発生している場合、remote.yaml の max_concurrency を減らします:

max_concurrency: 2  # Lower value for slower, more stable deployment

リソースに余裕がある場合、より高速なデプロイのために増やします:

max_concurrency: 8  # Higher value for faster deployment

2. バッチに分けてデプロイ

非常に大規模なデプロイの場合、ホストを複数のグループに分割します:

remote-batch1.yaml:

hosts:
  - host: "172.31.1.1"
  - host: "172.31.1.2"
  - host: "172.31.1.3"

remote-batch2.yaml:

hosts:
  - host: "172.31.1.4"
  - host: "172.31.1.5"
  - host: "172.31.1.6"

その後、各バッチを個別にデプロイします。

3. ネットワーク帯域幅の確認

デプロイ中のネットワーク使用量を監視します:

iftop

帯域幅が飽和している場合、同時実行数を減らすか、ピーク外の時間帯にデプロイします。

ログ分析

コントロールノードのログ確認

詳細なデプロイログを確認します:

tail -f /home/ubuntu/appdsm/log.log

以下を確認します:

SSH接続の失敗
ファイル転送エラー
権限拒否エラー
タイムアウトメッセージ

リモートホストのログ確認

リモートホストのエージェントランタイムログを確認します:

ssh ubuntu@172.31.1.243
tail -f /opt/appdynamics/appdsmartagent/log.log

以下を確認します:

コントローラー接続エラー
設定エラー
エージェント起動の失敗
ネットワークの問題

ログの詳細度を上げる

より詳細なログが必要な場合、config.ini で LogLevel を DEBUG に設定します:

[Telemetry]
LogLevel = DEBUG

ヘルプの取得

問題が解決しない場合:

ドキュメントの確認: smartagentctlのヘルプを確認します:
```
./smartagentctl --help
./smartagentctl start --help
```
AppDynamics ドキュメントの確認: AppDynamicsドキュメントポータルを参照します
ログファイルの確認: コントロールノードとリモートホストの両方のログを必ず確認します
コンポーネントを個別にテスト:
- SSH接続性を個別にテストします
- 単一のホストでエージェントの起動を手動でテストします
- コントローラーへの接続性を個別に確認します
診断情報の収集:
- コントロールノードのログ
- リモートホストのログ
- 設定ファイル（機密データは削除）
- エラーメッセージとスタックトレース

一般的なエラーメッセージ

エラーメッセージ	原因	解決方法
“Permission denied (publickey)”	SSHキー認証の失敗	SSHキーのパスと権限を確認
“Connection refused”	SSHポートにアクセスできない	ファイアウォールルールとSSHデーモンを確認
“No such file or directory”	設定ファイルが見つからない	設定ファイルの存在とパスが正しいことを確認
“YAML parse error”	無効なYAML構文	YAMLパーサーで構文を検証
“Controller unreachable”	ネットワーク接続の問題	リモートホストからコントローラーへの接続性をテスト
“Invalid credentials”	アカウントキーまたは名前が不正	AppDynamics の認証情報を確認

トラブルシューティングのベストプラクティス

常に –verbose フラグを使用: デバッグのための詳細な出力を提供します
最初に単一のホストでテスト: スケールアウトする前に1台のホストにデプロイします
すぐにログを確認: デプロイ直後にログを確認します
前提条件の確認: デプロイ前にすべての要件が満たされていることを確認します
接続性を個別にテスト: SSHとネットワーク接続性を個別に確認します
手動コマンドを使用: 手動でのSSHとエージェント起動をテストして問題を切り分けます

ヒント

トラブルシューティングでは、より複雑な問題に移る前に、最も簡単なテスト（例: ping、SSH接続性）から始めてください。

Jenkins 自動化

2 minutes

はじめに

このワークショップでは、Jenkins を使用して複数のEC2インスタンスにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、Jenkinsパイプラインを活用したスケーラブルで安全かつ再現性のあるSmart Agent運用方法を説明します。

学習内容

このワークショップでは、以下の内容を学びます:

Jenkinsを使用して複数のホストに同時に Smart Agent をデプロイ する
安全なSSHおよびAppDynamicsアクセスのために Jenkins 認証情報を設定 する
柔軟なデプロイシナリオのために パラメータ化されたパイプラインを作成 する
数千台のホストに対応するために バッチ処理を実装 する
インストール、設定、停止、クリーンアップを含む エージェントの完全なライフサイクルを管理 する
自動エラー追跡とレポートにより 障害を適切に処理 する

主な機能

並列デプロイ - 複数のホストに同時にデプロイ
完全なライフサイクル管理 - エージェントのインストール、アンインストール、停止、クリーンアップ
Infrastructure as Code - すべてのパイプラインをバージョン管理
セキュア - Jenkins認証情報によるSSH鍵ベースの認証
大規模スケーラブル - 自動バッチ処理により数千台のホストにデプロイ
Jenkins Agent - AWS VPC内で実行

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                    Jenkins-based Deployment                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Developer ──▶ Jenkins Master ──▶ Jenkins Agent (AWS VPC)      │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップには以下の内容が含まれます:

アーキテクチャと設計 - システム設計とネットワークトポロジーの理解
Jenkins セットアップ - Jenkins、認証情報、エージェントの設定
パイプライン作成 - デプロイパイプラインの作成と設定
デプロイワークフロー - デプロイの実行とインストールの検証

前提条件

Jenkinsサーバー（2.300以降）とPipelineプラグイン
ターゲットEC2インスタンスと同じVPC内のJenkinsエージェント
認証用のSSHキーペア
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

GitHub リポジトリ

すべてのパイプラインコードと設定ファイルはGitHubリポジトリで公開されています:

https://github.com/chambear2809/sm-jenkins

リポジトリには以下が含まれます:

完全なJenkinsfileパイプライン定義
詳細なセットアップドキュメント
設定例
トラブルシューティングガイド

ヒント

このワークショップを最も簡単にナビゲートするには、以下を使用します:

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）および右（▶️）カーソルキー

アーキテクチャと設計

5 minutes

システムアーキテクチャ

JenkinsベースのSmart Agentデプロイシステムは、ハブ・アンド・スポーク型のアーキテクチャを採用しています。AWS VPC内のJenkinsエージェントがSSH経由で複数のターゲットホストへのデプロイを調整します。

全体アーキテクチャ

graph TB
    subgraph "Jenkins Infrastructure"
        JM[Jenkins Master<br/>Web UI + Orchestration]
        JA[Jenkins Agent<br/>EC2 in VPC<br/>Label: linux]
    end

    subgraph "AWS VPC - Private Network"
        subgraph "Target EC2 Instances"
            H1[Host 1<br/>172.31.1.243]
            H2[Host 2<br/>172.31.1.48]
            H3[Host 3<br/>172.31.1.5]
            HN[Host N<br/>172.31.x.x]
        end
    end

    DEV[Developer/Operator]
    APPD[AppDynamics<br/>Controller]

    DEV -->|1. Triggers Pipeline| JM
    JM -->|2. Assigns Job| JA
    JA -->|3. SSH Deploy<br/>Private IPs| H1
    JA -->|3. SSH Deploy<br/>Private IPs| H2
    JA -->|3. SSH Deploy<br/>Private IPs| H3
    JA -->|3. SSH Deploy<br/>Private IPs| HN

    H1 -.->|Metrics| APPD
    H2 -.->|Metrics| APPD
    H3 -.->|Metrics| APPD
    HN -.->|Metrics| APPD

    style JM fill:#d4e6f1
    style JA fill:#a9cce3
    style H1 fill:#aed6f1
    style H2 fill:#aed6f1
    style H3 fill:#aed6f1
    style HN fill:#aed6f1

ネットワークアーキテクチャ

すべてのインフラストラクチャは、共有セキュリティグループを持つ単一のAWS VPC内で稼働します。JenkinsエージェントはプライベートIP経由でターゲットホストと通信するため、ターゲットホストにパブリックIPアドレスは不要です。

VPC レイアウト

┌─────────────────────────────────────────────────────────────────┐
│                        AWS VPC (10.0.0.0/16)                    │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │              Security Group: app-agents-sg                │  │
│  │  Rules:                                                   │  │
│  │  - Inbound: SSH (22) from Jenkins Agent only             │  │
│  │  - Outbound: HTTPS (443) to AppDynamics Controller       │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐      │
│  │ Jenkins Agent│    │  Target EC2  │    │  Target EC2  │      │
│  │              │    │              │    │              │      │
│  │ Private IP:  │───▶│ Private IP:  │    │ Private IP:  │      │
│  │ 172.31.50.10 │SSH │ 172.31.1.243 │    │ 172.31.1.48  │      │
│  │              │───▶│              │    │              │      │
│  │ Label: linux │    │ Ubuntu 20.04 │    │ Ubuntu 20.04 │      │
│  └──────────────┘    └──────────────┘    └──────────────┘      │
│         │                    │                    │             │
│         │                    │                    │             │
│         └────────────────────┴────────────────────┘             │
│                              │                                  │
└──────────────────────────────┼──────────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────┐
                    │   AppDynamics    │
                    │    Controller    │
                    │  (SaaS/On-Prem)  │
                    └──────────────────┘

デプロイフロー

完全なデプロイシーケンス

sequenceDiagram
    participant Dev as Developer
    participant JM as Jenkins Master
    participant JA as Jenkins Agent<br/>(VPC)
    participant TH as Target Hosts<br/>(VPC)
    participant AppD as AppDynamics<br/>Controller

    Dev->>JM: 1. Trigger Pipeline
    JM->>JM: 2. Load Credentials
    JM->>JA: 3. Schedule Job
    JA->>JA: 4. Prepare Batches

    loop For Each Batch
        JA->>TH: 5. SSH Copy Files (SCP)
        JA->>TH: 6. SSH Execute Commands
        TH->>TH: 7. Install/Config Agent
        TH-->>JA: 8. Return Status
    end

    JA->>JM: 9. Report Results
    JM->>Dev: 10. Show Build Status

    TH->>AppD: 11. Send Metrics (Post-Install)
    AppD-->>Dev: 12. View Monitoring Data

コンポーネントの詳細

Jenkins Master

役割:

ユーザー向けWeb UI
パイプラインのオーケストレーション
認証情報の管理
ビルド履歴とログ
ジョブのスケジューリング

要件:

Jenkins 2.300以降
プラグイン: Pipeline、SSH Agent、Credentials、Git
エージェントへのネットワークアクセス

Jenkins Agent

配置場所:

AWS VPC（ターゲットと同一）
プライベートネットワークアクセス

役割:

パイプラインステージの実行
ターゲットホストへのSSH接続
ファイル転送（SCP）
バッチ処理ロジック
エラー収集

要件:

ラベル: linux
Java 11以降
SSHクライアント
ネットワーク: すべてのターゲットへのSSH接続
ディスク: アーティファクト用に約20GB

ターゲットホスト

前提条件:

Ubuntu 20.04以降
SSHサーバーが稼働していること
sudoアクセス権を持つユーザー
SSH鍵が認証済みであること

デプロイ後:

/opt/appdynamics/
└── appdsmartagent/
    ├── smartagentctl
    ├── config.ini
    └── agents/
        ├── machine/
        ├── java/
        ├── node/
        └── db/

セキュリティアーキテクチャ

セキュリティレイヤー

AWS VPC 分離
- エージェント用のプライベートサブネット
- 直接のインターネットアクセスは不要
- VPCフローログの有効化
セキュリティグループ
- Jenkins AgentのIPをホワイトリスト登録
- ポート22（SSH）のみ
- ステートフルファイアウォールルール
SSH 鍵認証
- パスワード認証なし
- Jenkins認証情報に鍵を保存
- 一時鍵ファイル（600パーミッション）
- 各ビルド後に鍵を削除
Jenkins RBAC
- ロールベースのアクセス制御
- パイプラインレベルの権限
- 認証情報のアクセス制限
- 監査ログの有効化
シークレット管理
- コードやログにシークレットを含めない
- 認証情報のバインディングのみ
- 環境変数のマスキング
- 自動シークレットローテーション（オプション）

認証情報のフロー

flowchart LR
    subgraph "Jenkins Master"
        CS[Credentials Store<br/>Encrypted at Rest]
        JM[Jenkins Master]
    end

    subgraph "Jenkins Agent"
        WS[Workspace<br/>Temp Files]
        KEY[SSH Key File<br/>600 permissions]
    end

    subgraph "Target Hosts"
        TH[EC2 Instances<br/>Authorized Keys]
    end

    CS -->|Binding| JM
    JM -->|Secure Copy| KEY
    KEY -->|SSH Auth| TH
    WS -.->|Cleanup| X[Deleted]
    KEY -.->|Cleanup| X

    style CS fill:#fdeaa8
    style KEY fill:#fadbd8
    style X fill:#e8e8e8

バッチ処理

システムは自動バッチ処理を使用して、あらゆるスケールのデプロイに対応します。デフォルトでは、ホストは256台ずつのバッチで処理され、バッチ内のすべてのホストは並列でデプロイされます。

バッチ処理の仕組み

HOST LIST (1000 hosts)              BATCH_SIZE = 256

Host 001: 172.31.1.1                ┌──────────────────┐
Host 002: 172.31.1.2      ────────▶ │   BATCH 1        │
    ...                              │   Hosts 1-256    │ ───┐
Host 256: 172.31.1.256               │   Sequential     │    │
                                     └──────────────────┘    │
Host 257: 172.31.1.257               ┌──────────────────┐    │
Host 258: 172.31.1.258   ────────▶  │   BATCH 2        │    │ SEQUENTIAL
    ...                              │   Hosts 257-512  │    │ EXECUTION
Host 512: 172.31.1.512               │   Sequential     │    │
                                     └──────────────────┘    │
Host 513: 172.31.1.513               ┌──────────────────┐    │
    ...                              │   BATCH 3        │    │
Host 768: 172.31.1.768   ────────▶  │   Hosts 513-768  │ ───┘
                                     └──────────────────┘
Host 769: 172.31.1.769               ┌──────────────────┐
    ...                              │   BATCH 4        │
Host 1000: 172.31.2.232  ────────▶  │   Hosts 769-1000 │
                                     │   (232 hosts)    │
                                     └──────────────────┘

WITHIN EACH BATCH:
┌────────────────────────────────────────┐
│  All hosts deploy in PARALLEL          │
│                                        │
│  Host 1 ──┐                           │
│  Host 2 ──┤                           │
│  Host 3 ──┼─▶ Background processes (&)│
│    ...    │                           │
│  Host 256─┘   └─▶ wait command        │
└────────────────────────────────────────┘

スケーリング特性

デプロイ速度（デフォルト BATCH_SIZE=256）:

10台 → 1バッチ → 約2分
100台 → 1バッチ → 約3分
500台 → 2バッチ → 約6分
1,000台 → 4バッチ → 約12分
5,000台 → 20バッチ → 約60分

速度に影響する要因:

ネットワーク帯域幅（ホストあたり19MBのパッケージ）
SSH接続のオーバーヘッド（ホストあたり約1秒）
ターゲットホストのCPU/ディスク速度
Jenkinsエージェントのリソース

次のステップ

アーキテクチャを理解したところで、Jenkinsのセットアップと認証情報の設定に進みます。

Jenkins セットアップ

10 minutes

前提条件

開始する前に、以下を準備してください:

Jenkinsサーバー（バージョン2.300以降）
ターゲットEC2インスタンスと同じAWS VPC内のJenkinsエージェント
ターゲットホストへの認証用SSHキーペア
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

必要な Jenkins プラグイン

Manage Jenkins → Plugins → Available Plugins から以下のプラグインをインストールします:

Pipeline（コアプラグイン、通常はプリインストール済み）
SSH Agent Plugin
Credentials Plugin（通常はプリインストール済み）
Git Plugin（SCMを使用する場合）

インストール手順:

Manage Jenkins → Plugins に移動します
Available タブをクリックします
各プラグインを検索します
選択して Install をクリックします

Jenkins Agent の設定

JenkinsエージェントはプライベートIP経由でターゲットEC2インスタンスに到達できる必要があります。主に2つの方法があります:

オプション A: EC2 インスタンスをエージェントとして使用

ターゲットホストと 同じ VPC に EC2 インスタンスを起動 します

Java をインストール します（Jenkinsに必要）:

sudo apt-get update
sudo apt-get install -y openjdk-11-jdk

Jenkins にエージェントを追加 します:
- Manage Jenkins → Nodes → New Node に移動します
- 名前: aws-vpc-agent（または任意の名前）
- タイプ: Permanent Agent
- 設定:
  - Remote root directory: /home/ubuntu/jenkins
  - Labels: linux（パイプラインのエージェントラベルと一致させる必要があります）
  - Launch method: Launch agent via SSH
  - Host: EC2のプライベートIP
  - Credentials: エージェント用のSSH認証情報を追加

オプション B: 既存の Linux エージェントを使用

エージェントに linux ラベルが設定されていることを確認します
ターゲットホストへのネットワーク接続を確認します
SSHクライアントがインストールされていることを確認します

エージェントラベルの設定

警告

このワークショップのすべてのパイプラインは linux ラベルを使用します。エージェントにこのラベルが設定されていることを確認してください。

ラベルを設定または変更するには:

Manage Jenkins → Nodes に移動します
エージェントをクリックします
Configure をクリックします
Labels を linux に設定します
Save をクリックします

認証情報のセットアップ

Manage Jenkins → Credentials → System → Global credentials (unrestricted) に移動します。

パイプラインを動作させるために、3つの認証情報を作成する必要があります。

1. ターゲットホスト用 SSH 秘密鍵

この認証情報により、JenkinsがターゲットEC2インスタンスにSSH接続できるようになります。

Type: SSH Username with private key

ID: ssh-private-key（正確に一致させる必要があります）
Description: SSH key for EC2 target hosts
Username: ubuntu（または使用するSSHユーザー）
Private Key: 以下のいずれかを選択:
- Enter directly: PEMファイルの内容を貼り付け
- From file: PEMファイルをアップロード
- From Jenkins master: パスを指定

フォーマット例:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
...
-----END RSA PRIVATE KEY-----

2. デプロイ対象ホストリスト

この認証情報には、Smart Agentをデプロイするすべてのターゲットホストのリストが含まれます。

Type: Secret text

ID: deployment-hosts（正確に一致させる必要があります）
Description: List of target EC2 host IPs
Secret: 改行区切りのIPアドレスを入力

例:

172.31.1.243
172.31.1.48
172.31.1.5
172.31.10.20
172.31.10.21

重要

フォーマット要件:

1行に1つのIPアドレス
カンマなし
スペースなし
余分な文字なし
Unix改行コード（LF、CRLFではない）を使用

3. AppDynamics アカウントアクセスキー

この認証情報には、Smart Agentの認証に使用するAppDynamicsアカウントアクセスキーが含まれます。

Type: Secret text

ID: account-access-key（正確に一致させる必要があります）
Description: AppDynamics account access key
Secret: AppDynamicsのアクセスキー

例: abcd1234-ef56-7890-gh12-ijklmnopqrst

ヒント

AppDynamicsのアクセスキーは、Controllerの Settings → License → Account で確認できます。

認証情報のセキュリティベストプラクティス

認証情報管理のベストプラクティスに従ってください:

Jenkinsの認証情報暗号化を使用する（組み込み機能）
Jenkinsのロールベース認可でアクセスを制限する
SSH鍵を定期的にローテーションする
EC2インスタンスに最小権限のIAMロールを使用する
認証情報アクセスの監査ログを有効にする
認証情報をバージョン管理にコミットしない

Smart Agent パッケージのセットアップ

Smart AgentのZIPファイルは、Jenkinsからアクセス可能な場所に配置する必要があります。推奨される方法は、Jenkinsのホームディレクトリに保存することです。

Smart Agent のダウンロード

# AppDynamics からダウンロード
curl -o appdsmartagent_64_linux.zip \
  "https://download.appdynamics.com/download/prox/download-file/smart-agent/latest/appdsmartagent_64_linux.zip"

# ダウンロードを確認
ls -lh appdsmartagent_64_linux.zip

保存場所

パイプラインはSmart Agent ZIPを /var/jenkins_home/smartagent/appdsmartagent.zip で参照します。

以下のいずれかの方法で対応できます:

この場所にZIPファイルを正確に配置する
パイプラインパラメータ SMARTAGENT_ZIP_PATH をZIPファイルの場所に変更する

設定の確認

パイプライン作成に進む前に、セットアップを確認します:

1. エージェントの状態確認

Manage Jenkins → Nodes に移動します
エージェントが「online」と表示されていることを確認します
ラベルが linux に設定されていることを確認します

2. SSH 接続のテスト

SSHが動作することを確認するための簡単なテストパイプラインを作成します:

pipeline {
    agent { label 'linux' }
    stages {
        stage('Test SSH') {
            steps {
                withCredentials([
                    sshUserPrivateKey(credentialsId: 'ssh-private-key',
                                     keyFileVariable: 'SSH_KEY',
                                     usernameVariable: 'SSH_USER'),
                    string(credentialsId: 'deployment-hosts', variable: 'HOSTS')
                ]) {
                    sh '''
                        echo "Testing SSH credentials..."
                        echo "$HOSTS" | head -1 | while read HOST; do
                            ssh -i $SSH_KEY \
                                -o StrictHostKeyChecking=no \
                                -o ConnectTimeout=10 \
                                $SSH_USER@$HOST \
                                "echo 'Connection successful'"
                        done
                    '''
                }
            }
        }
    }
}

3. 認証情報の存在確認

Manage Jenkins → Credentials に移動します
以下の3つの認証情報がリストに表示されていることを確認します:
- ssh-private-key
- deployment-hosts
- account-access-key

よくある問題のトラブルシューティング

エージェントが利用できない

症状: パイプライン実行時に「No agent available」エラーが発生する

解決策:

Manage Jenkins → Nodes を確認します
エージェントがオンラインであることを確認します
エージェントに linux ラベルがあることを確認します
エージェントの接続をテストします

SSH 接続の失敗

症状: SSH経由でターゲットホストに接続できない

解決策:

# Jenkins エージェントマシンからテスト
ssh -i /path/to/key ubuntu@172.31.1.243 -o ConnectTimeout=10

# セキュリティグループがエージェントからの SSH を許可していることを確認
# 秘密鍵がターゲットの公開鍵と一致していることを確認

認証情報が見つからない

症状:「Credential not found」エラーが発生する

解決策:

認証情報のIDが正確に一致していることを確認します:
- ssh-private-key
- deployment-hosts
- account-access-key
認証情報のスコープが Global に設定されていることを確認します

ターゲットホストでの権限拒否

症状: SSHは成功するがコマンドが権限拒否で失敗する

解決策:

# ターゲットホストで、ユーザーが sudoers に含まれていることを確認
sudo visudo
# 以下の行を追加:
ubuntu ALL=(ALL) NOPASSWD: ALL

次のステップ

Jenkinsの認証情報とエージェントの設定が完了したら、デプロイパイプラインの作成に進みます。

パイプライン作成

10 minutes

概要

GitHubリポジトリには、Smart Agentのライフサイクル管理のための4つのメインパイプラインが含まれています:

Deploy Smart Agent - Smart Agentサービスのインストールと起動
Install Machine Agent - smartagentctlによるMachine Agentのインストール
Install Database Agent - smartagentctlによるDatabase Agentのインストール
Cleanup All Agents - /opt/appdynamicsディレクトリの削除

すべてのパイプラインコードは sm-jenkins GitHub リポジトリで公開されています。

パイプラインファイル

リポジトリには以下のJenkinsfileパイプライン定義が含まれています:

sm-jenkins/
└── pipelines/
    ├── Jenkinsfile.deploy                  # Deploy Smart Agent
    ├── Jenkinsfile.install-machine-agent  # Install Machine Agent
    ├── Jenkinsfile.install-db-agent       # Install Database Agent
    └── Jenkinsfile.cleanup                # Cleanup All Agents

Jenkins でのパイプライン作成

使用したい各Jenkinsfileに対して、以下の手順でJenkinsにパイプラインを作成します。

方法1: SCM からのパイプライン（推奨）

この方法では、パイプラインコードをバージョン管理に保持し、変更を自動的に同期します。

ステップ1: リポジトリのフォークまたはクローン

まず、リポジトリを自分のGitHubアカウントまたは組織にフォークするか、元のリポジトリを直接使用します。

リポジトリ URL: https://github.com/chambear2809/sm-jenkins

ステップ2: Jenkins でパイプラインを作成

Jenkins Dashboard に移動します
New Item をクリックします
アイテム名を入力します（例: Deploy-Smart-Agent）
Pipeline を選択します
OK をクリックします

ステップ3: パイプラインの設定

パイプライン設定ページで以下を設定します:

General セクション:

Description: Deploys AppDynamics Smart Agent to multiple hosts
Discard old builds はチェックしないままにします（または必要に応じて設定）

Build Triggers:

手動実行のみの場合はチェックしないままにします
必要に応じてWebhookやポーリングを設定します

Pipeline セクション:

Definition: Pipeline script from SCM を選択します
SCM: Git を選択します
Repository URL: https://github.com/chambear2809/sm-jenkins
Credentials: プライベートリポジトリの場合は追加します
Branch Specifier: */main（または */master）
Script Path: pipelines/Jenkinsfile.deploy

ステップ4: 保存

Save をクリックしてパイプラインを作成します。

ステップ5: 他のパイプラインでも繰り返す

作成したい各パイプラインに対して、適切なスクリプトパスを使用してステップ2-4を繰り返します:

パイプライン名	スクリプトパス
Deploy-Smart-Agent	`pipelines/Jenkinsfile.deploy`
Install-Machine-Agent	`pipelines/Jenkinsfile.install-machine-agent`
Install-Database-Agent	`pipelines/Jenkinsfile.install-db-agent`
Cleanup-All-Agents	`pipelines/Jenkinsfile.cleanup`

方法2: パイプラインスクリプトの直接入力

または、Jenkinsfileの内容をJenkinsに直接コピーすることもできます。

New Item を作成 します（方法1と同様）
Pipeline セクションで:
- Definition: Pipeline script を選択します
- Script: GitHubからJenkinsfileの内容全体をコピー/ペーストします
Save をクリックします

ヒント

方法1（SCM）を推奨します。パイプラインをバージョン管理に保持でき、更新が容易になります。

パイプラインパラメータ

各パイプラインは設定可能なパラメータを受け付けます。メインデプロイパイプラインの主要なパラメータを以下に示します:

Deploy Smart Agent パイプラインのパラメータ

パラメータ	デフォルト値	説明
`SMARTAGENT_ZIP_PATH`	`/var/jenkins_home/smartagent/appdsmartagent.zip`	Jenkins サーバー上の Smart Agent ZIP のパス
`REMOTE_INSTALL_DIR`	`/opt/appdynamics/appdsmartagent`	ターゲットホストのインストールディレクトリ
`APPD_USER`	`ubuntu`	Smart Agent プロセスを実行するユーザー
`APPD_GROUP`	`ubuntu`	Smart Agent プロセスを実行するグループ
`SSH_PORT`	`22`	リモートホストの SSH ポート
`AGENT_NAME`	`smartagent`	Smart Agent 名
`LOG_LEVEL`	`DEBUG`	ログレベル（DEBUG、INFO、WARN、ERROR）

Cleanup パイプラインのパラメータ

パラメータ	デフォルト値	説明
`REMOTE_INSTALL_DIR`	`/opt/appdynamics/appdsmartagent`	削除するディレクトリ
`SSH_PORT`	`22`	リモートホストの SSH ポート
`CONFIRM_CLEANUP`	`false`	クリーンアップを実行するにはチェックが必要

警告

Cleanupパイプラインには、誤って削除することを防ぐための確認パラメータがあります。クリーンアップを実行するには CONFIRM_CLEANUP にチェックを入れる必要があります。

パイプライン構造の理解

デプロイパイプラインの主要なコンポーネントを見ていきます:

1. エージェント宣言

agent { label 'linux' }

これにより、パイプラインが linux ラベルを持つJenkinsエージェントで実行されることが保証されます。

2. パラメータブロック

parameters {
    string(name: 'SMARTAGENT_ZIP_PATH', ...)
    string(name: 'REMOTE_INSTALL_DIR', ...)
    // ... その他のパラメータ
}

ビルドをトリガーする際に設定できるパラメータを定義します。

3. ステージ

デプロイパイプラインには以下のステージがあります:

Preparation - 認証情報からターゲットホストを読み込み
Extract Smart Agent - ZIPファイルをステージングディレクトリに展開
Configure Smart Agent - config.iniテンプレートを作成
Deploy to Remote Hosts - 各ホストにファイルをコピーしSmart Agentを起動
Verify Installation - すべてのホストでSmart Agentの状態を確認

4. 認証情報バインディング

withCredentials([
    sshUserPrivateKey(credentialsId: 'ssh-private-key', ...),
    string(credentialsId: 'account-access-key', ...)
]) {
    // 認証情報にアクセスできるパイプラインコード
}

ログに公開することなく、安全に認証情報を読み込みます。

5. Post アクション

post {
    success { ... }
    failure { ... }
    always { ... }
}

パイプライン完了後に、成功・失敗に関わらず実行するアクションを定義します。

パイプラインの命名規則

明確さと整理のために、一貫した命名規則を使用します:

推奨名称:

01-Deploy-Smart-Agent
02-Install-Machine-Agent
03-Install-Database-Agent
04-Cleanup-All-Agents

数字のプレフィックスにより、Jenkinsダッシュボードで論理的な順序を維持できます。

フォルダーによるパイプラインの整理

より良い整理のために、Jenkinsフォルダーを使用できます:

フォルダーを作成:
- New Item をクリックします
- 名前を入力します: AppDynamics Smart Agent
- Folder を選択します
- OK をクリックします
フォルダー内にパイプラインを作成:
- フォルダーに入ります
- 上記の手順でパイプラインを作成します

構成例:

AppDynamics Smart Agent/
├── Deployment/
│   └── 01-Deploy-Smart-Agent
├── Agent Installation/
│   ├── 02-Install-Machine-Agent
│   └── 03-Install-Database-Agent
└── Cleanup/
    └── 04-Cleanup-All-Agents

パイプラインコードの表示

完全なパイプラインコードはGitHubリポジトリで確認できます:

メインデプロイパイプライン: https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy

その他のパイプライン:

パイプライン設定のテスト

本番デプロイを実行する前に、パイプライン設定をテストします:

1. 単一ホストでのドライラン

IPが1つだけのテスト認証情報 deployment-hosts-test を作成します
パイプラインをこの認証情報を使用するよう一時的に変更します
パイプラインを実行し、単一ホストで動作することを確認します
確認後、完全なホストリストに更新します

2. 構文チェック

Jenkinsには組み込みの構文バリデーターがあります:

パイプラインに移動します
Pipeline Syntax リンクをクリックします
Declarative Directive Generator を使用して構文を検証します

次のステップ

パイプラインが作成できたら、最初のSmart Agentデプロイを実行する準備が整いました。

デプロイワークフロー

15 minutes

初回デプロイ

パイプラインの設定が完了したので、最初のSmart Agentデプロイを実行してみましょう。

ステップ1: パイプラインに移動

Jenkins Dashboard に移動します
Deploy-Smart-Agent パイプラインをクリックします

ステップ2: パラメータを指定してビルド

左サイドバーの Build with Parameters をクリックします
デフォルトパラメータを確認します:
- SMARTAGENT_ZIP_PATH: パスが正しいことを確認します
- REMOTE_INSTALL_DIR: /opt/appdynamics/appdsmartagent
- APPD_USER: ubuntu（または使用するSSHユーザー）
- APPD_GROUP: ubuntu
- SSH_PORT: 22
- AGENT_NAME: smartagent
- LOG_LEVEL: DEBUG
必要に応じてパラメータを調整します
Build をクリックします

ヒント

初回デプロイでは、IPアドレスが1つだけの別の認証情報を作成して、単一ホストでテストすることを検討してください。

ステップ3: パイプラインの実行を監視

Build をクリックすると、以下が表示されます:

Build added to queue - Build Historyにビルド番号が表示されます
ビルド番号をクリック します（例: #1）
Console Output をクリックしてリアルタイムのログを表示します

ステップ4: コンソール出力の理解

コンソール出力にはデプロイの各ステージが表示されます:

Started by user admin
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on aws-vpc-agent in /home/ubuntu/jenkins/workspace/Deploy-Smart-Agent
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Preparation)
[Pipeline] script
[Pipeline] {
Preparing Smart Agent deployment to 3 hosts: 172.31.1.243, 172.31.1.48, 172.31.1.5
...

表示される主要なステージ:

Preparation - ホストリストの読み込みと検証
Extract Smart Agent - ZIPファイルの展開
Configure Smart Agent - config.iniの作成
Deploy to Remote Hosts - 各ホストへのデプロイ
Verify Installation - Smart Agentの状態確認

ステップ5: 結果の確認

完了後、以下のいずれかが表示されます:

成功:

Smart Agent successfully deployed to all hosts
Finished: SUCCESS

部分的な成功:

Deployment completed with some failures
Failed hosts: 172.31.1.48
Finished: UNSTABLE

失敗:

Smart Agent deployment failed. Check logs for details.
Finished: FAILURE

インストールの検証

デプロイが成功したら、ターゲットホストでSmart Agentが稼働していることを確認します。

Smart Agent の状態確認

ターゲットホストにSSH接続して状態を確認します:

# ターゲットホストに SSH 接続
ssh ubuntu@172.31.1.243

# インストールディレクトリに移動
cd /opt/appdynamics/appdsmartagent

# Smart Agent の状態を確認
sudo ./smartagentctl status

期待される出力:

Smart Agent is running (PID: 12345)
Service: appdsmartagent.service
Status: active (running)

インストール済みエージェントの一覧表示

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl list

期待される出力:

No agents currently installed
(Use install-machine-agent or install-db-agent pipelines to add agents)

ログの確認

cd /opt/appdynamics/appdsmartagent
tail -f log.log

AppDynamics Controllerへの接続成功メッセージを確認します。

AppDynamics Controller での確認

AppDynamics Controllerにログインします
Servers → Servers に移動します
新しくデプロイされたホストを探します
Smart AgentがMetricをレポートしていることを確認します

追加エージェントのインストール

Smart Agentがデプロイされたら、他のパイプラインを使用して特定のエージェントタイプをインストールできます。

Machine Agent のインストール

Install-Machine-Agent パイプラインに移動します
Build with Parameters をクリックします
パラメータを確認します:
- AGENT_NAME: machine-agent
- SSH_PORT: 22
Build をクリックします

パイプラインは各ホストにSSH接続して以下を実行します:

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl install --component machine

Database Agent のインストール

Install-Database-Agent パイプラインに移動します
Build with Parameters をクリックします
データベース接続パラメータを設定します
Build をクリックします

パイプラインはすべてのホストにDatabase Agentをインストールして設定します。

エージェントインストールの確認

エージェントのインストール後、表示されることを確認します:

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl list

期待される出力:

Installed agents:
- machine-agent (running)
- db-agent (running)

一般的なデプロイシナリオ

シナリオ1: 初回デプロイ

ワークフロー:

Deploy-Smart-Agent パイプラインを実行します
完了を待って検証します
必要に応じて Install-Machine-Agent を実行します
必要に応じて Install-Database-Agent を実行します

シナリオ2: Smart Agent のアップデート

Smart Agentを新しいバージョンにアップデートするには:

新しいSmart Agent ZIPをダウンロードします
設定済みのパスにJenkinsに配置します
Deploy-Smart-Agent パイプラインを再度実行します

パイプラインは自動的に以下を行います:

既存のSmart Agentを停止
古いファイルを削除
新しいバージョンをインストール
Smart Agentを再起動

シナリオ3: 新しいホストの追加

Smart Agentを新しいホストに追加するには:

Jenkinsの deployment-hosts 認証情報を更新します
新しいIPアドレスを追加します（1行に1つ）
Deploy-Smart-Agent パイプラインを実行します

パイプラインは以下を行います:

設定済みのホストをスキップします（冪等性がある場合）
新しいホストにのみデプロイします

シナリオ4: 完全な削除

すべてのホストからSmart Agentを完全に削除するには:

Cleanup-All-Agents パイプラインに移動します
Build with Parameters をクリックします
CONFIRM_CLEANUP チェックボックスに チェックを入れます
Build をクリックします

これにより、すべてのホストから /opt/appdynamics/appdsmartagent ディレクトリが完全に削除されます。この操作は元に戻せません。

デプロイのトラブルシューティング

Preparation ステージでビルドが失敗する

症状: ホストリストの読み込み時にパイプラインが失敗する

原因: deployment-hosts 認証情報が見つからないか、正しくない

解決策:

Manage Jenkins → Credentials に移動します
deployment-hosts 認証情報が存在することを確認します
フォーマットを確認します（1行に1つのIP、カンマなし）
末尾にスペースがないことを確認します

SSH 接続の失敗

症状:「Permission denied」または「Connection refused」エラーが発生する

解決策:

セキュリティグループの確認:

# Jenkins エージェントからターゲットに到達できることを確認
ping 172.31.1.243
telnet 172.31.1.243 22

SSH の手動テスト:

# Jenkins エージェントマシンから
ssh -i /path/to/key ubuntu@172.31.1.243

SSH 鍵の確認:

ssh-private-key 認証情報が正しいことを確認します
ターゲットホストの ~/.ssh/authorized_keys に公開鍵があることを確認します

Smart Agent が起動しない

症状: デプロイは完了するがSmart Agentが稼働していない

解決策:

ターゲットホストのログを確認:

cd /opt/appdynamics/appdsmartagent
cat log.log

よくある問題:

無効なアクセスキー: account-access-key 認証情報を確認します
ネットワーク接続: Controllerへの送信HTTPS接続を確認します
権限の問題: APPD_USERに正しい権限があることを確認します

デプロイの部分的な成功

症状: 一部のホストは成功するが、他のホストは失敗する

解決策:

Console Output を確認 します - どのホストが失敗したかを特定します
失敗したホストを調査 します - SSHで接続して手動でテストします
パイプラインを再実行 します - Jenkinsがリトライが必要なホストを追跡します

パイプラインのベストプラクティス

1. まず単一ホストでテスト

本番環境にデプロイする前に、必ず単一ホストで新しい設定をテストします:

1. deployment-hosts-test 認証情報を作成（IP 1つ）
2. この認証情報を使用するテストパイプラインを作成
3. 成功を確認
4. 完全なホストリストにデプロイ

2. 説明的なビルド説明を使用

ビルドをトリガーした後、説明を追加します:

ビルドページに移動します
Edit Build Information をクリックします
説明を追加します:「本番環境デプロイ - 2024年第4四半期」

3. ビルド履歴の監視

ビルド履歴を定期的にチェックしてパターンを確認します:

失敗したビルド
所要時間の傾向
エラーメッセージ

4. メンテナンスウィンドウ中にデプロイをスケジュール

本番システムの場合:

Jenkinsのスケジュールビルドを使用します
トラフィックの少ない時間帯にデプロイします
ロールバック計画を準備しておきます

5. 認証情報を最新に保つ

SSH鍵を四半期ごとにローテーションします
インフラストラクチャの変更に合わせてホストリストを更新します
AppDynamicsアクセスキーの有効性を確認します

次のステップ

大規模デプロイのスケーリングと運用上の考慮事項について見ていきましょう。

GitHub Actions による自動化

2 minutes

はじめに

このワークショップでは、セルフホストランナーを使用した GitHub Actions で、複数のEC2インスタンスにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、このガイドではスケーラブルで安全かつ再現可能なSmart Agent運用のためにGitHub Actionsワークフローを活用する方法を説明します。

学習内容

このワークショップでは、以下の内容を学びます:

GitHub Actionsワークフローを使用して複数のホストに Smart Agent をデプロイ する
安全な認証情報管理のために GitHub Secrets と Variables を設定 する
AWS VPC内に セルフホストランナーをセットアップ する
数千台のホストにスケールするための 自動バッチ処理を実装 する
インストール、アンインストール、停止、クリーンアップなど エージェントの完全なライフサイクルを管理 する
ワークフローの実行を監視 し、問題をトラブルシューティングする

主な機能

並列デプロイ - 複数のホストに同時にデプロイ
完全なライフサイクル管理 - エージェントのすべての操作をカバーする11のワークフロー
Infrastructure as Code - すべてのワークフローをGitHubでバージョン管理
セキュア - SSH鍵はGitHub Secretsに保存、プライベートVPCネットワーキング
大規模スケーラブル - 自動バッチ処理で数千台のホストにデプロイ
セルフホストランナー - AWS VPC内で実行

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                  GitHub Actions-based Deployment                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Developer ──▶ GitHub.com ──▶ Self-hosted Runner (AWS VPC)     │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップは以下の内容で構成されています:

アーキテクチャと設計 - GitHub Actionsワークフローアーキテクチャの理解
GitHub のセットアップ - Secrets、Variables、セルフホストランナーの設定
ワークフローの作成 - 11の利用可能なワークフローの理解と使用
デプロイの実行 - ワークフローの実行とインストールの検証

利用可能なワークフロー

このソリューションには、Smart Agentの完全なライフサイクル管理のための 11のワークフロー が含まれています:

カテゴリ	ワークフロー数	説明
デプロイ	1	Smart Agent のデプロイと起動
エージェントのインストール	4	Node、Machine、DB、Java エージェントのインストール
エージェントのアンインストール	4	特定のエージェントタイプのアンインストール
エージェント管理	2	停止/クリーンおよび完全なクリーンアップ

すべてのワークフローはスケーラビリティのための自動バッチ処理をサポートしています。

前提条件

リポジトリアクセス権を持つGitHubアカウント
Ubuntu EC2インスタンスを持つAWS VPC
同じVPC内のセルフホストGitHub Actionsランナー
認証用のSSHキーペア
AppDynamics Smart Agentパッケージ

GitHub リポジトリ

すべてのワークフローコードと設定ファイルはGitHubリポジトリで利用できます:

https://github.com/chambear2809/github-actions-lab

リポジトリには以下が含まれています:

11の完全なワークフロー YAMLファイル
詳細なセットアップドキュメント
アーキテクチャ図
トラブルシューティングガイド

ヒント

このワークショップを最も簡単にナビゲートするには、以下を使用します:

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）および右（▶️）カーソルキー

アーキテクチャと設計

5 minutes

システムアーキテクチャ

GitHub ActionsベースのSmart Agentデプロイシステムは、AWS VPC内のセルフホストランナーを使用して、SSH経由で複数のターゲットホストへのデプロイを調整します。

ハイレベルアーキテクチャ

graph TB
    subgraph Internet
        GH[GitHub.com<br/>Repository & Actions]
        User[Developer<br/>Local Machine]
    end

    subgraph AWS["AWS VPC (172.31.0.0/16)"]
        subgraph SG["Security Group: smartagent-lab"]
            Runner[Self-hosted Runner<br/>EC2 Instance<br/>172.31.1.x]

            subgraph Targets["Target Hosts"]
                T1[Target Host 1<br/>Ubuntu EC2<br/>172.31.1.243]
                T2[Target Host 2<br/>Ubuntu EC2<br/>172.31.1.48]
                T3[Target Host 3<br/>Ubuntu EC2<br/>172.31.1.5]
            end
        end
    end

    User -->|git push| GH
    GH <-->|HTTPS:443<br/>Poll for jobs| Runner
    Runner -->|SSH:22<br/>Private IPs| T1
    Runner -->|SSH:22<br/>Private IPs| T2
    Runner -->|SSH:22<br/>Private IPs| T3

    style GH fill:#24292e,color:#fff
    style User fill:#0366d6,color:#fff
    style Runner fill:#28a745,color:#fff
    style T1 fill:#ffd33d,color:#000
    style T2 fill:#ffd33d,color:#000
    style T3 fill:#ffd33d,color:#000

ネットワークアーキテクチャ

すべてのインフラストラクチャは、共有セキュリティグループを持つ単一のAWS VPC内で動作します。セルフホストランナーはプライベートIP経由でターゲットホストと通信します。

VPC レイアウト

┌─────────────────────────────────────────────────────────────────┐
│                        AWS VPC (172.31.0.0/16)                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │          Security Group: smartagent-lab                   │  │
│  │  Rules:                                                   │  │
│  │  - Inbound: SSH (22) from same security group            │  │
│  │  - Outbound: HTTPS (443) to GitHub                       │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌─────────────┐    ┌──────────────┐    ┌──────────────┐       │
│  │ Self-hosted │    │  Target EC2  │    │  Target EC2  │       │
│  │   Runner    │    │              │    │              │       │
│  │             │───▶│ Private IP:  │    │ Private IP:  │       │
│  │ 172.31.1.x  │SSH │ 172.31.1.243 │    │ 172.31.1.48  │       │
│  │             │───▶│              │    │              │       │
│  │ Polls GitHub│    │ Ubuntu 20.04 │    │ Ubuntu 20.04 │       │
│  └─────────────┘    └──────────────┘    └──────────────┘       │
│         │                    │                    │             │
│         │                    │                    │             │
│         └────────────────────┴────────────────────┘             │
│                              │                                  │
└──────────────────────────────┼──────────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────┐
                    │   AppDynamics    │
                    │    Controller    │
                    │  (SaaS/On-Prem)  │
                    └──────────────────┘

ワークフロー実行フロー

完全なデプロイシーケンス

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant Runner as Self-hosted Runner
    participant Target as Target Host(s)

    Dev->>GH: 1. Push code or trigger workflow
    GH->>GH: 2. Workflow event triggered
    Runner->>GH: 3. Poll for jobs (HTTPS:443)
    GH->>Runner: 4. Assign job to runner
    Runner->>Runner: 5. Execute prepare job<br/>(load host matrix)

    par Parallel Execution
        Runner->>Target: 6a. SSH to Host 1<br/>(port 22)
        Runner->>Target: 6b. SSH to Host 2<br/>(port 22)
        Runner->>Target: 6c. SSH to Host 3<br/>(port 22)
    end

    Target->>Target: 7. Execute commands<br/>(install/uninstall/stop/clean)
    Target-->>Runner: 8. Return results
    Runner-->>GH: 9. Report job status
    GH-->>Dev: 10. Notify completion

コンポーネントの詳細

GitHub リポジトリ

格納内容:

11のワークフロー YAMLファイル
Smart Agentインストールパッケージ
設定ファイル（config.ini）

Secrets:

SSH秘密鍵

Variables:

ホストリスト（DEPLOYMENT_HOSTS）
ユーザー/グループ設定（オプション）

セルフホストランナー

配置場所:

AWS VPC（ターゲットと同じ）
プライベートネットワークアクセス

責務:

GitHubからワークフロージョブをポーリング
ワークフローステップの実行
ターゲットホストへのSSH接続
ファイル転送（SCP）
並列実行
エラー収集

要件:

Ubuntu/Amazon Linux 2
GitHubへの送信HTTPS（443）
ターゲットホストへの送信SSH（22）
SSHキー認証

アクセス:

GitHubへの送信HTTPS（443）
ターゲットホストへの送信SSH（22）
SSHキー認証を使用

ターゲットホスト

前提条件:

Ubuntu 20.04+
SSHサーバーが稼働中
sudoアクセス権を持つユーザー
認証済みSSHキー

デプロイ後:

/opt/appdynamics/
└── appdsmartagent/
    ├── smartagentctl
    ├── config.ini
    └── agents/
        ├── machine/
        ├── java/
        ├── node/
        └── db/

セキュリティアーキテクチャ

セキュリティレイヤー

AWS VPC の分離
- ホスト用のプライベートサブネット
- 直接のインターネットアクセスは不要
- VPCフローログを有効化
セキュリティグループ
- 同じセキュリティグループ内のみSSH（22）
- GitHubアクセス用の送信HTTPS（443）
- ステートフルファイアウォールルール
SSH キー認証
- パスワード認証なし
- キーはGitHub Secretsに保存
- ランナー上の一時キーファイル
- ワークフロー完了後にキーを削除
GitHub セキュリティ
- リポジトリアクセス制御
- ブランチ保護ルール
- Secretsはログに公開されない
- 環境変数のマスキング
ネットワークセキュリティ
- プライベートIP通信のみ
- パブリックIPは不要
- ランナーはターゲットと同じVPC内

ワークフローカテゴリ

システムには4つのカテゴリに分類された11のワークフローが含まれています:

GitHub Actions Workflows (11 Total)
├── Deployment (1 workflow)
│   └── Deploy Smart Agent (Batched)
├── Agent Installation (4 workflows)
│   ├── Install Node Agent (Batched)
│   ├── Install Machine Agent (Batched)
│   ├── Install DB Agent (Batched)
│   └── Install Java Agent (Batched)
├── Agent Uninstallation (4 workflows)
│   ├── Uninstall Node Agent (Batched)
│   ├── Uninstall Machine Agent (Batched)
│   ├── Uninstall DB Agent (Batched)
│   └── Uninstall Java Agent (Batched)
└── Smart Agent Management (2 workflows)
    ├── Stop and Clean Smart Agent (Batched)
    └── Cleanup All Agents (Batched)

バッチ処理戦略

すべてのワークフローは、あらゆるスケールのデプロイをサポートするために自動バッチ処理を使用します。

バッチ処理の仕組み

HOST LIST (1000 hosts)              BATCH_SIZE = 256

Host 001: 172.31.1.1                ┌──────────────────┐
Host 002: 172.31.1.2      ────────▶ │   BATCH 1        │
    ...                              │   Hosts 1-256    │ ───┐
Host 256: 172.31.1.256               │   Sequential     │    │
                                     └──────────────────┘    │
Host 257: 172.31.1.257               ┌──────────────────┐    │
Host 258: 172.31.1.258   ────────▶  │   BATCH 2        │    │ SEQUENTIAL
    ...                              │   Hosts 257-512  │    │ EXECUTION
Host 512: 172.31.1.512               │   Sequential     │    │
                                     └──────────────────┘    │
Host 513: 172.31.1.513               ┌──────────────────┐    │
    ...                              │   BATCH 3        │    │
Host 768: 172.31.1.768   ────────▶  │   Hosts 513-768  │ ───┘
                                     └──────────────────┘
Host 769: 172.31.1.769               ┌──────────────────┐
    ...                              │   BATCH 4        │
Host 1000: 172.31.2.232  ────────▶  │   Hosts 769-1000 │
                                     │   (232 hosts)    │
                                     └──────────────────┘

WITHIN EACH BATCH:
┌────────────────────────────────────────┐
│  All hosts deploy in PARALLEL          │
│                                        │
│  Host 1 ──┐                           │
│  Host 2 ──┤                           │
│  Host 3 ──┼─▶ Background processes (&)│
│    ...    │                           │
│  Host 256─┘   └─▶ wait command        │
└────────────────────────────────────────┘

シーケンシャルバッチの理由

リソース管理:

セルフホストランナーの過負荷を防止
各バッチは256の並列SSH接続を開く
シーケンシャル処理により安定したパフォーマンスを確保

設定変更可能:

デフォルトバッチサイズ: 256（GitHub Actionsのマトリックス制限）
ワークフロー入力でより小さなバッチに調整可能
速度とリソース使用量のバランスを調整

スケーリング特性

デプロイ速度（デフォルト BATCH_SIZE=256）:

10台のホスト → 1バッチ → 約2分
100台のホスト → 1バッチ → 約3分
500台のホスト → 2バッチ → 約6分
1,000台のホスト → 4バッチ → 約12分
5,000台のホスト → 20バッチ → 約60分

速度に影響する要因:

ネットワーク帯域幅（ホストあたり19MBのパッケージ）
SSH接続のオーバーヘッド（ホストあたり約1秒）
ターゲットホストのCPU/ディスク速度
ランナーのリソース（CPU/メモリ）

次のステップ

アーキテクチャを理解したところで、GitHubのセットアップとセルフホストランナーの設定に進みましょう。

GitHub のセットアップ

10 minutes

前提条件

開始する前に、以下を確認します:

リポジトリアクセス権を持つGitHubアカウント
Ubuntu EC2インスタンスを持つAWS VPC
ターゲットホストへの認証用SSHキーペア（PEMファイル）
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

リポジトリのフォークまたはクローン

まず、GitHub Actionsラボリポジトリへのアクセスを取得します。

リポジトリ URL: https://github.com/chambear2809/github-actions-lab

# Option 1: Fork the repository via GitHub UI
# Go to https://github.com/chambear2809/github-actions-lab
# Click "Fork" button

# Option 2: Clone directly (for testing)
git clone https://github.com/chambear2809/github-actions-lab.git
cd github-actions-lab

セルフホストランナーの設定

セルフホストランナーは、ターゲットEC2インスタンスと同じAWS VPCにデプロイする必要があります。

EC2 インスタンスへのランナーのインストール

VPC内で EC2 インスタンスを起動 します（UbuntuまたはAmazon Linux 2）
フォークしたリポジトリの ランナー設定に移動 します:
```
Settings → Actions → Runners → New self-hosted runner
```
ランナーインスタンスに SSH 接続 し、インストールコマンドを実行します:

# Create runner directory
mkdir actions-runner && cd actions-runner

# Download runner (check GitHub for latest version)
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz

# Extract
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz

# Configure (use token from GitHub UI)
./config.sh --url https://github.com/YOUR_USERNAME/github-actions-lab --token YOUR_TOKEN

# Install as service
sudo ./svc.sh install

# Start service
sudo ./svc.sh start

ランナーステータスの確認

ランナーが以下の場所で “Idle”（緑色）と表示されていることを確認します:

Settings → Actions → Runners

ヒント

ランナーはワークフロージョブを受け取るためにオンラインかつアイドル状態を維持する必要があります。オフラインと表示される場合は、サービスステータスを確認します: sudo ./svc.sh status

GitHub Secrets の設定

Settings → Secrets and variables → Actions → Secrets に移動します。

SSH 秘密鍵の Secret

このSecretには、ターゲットホストにアクセスするためのSSH秘密鍵が含まれます。

“New repository secret” をクリックします
Name: SSH_PRIVATE_KEY
Value: PEMファイルの内容を貼り付けます

# View your PEM file
cat /path/to/your-key.pem

フォーマット例:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
...
-----END RSA PRIVATE KEY-----

“Add secret” をクリックします

重要

SSHキーをリポジトリにコミットしないでください。機密性の高い認証情報には必ずGitHub Secretsを使用します。

GitHub Variables の設定

Settings → Secrets and variables → Actions → Variables に移動します。

デプロイホスト Variable（必須）

このVariableには、Smart Agentをデプロイするすべてのターゲットホストのリストが含まれます。

“New repository variable” をクリックします
Name: DEPLOYMENT_HOSTS
Value: ターゲットホストのIPを入力します（1行に1つ）

172.31.1.243
172.31.1.48
172.31.1.5
172.31.10.20
172.31.10.21

フォーマット要件:

1行に1つのIP
カンマなし
スペースなし
余分な文字なし
Unix改行コード（LF、CRLFではなく）を使用

“Add variable” をクリックします

オプションの Variables

これらのVariableはオプションで、Smart Agentサービスのユーザー/グループ設定に使用されます:

SMARTAGENT_USER

“New repository variable” をクリックします
Name: SMARTAGENT_USER
Value: 例: appdynamics
“Add variable” をクリックします

SMARTAGENT_GROUP

“New repository variable” をクリックします
Name: SMARTAGENT_GROUP
Value: 例: appdynamics
“Add variable” をクリックします

ネットワーク設定

同じVPCおよびセキュリティグループ内のすべてのEC2インスタンスを使用するラボセットアップの場合:

セキュリティグループルール

インバウンドルール:

同じセキュリティグループからのSSH（ポート22）（ソース: 同じSG）

アウトバウンドルール:

0.0.0.0/0へのHTTPS（ポート443）（GitHub APIアクセス用）
同じセキュリティグループへのSSH（ポート22）（ターゲットアクセス用）

ネットワークのベストプラクティス

DEPLOYMENT_HOSTS にはプライベートIPアドレス（172.31.x.x）を使用
ランナーとターゲットを同じセキュリティグループに配置
ターゲットホストにパブリックIPは不要
ランナーはプライベートネットワーク経由で通信
GitHubポーリング用のアウトバウンドHTTPSが必要

設定の確認

ワークフローを実行する前に、セットアップを確認します:

1. ランナーステータスの確認

Settings → Actions → Runners に移動します
ランナーが「Idle」（緑色）と表示されていることを確認します
「Last seen」のタイムスタンプが最近であることを確認します

2. SSH 接続のテスト

ランナーインスタンスからターゲットホストにSSH接続します:

# On runner instance
ssh -i ~/.ssh/your-key.pem ubuntu@172.31.1.243

成功すると、ターゲットホストのシェルプロンプトが表示されます。

3. Secrets と Variables の確認

Settings → Secrets and variables → Actions に移動します
Secretsタブに SSH_PRIVATE_KEY が表示されていることを確認します
Variablesタブに DEPLOYMENT_HOSTS が表示されていることを確認します

4. リポジトリアクセスの確認

ランナーがリポジトリにアクセスできることを確認します:

# On runner instance, as the runner user
cd ~/actions-runner
./run.sh  # Test run (Ctrl+C to stop)

「Listening for Jobs」と表示されます。

よくある問題のトラブルシューティング

ランナーがジョブを取得しない

症状: ワークフローが「queued」状態のまま

解決策:

ランナーステータスを確認します: sudo systemctl status actions.runner.*
ランナーを再起動します: sudo ./svc.sh restart
GitHubへのアウトバウンドHTTPS（443）接続を確認します

SSH 接続の失敗

症状: ワークフローが「Permission denied」または「Connection refused」で失敗

解決策:

# Test from runner
ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243 -o ConnectTimeout=10

# Check security group allows SSH from runner
# Verify private key matches public key on targets

ホスト名に無効な文字

症状: エラー「hostname contains invalid characters」

解決策:

DEPLOYMENT_HOSTS Variableを編集します
末尾にスペースがないことを確認します
Unix改行コード（LF、CRLFではなく）を使用します
1行に1つのIP、余分な文字なし

Secrets が見つからない

症状: エラー「Secret SSH_PRIVATE_KEY not found」

解決策:

Secret名が正確に一致していることを確認します: SSH_PRIVATE_KEY
SecretがリポジトリSecrets（環境Secretsではなく）にあることを確認します
リポジトリの管理者アクセス権があることを確認します

セキュリティのベストプラクティス

安全な運用のために、以下のベストプラクティスに従います:

すべての秘密鍵にGitHub Secretsを使用
SSHキーを定期的にローテーション
ランナーをプライベートVPCサブネットに配置
ランナーのセキュリティグループを最小限のアクセスに制限
ランナーソフトウェアを定期的にアップデート
ブランチ保護ルールを有効化
環境ごとに別のキーを使用
リポジトリアクセスの監査ログを有効化

次のステップ

GitHubの設定とランナーのセットアップが完了したら、利用可能なワークフローを確認し、最初のデプロイを実行しましょう。

ワークフローの理解

10 minutes

利用可能なワークフロー

GitHub Actionsラボには、Smart Agentの完全なライフサイクル管理のための 11のワークフロー が含まれています。すべてのワークフローファイルはリポジトリの .github/workflows/ で利用できます。

リポジトリ: https://github.com/chambear2809/github-actions-lab

ワークフローカテゴリ

1. デプロイ（1ワークフロー）

Deploy Smart Agent（バッチ処理）

ファイル: deploy-agent-batched.yml
目的: Smart Agentのインストールとサービスの起動
機能:
- 自動バッチ処理（デフォルト: バッチあたり256ホスト）
- 設定可能なバッチサイズ
- 各バッチ内での並列デプロイ
- シーケンシャルバッチ処理
入力:
- batch_size: バッチあたりのホスト数（デフォルト: 256）
トリガー: 手動のみ（workflow_dispatch）

2. エージェントのインストール（4ワークフロー）

すべてのインストールワークフローは、特定のエージェントタイプをインストールするために smartagentctl を使用します:

Install Node Agent（バッチ処理）

ファイル: install-node-batched.yml
コマンド: smartagentctl install node
バッチ処理: あり（設定可能）

Install Machine Agent（バッチ処理）

ファイル: install-machine-batched.yml
コマンド: smartagentctl install machine
バッチ処理: あり（設定可能）

Install DB Agent（バッチ処理）

ファイル: install-db-batched.yml
コマンド: smartagentctl install db
バッチ処理: あり（設定可能）

Install Java Agent（バッチ処理）

ファイル: install-java-batched.yml
コマンド: smartagentctl install java
バッチ処理: あり（設定可能）

3. エージェントのアンインストール（4ワークフロー）

すべてのアンインストールワークフローは、特定のエージェントタイプを削除するために smartagentctl を使用します:

Uninstall Node Agent（バッチ処理）

ファイル: uninstall-node-batched.yml
コマンド: smartagentctl uninstall node
バッチ処理: あり（設定可能）

Uninstall Machine Agent（バッチ処理）

ファイル: uninstall-machine-batched.yml
コマンド: smartagentctl uninstall machine
バッチ処理: あり（設定可能）

Uninstall DB Agent（バッチ処理）

ファイル: uninstall-db-batched.yml
コマンド: smartagentctl uninstall db
バッチ処理: あり（設定可能）

Uninstall Java Agent（バッチ処理）

ファイル: uninstall-java-batched.yml
コマンド: smartagentctl uninstall java
バッチ処理: あり（設定可能）

4. Smart Agent 管理（2ワークフロー）

Stop and Clean Smart Agent（バッチ処理）

ファイル: stop-clean-smartagent-batched.yml
コマンド:
- smartagentctl stop
- smartagentctl clean
目的: Smart Agentサービスの停止とすべてのデータのパージ
バッチ処理: あり（設定可能）

Cleanup All Agents（バッチ処理）

ファイル: cleanup-appdynamics.yml
コマンド: sudo rm -rf /opt/appdynamics
目的: /opt/appdynamicsディレクトリの完全な削除
バッチ処理: あり（設定可能）
警告: すべてのAppDynamicsコンポーネントが完全に削除されます

「Cleanup All Agents」ワークフローは /opt/appdynamics を完全に削除します。この操作は元に戻せません。注意して使用してください。

ワークフローの構造

すべてのバッチ処理ワークフローは、一貫した2ジョブ構成に従います:

ジョブ 1: Prepare

prepare:
  runs-on: self-hosted
  outputs:
    batches: ${{ steps.create-batches.outputs.batches }}
  steps:
    - name: Load hosts and create batches
      run: |
        # Load DEPLOYMENT_HOSTS variable
        # Split into batches of N hosts
        # Output as JSON array

目的: GitHub Variablesからターゲットホストを読み込み、バッチマトリックスを作成

ジョブ 2: Deploy/Install/Uninstall

deploy:
  needs: prepare
  runs-on: self-hosted
  strategy:
    matrix:
      batch: ${{ fromJson(needs.prepare.outputs.batches) }}
  steps:
    - name: Setup SSH key
    - name: Execute operation on all hosts in batch (parallel)

目的: 各バッチに対して並列に実行し、バッチ内のすべてのホストで特定の操作を実行

バッチ処理の動作

仕組み

Prepare ジョブ が DEPLOYMENT_HOSTS を読み込み、バッチに分割
Deploy ジョブ がバッチごとに1つのマトリックスエントリを作成
バッチはシーケンシャルに処理 され、ランナーの過負荷を防止
各バッチ内 では、バックグラウンドプロセスを使用してすべてのホストが並列にデプロイ

設定可能なバッチサイズ

すべてのワークフローは batch_size 入力を受け付けます（デフォルト: 256）:

# Via GitHub CLI
gh workflow run "Deploy Smart Agent" -f batch_size=128

# Via GitHub UI
Actions → Select workflow → Run workflow → Set batch_size

例

100台のホスト、batch_size=256: 1バッチ、約3分
500台のホスト、batch_size=256: 2バッチ、約6分
1,000台のホスト、batch_size=128: 8バッチ、約16分
5,000台のホスト、batch_size=256: 20バッチ、約60分

ワークフローの実行順序

典型的なデプロイシーケンス

Deploy Smart Agent - 初期デプロイ
Install Machine Agent - 必要に応じて特定のエージェントをインストール
Install DB Agent - データベースモニタリングのインストール
（必要に応じて他のインストールワークフローを使用）

メンテナンス/アップデートシーケンス

Stop and Clean Smart Agent - サービスの停止とデータのクリーン
Deploy Smart Agent - 更新バージョンの再デプロイ
エージェントの再インストール - 必要なエージェントの再インストール

完全な削除シーケンス

Stop and Clean Smart Agent - サービスの停止
Cleanup All Agents - /opt/appdynamicsディレクトリの削除

ワークフローコードの確認

リポジトリで完全なワークフロー YAMLファイルを確認できます:

メインデプロイワークフロー: https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml

すべてのワークフロー: https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows

ワークフローの機能

組み込みエラーハンドリング

ホストごとのエラー追跡
失敗したホストのレポート
バッチレベルの障害処理
常に実行されるサマリー

並列実行

バッチ内のすべてのホストが同時にデプロイ
SSHバックグラウンドプロセス（&）を使用
waitコマンドですべての完了を保証
リソース制限内での最大並列処理

セキュリティ

SSHキーはログに公開されない
認証情報は環境変数としてバインド
自動化のために厳密なホストキーチェックを無効化
ワークフロー完了後にキーを削除

次のステップ

利用可能なワークフローを理解したところで、最初のデプロイを実行しましょう。

ワークフローの実行

15 minutes

ワークフローのトリガー

すべてのワークフローは workflow_dispatch で設定されており、手動でトリガーする必要があります。ワークフローを実行する主な方法は2つあります:

GitHub UI - ビジュアルインターフェース、ほとんどのユーザーにとって最も簡単
GitHub CLI - コマンドラインインターフェース、自動化に最適

方法 1: GitHub UI

ステップ 1: Actions タブに移動

GitHub上のフォークしたリポジトリに移動します
上部の Actions タブをクリックします

ステップ 2: ワークフローを選択

左側のサイドバーに、利用可能なすべてのワークフローが表示されます:

Deploy Smart Agent
Install Node Agent (Batched)
Install Machine Agent (Batched)
Install DB Agent (Batched)
Install Java Agent (Batched)
Uninstall Node Agent (Batched)
Uninstall Machine Agent (Batched)
Uninstall DB Agent (Batched)
Uninstall Java Agent (Batched)
Stop and Clean Smart Agent (Batched)
Cleanup All Agents

実行するワークフローをクリックします。

ステップ 3: ワークフローを実行

“Run workflow” ボタン（右上）をクリックします
ブランチ main を選択します
（オプション）必要に応じて batch_size を調整します
“Run workflow” ボタンをクリックします

ステップ 4: 実行を監視

ワークフローが下のリストに表示されます
ワークフローの実行をクリックして詳細を確認します
リアルタイムで進捗を監視します
ジョブ名をクリックして詳細なログを確認します

方法 2: GitHub CLI

GitHub CLI のインストール

# macOS
brew install gh

# Linux
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh

認証

gh auth login

ワークフローの実行

# Deploy Smart Agent (default batch size)
gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab

# Deploy with custom batch size
gh workflow run "Deploy Smart Agent" \
  --repo YOUR_USERNAME/github-actions-lab \
  -f batch_size=128

# Install agents
gh workflow run "Install Node Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

gh workflow run "Install Machine Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Uninstall agents
gh workflow run "Uninstall Node Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Stop and clean
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Complete cleanup
gh workflow run "Cleanup All Agents" \
  --repo YOUR_USERNAME/github-actions-lab

ワークフローの監視

# List recent workflow runs
gh run list --repo YOUR_USERNAME/github-actions-lab

# View specific run
gh run view RUN_ID --repo YOUR_USERNAME/github-actions-lab

# Watch run in progress
gh run watch RUN_ID --repo YOUR_USERNAME/github-actions-lab

# View failed logs
gh run view RUN_ID --log-failed --repo YOUR_USERNAME/github-actions-lab

初回デプロイのウォークスルー

完全な初回デプロイの手順を説明します:

ステップ 1: セットアップの確認

ワークフローを実行する前に、以下を確認します:

セルフホストランナーが「Idle」（緑色）と表示されている
SSH_PRIVATE_KEY Secretが設定されている
DEPLOYMENT_HOSTS VariableにターゲットIPが含まれている
ネットワーク接続が確認済み

ステップ 2: Smart Agent のデプロイ

GitHub UI 経由:

Actions タブに移動します
“Deploy Smart Agent” を選択します
“Run workflow” をクリックします
デフォルトのbatch_size（256）を受け入れます
“Run workflow” をクリックします

GitHub CLI 経由:

gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab

ステップ 3: 実行の監視

ワークフローは以下を表示します:

Prepare ジョブ - バッチマトリックスの作成
Deploy ジョブ（バッチごとに1つ）- ホストへのデプロイ

各ジョブをクリックして詳細なログを確認します。

ステップ 4: インストールの確認

ターゲットホストにSSH接続して確認します:

# SSH to target
ssh ubuntu@172.31.1.243

# Check Smart Agent status
cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl status

期待される出力:

Smart Agent is running (PID: 12345)
Service: appdsmartagent.service
Status: active (running)

ステップ 5: 追加エージェントのインストール（オプション）

必要に応じて、特定のエージェントタイプをインストールします:

# Install Machine Agent
gh workflow run "Install Machine Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Install DB Agent
gh workflow run "Install DB Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

ワークフロー出力の理解

Prepare ジョブの出力

Loading deployment hosts...
Total hosts: 1000
Batch size: 256
Creating 4 batches...
Batch 1: Hosts 1-256
Batch 2: Hosts 257-512
Batch 3: Hosts 513-768
Batch 4: Hosts 769-1000

Deploy ジョブの出力（バッチごと）

Processing batch 1 of 4
Deploying to 256 hosts in parallel...
Host 172.31.1.1: SUCCESS
Host 172.31.1.2: SUCCESS
Host 172.31.1.3: SUCCESS
...
Batch 1 complete: 256/256 succeeded

完了サマリー

Deployment Summary:
Total hosts: 1000
Successful: 998
Failed: 2
Failed hosts:
  - 172.31.1.48
  - 172.31.1.125

よくあるデプロイシナリオ

シナリオ 1: 初期デプロイ

# 1. Deploy Smart Agent
gh workflow run "Deploy Smart Agent"

# 2. Verify deployment
# SSH to a host and check status

# 3. Install agents as needed
gh workflow run "Install Machine Agent (Batched for Large Scale)"
gh workflow run "Install DB Agent (Batched for Large Scale)"

シナリオ 2: Smart Agent のアップデート

# 1. Stop and clean current installation
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"

# 2. Update Smart Agent ZIP in repository
# (Push new version to repository)

# 3. Deploy new version
gh workflow run "Deploy Smart Agent"

# 4. Reinstall agents
gh workflow run "Install Machine Agent (Batched for Large Scale)"

シナリオ 3: 新しいホストの追加

# 1. Update DEPLOYMENT_HOSTS variable in GitHub
# Add new IPs

# 2. Deploy to all hosts (will skip existing ones with idempotent logic)
gh workflow run "Deploy Smart Agent"

シナリオ 4: 完全な削除

# 1. Stop and clean
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"

# 2. Complete removal
gh workflow run "Cleanup All Agents"

「Cleanup All Agents」は /opt/appdynamics を完全に削除します。この操作は元に戻せません。

ワークフロー失敗のトラブルシューティング

ワークフローが「Queued」のまま

症状: ワークフローが開始されない

原因: ランナーが利用できないかオフライン

解決策:

ランナーステータスを確認します: Settings → Actions → Runners
ランナーが「Idle」（緑色）と表示されていることを確認します
必要に応じてランナーを再起動します: sudo ./svc.sh restart

SSH 接続の失敗

症状:「Permission denied」または「Connection refused」エラー

解決策:

SSH を手動でテスト:

# From runner instance
ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243

セキュリティグループを確認:

ランナーからのSSH（22）が許可されていることを確認
ランナーとターゲットが同じセキュリティグループにあることを確認

SSH キーを確認:

SSH_PRIVATE_KEY Secretが実際のキーと一致していることを確認
ターゲットホストに公開鍵があることを確認

部分的なバッチの失敗

症状: 一部のホストが成功し、他が失敗

解決策:

ワークフローログで失敗したホストを特定
失敗したホストにSSH接続して調査
ワークフローを再実行（冪等性 - 成功したホストはスキップ）

バッチジョブエラー

症状:「Error splitting hosts into batches」

解決策:

DEPLOYMENT_HOSTS Variableのフォーマットを確認
1行に1つのIPであることを確認
末尾のスペースや特殊文字がないことを確認
Unix改行コード（LF、CRLFではなく）を使用

パフォーマンスチューニング

バッチサイズの調整

小さなバッチ（リソース使用量が少ない、速度は低下）:

gh workflow run "Deploy Smart Agent" -f batch_size=128

大きなバッチ（リソース使用量が多い、速度は向上）:

gh workflow run "Deploy Smart Agent" -f batch_size=256

ランナーリソースの推奨事項

ホスト数	CPU	メモリ	バッチサイズ
1-100	2コア	4 GB	256
100-500	4コア	8 GB	256
500-2000	8コア	16 GB	256
2000+	16コア	32 GB	256

ベストプラクティス

まず単一ホストでテスト
- 1つのIPでテスト変数を作成
- ワークフローを実行して確認
- その後フルリストにデプロイ
ワークフロー実行の監視
- リアルタイムでログを監視
- エラーを即座に確認
- サンプルホストで検証
適切なバッチサイズの使用
- デフォルト（256）はほとんどの場合に適用
- ランナーに負荷がかかる場合は削減
- ランナーのリソース使用量を監視
ワークフローを最新の状態に維持
- リポジトリから最新の変更をプル
- 本番環境以外で先にアップデートをテスト
- カスタマイズ内容をドキュメント化
ランナーの正常性を維持
- ランナーをオンラインかつアイドル状態に維持
- ランナーソフトウェアを定期的にアップデート
- ディスク容量とリソースを監視

次のステップ

おめでとうございます。GitHub Actionsを使用したAppDynamics Smart Agentデプロイの自動化方法を学びました。詳細については、完全なリポジトリを参照してください。

Smart Agent と Ansible によるモニタリングのコード化

10 minutes

はじめに

このガイドでは、Ansibleを使用してCisco AppDynamics Smart Agentを複数のホストにデプロイする方法を説明します。自動化を活用することで、モニタリングインフラストラクチャの一貫性、堅牢性、スケーラビリティを確保できます。

アーキテクチャの概要

デプロイアーキテクチャは、Ansibleコントロールノードを活用して、ターゲットホストへのSmart Agentのインストールと設定をオーケストレーションします。

graph TD
    CN[Ansible Control Node<br/>(macOS/Linux)] -->|SSH| H1[Target Host 1<br/>(Debian/RedHat)]
    CN -->|SSH| H2[Target Host 2<br/>(Debian/RedHat)]
    CN -->|SSH| H3[Target Host N<br/>(Debian/RedHat)]

    subgraph "Target Host Configuration"
        SA[Smart Agent Service]
        Config[config.ini]
        Package[Installer .deb/.rpm]
    end

    H1 --> SA
    H2 --> SA
    H3 --> SA

主要コンポーネント

Ansible Control Node: プレイブックを実行するマシン（例: ラップトップやジャンプホスト）です。
Target Hosts: Smart Agentがインストールされるサーバーです。
Inventory: ターゲットホストとその接続情報の一覧です。
Playbook: デプロイタスクを定義するYAMLファイルです。

前提条件

開始する前に、以下を確認してください

SSH経由でターゲットホストにアクセスできること。
ターゲットホストでsudo権限を持っていること。
Smart Agentインストールパッケージ（.deb または .rpm）をダウンロード済みであること。
AppDynamics Controllerのアカウント情報（Access Key、Account Name、URL）を用意していること。

ステップ1: macOS に Ansible をインストールする

まず、コントロールノードにAnsibleをインストールします。

Homebrew をインストール します（未インストールの場合）

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Ansible をインストール します
```
brew install ansible
```
インストールを確認 します
```
ansible --version
```
Ansibleのインストール済みバージョンを示す出力が表示されます。

セットアップと設定

10 minutes

ステップ2: ファイルとディレクトリ構成を準備する

Ansibleデプロイ用のプロジェクトディレクトリを作成します。以下のファイルを含める必要があります

.
├── appdsmartagent_64_linux_24.6.0.2143.deb  # Debian package
├── appdsmartagent_64_linux_24.6.0.2143.rpm  # RedHat package
├── inventory-cloud.yaml                     # Inventory file
├── smartagent.yaml                          # Playbook
└── variables.yaml                           # Variables file

ターゲット環境に適したSmart Agentパッケージをダウンロード済みであることを確認してください。

ステップ3: ファイルの内容を理解する

1. インベントリファイル（`inventory-cloud.yaml`）

インベントリファイルには、Smart Agentをデプロイするホストの一覧を記載します。ホストと認証情報をここで定義します。

all:
  hosts:
    smartagent-host-1:
      ansible_host: 54.173.1.106
      ansible_username: ec2-user
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'

    smartagent-host-2:
      ansible_host: 192.168.86.107
      ansible_username: aleccham
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!

    smartagent-host-3:
      ansible_host: 54.82.95.69
      ansible_username: ubuntu
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!

Action: ansible_host のIPアドレスと認証情報を、実際のラボ環境の情報に更新します。

2. 変数ファイル（`variables.yaml`）

このファイルには、Smart Agentの設定情報が含まれています。

smart_agent:
  controller_url: 'CONTROLLER URL HERE, JUST THE BASE URL' # o11y.saas.appdynamics.com
  account_name: 'Account Name Here'
  account_access_key: 'YOUR ACCESS KEY HERE'
  fm_service_port: '443' # Use 443 or 8080 depending on your environment.
  ssl: true

smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb'  # or the appropriate package name
smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm'  # or the appropriate package name

Action: smart_agent セクションを、使用するController URL、アカウント名、アクセスキーに更新します。

3. プレイブック（`smartagent.yaml`）

このプレイブックは、Cisco AppDynamics Distribution of OpenTelemetry Collectorのデプロイをオーケストレーションします。タスクの概要は以下のとおりです

前提パッケージ: 必要なパッケージをインストールします（RedHatの場合は yum-utils、Debianの場合は curl/apt-transport-https）。
ディレクトリのセットアップ: /opt/appdynamics/appdsmartagent ディレクトリが存在することを確認します。
設定:
- config.ini が存在するかチェックします。
- 存在しない場合、variables.yaml の値を使用してデフォルトの config.ini を作成します。
- lineinfile を使用して設定キー（AccountAccessKey、ControllerURLなど）を更新し、設定が正しいことを確認します。
パッケージ管理:
- OSファミリー（Debian/RedHat）に基づいて適切なパッケージパスを決定します。
- パッケージがローカルに存在しない場合は失敗します。
- パッケージをターゲットホストの /tmp ディレクトリにコピーします。
- dpkg または yum を使用してパッケージをインストールします。
サービス管理: smartagent サービスを再起動します。
クリーンアップ: 一時パッケージファイルを削除します。

このプレイブックは、when: ansible_os_family == ... の条件分岐を使用して、同じワークフロー内でRedHatとDebianの両方のシステムに対応しています。

デプロイ

5 minutes

ステップ4: プレイブックを実行する

Smart Agentをデプロイするには、プロジェクトディレクトリから以下のコマンドを実行します

ansible-playbook -i inventory-cloud.yaml smartagent.yaml

インベントリファイルに別の名前を付けた場合は、inventory-cloud.yaml を適切なファイル名に置き換えます。

確認

プレイブックが正常に完了したら、ターゲットホストの1つにログインしてサービスの状態を確認することで、デプロイを検証できます

systemctl status smartagent

サービスがactive (running) と表示されます。

その他のワークショップ

Pet Clinic Java ワークショップ
JavaアプリケーションをつかったSplunk Oservabilityのワークショップです
OpenTelemetry Collector
OpenTelemetry Collectorのコンセプトを学び、Splunk Observability Cloudにデータを送信する方法を理解しましょう。

Pet Clinic Java ワークショップ

このワークショップでは、Splunk Observabilityプラットフォームの以下のコンポーネントを構成するための、基本的なステップを体験できます

Splunk Infrastructure Monitoring (IM)
Splunk APM
- Endpoint Performance
- Database Query Performance
- AlwaysOn Profiling
Splunk Real User Monitoring (RUM)
Splunk LogObserver

ワークショップの中では、Javaのサンプルアプリケーション（Spring Pet Clinic）をクローン（ダウンロード）し、アプリケーションのコンパイル、パッケージ、実行していきます。

アプリケーションを起動すると、OpenTelemetry Javaエージェントを通じて、Splunk APMでメトリクスとトレースが即座に表示されるようになります。

その後、Splunk OpenTelemetry Javascript Libraries (RUM)を使用して、Pet Clinicのエンドユーザーインターフェース（アプリケーションによってレンダリングされるHTMLページ）を計装し、エンドユーザーが実行する個々のクリックとページロードのすべてについて、RUMトレースを生成していきます。

前提条件

このワークショップは、ホスト/インスタンスが提供されるSplunk実行ワークショップ または 自前のホスト/Multipassインスタンスで行う、自己主導型のワークショップです。

ご自身のシステムには、以下のものがインストールされ、有効になっている必要があります

JDK 17
ポート 8083 が開いていること（インバウンド/アウトバウンド）

OpenTelemetry Collectorをインストールする

1. はじめに

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

インフラストラクチャーのメトリクス（ディスク、CPU、メモリなど）
Application Performance Monitoring（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>"

既存のOpenTelemetryコレクターをすべて削除する

同じVMインスタンスにSplunk IMワークショップのセットアップをしている場合、Otel Collectorをインストールする前にKubernetesで実行中のCollectorを削除していることを確認してください。これは、以下のコマンドを実行することで行うことができます

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

AWS/EC2インスタンスの場合

。 AWS/EC2インスタンス上でこのワークショップを行う場合、インスタンスのホスト名を公開するためにコレクターにパッチを適用する必要があります

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

インストールが完了したら、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

情報

実際にアプリをコンパイルする前に、mavenが多くの依存ライブラリをダウンロードするため、初回実行時には数分かかるでしょう。2回目以降の実行はもっと短くなります。

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

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にアクセスして、それぞれのテレメトリーデータを確認してみましょう！

Troubleshooting MetricSetsを追加する

サービスマップやTab Spotlightで、 version などのカスタム属性で分析できるようにするためには、Troubleshooting MetricSetsの設定をあらかじめ追加する必要があります。左メニューの Settings → APM MetricSets で、設定を管理することができます。もしお使いのアカウントで分析できなければ、設定を追加してみましょう。

次のセクションではカスタム計装を追加して、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

Tips: nanoの使い方と壊れたファイルの直し方

nanoはLinux環境でよく使われる、シンプルなエディタの一つです。

Alt-U で、アンドゥができます。Macの場合は Esc キーを押したあとに U を押してください！
ctrl-_ のあとに数字を入力すると、指定した行数にジャンプします。
ctrl-O のあとに Enter で、ファイルを保存します。
ctrl-X で、nanoを終了します。

もしファイルをどうしようもなく壊してしまって元に戻したい場合は、gitを使って次のようにするとよいでしょう。

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を開き、アプリケーションのトレースを見ていきます。

さらなる情報: マニュアル計装について

マニュアル計装で何ができるか、他の言語でのやり方などは、OpenTelemetryの公式ウェブサイトにある Instrumentation ページをご覧ください。

検証が完了したら、ターミナルで 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

versionを自動で設定する

ここまできて version を毎回変えるためにコマンドラインを修正するのは大変だと思うことでしょう。実際、修正が漏れた人もいるかもしれません。本番環境では、環境変数でアプリケーションバージョンを与えたり、コンテナイメージの作成時にビルドIDを与えたりすることになるはずです。

次に、より多くのトラフィックを生成するために、アプリケーションに再度アクセスしてみましょう。 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アプリケーションからのログメッセージのみを選択するためのフィルタを追加できます。

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

4. まとめ

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

OpenTelemetryでクラウドネイティブ環境のオブザーバビリティを実現する

概要

OpenTelemetryを使い始める場合は、バックエンドに直接データを送ることから始めるかもしれません。最初のステップとしてはよいですが、OpenTelemetry Collectorをオブザーバビリティのアーキテクチャとして使用するのは多くの利点があり、本番環境ではCollectorを使ったデプロイを推奨しています。

このワークショップでは、OpenTelemetry Collectorを使用することに焦点を当て、Splunk Observability Cloudで使用するためのレシーバー、プロセッサー、エクスポーターを定義し、実際にテレメトリデータを送信するためのパイプラインを設定することで、環境に合わせてCollectorを活用を学びます。また、分散プラットフォームのビジネスニーズに対応するための、カスタムコンポーネントを追加できるようになるまでの道のりを進むことになります。

Ninja セクション

ワークショップの途中には、展開できる Ninjaセクションがあります。これらはより実践的で、ワークショップ中、もしくは自分の時間を使って、さらに技術的な詳細に取り組むことができます。

OpenTelemetryプロジェクトは頻繁に開発されているため、Ninjaセクションの内容が古くなる可能性があることに注意してください。コンテンツが古い場合には更新のリクエストを出すこともできますので、必要なものを見つけた場合はお知らせください。

Ninja: をテストして！

このワークショップを完了すると、正式に OpenTelemetry Collector ニンジャになります！

対象者

このワークショップは、OpenTelemetry Collectorのアーキテクチャとデプロイメントについてさらに学びたいと考えている開発者やシステム管理者を対象としています。

前提条件

データ収集に関する基本的な理解
コマンドラインとvim/viの経験
Ubuntu 20.04 LTSまたは22.04 LTSが稼働するインスタンス/ホスト/VM
- 最小要件はAWS/EC2 t2.micro（1 CPU、1GB RAM、8GBストレージ）

学習目標

このセッションの終わりまでに、参加者は以下を行うことができるようになります

OpenTelemetryのコンポーネントを理解する
レシーバー、プロセッサー、エクスポーターを使用してデータを収集・分析する
OpenTelemetryを使用する利点を特定する
自分たちのビジネスニーズに対応するカスタムコンポーネントを構築する

OpenTelemetry のアーキテクチャー

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

flowchart LR;
    subgraph Receivers
    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 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 のようになれば、インストールは成功です！

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

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

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

Collector が動作していることを確認する

これで、Collectorが動いているはずです。root権限で systemctl コマンドを使って、それを確かめてみましょう。

sudo systemctl status otelcol-contrib

● otelcol-contrib.service - OpenTelemetry Collector Contrib
     Loaded: loaded (/lib/systemd/system/otelcol-contrib.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-05-16 08:23:23 UTC; 25s ago
   Main PID: 1415 (otelcol-contrib)
      Tasks: 5 (limit: 1141)
     Memory: 22.2M
        CPU: 125ms
     CGroup: /system.slice/otelcol-contrib.service
             └─1415 /usr/bin/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml

May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: NumberDataPoints #0
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Data point attributes:
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]:      -> exporter: Str(logging)
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]:      -> service_instance_id: Str(df8a57f4-abdc-46b9-a847-acd62db1001f)
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]:      -> service_name: Str(otelcol-contrib)
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]:      -> service_version: Str(0.75.0)
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: StartTimestamp: 2023-05-16 08:23:39.006 +0000 UTC
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Timestamp: 2023-05-16 08:23:39.006 +0000 UTC
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Value: 0.000000
May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]:         {"kind": "exporter", "data_type": "metrics", "name": "logging"}

Tips: status表示を中止するには

systemctl status コマンドの表示を中止するときは q キーを押してください。

サービスを停止するときは、 stop コマンドを使います。

sudo systemctl stop otelcol-contrib

更新した設定ファイルを読み込ませるときは、 restart コマンドでサービスの再起動をしましょう。

sudo systemctl restart otelcol-contrib

Ninja: Open Telemetry Collector Builder (ocb) を使って、独自のコレクターを作る

このパートでは、お使いのシステムに以下のものがインストールされている必要があります

Go (latest version)

cd /tmp
wget https://golang.org/dl/go1.20.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz

.profile を編集して、次の環境変数をセットします:

export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

そして、シェルのセッションを更新します:

source ~/.profile

Goのバージョンを確認します:

go version

ocbのインストール
- ocbバイナリーを project releases からダウンロードして、次のコマンドを実行します:
```
mv ocb_0.80.0_darwin_arm64 /usr/bin/ocb
chmod 755 /usr/bin/ocb
```
  別のアプローチとして、Goのツールチェーンを使ってバイナリをローカルにビルドする方法もあります:
```
go install go.opentelemetry.io/collector/cmd/builder@v0.80.0
mv $(go env GOPATH)/bin/builder /usr/bin/ocb
```
(Optional) Docker

なぜ独自のコレクターをビルドするの？

コレクターのデフォルトのディストリビューション（coreおよびcontrib）は、含まれれるコンポーネントが少なすぎたり、もしくは多すぎたりします。

本番環境でcontribコレクターを実行することはできますが、インストールされているコンポーネントの量が多く、デプロイに必要ではないものも含まれるため、一般的には推奨されません。

独自のコレクターをビルドする利点は？

独自のコレクターバイナリー（通常は「ディストリビューション」と呼ばれる）を作成することで、必要なものだけをビルドすることができます。

メリットは次のとおりです:

バイナリーのサイズが小さい
一般的なGoの脆弱性スキャナーを利用できる
組織独自のコンポーネントを組み込むことができる

カスタムコレクターをビルドするときの注意事項は？

さて、これはNinjaゾーンの人たちにあえて言うことではないかもしれませんが:

Goの開発経験を、必須ではないが、推奨される
Splunkの サポートがない
ディストリビューションのライフサイクルを管理しなければならない

プロジェクトは安定性に向けて進んでいますが、行われた変更がワークフローを壊す可能性があることに注意してください。Splunkチームは、より高い安定性とサポートを提供し、デプロイメントニーズに対応するためのキュレーションされた経験を提供しています。

Ninja ゾーン

必要なツールをすべてインストールしたら、以下のディレクトリ構造に従い、 otelcol-builder.yaml という新しいファイルを作成します:

.
└── otelcol-builder.yaml

ファイルを作成したら、インストールするコンポーネントのリストと追加のメタデータを追加する必要があります。

この例では、導入設定に必要なコンポーネントのみをインストールするためのビルダーマニフェストを作成します:

dist:
  name: otelcol-ninja
  description: A custom build of the Open Telemetry Collector
  output_path: ./dist

extensions:
- gomod: go.opentelemetry.io/collector/extension/ballastextension v0.80.0
- gomod: go.opentelemetry.io/collector/extension/zpagesextension  v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/httpforwarder v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0

exporters:
- gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/splunkhecexporter v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/signalfxexporter v0.80.0

processors:
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0
- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.80.0

receivers:
- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/zipkinreceiver v0.80.0

ocb のためのyamlファイルを作成して更新したら、次のコマンドを実行します:

ocb --config=otelcol-builder.yaml

すると、次のようなディレクトリ構造が作成されます:

├── dist
│   ├── components.go
│   ├── components_test.go
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   ├── main_others.go
│   ├── main_windows.go
│   └── otelcol-ninja
└── otelcol-builder.yaml

最後に、 ./dist/otelcol-ninja を実行すれば、独自ビルドのCollectorが動作することがわかります。このコマンドを実行する前に、 otelcol-contrib サービスが停止していることを確認してください。

./dist/otelcol-ninja --config=file:/etc/otelcol-contrib/config.yaml

この設定ファイルで記述されているコンポーネントは、ビルドに含まれていないかもしれません。エラーの内容を含めて、何が起こるかを見てみましょう。

リファレンス

https://opentelemetry.io/docs/collector/custom-collector/

デフォルト設定

OpenTelemetry CollectorはYAMLファイルを使って設定をしていきます。これらのファイルには、必要に応じて変更できるデフォルト設定が含まれています。提供されているデフォルト設定を見てみましょう:

cat /etc/otelcol-contrib/config.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
extensions:
  health_check:
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:

exporters:
  logging:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [logging]

  extensions: [health_check, pprof, zpages]

おめでとうございます！OpenTelemetry Collectorのダウンロードとインストールに成功しました。あなたはOTel Ninjaになる準備ができました。しかしまずは、設定ファイルとOpenTelemetry Collectorの異なるディストリビューションについて見ていきましょう。

メモ

Splunkは、自社で完全にサポートされたOpenTelemetry Collectorのディストリビューションを提供しています。このディストリビューションは、Splunk GitHub Repository からインストールするか、Splunk Observability Cloudのウィザードを使用して、簡単なインストールスクリプトを作成し、コピー＆ペーストすることで利用できます。このディストリビューションには、OpenTelemetry Collector Contribディストリビューションにはない追加機能や強化が含まれています。

SplunkのOpenTelemetry Collectorディストリビューションは本番環境でテスト済みであり、多くの顧客が本番環境で使用しています。
このディストリビューションを使用する顧客は、公式のSplunkサポートから、SLAの範囲内で直接支援を受けることができます。
メトリクスとトレース収集のコア構成体験に将来的な破壊的変更がないことを心配せずに、SplunkのOpenTelemetry Collectorディストリビューションを使用または移行することができます（OpenTelemetryログ収集の設定はベータ版です）。Collector自身のメトリクスに破壊的変更がある可能性はあります。

このセクションでは、ホストメトリクスをSplunk Observability Cloudに送信するために、設定ファイルの各セクションを詳しく見ていき、変更する方法について説明します。

OpenTelemetry Collector エクステンション

さて、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 Receivers
    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 エクステンション

Health Check エクステンション

他のコンポーネントと同様に、エクステンションは config.yaml ファイルで設定できます。ここでは実際に config.yaml ファイルを編集して、エクステンションを設定していきましょう。デフォルトの config.yaml では、すでに pprof エクステンションと zpages エクステンションが設定されていることを確認してみてください。このワークショップでは、設定ファイルをアップデートして health_check エクステンションを追加し、ポートを解放し、外部ネットワークからコレクターのヘルスチェックにアクセスできるようにしていきます。

sudo vi /etc/otelcol-contrib/config.yaml

extensions:
  health_check:
    endpoint: 0.0.0.0:13133

コレクターを起動します:

sudo systemctl restart otelcol-contrib

このエクステンションはHTTPのURLを公開し、OpenTelemetry Collectorの稼働状況をチェックするプローブを提供します。このエクステンションはKubernetes環境でのLiveness/Readinessプローブとしても使われています。 curl コマンドの使い方は、curl man page を参照してください。

次のコマンドを実行します:

curl http://localhost:13133

{"status":"Server available","upSince":"2023-04-27T10:11:22.153295874+01:00","uptime":"16m24.684476004s"}

OpenTelemetry Collector エクステンション

Performance Profiler エクステンション

Performance Profiler エクステンションは、Goのnet/http/pprofエンドポイントを有効化します。これは通常、開発者がパフォーマンスプロファイルを収集し、サービスの問題を調査するために使用します。このワークショップでは詳しく紹介はしません。

OpenTelemetry Collector エクステンション

zPages エクステンション

zPages は、外部エクスポータに代わるプロセス内部の機能です。有効化すると、バックグラウンドでトレースとメトリクス情報を収集し、集計し、どのようなデータを扱ったかのWebページを公開します。zpagesは、コレクターが期待どおりに動作していることを確認するための非常に便利な診断機能です。

ServiceZ は、コレクターサービスの概要と、pipelinez、extensionz、featurez zPagesへのクイックアクセスを提供します。このページでは、ビルドとランタイムの情報も提供します。

URL: http://localhost:55679/debug/servicez (localhost は、適切なホスト名に切り替えてください)

PipelineZ は、コレクターで実行中のパイプラインに関する情報を提供します。タイプ、データが変更されているか、各パイプラインで使用されているレシーバー、プロセッサー、エクスポーターの情報を見ることができます。

URL: http://localhost:55679/debug/pipelinez (localhost は、適切なホスト名に切り替えてください)

ExtensionZ は、コレクターで有効化されたエクステンションを確認できます。

Example URL: http://localhost:55679/debug/extensionz (localhost は、適切なホスト名に切り替えてください)

Ninja: storageエクステンションでデータの耐久性を向上させる

これをこなうには、ディストリビューションに file_storage エクステンションモジュールがインストールされていることを確認する必要があります。確認するには、otelcol-contrib components コマンドを実行します:

otelcol-contrib components

# ... truncated for clarity
extensions:
  - file_storage

buildinfo:
    command: otelcol-contrib
    description: OpenTelemetry Collector Contrib
    version: 0.80.0
receivers:
    - prometheus_simple
    - apache
    - influxdb
    - purefa
    - purefb
    - receiver_creator
    - mongodbatlas
    - vcenter
    - snmp
    - expvar
    - jmx
    - kafka
    - skywalking
    - udplog
    - carbon
    - kafkametrics
    - memcached
    - prometheus
    - windowseventlog
    - zookeeper
    - otlp
    - awsecscontainermetrics
    - iis
    - mysql
    - nsxt
    - aerospike
    - elasticsearch
    - httpcheck
    - k8sobjects
    - mongodb
    - hostmetrics
    - signalfx
    - statsd
    - awsxray
    - cloudfoundry
    - collectd
    - couchdb
    - kubeletstats
    - jaeger
    - journald
    - riak
    - splunk_hec
    - active_directory_ds
    - awscloudwatch
    - sqlquery
    - windowsperfcounters
    - flinkmetrics
    - googlecloudpubsub
    - podman_stats
    - wavefront
    - k8s_events
    - postgresql
    - rabbitmq
    - sapm
    - sqlserver
    - redis
    - solace
    - tcplog
    - awscontainerinsightreceiver
    - awsfirehose
    - bigip
    - filelog
    - googlecloudspanner
    - cloudflare
    - docker_stats
    - k8s_cluster
    - pulsar
    - zipkin
    - nginx
    - opencensus
    - azureeventhub
    - datadog
    - fluentforward
    - otlpjsonfile
    - syslog
processors:
    - resource
    - batch
    - cumulativetodelta
    - groupbyattrs
    - groupbytrace
    - k8sattributes
    - experimental_metricsgeneration
    - metricstransform
    - routing
    - attributes
    - datadog
    - deltatorate
    - spanmetrics
    - span
    - memory_limiter
    - redaction
    - resourcedetection
    - servicegraph
    - transform
    - filter
    - probabilistic_sampler
    - tail_sampling
exporters:
    - otlp
    - carbon
    - datadog
    - f5cloud
    - kafka
    - mezmo
    - skywalking
    - awsxray
    - dynatrace
    - loki
    - prometheus
    - logging
    - azuredataexplorer
    - azuremonitor
    - instana
    - jaeger
    - loadbalancing
    - sentry
    - splunk_hec
    - tanzuobservability
    - zipkin
    - alibabacloud_logservice
    - clickhouse
    - file
    - googlecloud
    - prometheusremotewrite
    - awscloudwatchlogs
    - googlecloudpubsub
    - jaeger_thrift
    - logzio
    - sapm
    - sumologic
    - otlphttp
    - googlemanagedprometheus
    - opencensus
    - awskinesis
    - coralogix
    - influxdb
    - logicmonitor
    - signalfx
    - tencentcloud_logservice
    - awsemf
    - elasticsearch
    - pulsar
extensions:
    - zpages
    - bearertokenauth
    - oidc
    - host_observer
    - sigv4auth
    - file_storage
    - memory_ballast
    - health_check
    - oauth2client
    - awsproxy
    - http_forwarder
    - jaegerremotesampling
    - k8s_observer
    - pprof
    - asapclient
    - basicauth
    - headers_setter

このエクステンションは、エクスポーターが設定されたエンドポイントにデータを送信できない事象が発生したときに、データをディスクにキューイングする機能をエクスポーターに提供します。

このエクステンションを設定するには、以下の情報を含むように設定を更新する必要があります。まず、 /tmp/otel-dataディレクトリを作成し、読み取り/書き込み権限を与えてください

extensions:
...
  file_storage:
    directory: /tmp/otel-data
    timeout: 10s
    compaction:
      directory: /tmp/otel-data
      on_start: true
      on_rebound: true
      rebound_needed_threshold_mib: 5
      rebound_trigger_threshold_mib: 3

# ... truncated for clarity

service:
  extensions: [health_check, pprof, zpages, file_storage]

なぜキューデータをディスクに書くの？

コレクターはネットワークの不調（および、コレクターの再起動）を乗り切って、アップストリームプロバイダーに確実にデータを送信できるようになります。

キューデータをディスクに書く時の注意事項は？

ディスクの性能により、データスループットの性能に影響を与える可能性があります

参照

設定を確認しましょう

さて、エクステンションについて説明したので、設定の変更箇所を確認していきましょう。

Check-in設定ファイルを確認してください

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:

exporters:
  logging:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [logging]

  extensions: [health_check, pprof, zpages]

さて、エクステンションについて復習したところで、ワークショップのデータパイプラインの部分に飛び込んでみましょう。パイプラインとは、コレクター内でデータがたどる経路を定義するもので、レシーバーから始まり、追加の処理や変更をし、最終的にエクスポーターを経由してコレクターを出ます。

OpenTelemetry Collectorのデータパイプラインは、レシーバー、プロセッサー、エクスポーターで構成されています。まずは、レシーバーから見ていきましょう。

OpenTelemetry Collector レシーバー

レシーバーワークショップへようこそ！OpenTelemetry Collectorのデータパイプラインのスタート地点です。さあ、始めましょう。

レシーバーはデータをCollectorに取り込む方法で、プッシュベースとプルベースのものがあります。レシーバーは1つ以上のデータソースをサポートします。一般的に、レシーバーは指定されたフォーマットでデータを受け入れ、内部フォーマットに変換し、該当するパイプラインで定義されたプロセッサやエクスポータにデータを渡します。

プッシュまたはプルベースのレシーバは、データをCollectorに取り込む方法です。レシーバは1つまたは複数のデータソースをサポートします。通常、レシーバは指定されたフォーマットでデータを受け入れ、内部フォーマットに変換し、該当するパイプラインで定義されたプロセッサーやエクスポーターにデータを渡します。

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

flowchart LR;
    style M fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
    subgraph Receivers
    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 レシーバー

Host Metrics レシーバー

Host Metrics レシーバー は、さまざまなソースからスクレイピングされたホストシステムに関するメトリクスを生成します。これは、コレクターがエージェントとしてデプロイされるときに使用さます。

etc/otel-contrib/config.yaml ファイルを更新して、hostmetrics レシーバーを設定してみましょう。以下のYAMLを receivers セクションの下に挿入します。

sudo vi /etc/otelcol-contrib/config.yaml

Tips: vi or nano

vi/vimの操作に慣れていない場合は、nano もお試しいただくと良いかもしれません。nanoはLinux環境でよく使われる、シンプルなエディタの一つです。

sudo nano /etc/otelcol-contrib/config.yaml

Alt-U で、アンドゥができます。Macの場合は Esc キーを押したあとに U を押してください！
ctrl-_ のあとに数字を入力すると、指定した行数にジャンプします。
ctrl-O のあとに Enter で、ファイルを保存します。
ctrl-X で、nanoを終了します。

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:

OpenTelemetry Collector レシーバー

Prometheus レシーバー

Prometheus のレシーバーも、もちろんあります。Prometheus はOpenTelemetry Collectorで使われているオープンソースのツールキットです。このレシーバーは、OpenTelemetry Collector自身からメトリクスをスクレイピングするためにも使われます。これらのメトリクスは、コレクタの健全性をモニタリングするために使用できる。

ここでは、prometheus レシーバーを変更して、コレクター自身からメトリクスを収集できるようにしてみます。レシーバーの名前を prometheus から prometheus/internal に変更して、レシーバーが何をしているのかをより明確しましょう。設定ファイルを以下のように更新します

prometheus/internal:
  config:
    scrape_configs:
    - job_name: 'otel-collector'
      scrape_interval: 10s
      static_configs:
      - targets: ['0.0.0.0:8888']

上記の設定では、OpenTelemetry Collector自身が公開しているPrometheusエンドポイントをスクレイピングしています。どのような情報が得られるか、curl コマンドで試すことができます:

curl http://localhost:8888/metrics

Tips: コンポーネントに名前をつける

レシーバー、プロセッサー、エクスポーター、パイプラインなどのコンポーネントは、 otlp や otlp/2 のように、 type[/name] 形式に従った識別子によって定義されます。識別子が一意である限り、与えられたタイプのコンポーネントを複数回定義することができるようになります。

ここでは prometheus/internal という識別子でこのコンポーネントを特定できるようにしたので、別の prometheus レシーバーを追加して、監視対象インスタンスのPrometheusエンドポイントをスクレイピングさせることもできます。

ダッシュボード例 - Prometheus メトリクス

このスクリーンショットは、 prometheus/internal レシーバーがOpenTelemetry Collectorから収集したメトリクスの、spmeのダッシュボードの例です。ここではスパン・メトリクス・ログの、それぞれの受信および送信の様子を見ることができます。

メモ

このダッシュボードはSplunk Observability Cloudにある組み込みダッシュボードで、Splunk OpenTelemetry Collectorのインストールの状況を簡単にモニタリングできます。

OpenTelemetry Collector レシーバー

その他のレシーバー

デフォルトの設定には、他のレシーバーがあることに気づくはずです。 otlp、opencensus、jaeger、zipkin が定義されています。これらは他のソースからテレメトリーデータを受信するために使われます。このワークショップでは、これらのレシーバーについては取り上げませんので、そのままにしておきましょう。

Ninja: レシーバーを動的に生成する

dockerコンテナ、kubernetesポッド、sshセッションのような短時間のタスクを観測するために、receiver creator レシーバーと observer エクステンションを使って、対象のサービスが起動するタイミングで新しいレシーバーを作成することができます。

何が必要なの？

receiver creatorとそれに関連するobserverエクステンションの使用を開始するには、collector build manifestに追加する必要があります。

詳細は installation を参照してください。

注意事項はある？

短命なタスクの中には、username や password のような追加設定を必要とするものがあります。それらの値は環境変数を参照したり、 ${file:./path/to/database/password} のようなスキーム展開構文を使うこともできます。

組織における機密情報の取り扱い規定に従って、どのような方法を取るかを検討してください。

Ninja ゾーン

このNinjaゾーンに必要なものは2つだけです:

builder manifestに、 receiver creatorレシーバーとobserverエクステンションを追加する
検出されたエンドポイントを検出するように、設定を作成する

次のようにすると、設定をテンプレート化できます:

receiver_creator:
  watch_observers: [host_observer]
  receivers:
    redis:
      rule: type == "port" && port == 6379
      config:
        password: ${env:HOST_REDIS_PASSWORD}

他の例は receiver creator’s examples にあります。

設定を確認しましょう

これで、レシーバーをカバーできました。ここで、設定のの変更内容をチェックしてみましょう。

Check-in設定をレビューしてください

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:

exporters:
  logging:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [otlp, opencensus, prometheus/internal]
      processors: [batch]
      exporters: [logging]

  extensions: [health_check, pprof, zpages]

これで、レシーバーを通してOpenTelemetry Collectorにデータがどのように取り込まれるかを確認しました。次に、コレクターが受信したデータをどのように処理するかを見てみましょう。

警告

ここではコレクターを再起動しないでください！　 /etc/otelcol-contrib/config.yaml の変更はまだ完了していません。

OpenTelemetry Collector プロセッサー

プロセッサーは、レシーバーとエクスポーターとの間で、データに対して実行される処理です。プロセッサーはオプションですが、いくつかは推奨されています。OpenTelemetry Collector Contribには多数のプロセッサーが含まれています。

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

flowchart LR;
    style Processors fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
    subgraph Receivers
    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 プロセッサー

Batch プロセッサー

デフォルトでは、batch プロセッサーだけが有効になっています。このプロセッサーは、データをエクスポートする前にバッチ処理して、エクスポーターへのネットワーク・コールの回数を減らすために使われます。このワークショップではデフォルトの設定を使用します

send_batch_size (デフォルト = 8192): タイムアウトに関係なく、バッチを送信するスパン、メトリクスデータポイント、またはログレコードの数。パイプラインの次のコンポーネントに送信されるバッチサイズを制限する場合には、 send_batch_max_size を使います。
timeout (デフォルト = 200ms): サイズに関係なく、バッチが送信されるまでの時間。ゼロに設定すると、send_batch_size の設定を無視して send_batch_max_size だけが適用され、データは直ちに送信されます。
send_batch_max_size (デフォルト = 0): バッチサイズの上限。0 を設定すると、バッチサイズの上限がないことして扱われます。この設定は、大きなバッチが小さなユニットに分割されることを保証します。send_batch_size 以上でなければななりません。

OpenTelemetry Collector プロセッサー

Resource Detection プロセッサー

resourcedetection プロセッサーは、ホストからリソース情報を検出して、テレメトリーデータ内のリソース値をこの情報で追加または上書きすることができます。

デフォルトでは、可能であればホスト名をFQDNに設定し、そうでなければOSが提供するホスト名になります。このロジックは hostname_sources オプションを使って変更できます。FQDNを取得せず、OSが提供するホスト名を使用するには、hostname_sources を os に設定します。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]

If the workshop instance is running on an AWS/EC2 instance we can gather the following tags from the EC2 metadata API (this is not available on other platforms). ワークショップのインスタンスがAWS/EC2インスタンスで実行されている場合、EC2のメタデータAPIから以下のタグを収集します（これは他のプラットフォームでは利用できないものもあります）。

cloud.provider ("aws")
cloud.platform ("aws_ec2")
cloud.account.id
cloud.region
cloud.availability_zone
host.id
host.image.id
host.name
host.type

これらのタグをメトリクスに追加するために、別のプロセッサーとして定義してみましょう。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]

OpenTelemetry Collector プロセッサー

Attributes プロセッサー

attributeプロセッサーを使うと、スパン、ログ、またはメトリクスの属性を変更できます。また、このプロセッサーは、入力データをフィルタリングし、マッチさせ、指定されたアクションに含めるべきか、除外すべきかを決定する機能もサポートしています。

アクションを設定するには、指定された順序で実行されるアクションのリストを記述します。サポートされるアクションは以下の通りです

insert: その属性がない場合に、新しい属性値を挿入します。
update: その属性がある場合に、その属性値を更新します。
upsert: insertまたはupdateを実行します。属性がない場合には新しい属性値を挿入し、属性がある場合にはその値を更新します。
delete: 入力データから属性値を削除します。
hash: 属性値をハッシュ化 (SHA1) します。
extract: 入力キーの値を正規表現ルールを使って抽出し、対象キーの値を更新します。対象キーがすでに存在する場合は、その値は上書きされます。

次の例のように、attributeプロセッサーを使って、キーは participant.name、あたいはあなたの名前（例: marge_simpson）という新しい属性を追加してみましょう。

警告

INSERT_YOUR_NAME_HERE の箇所は、自分の名前に置き換えてください。また、自分の名前に スペースを使わない ようにしてください。

このワークショップの後半では、この属性を使用してSplunk Observability Cloudでメトリクスをフィルタリングします。

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

Ninja: コネクターを使って内部への洞察を加速する

最近追加されたものの一つとして、connector というコンセプトがあります。これを使うと、あるパイプラインの出力を別のパイプラインの入力に結合できるようになります。

利用シーンとして、送信するデータポイントの量、エラーステータスを含むログの数をメトリクスをとして出力するサービスがあります。他には、あるデプロイ環境から送信されるデータ量のメトリクスを生成するサービスがあります。このような場合に、countコネクターですぐに対応できます。

プロセッサーではなくコネクターなのはなぜ？

プロセッサーは、処理したデータを次に渡すものであり、追加の情報を出力することはできません。コネクターはレシーバーで受け取ったデータを出力せずに、私たちが求める洞察を作り出す機会を提供します。

たとえば、countコネクターを使うと、環境変数 deployment を持たないログ、メトリクス、トレースの数をカウントすることができます。

また、非常にシンプルな例として、deployment 別にデータ使用量を分解して出力することもできます。

コネクターの注意事項

コネクターは、あるパイプラインからエクスポートされ、別のパイプラインでレシーバーで定義されたデータのみを受け入れます。コレクターをどう構築してどう利用するか、設定を検討する必要があります。

参照

設定を確認しましょう

これで、プロセッサーがカバーできました。ここで、設定のの変更内容をチェックしてみましょう。

Check-in設定をレビューしてください

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  logging:
    verbosity: detailed

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [logging]

  extensions: [health_check, pprof, zpages]

OpenTelemetry Collector エクスポーター

エクスポーターは、プッシュまたはプルベースであり、一つ以上のバックエンド/デスティネーションにデータを送信する方法です。エクスポーターは、一つまたは複数のデータソースをサポートすることがあります。

このワークショップでは、otlphttp エクスポーターを使用します。OpenTelemetry Protocol (OTLP) は、テレメトリーデータを伝送するためのベンダーニュートラルで標準化されたプロトコルです。OTLPエクスポーターは、OTLPプロトコルを実装するサーバーにデータを送信します。OTLPエクスポーターは、gRPC および HTTP/JSON プロトコルの両方をサポートします。

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

flowchart LR;
    style Exporters fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
    subgraph Receivers
    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 エクスポーター

OTLP HTTP エクスポーター

Splunk Observability CloudへHTTP経由でメトリックスを送信するためには、otlphttp エクスポーターを設定する必要があります。

/etc/otelcol-contrib/config.yaml ファイルを編集し、otlphttp エクスポーターを設定しましょう。以下のYAMLを exporters セクションの下に挿入し、例えば2スペースでインデントしてください。

また、ディスクの容量不足を防ぐために、ロギングエクスポーターの詳細度を変更します。デフォルトの detailed は非常に詳細です。

exporters:
  logging:
    verbosity: normal
  otlphttp/splunk:

次に、metrics_endpoint を定義して、ターゲットURLを設定していきます。

メモ

Splunk主催のワークショップの参加者である場合、使用しているインスタンスにはすでにRealm環境変数が設定されています。その環境変数を設定ファイルで参照します。それ以外の場合は、新しい環境変数を作成してRealmを設定する必要があります。例えば

export REALM="us1"

使用するURLは https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp です。（Splunkは、データの居住地に応じて世界中の主要地域にRealmを持っています）。

otlphttp エクスポーターは、traces_endpoint と logs_endpoint それぞれのターゲットURLを定義することにより、トレースとログを送信するようにも設定できますが、そのような設定はこのワークショップの範囲外とします。

exporters:
  logging:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp

デフォルトでは、すべてのエンドポイントで gzip 圧縮が有効になっています。エクスポーターの設定で compression: none を設定することにより、圧縮を無効にすることができます。このワークショップでは圧縮を有効にしたままにし、データを送信する最も効率的な方法としてデフォルト設定を使っていきます。

Splunk Observability Cloudにメトリクスを送信するためには、アクセストークンを使用する必要があります。これは、Splunk Observability Cloud UIで新しいトークンを作成することにより行うことができます。トークンの作成方法についての詳細は、Create a token を参照してください。トークンは INGEST タイプである必要があります。

メモ

Splunk主催のワークショップの参加者である場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定されています）ので、その環境変数を設定ファイルで参照します。それ以外の場合は、新しいトークンを作成し、それを環境変数として設定する必要があります。例えば

export ACCESS_TOKEN=<replace-with-your-token>

トークンは、設定ファイル内で headers: セクションの下に X-SF-TOKEN: ${env:ACCESS_TOKEN} を挿入することにで定義します

exporters:
  logging:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-TOKEN: ${env:ACCESS_TOKEN}

設定を確認しましょう

これで、エクスポーターもカバーできました。設定を確認していきましょう

Check-in設定をレビューしてください

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  logging:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-TOKEN: ${env:ACCESS_TOKEN}

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [logging]

  extensions: [health_check, pprof, zpages]

もちろん、OTLP プロトコルをサポートする他のソリューションを指すように metrics_endpoint を簡単に設定することができます。

次に、config.yaml のサービスセクションで、今設定したレシーバー、プロセッサー、エクスポーターを有効にしていきます。

OpenTelemetry Collector サービス

Service セクションでは、レシーバー、プロセッサー、エクスポーター、およびエクステンションにある設定に基づいて、コレクターで有効にするコンポーネントを設定していきます。

情報

コンポーネントが設定されていても、Service セクション内で定義されていない場合、そのコンポーネントは有効化されません。

サービスのセクションは、以下の3つのサブセクションで構成されています

extensions（拡張機能）
pipelines（パイプライン）
telemetry（テレメトリー）

デフォルトの設定では、拡張機能セクションが health_check、pprof、zpages を有効にするように設定されており、これらは以前のエクステンションのモジュールで設定しました。

service:
  extensions: [health_check, pprof, zpages]

それでは、メトリックパイプラインを設定していきましょう！

OpenTelemetry Collector サービス

Hostmetrics レシーバー

ワークショップのレシーバー部分で振り返ると、ホストシステムに関するメトリクスを生成するために、様々なソースからスクレイピングする Host Metrics レシーバーを定義しました。このレシーバーを有効にするためには、メトリクスパイプラインに hostmetrics レシーバーを含める必要があります。

metrics パイプラインで、メトリクスの receivers セクションに hostmetrics を追加します。

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus]
      processors: [batch]
      exporters: [logging]

OpenTelemetry Collector サービス

Prometheus Internal レシーバー

ワークショップの前半で、prometheus レシーバーの名前を変更し、コレクター内部のメトリクスを収集していることを反映して、prometheus/internal という名前にしました。

現在、メトリクスパイプラインの下で prometheus/internal レシーバーを有効にする必要があります。metrics パイプラインの下の receivers セクションを更新して、prometheus/internal を含めます

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch]
      exporters: [logging]

OpenTelemetry Collector サービス

Resource Detection プロセッサー

また、コレクターがインスタンスのホスト名やAWS/EC2のメタデータを取得できるように、resourcedetection/system および resourcedetection/ec2 プロセッサーを追加しました。これらのプロセッサーをメトリクスパイプライン下で有効にする必要があります。

metrics パイプラインの下の processors セクションを更新して、resourcedetection/system および resourcedetection/ec2 を追加します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2]
      exporters: [logging]

OpenTelemetry Collector サービス

Attributes プロセッサー

また、このワークショップのプロセッサーセクションでは、attributes/conf プロセッサーを追加し、コレクターがすべてのメトリクスに participant.name という新しい属性を挿入するようにしました。これをメトリクスパイプライン下で有効にする必要があります。

metrics パイプラインの下の processors セクションを更新して、attributes/conf を追加します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
      exporters: [logging]

OpenTelemetry Collector サービス

OTLP HTTP エクスポーター

ワークショップのエクスポーターセクションでは、otlphttp エクスポーターを設定して、メトリクスをSplunk Observability Cloudに送信するようにしました。これをメトリクスパイプライン下で有効にする必要があります。

metrics パイプラインの下の exporters セクションを更新して、otlphttp/splunk を追加します

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
      exporters: [logging, otlphttp/splunk]

Ninja: コレクターの内部を観測する

コレクターは、その動作に関する内部シグナルを捕捉しています。これには実行中のコンポーネントからの追加されるシグナルも含まれます。これは、データの流れに関する決定を行うコンポーネントが、その情報をメトリクスやトレースとして表面化する方法を必要とするためです。

なぜコレクターを監視するの？

これは「監視者を監視するのは誰か？」という種類の問題ですが、このような情報を表面化できることは重要です。コレクターの歴史の興味深い部分は、GoメトリクスのSDKが安定と考えられる前に存在していたことで、コレクターは当面の間、この機能を提供するためにPrometheusエンドポイントを公開しています。

注意点

組織内で稼働している各コレクターの内部使用状況を監視することは、新しいメトリクス量（MTS）を大幅な増加させる可能性があります。Splunkディストリビューションはこれらのメトリクスをキュレーションしており、増加を予測するのに役立ちます。

Ninja ゾーン

コレクターの内部オブザーバビリティを公開するためには、いくつかの設定を追加することがあります

service:
  telemetry:
    logs:
      level: <info|warn|error>
      development: <true|false>
      encoding: <console|json>
      disable_caller: <true|false>
      disable_stacktrace: <true|false>
      output_paths: [<stdout|stderr>, paths...]
      error_output_paths: [<stdout|stderr>, paths...]
      initial_fields:
        key: value
    metrics:
      level: <none|basic|normal|detailed>
      # Address binds the promethues endpoint to scrape
      address: <hostname:port>

service:
  telemetry:
    logs: 
      level: info
      encoding: json
      disable_stacktrace: true
      initial_fields:
        instance.name: ${env:INSTANCE}
    metrics:
      address: localhost:8888

参照

https://opentelemetry.io/docs/collector/configuration/#service

完成した設定

Check-in完成した設定をレビューしてください

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      # CPU utilization metrics
      cpu:
      # Disk I/O metrics
      disk:
      # File System utilization metrics
      filesystem:
      # Memory utilization metrics
      memory:
      # Network interface I/O metrics & TCP connection metrics
      network:
      # CPU load metrics
      load:
      # Paging/Swap space utilization and I/O metrics
      paging:
      # Process count metrics
      processes:
      # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
      # process:
  otlp:
    protocols:
      grpc:
      http:

  opencensus:

  # Collect own metrics
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8888']

  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  zipkin:

processors:
  batch:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]
  resourcedetection/ec2:
    detectors: [ec2]
  attributes/conf:
    actions:
      - key: participant.name
        action: insert
        value: "INSERT_YOUR_NAME_HERE"

exporters:
  logging:
    verbosity: normal
  otlphttp/splunk:
    metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
    headers:
      X-SF-TOKEN: ${env:ACCESS_TOKEN}

service:

  pipelines:

    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]
      processors: [batch]
      exporters: [logging]

    metrics:
      receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
      processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] 
      exporters: [logging, otlphttp/splunk]

  extensions: [health_check, pprof, zpages]

ヒント

コレクターを再起動する前に、設定ファイルを検証することをお勧めします。これは、組み込みの validate コマンドを使用して行うことができます

otelcol-contrib validate --config=file:/etc/otelcol-contrib/config.yaml

Error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:

* error decoding 'processors': error reading configuration for "attributes/conf": 1 error(s) decoding:

* 'actions[0]' has invalid keys: actions
2023/06/29 09:41:28 collector server run finished with error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:

* error decoding 'processors': error reading configuration for "attributes/conf": 1 error(s) decoding:

* 'actions[0]' has invalid keys: actions

動作する設定ができたので、コレクターを起動し、その後 zPages が報告している内容を確認しましょう。

sudo systemctl restart otelcol-contrib

データの可視化

Splunk Observability Cloud

OpenTelemetry Collectorを設定してSplunk Observability Cloudにメトリクスを送信するようにしたので、Splunk Observability Cloudでデータを見てみましょう。Splunk Observability Cloudへの招待を受け取っていない場合は、講師がログイン資格情報を提供します。

その前に、もう少し興味深くするために、インスタンスでストレステストを実行しましょう。これにより、ダッシュボードが活性化されます。

sudo apt install stress
while true; do stress -c 2 -t 40; stress -d 5 -t 40; stress -m 20 -t 40; done

Splunk Observability Cloudにログインしたら、左側のナビゲーションを使用して Dashboards に移動します

検索ボックスで OTel Contrib を検索します

情報

ダッシュボードが存在しない場合は、講師が迅速に追加します。このワークショップのSplunk主催版に参加していない場合、インポートするダッシュボードグループはこのページの下部にあります。

OTel Contrib Dashboard ダッシュボードをクリックして開きます

ダッシュボードの上部にある Filter 欄に「participant」の途中まで入力し、候補に出る participant.name を選択します

participant.name で、config.yaml 内で設定したあなたの名前を入力するか、リストから選択することができます

これで、OpenTelemetry Collectorを設定したホストの、ホストメトリクスを確認することができます。

ダッシュボードJSONのダウンロード方法

index.files/dashboard_OTel-Contrib-Dashboard.json (40 KB)

OpenTelemetry Collector を開発する

カスタムコンポーネントの開発

Open Telemetry Collectorのためのコンポーネントを構築するには、以下の3つの主要な部分が必要です

Configuration - ユーザーが設定できる値は何か
Factory - 提供された値を使ってコンポーネントを作成する
Business Logic - コンポーネントが実行する必要があること

これについて、プロジェクトの重要なDevOpsメトリクスを追跡するためにJenkinsと連携するコンポーネントを構築する例を考えていきます。

測定しようとしているメトリクスは次のとおりです

変更に対するリードタイム - 「コミットが本番環境に入るまでにかかる時間」
変更失敗率 - 「本番環境での障害を引き起こすデプロイの割合」
デプロイ頻度 - 「[チーム]が本番環境に成功してリリースする頻度」
平均復旧時間 - 「[チーム]が本番環境の障害から復旧するのにかかる時間」

これらの指標はGoogleの DevOps Research and Assessment (DORA) チームによって特定されたもので、ソフトウェア開発チームのパフォーマンスを示すのに役立ちます。Jenkins CI を選択した理由は、私たちが同じオープンソースソフトウェアエコシステムに留まり、将来的にベンダー管理のCIツールが採用する例となることができるためです。

計装 🆚 コンポーネント

組織内でオブザーバビリティを向上させる際には、トレードオフが発生するため、考慮する点があります。

	長所	短所
（自動）計装¹	システムを観測するために外部APIが不要	計装を変更するにはプロジェクトの変更が必要
	システム所有者/開発者は可観測性の変更が可能	ランタイムへの追加の依存が必要
	システムの文脈を理解し、Exemplar とキャプチャされたデータを関連付けることが可能	システムのパフォーマンスに影響を与える可能性がある
コンポーネント	データ名や意味の変更をシステムのリリースサイクルから独立した展開が可能	APIの破壊的な変更の可能性があり、システムとコレクター間でリリースの調整が必要
	その後の利用に合わせて収集されるデータの更新/拡張が容易	キャプチャされたデータの意味がシステムリリースと一致せず、予期せず壊れる可能性がある

計装（instrument, インストゥルメント）とは、アプリケーションなどのシステムコンポーネントに対して、トレースやメトリクス、ログなどのテレメトリーデータを出力させる実装。計装ライブラリを最低限セットアップするだけで一通りのトレースやメトリクスなどを出力できるような対応を「自動計装」と呼びます。 ↩︎

OpenTelemetry Collector を開発する

プロジェクトのセットアップ Ninja

メモ

このワークショップのセクションを完了する時間は経験によって異なる場合があります。

完成したものはこちらにあります。詰まった場合や講師と一緒に進めたい場合に利用してください。

新しい Jenkins CI レシーバーの開発を始めるため、まずはGoプロジェクトのセットアップから始めていきます。新しいGoプロジェクトを作成する手順は以下の通りです

${HOME}/go/src/jenkinscireceiver という名前の新しいディレクトリを作成し、そのディレクトリに移動します。
1. 実際のディレクトリ名や場所は厳密ではありません。自分の開発ディレクトリを自由に選ぶことができます。
go mod init splunk.conf/workshop/example/jenkinscireceiver を実行して、Goのモジュールを初期化します。
1. 依存関係を追跡するために使用される go.mod というファイルが作成されます。
2. インポートされている依存関係のチェックサム値が go.sum として保存されます。

Check-ingo.modをレビューする

`` text module splunk.conf/workshop/example/jenkinscireceiver

go 1.20

OpenTelemetry Collector を開発する

Configuration の構築

コンポーネントのConfiguration部分は、ユーザーがコンポーネントに対する入力を行う方法であり、設定に使用される値は以下のようである必要があります

そのフィールドが何を制御するのか、ユーザーが直感的に理解できる
必須項目とオプション項目が明確である
共通の名前とフィールドを再利用する
オプションをシンプルに保つ

---
# Required Values
endpoint: http://my-jenkins-server:8089
auth:
    authenticator: basicauth/jenkins
# Optional Values
collection_interval: 10m
metrics:
    example.metric.1:
        enabled: true
    example.metric.2:
        enabled: true
    example.metric.3:
        enabled: true
    example.metric.4:
        enabled: true

---
jenkins_server_addr: hostname
jenkins_server_api_port: 8089
interval: 10m
filter_builds_by:
    - name: my-awesome-build
      status: amber
track:
    values:
        example.metric.1: yes
        example.metric.2: yes
        example.metric.3: no
        example.metric.4: no

悪い例では、Configurationのベストプラクティスに反するとコンポーネントが使いにくくなってしまうことが理解できるはずです。フィールドの値が何であるべきかを明確ではなく、既存のプロセッサーに移譲できる機能を含み、コレクター内の他のコンポーネントと比較してフィールドの命名に一貫性がありません。

良い例では、必要な値をシンプルに保ち、他のコンポーネントからのフィールド名を再利用し、コンポーネントがJenkinsとコレクター間の相互作用にのみ焦点を当てています。

設定値の中には、このコンポーネントで独自に追加するものと、コレクター内部の共有ライブラリによって提供されているものがあります。これらはビジネスロジックに取り組む際にさらに詳しく説明します。Configurationは小さく始めるべきで、ビジネスロジックに追加の機能が必要になったら、設定も追加していきましょう。

コードを書く

Configurationに必要なコードを実装するために、config.go という名前の新しいファイルを以下の内容で作成します

package jenkinscireceiver

import (
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type Config struct {
    // HTTPClientSettings contains all the values
    // that are commonly shared across all HTTP interactions
    // performed by the collector.
    confighttp.HTTPClientSettings `mapstructure:",squash"`
    // ScraperControllerSettings will allow us to schedule 
    // how often to check for updates to builds.
    scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
    // MetricsBuilderConfig contains all the metrics
    // that can be configured.
    metadata.MetricsBuilderConfig `mapstructure:",squash"`
}

OpenTelemetry Collector を開発する

コンポーネントを検討する

Jenkinsからメトリクスを取得するために必要なコンポーネントの種類をおさらいしましょう

エクステンションが解決するビジネスユースケースは以下の通りです

実行時の設定が必要な共有機能を持つ
コレクターの実行時間の観察に間接的に役立つ

詳細については、エクステンションの概要を参照してください。

レシーバーが解決するビジネスユースケースは以下の通りです

リモートソースからのデータの取得
リモートソースからのデータの受信

これらは一般的に pull 対 push ベースのデータ収集と呼ばれ、詳細についてはレシーバーの概要で読むことができます。

プロセッサーが解決するビジネスユースケースは以下の通りです

データ、フィールド、または値の追加または削除
データの観察と意思決定
バッファリング、キューイング、および並べ替え

プロセッサーを通過するデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があることを覚えておいてください。詳細については、プロセッサーの概要をご覧ください。

エクスポーターが解決するビジネスユースケースは以下の通りです

データをツール、サービス、またはストレージに送信する

OpenTelemetryコレクターは「バックエンド」、すべてを一元化した観測可能性スイートを目指すのではなく、OpenTelemetryの創設原則に忠実であり続けることを目指しています。つまり、ベンダーに依存しない全ての人のための観測可能性です。詳細については、エクスポーターの概要をお読みください。

コネクターは比較的新しいコンポーネントで、このワークショップではあまり触れていません。コネクターは、異なるテレメトリタイプやパイプラインをまたいで使用できるプロセッサーのようなものだといえます。たとえば、コネクターはログとしてデータを受け取り、メトリクスとして出力したり、あるパイプラインからメトリクスを受け取り、テレメトリーデータに関するメトリクスを提供したりすることができます。

コネクターが解決するビジネスケースは以下の通りです

異なるテレメトリタイプ間の変換
- ログからメトリクスへ
- トレースからメトリクスへ
- メトリクスからログへ
受信したデータを観察し、自身のデータを生成する
- メトリクスを受け取り、データの分析メトリクスを生成する。

Ninjaセクションの一部としてプロセッサーの概要内で簡単に概要が説明されています。

これらのコンポーネントについて考えると、Jenkinsに対応する場合はプルベースのレシーバーを開発する必要があることがわかります。

OpenTelemetry Collector を開発する

メトリクスを設計する

レシーバーによってキャプチャされるメトリクスを定義し、エクスポートするために、コレクターのために開発された mdatagen を使って、yamlで定義したメトリクスをコードに変換していきます。

---
# Type defines the name to reference the component
# in the configuration file
type: jenkins

# Status defines the component type and the stability level
status:
  class: receiver
  stability:
    development: [metrics]

# Attributes are the expected fields reported
# with the exported values.
attributes:
  job.name:
    description: The name of the associated Jenkins job
    type: string
  job.status:
    description: Shows if the job had passed, or failed
    type: string
    enum:
    - failed
    - success
    - unknown

# Metrics defines all the pontentially exported values from this receiver. 
metrics:
  jenkins.jobs.count:
    enabled: true
    description: Provides a count of the total number of configured jobs
    unit: "{Count}"
    gauge:
      value_type: int
  jenkins.job.duration:
    enabled: true
    description: Show the duration of the job
    unit: "s"
    gauge:
      value_type: int
    attributes:
    - job.name
    - job.status
  jenkins.job.commit_delta:
    enabled: true
    description: The calculation difference of the time job was finished minus commit timestamp
    unit: "s"
    gauge:
      value_type: int
    attributes:
    - job.name
    - job.status

// To generate the additional code needed to capture metrics, 
// the following command to be run from the shell:
//  go generate -x ./...

//go:generate go run github.com/open-telemetry/opentelemetry-collector-contrib/cmd/mdatagen@v0.80.0 metadata.yaml
package jenkinscireceiver

// There is no code defined within this file.

次のセクションに進む前に、これらのファイルをプロジェクトフォルダ内に作成してください。

Factory の構築

Factoryはソフトウェアデザインパターンの一種で、提供されたConfigurationを使って、動的にオブジェクト（この場合は jenkinscireceiver）を作成するものです。現実的な例では、携帯電話店に行って、あなたの正確な説明に合った携帯電話を求め、それを提供されるようなものです。

コマンド go generate -x ./... を実行すると、定義されたメトリクスをエクスポートするために必要なすべてのコードを含む新しいフォルダ jenkinscireceiver/internal/metadata が作成されます。生成されるコードは以下の通りです

package jenkinscireceiver

import (
    "errors"

    "go.opentelemetry.io/collector/component"
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

func NewFactory() receiver.Factory {
    return receiver.NewFactory(
        metadata.Type,
        newDefaultConfig,
        receiver.WithMetrics(newMetricsReceiver, metadata.MetricsStability),
    )
}

func newMetricsReceiver(_ context.Context, set receiver.CreateSettings, cfg component.Config, consumer consumer.Metrics) (receiver.Metrics, error) {
    // Convert the configuration into the expected type
    conf, ok := cfg.(*Config)
    if !ok {
        return nil, errors.New("can not convert config")
    }
    sc, err := newScraper(conf, set)
    if err != nil {
        return nil, err
    }
    return scraperhelper.NewScraperControllerReceiver(
        &conf.ScraperControllerSettings,
        set,
        consumer,
        scraperhelper.AddScraper(sc),
    )
}

package jenkinscireceiver

import (
    "go.opentelemetry.io/collector/config/confighttp"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type Config struct {
    // HTTPClientSettings contains all the values
    // that are commonly shared across all HTTP interactions
    // performed by the collector.
    confighttp.HTTPClientSettings `mapstructure:",squash"`
    // ScraperControllerSettings will allow us to schedule 
    // how often to check for updates to builds.
    scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
    // MetricsBuilderConfig contains all the metrics
    // that can be configured.
    metadata.MetricsBuilderConfig `mapstructure:",squash"`
}

func newDefaultConfig() component.Config {
    return &Config{
        ScraperControllerSettings: scraperhelper.NewDefaultScraperControllerSettings(metadata.Type),
        HTTPClientSettings:        confighttp.NewDefaultHTTPClientSettings(),
        MetricsBuilderConfig:      metadata.DefaultMetricsBuilderConfig(),
    }
}

package jenkinscireceiver

type scraper struct {}

func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
    // Create a our scraper with our values 
    s := scraper{
        // To be filled in later
    }
    return scraperhelper.NewScraper(metadata.Type, s.scrape)
}

func (scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    // To be filled in
    return pmetrics.NewMetrics(), nil
}

---
dist:
  name: otelcol
  description: "Conf workshop collector"
  output_path: ./dist
  version: v0.0.0-experimental

extensions:
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/basicauthextension v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0

receivers:
  - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
  - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
  - gomod: splunk.conf/workshop/example/jenkinscireceiver v0.0.0
    path: ./jenkinscireceiver

processors:
  - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0

exporters:
  - gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
  - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.80.0

# This replace is a go directive that allows for redefine
# where to fetch the code to use since the default would be from a remote project.
replaces:
- splunk.conf/workshop/example/jenkinscireceiver => ./jenkinscireceiver

├── build-config.yaml
└── jenkinscireceiver
    ├── go.mod
    ├── config.go
    ├── factory.go
    ├── scraper.go
    └── internal
      └── metadata

これらのファイルがプロジェクトに作成されたら、go mod tidy を実行します。すると、すべての依存ライブラリが取得され、go.mod が更新されます。

OpenTelemetry Collector を開発する

ビジネスロジックを作る

この時点では、何も行っていないカスタムコンポーネントが作成されています。ここから、Jenkinsからデータを取得するための必要なロジックを追加していきましょう。

ここからのステップは以下の通りです

Jenkinsに接続するクライアントを作成する
設定されたすべてのジョブをキャプチャする
設定されたジョブの最後のビルドのステータスを報告する
コミットタイムスタンプとジョブ完了の時間差を計算する

変更を scraper.go に加えていきます。

Jenkinsサーバーに接続するために、パッケージ “github.com/yosida95/golang-jenkins” を使用します。これには、Jenkinsサーバーからデータを読み取るために必要な機能が提供されています。

次に、“go.opentelemetry.io/collector/receiver/scraperhelper” ライブラリのいくつかのヘルパー関数を利用して、コンポーネントの起動が完了したらJenkinsサーバーに接続できるようにするスタート関数を作成します。

package jenkinscireceiver

import (
    "context"

    jenkins "github.com/yosida95/golang-jenkins"
    "go.opentelemetry.io/collector/component"
    "go.opentelemetry.io/collector/pdata/pmetric"
    "go.opentelemetry.io/collector/receiver"
    "go.opentelemetry.io/collector/receiver/scraperhelper"

    "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
)

type scraper struct {
    mb     *metadata.MetricsBuilder
    client *jenkins.Jenkins
}

func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
    s := &scraper{
        mb : metadata.NewMetricsBuilder(cfg.MetricsBuilderConfig, set),
    }
    
    return scraperhelper.NewScraper(
        metadata.Type,
        s.scrape,
        scraperhelper.WithStart(func(ctx context.Context, h component.Host) error {
            client, err := cfg.ToClient(h, set.TelemetrySettings)
            if err != nil {
                return err
            }
            // The collector provides a means of injecting authentication
            // on our behalf, so this will ignore the libraries approach
            // and use the configured http client with authentication.
            s.client = jenkins.NewJenkins(nil, cfg.Endpoint)
            s.client.SetHTTPClient(client)
            return nil
        }),
    )
}

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    // To be filled in
    return pmetric.NewMetrics(), nil
}

これで、Jenkinsレシーバーを初期化するために必要なすべてのコードが完成しました。

ここから先は、実装が必要な scrape メソッドに焦点を当てます。このメソッドは、設定された間隔（デフォルトでは1分）ごとに実行されます。

Jenkinsサーバーの負荷状況や、どの程度のプロジェクトが実行されているかを測定するために、Jenkinsで設定されているジョブの数をキャプチャしたいと考えています。これを行うために、Jenkinsクライアントを呼び出してすべてのジョブをリスト化し、エラーが報告された場合はメトリクスなしでそれを返し、そうでなければメトリクスビルダーからのデータを発行します。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value. 
    now := pcommon.NewTimestampFromTime(time.Now())
    
    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
    
    // To be filled in

    return s.mb.Emit(), nil
}

前のステップにより、すべてのジョブをキャプチャしてジョブの数をレポートできるようになりました。このステップでは、それぞれのジョブを調査し、レポートされた値を使用してメトリクスをキャプチャしていきます。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value. 
    now := pcommon.NewTimestampFromTime(time.Now())
    
    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
    
    for _, job := range jobs {
        // Ensure we have valid results to start off with
        var (
            build  = job.LastCompletedBuild
            status = metadata.AttributeJobStatusUnknown
        )

        // This will check the result of the job, however,
        // since the only defined attributes are 
        // `success`, `failure`, and `unknown`. 
        // it is assume that anything did not finish 
        // with a success or failure to be an unknown status.

        switch build.Result {
        case "aborted", "not_built", "unstable":
            status = metadata.AttributeJobStatusUnknown
        case "success":
            status = metadata.AttributeJobStatusSuccess
        case "failure":
            status = metadata.AttributeJobStatusFailed
        }

        s.mb.RecordJenkinsJobDurationDataPoint(
            now,
            int64(job.LastCompletedBuild.Duration),
            job.Name,
            status,
        )
    }

    return s.mb.Emit(), nil
}

最後のステップでは、コミットからジョブ完了までにかかった時間を計算して、DORA メトリクスを推測するのに役立てていきます。

func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
    jobs, err := s.client.GetJobs()
    if err != nil {
        return pmetric.Metrics{}, err
    }

    // Recording the timestamp to ensure
    // all captured data points within this scrape have the same value. 
    now := pcommon.NewTimestampFromTime(time.Now())
    
    // Casting to an int64 to match the expected type
    s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
    
    for _, job := range jobs {
        // Ensure we have valid results to start off with
        var (
            build  = job.LastCompletedBuild
            status = metadata.AttributeJobStatusUnknown
        )

        // Previous step here

        // Ensure that the `ChangeSet` has values
        // set so there is a valid value for us to reference
        if len(build.ChangeSet.Items) == 0 {
            continue
        }

        // Making the assumption that the first changeset
        // item is the most recent change.
        change := build.ChangeSet.Items[0]

        // Record the difference from the build time
        // compared against the change timestamp.
        s.mb.RecordJenkinsJobCommitDeltaDataPoint(
            now,
            int64(build.Timestamp-change.Timestamp),
            job.Name,
            status,
        )
    }

    return s.mb.Emit(), nil
}

これらのステップがすべて完了すると、Jenkins CIレシーバーが完成します！

次は何をするの？

コンポーネントに必要な機能は、おそらく他にもたくさん思いつくでしょう。例えば

ジョブで使用されたブランチ名を含めることはできますか？
ジョブのプロジェクト名を含めることはできますか？
プロジェクトのジョブの総持続時間をどのように計算しますか？
変更が機能するかどうかをどのように検証しますか？

この時間を使って遊んでみたり、壊してみたり、変更してみたり、ビルドからのログをキャプチャしてみるなどしてください。

リソース

よくある質問とその回答
オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。
ディメンション、プロパティ、タグ
ディメンションとプロパティの比較で、どちらかを使うべきかというのはよく議論されます。
OpenTelemetryでのタグ付け
大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、規則が遵守されるようにガバナンスプロセスを確立することが重要です。

よくある質問とその回答

オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。

Q: アラートとインシデント対応、インシデント管理の違いは？

A: アラート、インシデント対応、インシデント管理は関連する機能です。これらは一緒にインシデント対応および解決プロセスを構成します。

モニタリングやオブザーバビリティのツールはインシデント対応プラットフォームにアラートを送信します。これらのプラットフォームはアラートのコレクションを収集し、それらをインシデントとして相関させます。

これらのインシデントは記録のためにインシデント管理（ITSM）プラットフォームに記録されます。アラートは何かが起こったことを示すトリガーであり、インシデントへのコンテキストを提供します。

インシデントには、アラートの内容、インシデントが作成されてから関連するすべての活動、およびフォローされるオンコールポリシーが含まれます。ITSMは、インシデントがアクティブであるときおよび解決された後のインシデントを記録するシステムです。

インシデント対応および管理をより良く実践するために、これらのコンポーネントが必要になります。

On-Call

Q: オブザーバビリティはモニタリングとは違うものですか？

A: モニタリングとオブザーバビリティの主な違いは、「既知の未知」と「未知の未知」の違いです。

モニタリングでは、オペレーターは通常、システムのアーキテクチャと要素に関する事前の知識を持っています。彼らは要素間の関係とそれに関連するメタデータを確実に予測することができます。モニタリングは、頻繁に変更されない状態のインフラストラクチャに適しています。

オブザーバビリティは、オペレーターがシステム内のすべての要素とそれらの関係を予測し、追跡する能力が限定されているシステム向けです。

オブザーバビリティは、従来のメトリクスのモニタリングを含む一連のプラクティスと技術です。

これらのプラクティスと技術を組み合わせることで、オペレーターはシステムのすべての要素に関する事前の知識がなくても、頻繁に変更がある複雑な環境を理解することができます。オブザーバビリティ技術は、環境の変動やメタデータの変化（カーディナリティ）を従来のモニタリングよりもよく考慮できるため、より静的なモニタリングと比較して優れています。

Observability

Q: トレースとスパンとは何ですか？

A: トレースとスパンは、メトリクスとログと共に、現代のオブザーバビリティツールにフィードされるコアタイプのデータを構成します。それらは特定の要素と機能を持っていますが、一緒にうまく機能します。

マイクロサービスベースのアーキテクチャは分散しているため、システム内のトランザクションは完了する前に複数のサービスにアクセスします。これにより、問題の場所を正確に特定することが困難になります。トレースは、分散システム内のすべてのサービスを通るリクエストの完全なパスを追跡するための方法です。スパンは、各サービスでの時間のかかる操作です。トレースはスパンの結合したものであり、一緒になると個々のサービスプロセスについてより詳細な情報を提供します。メトリクスはシステムの健康状態の良いスナップショットを提供し、ログは問題を調査する際に深さを提供しますが、トレースとスパンはオペレーターに問題の源泉をより多くのコンテキストでナビゲートするのに役立ちます。これにより、インシデントの調査にかかる時間が節約され、現代のアーキテクチャの複雑さがサポートされます。

APM

Q: サイドカーパターンとは何ですか？

A: サイドカーパターンは、関連するサービスをインフラストラクチャによって直接接続するためのデザインパターンです。関連するサービスは、接続されているアプリケーションロジックに機能を追加したりサポートしたりすることができます。これは、管理計画に関連するエージェントをアプリケーションサービスと共に展開する方法として広く使用されます。

オブザーバビリティでは、サイドカーサービスはアプリケーションロジックであり、そのサービスからデータを収集するエージェントです。このセットアップには、アプリケーションサービスを含むコンテナと、エージェントを実行するコンテナの2つが必要です。コンテナはポッドを共有し、ディスク、ネットワーク、名前空間などのリソースを共有します。また、一緒にデプロイされ、同じライフサイクルを共有します。

Observability

ディメンション、プロパティ、タグ

メトリクスにコンテキストを与える

ディメンションとプロパティの違いや、どちらを使うべきかというのは、よく話題にされます。それぞれの説明から始めるのではなく、私たちがどのように使い、どのように似ているのかを理解してから、それぞれの違いや、なぜどちらかを使うのかの例を見ていくことにしましょう。

ディメンションとプロパティの類似点

最も単純な答えは、ディメンションとプロパティはともに、メトリクスにコンテキスト（状況）を追加するメタデータの key:value ペアであるということです。メトリクス自体は、cpu.utilization のような標準的なインフラストラクチャメトリクスであろうと、API呼び出しの回数のようなカスタムメトリクスであろうと、実際に測定しているものなら全てに当てはまります。

cpu.utilization メトリクスの値が50%であっても、それがどこから来たのかなどのコンテキストを知らなければ、それは単なる数字であり、私たちにとって有用ではありません。少なくとも、どのホストから来たのかを知る必要があります。

現在では、個々のホストのパフォーマンスや利用率よりも、クラスターやデータセンター全体のパフォーマンスや利用率をより気にすることが多く、ホストのクラスター全体の平均 cpu.utilization、あるホストの cpu.utilization が同じサービスを実行する他のホストと比べて外れ値である場合、あるいは環境間での平均 cpu.utilization を比較することに興味を持っています。

このように cpu.utilization メトリクスをスライス、集約、またはグループ化するためには、受け取る cpu.utilization メトリクスのメタデータに、ホストが属するクラスター、ホスト上で実行されているサービス、およびそれが属する環境などの情報が必要です。このメタデータは、ディメンションまたはプロパティの key:value ペアの形で存在することができます。

例えば、ダッシュボードでフィルターを適用したり、分析関数を実行する際にグループ化機能を使用したりするとき、プロパティまたはディメンションを使用することができます。

では、ディメンションとプロパティはどう違うの？

ディメンションはメトリクスと共に取り込み時に送信されるのに対し、プロパティは取り込み後にメトリクスやディメンションに適用されます。これは、`cpu.utilization`` の値がどのホストから来ているかのような、データポイント（メトリクスの単一の報告値）をユニークにするために必要なメタデータはディメンションでなければならないことを意味します。メトリクス名 + ディメンションはMTS（メトリクスの時間系列）をユニークに定義します。

例：特定のホスト（server1）によって送信される cpu.utilization メトリクスで、ディメンション host:server1 があれば、それはユニークな時間系列と見なされます。もし10台のサーバーがそのメトリクスを送信していれば、メトリクス名 cpu.utilization を共有し、ディメンションのキー値ペア（host:server1, host:server2…host:server10）でユニークに識別される10の時間系列があります。

しかし、サーバー名がデータセンター内でのみユニークである場合、データセンターの場所を示す2番目のディメンションdcを追加する必要があります。これにより、可能なMTSの数は倍になります。受信された cpu.utilization メトリクスは、2組のディメンションのキー値ペアによってユニークに識別されます。

cpu.utilization に dc:east と host:server1 を加えたものは、cpu.utilization に dc:west と host:server1 を加えたものとは異なる時間系列を作り出します。

ディメンションは不変だが、プロパティは可変である

上記で述べたように、メトリクス名 + ディメンションの組み合わせで、ユニークなMTSを作ります。したがって、ディメンションの値が変わると、メトリクス名 + ディメンション値の新しいユニークな組み合わせが生まれ、新しいMTSが作成されます。

一方、プロパティはメトリクス（またはディメンション）が取り込まれた後に適用されます。メトリクスにプロパティを適用すると、そのメトリクスが属するすべてのMTSに伝播して適用されます。または、ディメンションにプロパティを適用する場合、例えば host:server1 とすると、そのホストからのすべてのメトリクスにそのプロパティが添付されます。プロパティの値を変更すると、そのプロパティが添付されているすべてのMTSのプロパティ値が更新されます。これが重要な理由は何でしょうか？　プロパティの歴史的な値にこだわる場合、それをディメンションにする必要があることを意味しています。

例：私たちはアプリケーションに関するカスタムメトリクスを収集しています。1つのメトリクスは latency で、アプリケーションへのリクエストのレイテンシーをカウントします。顧客ごとにレイテンシーを分類して比較できるように customer ディメンションを持っています。私たちは、顧客が使用しているバージョン別にアプリケーションの latency を分類して比較したいと考え、プロパティ version を customer ディメンションに添付しました。最初はすべての顧客がアプリケーションバージョン1を使用しているので、version:1 です。

現在、いくつかの顧客がアプリケーションのバージョン2を使用しているため、それらの顧客に対してプロパティを version:2 に更新します。これらの顧客の version プロパティの値を更新すると、その顧客に関連するすべてのMTSに伝播します。これにより、これらの顧客が以前に version:1 を使用していたという歴史が失われるため、歴史的な期間にわたって version:1 と version:2 の latency を比較する場合、正確なデータを得ることはできません。この場合、メトリクスの時間系列をユニークにするためにアプリケーションの version が必要ではないかもしれませんが、歴史的な値にこだわるために version をディメンションにする必要があります。

結局、いつ、ディメンションじゃなくてプロパティを使うの？

メトリクスに添付したいメタデータがあるが、取り込み時にはそれを知らない場合が第一の理由です。第二の理由は、ベストプラクティスとして、ディメンションである必要がなければ、それをプロパティにすることです。なぜでしょうか？

一つの理由は、現在、分析ジョブやチャートレンダリングあたりのMTSの上限が5Kであり、ディメンションが多いほど多くのMTSを生成することです。プロパティは完全に自由形式であり、MTSの数を増やすことなく、メトリクスやディメンションに必要な情報を追加することができます。

ディメンションは各データポイントと共に送信されるため、ディメンションが多いほど、より多くのデータを送信することになります。これは、クラウドプロバイダーがデータ転送に料金を請求する場合、コストが高くなる可能性があります。

プロパティを使う良い例としては、ホスト情報の追加などがあります。 machine_type, processor, os などの情報を確認することが重要ですが、これらをディメンションとして設定し、各ホストからのすべてのメトリクスと共に送信するのではなく、プロパティとして設定し、ホストディメンションに添付することができます。

例えば host:server1 では、プロパティ machine_type:ucs, processor:xeon-5560, os:rhel71 を設定します。host:server1 というディメンションを持つメトリクスが入ってくるたびに、上記のすべてのプロパティが自動的に適用されます。

プロパティの使用例としては、各サービスのエスカレーション連絡先や、各顧客のSLAレベルを知りたい場合があります。これらの項目は、メトリクスをユニークに識別するために必要ではなく、歴史的な値にも関心がないため、プロパティにすることができます。プロパティはサービスディメンションや顧客ディメンションに追加され、これらのディメンションを持つすべてのメトリクスやMTSに適用されます。

タグについてはどうですか？

タグは、メトリクスにコンテキストを与えたり整理するのに使われる、メタデータの3番目のタイプです。ディメンションやプロパティとは異なり、タグは key:value ペアではありません。タグはラベルやキーワードとして考えることができます。プロパティと同様に、タグは取り込み後にUIのCatalogやAPIを通じてプログラム的にデータに適用されます。タグはメトリクス、ディメンション、ディテクターなどの他のオブジェクトに適用することができます。

タグを使う場面はどこですか？

タグが必要とされるのは、タグとオブジェクトの間に多対一の関係がある場合や、タグとそれに適用されるオブジェクト間に一対多の関係がある場合です。本質的に関連していないメトリクスをまとめるのに役立ちます。

例として、複数のアプリケーションを実行しているホストがある場合です。各アプリケーションに対してタグ（ラベル）を作成し、それぞれのホストに複数のタグを適用して、その上で実行されているアプリケーションをラベル付けします。

例：Server1は3つのアプリケーションを実行しています。タグ app1, app2, app3 を作成し、ディメンション host:server1 にこれら3つのタグをすべて適用します。

上記の例を拡張すると、アプリケーションからのメトリクスも収集しているとします。作成したタグを、アプリケーション自体から来るメトリクスに適用することができます。タグに基づいてフィルタリングすることで、アプリケーションに基づいてフィルタリングしながら、アプリケーションと関連するホストメトリクスの全体像を得ることができます。

例：App1は service:application1 というディメンションでメトリクスを送信します。service:application1 のディメンションにタグ app1 を適用します。その後、チャートやダッシュボードでタグ app1 でフィルタリングすることができます。

タグの他の使用例には、単一の可能な値を持つ二進状態があります。例として、カナリアテストを行い、カナリアデプロイを行った際に新しいコードを受け取ったホストをマークして、新しいコードを受け取らなかったホストとのパフォーマンスを比較しやすくすることがあります。単一の値 canary しかないため、key:value ペアは必要ありません。

ただし、タグでフィルタリングはできますが、groupBy関数では使用できないことに注意してください。groupBy関数は key:value ペアのキー部分を指定して実行され、そのキーの値に基づいて結果がグループ化されます。

さらなる情報

カスタムメトリクスのディメンションを送信する方法に関する情報については、お使いのライブラリに関するクライアントライブラリのドキュメントをご覧ください。

APIを通じてメトリクスやディメンションにプロパティやタグを適用する方法については、 /metric/:name、/dimension/:key/:value に関するAPIドキュメントを参照してください。

UIのメタデータカタログでプロパティやタグを追加または編集する方法については、Search the Metric Finder and Metadata catalogで、Add or edit metadata セクションをご覧ください。

OpenTelemetryとSplunkにおける、タグ付けのための命名規則

はじめに

大規模な組織でOpenTelemetryを展開する際には、タグ付けのための標準化された命名規則を定義し、その規則が遵守されるようにガバナンスプロセスを設定することが非常に重要です。

これにより、OpenTelemetryを通じて収集されるMELTデータ（メトリクス、イベント、ログ、トレース）を、アラート、ダッシュボード作成、トラブルシューティングの目的で効率的に活用することが可能になります。また、Splunk Observability Cloudのユーザーが探しているデータを迅速に見つけることができます。

命名規則はまた、データを効果的に集約するためにも重要です。例えば、環境ごとのユニークなホストの数を数えたい場合、ホスト名と環境名を捉えるための標準化された規則を使用する必要があります。

属性 vs タグ

先に進む前に、用語についての注意をしておきましょう。OpenTelemetryの「タグ」は「属性（attribute）」と呼ばれます。属性は、手動または自動の計装を通じて、メトリクス、ログ、トレースに添付することができます。

属性はまた、Resource Detection processorなどのさまざまなプロセッサを使用して、OpenTelemetryコレクターレベルでメトリクス、ログ、トレースに添付することもできます。

Splunk Observability Cloudに属性付きのトレースが取り込まれると、それらは「タグ」として利用可能になります。オプションとして、トレースの一部として収集された属性は、Troubleshooting Metric Setsの作成に使用され、Tag Spotlightなどのさまざまな機能と共に使用することができます。

また、属性はMonitoring Metric Setsの作成に使用され、アラートのトリガーとして使用することもできます。

リソースに関するセマンティック規約

OpenTelemetry リソースセマンティック規約は、組織が標準化すべき属性を決定する際の出発点として使用できます。以下のセクションでは、よく使用される属性のいくつか見ていきましょう。

サービス属性

監視されるサービスを記述するために多くの属性が使用されます。

service.name はサービスの論理名を定義する必須の属性です。OpenTelemetry SDKによって自動的に追加されますが、カスタマイズすることができます。これはシンプルに保つことが最善です（例えば、inventoryservice は inventoryservice-prod-hostxyz よりも良いでしょう。他の属性を使用してサービスの他の側面を捉えることができます）。

以下のサービス属性が推奨されます

service.namespace はサービスを所有するチームを識別するために使用されます
service.instance.id はサービスのユニークなインスタンスを識別するために使用されます
service.version はサービスのバージョンを識別するために使用されます

テレメトリSDK

これらの属性はSDKによって自動的に設定され、使用されている計測ライブラリに関する情報を記録します

telemetry.sdk.name は通常 opentelemetry に設定されます。
telemetry.sdk.language はSDKの言語で、例えば java です。
telemetry.sdk.version は使用されているSDKのバージョンを識別します。

コンテナ

コンテナで実行されるサービスには、container.id、container.name、container.image.name など、コンテナのランタイムを記述するための多くの属性が使用されます。完全なリストはこちらで確認できます。

ホスト

これらの属性は、サービスが実行されているホストを記述し、host.id、host.name、host.arch などの属性を含みます。完全なリストはこちらで確認できます。

デプロイ環境

deployment.environment 属性は、サービスがデプロイされている環境（staging や production など）を識別するために使用されます。

Splunk Observability Cloudは、この属性を使用して関連コンテンツを有効する（詳細はこちら）ため、この属性を含めることが重要です。

クラウド

AWSなどのパブリッククラウド環境で実行されるサービスに関する情報を捉えるための属性もあります。これには、cloud.provider、cloud.account.id、cloud.region が含まれます。

属性の完全なリストはこちらで確認できます。

一部のクラウドプロバイダー、例えば GCP は、独自のセマンティック規則を定義しています。

Kubernetes

Kubernetesで実行されるアプリケーションにも、いくつかの標準化された属性があります。これらの多くは、SplunkのOpenTelemetryコレクター配布によって自動的に追加されます（詳細はこちら）。

属性は、例えば k8s.cluster.name、k8s.node.name、k8s.pod.name、k8s.namespace.name、kubernetes.workload.name などがあります。

カスタム属性のベストプラクティス

多くの組織では、OpenTelemetryのリソースセマンティック規約で定義されているもの以上の属性が欲しくなります。

この場合、セマンティック規約にすでに含まれている属性名との命名競合を避けることが重要です。つまり、特定の属性名を命名規則に決定する前に、セマンティック規約をチェックすると良いでしょう。

属性名の命名規則に加えて、属性値も考慮する必要があります。例えば、アプリケーションが属する特定のビジネスユニットをキャプチャしたい場合、簡単にかつ効果的にフィルタリングするために、標準化されたビジネスユニット値のリストも持ちたいでしょう。

OpenTelemetryコミュニティでは、属性の命名に従うべきガイドラインも提供しています。こちらで見つけることができます。

Recommendations for Application Developersは、私たちの議論に最も関連しています。

そこでは、以下を推奨しています

com.acme.shopname のように、会社のドメイン名で属性名を接頭辞として付けること（属性が社内だけでなく外部で使用される可能性がある場合）
属性が特定のアプリケーションに固有であり、組織内でのみ使用される場合は、アプリケーション名で属性名に接頭辞を付けること
既存のOpenTelemetryセマンティック規約の名前を属性名の接頭辞として使用しないこと
異なる組織や業界全体で一般的なニーズがある場合は、あなたの属性名をOpenTelemetry仕様に追加する提案を検討すること
otel.* で始まる属性名は避けること。これはOpenTelemetry仕様の使用に予約されています

カーディナリティに関する考慮事項

属性名と値の命名基準を決定する際に考慮すべき最後の点は、メトリクスのカーディナリティに関連しています。

のカーディナリティは、メトリクス名とそれに関連する次元の組み合わせによって生成されるユニークなメトリクス時系列（MTS: Metric Time Series）の数として定義されます。

メトリクスは、ディメンションの数とそれらのディメンションが持つユニークな値の数が多い場合に、高いカーディナリティを持つことになります。

例えば、あなたのアプリケーションが custom.metric という名前のメトリクスのデータを送信するとします。属性がない場合、custom.metric は単一のメトリクス時系列（MTS）を生成します。

一方で、custom.metric が customer.id という属性を含み、数千の顧客ID値がある場合、これは数千のメトリクス時系列を生成し、コストやクエリ性能に影響を与える可能性があります。

Splunk Observability Cloudは、メトリクスの使用量を管理するためのレポートを提供しています。そして、望ましくないディメンションを削除するルールを作成することができます。しかし、最初の防衛線は、属性名と値の組み合わせがどのようにメトリクスのカーディナリティを増加させるかを理解することです。

まとめ

このドキュメントでは、大規模なOpenTelemetry計装の展開を開始する前に、OpenTelemetryタグの命名規則を定義することの重要性を強調しました。

OpenTelemetryのリソースセマンティック規約がいくつかの属性の命名規則を定義し、多くの属性がOpenTelemetry SDKやOpenTelemetryコレクター内で動作するプロセッサーを通じて自動的に収集される方法について説明しました。

最後に、リソースセマンティック規約が組織のニーズに十分でない場合に、属性名を作成するためのベストプラクティスを共有しました。

Scenarios

ThousandEyes と Splunk Observability Cloud の統合

120 minutes Author Alec Chamberlain

このワークショップでは、ThousandEyes と Splunk Observability Cloud を統合して、シンセティック監視とオブザーバビリティデータ全体にわたる統一された可視性を提供する方法を説明します。

学習内容

このワークショップを終了すると、以下のことができるようになります：

Kubernetesにコンテナ化されたワークロードとしてThousandEyes Enterprise Agentをデプロイする
OpenTelemetryを使用してThousandEyesメトリクスをSplunk Observability Cloudと統合する
ThousandEyesとSplunk APMが同じリクエストにリンクできるように分散トレーシングを構成する
内部Kubernetesサービスと外部依存関係のシンセティックテストを作成する
Splunk Observability Cloudダッシュボードでテスト結果を監視する
ThousandEyesからSplunk APMトレースに移動し、元のThousandEyesテストに戻る

セクション

コアパス

概要 - ThousandEyesエージェントの種類とアーキテクチャを理解する
デプロイメント - KubernetesにEnterprise Agentをデプロイする
Splunk 統合 - ThousandEyesメトリクスをSplunk Observability Cloudにストリーミングする
分散トレーシング - ThousandEyesとSplunk APM間のサポートされた双方向ドリルダウンを有効にする

シナリオ拡張

Kubernetes テスト - シンセティック監視とトレース相関の両方に役立つ内部テストを作成する
RUM - エンドユーザー調査のためにThousandEyesネットワークシグナルとSplunk RUMを相関させる

サポート

トラブルシューティング - よくある問題と解決策

ヒント

このシナリオは2つの接続された統合と考えてください：OpenTelemetryストリームはThousandEyesメトリクスをSplunkに取り込み、分散トレーシングはSplunk APMからThousandEyesに戻る逆方向のパスを提供します。

前提条件

Kubernetesクラスター（v1.16以上）
選択したnamespaceにリソースをデプロイするためのRBAC権限
Enterprise AgentトークンにアクセスできるThousandEyesアカウント
インジェストトークンへのアクセスとAPMルックアップ用のAPIトークンを作成する権限を持つSplunk Observability Cloudアカウント

統合のメリット

ThousandEyesをSplunk Observability Cloudに接続することで、以下のメリットが得られます：

🔗 統一された可視性: シンセティックテスト結果をRUM、APMトレース、インフラストラクチャメトリクスと相関させる
📊 強化されたダッシュボード: ThousandEyesデータを既存のSplunkオブザーバビリティメトリクスと並べて可視化する
🔄 双方向ドリルダウン: ThousandEyes Service MapからSplunkトレースに移動し、Splunk APMからリクエストを生成したThousandEyesテストに戻る
🚨 一元化されたアラート: Splunk内でThousandEyesテスト結果に基づいてアラートを構成する
🔍 根本原因分析: 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定する
📈 包括的な分析: Splunkの強力な分析エンジンでシンセティック監視のトレンドを分析する

概要

    </a>
  </div>
  <div class="card-content-text">
      Kubernetes、ThousandEyes、Splunk Observability Cloud にまたがるワークショップアーキテクチャと ThousandEyes エージェントモデルについて理解します。
  </div>
</div>

デプロイメント

    </a>
  </div>
  <div class="card-content-text">
      ThousandEyes Enterprise Agent を Kubernetes にデプロイし、ThousandEyes Cloud に正しく登録されることを確認します。
  </div>
</div>

Splunk 連携

    </a>
  </div>
  <div class="card-content-text">
      ThousandEyes から Splunk Observability Cloud への OpenTelemetry ベースのメトリクスストリームを設定します。
  </div>
</div>

分散トレーシング

    </a>
  </div>
  <div class="card-content-text">
      ThousandEyes と Splunk APM 間でサポートされているトレース相関を有効にし、調査中にチームが両製品間を移動できるようにします。
  </div>
</div>

Kubernetes テスト

    </a>
  </div>
  <div class="card-content-text">
      シンセティック監視とトレース相関の両方に役立つ、内部 Kubernetes テストと外部依存関係テストを作成します。
  </div>
</div>

    </a>
  </div>
  <div class="card-content-text">
      ThousandEyes のネットワークメトリクスと Splunk RUM を関連付けて、エンドユーザー体験とネットワークの問題を一緒に調査できるようにします。
  </div>
</div>

トラブルシューティング

    </a>
  </div>
  <div class="card-content-text">
      ThousandEyes シナリオにおけるデプロイメント、接続性、メトリクスストリーミング、トレース相関の一般的な問題を診断します。
  </div>
</div>

概要

10 minutes

ThousandEyes エージェントの種類

Enterprise Agents

Enterprise Agentsは、お客様のインフラストラクチャ内にデプロイするソフトウェアベースの監視エージェントです。以下の機能を提供します：

内部から外部への可視性: 内部ネットワークから外部サービスへの監視とテスト
カスタマイズ可能な配置: ユーザーやアプリケーションが存在する場所にデプロイ
完全なテスト機能: HTTP、ネットワーク、DNS、音声、その他のテストタイプ
継続的な監視: スケジュールされたテストを実行する常時稼働エージェント

このワークショップでは、Enterprise AgentをKubernetesクラスター内のコンテナ化されたワークロードとしてデプロイします。

Endpoint Agents

Endpoint Agentsは、エンドユーザーデバイス（ラップトップ、デスクトップ）にインストールされる軽量エージェントで、以下の機能を提供します：

実際のユーザー視点: 実際のユーザーエンドポイントからの監視
ブラウザベースの監視: リアルユーザーエクスペリエンスメトリクスの取得
セッションデータ: ユーザーの視点からのアプリケーションパフォーマンスに関する詳細なインサイト

このワークショップでは、Enterprise Agent のデプロイのみを対象としています。

アーキテクチャ

graph LR
    subgraph k8s["Kubernetes Cluster"]
        secret["Secret<br/>te-creds"]
        agent["ThousandEyes<br/>Enterprise Agent<br/>Pod"]

        subgraph apps["Application Pods"]
            api["API Gateway<br/>Pod"]
            payment["Payment Service<br/>Pod"]
            auth["Auth Service<br/>Pod"]
        end

        subgraph svcs["Services"]
            api_svc["api-gateway<br/>Service"]
            payment_svc["payment-svc<br/>Service"]
            auth_svc["auth-service<br/>Service"]
        end

        api_svc --> api
        payment_svc --> payment
        auth_svc --> auth

        secret -.-> agent
        agent -->|"HTTP Tests"| api_svc
        agent -->|"HTTP Tests"| payment_svc
        agent -->|"HTTP Tests"| auth_svc
    end

    external["External<br/>Services"]

    agent --> external

    subgraph te["ThousandEyes Platform"]
        te_cloud["ThousandEyes<br/>Cloud"]
        te_api["API<br/>v7/stream"]
        te_cloud <--> te_api
    end

    agent -->|"Test Results"| te_cloud

    subgraph splunk["Splunk Observability Cloud"]
        otel["OpenTelemetry<br/>Collector"]
        metrics["Metrics"]
        dashboards["Dashboards"]
        apm["APM/RUM"]
        alerts["Alerts"]

        otel --> metrics
        otel --> dashboards
        metrics --> apm
        dashboards --> alerts
    end

    te_cloud -->|"OTel/HTTP metrics"| otel
    te_cloud -->|"Trace lookup"| apm
    apm -->|"Deep links to test"| te_cloud

    user["DevOps/SRE<br/>Team"]
    user -.-> te_cloud
    user -.-> dashboards
    user -.-> agent

    style k8s fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
    style apps fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style svcs fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style agent fill:#ffeb3b,stroke:#f57c00,stroke-width:2px
    style secret fill:#ffcdd2,stroke:#c62828,stroke-width:2px
    style api fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style payment fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style auth fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style api_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style payment_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style auth_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style external fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
    style te fill:#fff9c4,stroke:#f57f17,stroke-width:2px
    style te_cloud fill:#ffecb3,stroke:#f57f17,stroke-width:2px
    style te_api fill:#ffe082,stroke:#f57f17,stroke-width:2px
    style splunk fill:#ff6e40,stroke:#d84315,stroke-width:2px
    style otel fill:#ff8a65,stroke:#d84315,stroke-width:2px
    style metrics fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style dashboards fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style apm fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style alerts fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style user fill:#b2dfdb,stroke:#00695c,stroke-width:2px

アーキテクチャコンポーネント

1. Kubernetes クラスター

Secret (te-creds): 認証用のbase64エンコードされた TEAGENT_ACCOUNT_TOKEN を保存
ThousandEyes Enterprise Agent Pod:
- コンテナイメージ: thousandeyes/enterprise-agent:latest
- ホスト名: te-agent-aleccham（カスタマイズ可能）
- セキュリティ権限: NET_ADMIN、SYS_ADMIN（ネットワークテストに必要）
- メモリ割り当て: 2GBリクエスト、3.5GB上限
- ネットワークモード: IPv4のみ（環境変数 TEAGENT_INET: "4" で設定）
- イメージプルポリシー: Always（最新イメージのプルを保証）
- Initコマンド: /sbin/my_init（エージェントの適切な初期化に必要）
内部サービス: REST API、マイクロサービス、データベース、gRPCサービスを含むKubernetesワークロード

2. テスト対象

内部サービス: Kubernetesクラスター内のサービスを監視
外部サービス: 以下のような外部依存関係をテスト：
- 決済ゲートウェイ（Stripe、PayPal）
- サードパーティAPI
- SaaSアプリケーション
- CDNエンドポイント
- 公開ウェブサイト

3. ThousandEyes Platform

ThousandEyes Cloud: 以下のための中央プラットフォーム：
- エージェントの登録と管理
- テストの設定とスケジューリング
- メトリクスの収集と集約
- 組み込みアラートエンジン
ThousandEyes API: プログラムによるアクセスのためのRESTful API（v7/streamエンドポイント）

4. テストタイプとメトリクス

Enterprise Agentは以下を実行します：

HTTP/HTTPS テスト: ウェブページの可用性、応答時間、ステータスコード
DNS テスト: 名前解決時間、レコード検証
ネットワーク層テスト: レイテンシ、パケットロス、パス可視化
Voice/RTP テスト: 音声トラフィックの品質メトリクス

収集されるメトリクスには以下が含まれます：

HTTPサーバー可用性（%）
スループット（bytes/s）
リクエスト時間（秒）
ページロード完了率（%）
エラーコードと失敗理由

5. Splunk Observability Cloud との統合

OpenTelemetry Metrics Stream:
- エンドポイント: https://ingest.{realm}.signalfx.com/v2/datapoint/otlp
- プロトコル: HTTPまたはgRPC
- フォーマット: Protobuf
- 認証: X-SF-Token ヘッダー
- シグナルタイプ: Metrics（OpenTelemetry v2）
分散トレーシング統合:
- ThousandEyesテストタイプ: 分散トレーシングが有効な HTTP Server または API
- ThousandEyesコネクタターゲット: https://api.{realm}.signalfx.com
- 認証: X-SF-Token ヘッダーにSplunk API トークン
- 結果: ThousandEyesは関連するSplunk APMトレースを開くことができ、Splunk APMトレースは元のThousandEyesテストにリンクバックできます
オブザーバビリティ機能:
- Metrics: ThousandEyesデータのリアルタイム可視化
- Dashboards: 統合ビューを備えた事前構築済みThousandEyesダッシュボード
- APM/RUM 統合: シンセティックテストとアプリケーショントレースおよびリアルユーザーモニタリングの相関
- Alerting: 相関ルールを備えた一元化されたアラート管理

6. データフロー

エージェントがKubernetes Secretからのトークンを使用して認証
エージェントが内部および外部ターゲットに対してスケジュールされたテストを実行
テスト結果がThousandEyes Cloudに送信
ThousandEyesがOpenTelemetryプロトコルを介してSplunkにメトリクスをストリーミング
分散トレーシングが有効なHTTP ServerおよびAPIテストの場合、ThousandEyesはリクエストに b3、traceparent、tracestate ヘッダーを挿入
計装されたアプリケーションが結果のトレースをSplunk APMに送信
ThousandEyesは関連するSplunkトレースを開くことができ、Splunk APMは元のThousandEyesテストにリンクバック可能
DevOps、ネットワーク、アプリケーションチームが調査中に両方のビューで協力

テスト機能

このデプロイにより、以下が可能になります：

✅ 内部サービスのテスト: クラスター内からKubernetesサービス、API、マイクロサービスを監視
✅ 外部依存関係のテスト: 決済ゲートウェイ、サードパーティAPI、SaaSプラットフォームへの接続性を検証
✅ パフォーマンスの測定: クラスターの視点からレイテンシ、可用性、パフォーマンスメトリクスを取得
✅ 問題のトラブルシューティング: 問題がインフラストラクチャ、ネットワークパス、または計装されたアプリケーションサービスのいずれに起因するかを特定

注意

これはThousandEyesエージェントの公式にサポートされたデプロイ設定ではありません。ただし、本番環境に近い環境でテストされており、非常にうまく動作します。

デプロイメント

20 minutes

このセクションでは、KubernetesクラスターにThousandEyes Enterprise Agentをデプロイする手順を説明します。

コンポーネント

デプロイメントは2つのファイルで構成されています：

1. シークレットファイル (`credentialsSecret.yaml`)

ThousandEyesエージェントトークン（base64エンコード済み）を含みます。このシークレットは、エージェントをThousandEyes Cloudで認証するためにデプロイメントから参照されます。

apiVersion: v1
kind: Secret
metadata:
  name: te-creds
type: Opaque
data:
  TEAGENT_ACCOUNT_TOKEN: <base64-encoded-token>

2. デプロイメントマニフェスト (`thousandEyesDeploy.yaml`)

以下の主要な設定でEnterprise AgentのPod構成を定義します：

Namespace: te-demo（必要に応じてカスタマイズ）
Image: Docker Hubの thousandeyes/enterprise-agent:latest
Hostname: te-agent-aleccham（ThousandEyesダッシュボードに表示されます）
Capabilities: ネットワークテストに NET_ADMIN と SYS_ADMIN が必要
Resources:
- メモリ制限: 3584Mi
- メモリ要求: 2000Mi

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: te-demo
  name: thousandeyes
  labels:
    app: thousandeyes
spec:
  replicas: 1
  selector:
    matchLabels:
      app: thousandeyes
  template:
    metadata:
      labels:
        app: thousandeyes
    spec:
      hostname: te-agent-aleccham
      containers:
      - name: thousandeyes
        image: 'thousandeyes/enterprise-agent:latest'
        imagePullPolicy: Always
        command:
          - /sbin/my_init
        securityContext:
          capabilities:
            add:
              - NET_ADMIN
              - SYS_ADMIN
        env:
          - name: TEAGENT_ACCOUNT_TOKEN
            valueFrom:
              secretKeyRef:
                name: te-creds
                key: TEAGENT_ACCOUNT_TOKEN
          - name: TEAGENT_INET
            value: "4"
        resources:
          limits:
            memory: 3584Mi
          requests:
            memory: 2000Mi

重要な注意事項

エージェントはネットワークテストを実行するために昇格した権限（NET_ADMIN、SYS_ADMIN）が必要です
TEAGENT_INET: "4" 環境変数はIPv4専用モードを強制します（一部のネットワーク構成で必要）
/sbin/my_init コマンドは、エージェントの適切な初期化とサービス管理に必要です
imagePullPolicy: Always は常に最新のイメージバージョンをプルすることを保証します
ThousandEyesダッシュボードでエージェントを一意に識別するために hostname フィールドを調整してください
Kubernetes環境に合わせて namespace を変更してください
ThousandEyes Enterprise Agentは比較的高いハードウェア要件があります。環境に応じてこれらを調整する必要がある場合があります

インストール手順

ステップ 1: ThousandEyes トークンの作成

app.thousandeyes.com/login でThousandEyesプラットフォームにログインします
Cloud & Enterprise Agents > Agent Settings > Add New Enterprise Agent に移動します
Account Group Token をコピーします
トークンをBase64エンコードします：
```
echo -n 'your-token-here' | base64
```
次のステップのためにbase64エンコードされた出力を保存します

ステップ 2: Namespace の作成

Namespaceを作成します（存在しない場合）：

kubectl create namespace te-demo

ステップ 3: シークレットの作成

base64エンコードされたトークンを含む credentialsSecret.yaml という名前のファイルを作成します：

apiVersion: v1
kind: Secret
metadata:
  name: te-creds
  namespace: te-demo
type: Opaque
data:
  TEAGENT_ACCOUNT_TOKEN: <your-base64-encoded-token-here>

シークレットを適用します：

kubectl apply -f credentialsSecret.yaml

ステップ 4: デプロイメントの作成

上記のデプロイメントマニフェストを含む thousandEyesDeploy.yaml という名前のファイルを作成します（必要に応じてhostnameとnamespaceをカスタマイズしてください）。

デプロイメントを適用します：

kubectl apply -f thousandEyesDeploy.yaml

ステップ 5: デプロイメントの確認

エージェントが実行中であることを確認します：

kubectl get pods -n te-demo

期待される出力：

NAME                            READY   STATUS    RESTARTS   AGE
thousandeyes-xxxxxxxxxx-xxxxx   1/1     Running   0          2m

エージェントが接続していることを確認するためにログをチェックします：

kubectl logs -n te-demo -l app=thousandeyes

ステップ 6: ThousandEyes ダッシュボードでの確認

ThousandEyesダッシュボードでエージェントが正常に登録されたことを確認します：

Cloud & Enterprise Agents > Agent Settings に移動して、新しく登録されたエージェントを確認します。

成功

ThousandEyes Enterprise AgentがKubernetesで実行されています！次に、Splunk Observability Cloudとの統合を行います。

背景

ThousandEyesは公式のKubernetesデプロイメントドキュメントを提供していません。標準的なデプロイメント方法は docker run コマンドを使用するため、再利用可能なKubernetesマニフェストに変換することが困難です。このガイドは、本番環境対応のKubernetes構成を提供することでそのギャップを埋めます。

Splunk 連携

15 minutes

Splunk Observability Cloud について

Splunk Observability Cloudは、メトリクス、トレース、ログを大規模に監視するために構築されたリアルタイムのオブザーバビリティプラットフォームです。OpenTelemetryデータを取り込み、高度なダッシュボードと分析機能を提供して、チームがパフォーマンスの問題を迅速に検出し解決できるよう支援します。このセクションでは、OpenTelemetryを使用してThousandEyesデータをSplunk Observability Cloudと統合する方法を説明します。

このセクションの範囲

このセクションでは、ThousandEyesからSplunk Observability Cloudへのメトリクスストリーミングパスについて説明します。次のセクションでは、ThousandEyesとSplunk APM間の双方向リンクを作成する別の分散トレーシングワークフローを追加します。

ステップ 1: Splunk Observability Cloud アクセストークンを作成する

ThousandEyesメトリクスをSplunk Observability Cloudに送信するには、Ingest スコープを持つアクセストークンが必要です。以下の手順に従ってください：

Splunk Observability Cloudプラットフォームで、Settings > Access Token に移動します
Create Token をクリックします
Name を入力します
Ingest スコープを選択します
Create を選択してアクセストークンを生成します
アクセストークンをコピーし、安全に保管します

テレメトリデータをSplunk Observability Cloudに送信するには、アクセストークンが必要です。

ステップ 2: 連携を作成する

この連携は、ThousandEyesメトリクスをSplunk Observability Cloudのダッシュボードとディテクターに送信する一方向のテレメトリストリームです。

ThousandEyes UI を使用する

Splunk Observability CloudとThousandEyesを連携するには：

ThousandEyesプラットフォームでアカウントにログインし、Manage > Integration > Integration 1.0 に移動します
New Integration をクリックし、OpenTelemetry Integration を選択します
連携の Name を入力します
Target を HTTP に設定します
Endpoint URL を入力します：https://ingest.{REALM}.signalfx.com/v2/datapoint/otlp
- {REALM} をSplunk環境に置き換えます（例：us1、eu0）
Preset Configuration で Splunk Observability Cloud を選択します
Auth Type で Custom を選択します
以下の Custom Headers を追加します：
- X-SF-Token: {TOKEN}（ステップ1で作成したSplunk Observability Cloudアクセストークンを入力）
- Content-Type: application/x-protobuf
OpenTelemetry Signal で Metric を選択します
Data Model Version で v2 を選択します
テストを選択します
Save をクリックして連携の設定を完了します

これでThousandEyesデータとSplunk Observability Cloudの連携が正常に完了しました。

ThousandEyes API を使用する

プログラムによる連携には、以下のAPIコマンドを使用します：

HTTP Protocol

curl -v -XPOST https://api.thousandeyes.com/v7/stream \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "type": "opentelemetry",
    "testMatch": [{
      "id": "281474976717575",
      "domain": "cea"
    }],
    "endpointType": "http",
    "streamEndpointUrl": "https://ingest.{REALM}.signalfx.com:443/v2/datapoint/otlp",
    "customHeaders": {
      "X-SF-Token": "{TOKEN}",
      "Content-Type": "application/x-protobuf"
    }
  }'

gRPC Protocol

curl -v -XPOST https://api.thousandeyes.com/v7/stream \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "type": "opentelemetry",
    "testMatch": [{
      "id": "281474976717575",
      "domain": "cea"
    }],
    "endpointType": "grpc",
    "streamEndpointUrl": "https://ingest.{REALM}.signalfx.com:443",
    "customHeaders": {
      "X-SF-Token": "{TOKEN}",
      "Content-Type": "application/x-protobuf"
    }
  }'

streamEndpointUrl と X-SF-Token の値を、お使いのSplunk Observability Cloudインスタンスの正しい値に置き換えてください。

注意

{REALM} をSplunk環境のRealm（例：us1、us2、eu0）に、{TOKEN} を実際のSplunkアクセストークンに置き換えてください。

次のステップ

メトリクス連携が完了したら、分散トレーシングに進み、ThousandEyesからSplunk APMへの、そしてその逆の調査パスを追加します。

ステップ 3: Splunk Observability Cloud の ThousandEyes ダッシュボード

連携が設定されると、Splunk Observability Cloud内のThousandEyes Network Monitoring Dashboardでリアルタイムの監視データを表示できます。ダッシュボードには以下が含まれます：

HTTP Server Availability (%)：監視対象のHTTPサーバーの可用性を表示します
HTTP Throughput (bytes/s)：時間の経過に伴うデータ転送速度を表示します
Client Request Duration (seconds)：クライアントリクエストのレイテンシを測定します
Web Page Load Completion (%)：ページ読み込み成功の割合を表示します
Page Load Duration (seconds)：ページの読み込み時間を表示します

ダッシュボードテンプレート

ダッシュボードテンプレートは以下のリンクからダウンロードできます：ThousandEyes Splunk Observability Cloud ダッシュボードテンプレートをダウンロード (Google Drive)。

完了

ThousandEyesデータがSplunk Observability Cloudにストリーミングされるようになりました。次に、分散トレーシングコネクタを追加して、トラブルシューティング中にThousandEyesとSplunk APMの間を移動できるようにします。

分散トレーシングと双方向ドリルダウン

25 minutes

このセクションでは、ThousandEyesとSplunkの統合を真の調査ワークフローに変えます。前のセクションでは、ThousandEyesが合成メトリクスをSplunk Observability Cloudにストリーミングしました。このセクションでは、サポートされている ThousandEyes <-> Splunk APM 分散トレーシング統合 を有効にし、ネットワーク、プラットフォーム、アプリケーションチームが同じリクエストを見ながら両方のツール間を行き来できるようにします。

これが重要な理由

これは、2つの環境間で 双方向アクセス を可能にする部分です。ThousandEyesからSplunk APMの関連トレースを開くことができ、Splunk APMから元のThousandEyesテストに戻ることができます。

学習内容

このセクションを終了すると、以下のことができるようになります：

内部サービスを計装してSplunk APMにトレースを送信する
ThousandEyesの HTTP Server または API テストで分散トレーシングを有効にする
Splunk APM用のThousandEyes Generic Connector を設定する
ThousandEyesの Service Map を開き、対応するSplunkトレースに直接ジャンプする
Splunk APMのThousandEyesメタデータを使用して、元のThousandEyesテストに戻る

サポートされているワークフロー

この学習シナリオは、ThousandEyesとSplunkがドキュメント化しているサポートされたワークフローに従います：

ThousandEyesは、分散トレーシングが有効になっている場合、HTTP Server および API テストに b3、traceparent、tracestate ヘッダーを自動的に挿入します。
監視対象のエンドポイントは、ヘッダーを受け入れ、OpenTelemetryで計装され、トレースコンテキストを伝播し、オブザーバビリティバックエンドにトレースを送信する必要があります。
Splunk APMの場合、ThousandEyesは https://api.<REALM>.signalfx.com を指し、API スコープ のSplunkトークンで認証する Generic Connector を使用します。
Splunk APMは、thousandeyes.test.id や thousandeyes.permalink などのThousandEyes属性で一致するトレースを強化し、ThousandEyesへの逆ジャンプを可能にします。

これらのヘッダーの実際の意味

この部分は見落としがちですが、そうすべきではありません。トレース相関は、サービスがThousandEyesが挿入するヘッダーを理解し、トレースを正しく継続する場合にのみ機能します。

traceparent と tracestate はW3C Trace Contextヘッダーです。
b3 はZipkin B3シングルヘッダー形式です。
ThousandEyesは両方を挿入します。これは、実際の環境には、同じ伝播形式を好まないプロキシ、メッシュ、ゲートウェイ、アプリランタイムが混在していることが多いためです。

OpenTelemetryの用語では、重要な設定はプロパゲーターリストです：

OTEL_PROPAGATORS=baggage,b3,tracecontext

これは2つのことを行います：

サービスが受信ThousandEyesリクエストから B3 または W3C コンテキストのいずれかを抽出できるようにします。
tracecontext を有効にしておくことで、W3C tracestate を保持します。

重要な詳細

tracestate を別のOpenTelemetryプロパゲーターとして追加する必要は ありません。tracecontext プロパゲーターが traceparent と tracestate の両方を処理します。

「正しく行う」とはどういうことか

コレクターはこのセットアップの一部に過ぎません。Kubernetesでの正しいThousandEyesトレーシングデプロイメントには 3 つのレイヤー があります：

Deployment アノテーション - OpenTelemetry Operatorがランタイム固有の計装を挿入するため。
Instrumentation リソース - 挿入されたSDKがトレースの送信先と使用するプロパゲーターを知るため。
Collector トレースパイプライン - OTLPトレースが実際に受信され、Splunk APMにエクスポートされるため。

最も一般的な間違いは、コレクターだけに焦点を当てることです。コレクターは生の b3、traceparent、または tracestate リクエストヘッダーを直接見ることはありません。アプリケーションまたは自動計装ライブラリがまずそれらのヘッダーを抽出し、スパンコンテキストを継続し、次にOTLP経由でコレクターにスパンを送信する必要があります。

現在のクラスターからの実際の設定

以下の例は、このワークショップを現在実行しているライブクラスターからトリミングされたものです。これらは、今日Kubernetesで実際に機能しているパターンを示しています。

1. Deployment アノテーション

ライブクラスターでは、teastore アプリケーションは teastore/default Instrumentationリソースを指しています：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: teastore-webui-v1
  namespace: teastore
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/container-names: teastore-webui-v1
        instrumentation.opentelemetry.io/inject-java: teastore/default

これは、ThousandEyesリクエストがトレースに変換されない場合に最初に確認する場所です。

2. Instrumentation リソース

これは teastore からのライブ Instrumentation オブジェクトで、ThousandEyesに関係するフィールドにトリミングされています：

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: default
  namespace: teastore
spec:
  exporter:
    endpoint: http://splunk-otel-collector-agent.otel-splunk.svc:4317
  propagators:
    - baggage
    - b3
    - tracecontext
  sampler:
    type: parentbased_always_on
  env:
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: deployment.environment=teastore

これがThousandEyesシナリオの重要な部分です：

endpoint はクラスターローカルのOTelエージェントサービスにスパンを送信します。
b3 はThousandEyes B3ヘッダーの抽出を可能にします。
tracecontext は traceparent と tracestate を保持します。
parentbased_always_on は、ThousandEyesがリクエストを開始するとトレースが継続することを保証します。

3. 挿入された Pod が実際に取得するもの

実行中の teastore-webui-v1 Podでは、オペレーターが以下の環境変数を挿入しました：

- name: JAVA_TOOL_OPTIONS
  value: " -javaagent:/otel-auto-instrumentation-java-teastore-webui-v1/javaagent.jar"
- name: OTEL_SERVICE_NAME
  value: teastore-webui-v1
- name: OTEL_EXPORTER_OTLP_ENDPOINT
  value: http://splunk-otel-collector-agent.otel-splunk.svc:4317
- name: OTEL_PROPAGATORS
  value: baggage,b3,tracecontext
- name: OTEL_TRACES_SAMPLER
  value: parentbased_always_on

これは有用な検証チェックポイントです。プロパゲーターが抽象的な設定オブジェクトで宣言されているだけでなく、ワークロードに適用されていることを証明するためです。

4. Agent Collector トレースパイプライン

otel-splunk のライブエージェントコレクターは、OTLP、Jaeger、Zipkinトラフィックを受信し、上流にトレースを転送しています。これは実行中のConfigMapからのトリミングされた抜粋です：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_http:
        endpoint: 0.0.0.0:14268
  zipkin:
    endpoint: 0.0.0.0:9411

service:
  pipelines:
    traces:
      receivers: [otlp, jaeger, zipkin]
      processors:
        [memory_limiter, k8sattributes, batch, resourcedetection, resource, resource/add_environment]
      exporters: [otlp, signalfx]

ThousandEyesの場合、重要な部分はコレクターの特別なB3オプションではありません。重要な部分は、コレクターが 4317 と 4318 でOTLPを公開していること、およびサービスがそこにスパンをエクスポートしていることです。

5. Gateway Collector の Splunk APM へのエクスポート

ライブゲートウェイコレクターは、トレースをSplunk Observability Cloudに転送します。これは実行中のゲートウェイConfigMapの関連部分です：

exporters:
  otlphttp:
    auth:
      authenticator: headers_setter
    traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        include_metadata: true
      http:
        endpoint: 0.0.0.0:4318
        include_metadata: true

service:
  pipelines:
    traces:
      receivers: [otlp, jaeger, zipkin]
      processors:
        [memory_limiter, k8sattributes, batch, resource/add_cluster_name, resource/add_environment]
      exporters: [otlphttp, signalfx]

これは、スパンをSplunk APMに送信する部分です。このパイプラインが壊れている場合、ThousandEyesはリクエストにヘッダーを挿入できますが、相関トレースがSplunkに表示されることはありません。

現在のクラスターのポイント

ライブクラスターでは、teastore/default InstrumentationリソースがThousandEyesで従うべきパターンです。これは b3 と tracecontext を明示的に含んでいるためです。これが、このシナリオで複製したい設定です。

重要

このセクションではブラウザページのURLを使用 しないでください。ThousandEyesのドキュメントによると、ブラウザはこのワークフローに必要なカスタムトレースヘッダーを受け入れません。代わりに、HTTP Server または API テストの背後にある計装されたバックエンドエンドポイントを使用してください。

ステップ 1：ワークロードが Splunk APM にトレースを送信していることを確認する

アプリケーションがすでに計装されていて、トレースがSplunk APMに表示されている場合は、ステップ2にスキップできます。そうでない場合、Kubernetesでの最速の学習パスは、ゼロコード計装用のオペレーターを有効にしたSplunk OpenTelemetry Collectorを使用することです。

Splunk OpenTelemetry Collector とオペレーターをインストールする

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
helm repo update

helm install splunk-otel-collector splunk-otel-collector-chart/splunk-otel-collector \
  --namespace otel-splunk \
  --create-namespace \
  --set splunkObservability.realm=$REALM \
  --set splunkObservability.accessToken=$ACCESS_TOKEN \
  --set clusterName=$CLUSTER_NAME \
  --set operator.enabled=true \
  --set operatorcrds.install=true

自動計装用に Deployment にアノテーションを付ける

Javaワークロードの場合、一般的な例は次のようになります：

kubectl patch deployment api-gateway -n production -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/inject-java":"otel-splunk/splunk-otel-collector"}}}}}'

他のランタイムの場合は、言語に合ったアノテーションを使用してください：

instrumentation.opentelemetry.io/inject-nodejs
instrumentation.opentelemetry.io/inject-python
instrumentation.opentelemetry.io/inject-dotnet

コレクターがアプリケーションと同じ名前空間にインストールされている場合、公式のSplunkドキュメントでは "true" をアノテーション値として使用することもサポートしています。

このワークショップ環境の ライブクラスターパターン に従いたい場合、アノテーション値は名前空間修飾され、teastore/default Instrumentationオブジェクトを指します：

kubectl patch deployment teastore-webui-v1 -n teastore -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/container-names":"teastore-webui-v1","instrumentation.opentelemetry.io/inject-java":"teastore/default"}}}}}'

トレースが存在することを検証する

デプロイメントのロールアウトが完了するまで待ちます：
```
kubectl rollout status deployment/api-gateway -n production
```
複数のサービスを横断するバックエンドエンドポイントに対していくつかのリクエストを生成します。例：
```
http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
```
現在のワークショップクラスターでは、http://teastore-webui.teastore.svc.cluster.local:8080/ のようなサービスが適切なターゲットです。これは、いくつかの下流アプリケーションサービスをフロントエンドし、単純なヘルスチェックよりも有用なエンドツーエンドトレースを生成するためです。
続行する前に、Splunk APM にトレースが到着していることを確認してください。

学習のヒント

トレーシング演習には、純粋な /health エンドポイントではなく、ビジネストランザクションを使用してください。マルチサービスリクエストは、ThousandEyesでより良いService Mapを提供し、Splunk APMでより有用なトレースを提供します。

ステップ 2：ThousandEyes テストで分散トレーシングを有効にする

ステップ1の計装されたバックエンドエンドポイントをターゲットとする HTTP Server または API テストを作成または編集します。

ThousandEyesで、HTTP Server または API テストを作成します。
Advanced Settings を開きます。
Distributed Tracing を有効にします。
テストを保存し、すでにSplunk APMにトレースを送信しているのと同じエンドポイントに対して実行します。

テストが実行された後、ThousandEyesはトレースヘッダーを挿入し、そのリクエストのトレースコンテキストをキャプチャします。

ステップ 3：ThousandEyes で Splunk APM コネクターを作成する

前のセクションのメトリックストリーミング統合は Ingest トークンを使用します。このステップは異なります：ThousandEyesはSplunk APMにクエリを実行してトレースリンクを構築する必要があるため、代わりにSplunk API トークンを使用します。

Splunk Observability Cloudで、API スコープを持つアクセストークンを作成します。
ThousandEyesで、Manage > Integrations > Integrations 2.0 に移動します。
以下の設定で Generic Connector を作成します：
- Target URL: https://api.<REALM>.signalfx.com
- Header: X-SF-Token: <your-api-scope-token>
新しい Operation を作成し、Splunk Observability APM を選択します。
オペレーションを有効にして、統合を保存します。

ステップ 4：双方向調査ループを検証する

テストが実行され、コネクターが有効になったら、両方向でワークフローを検証します。

ThousandEyes から始める

ThousandEyesでテストを開きます。
Service Map タブに移動します。
トレースパス、サービスレイテンシー、下流のエラーが表示されることを確認します。
ThousandEyesから Splunk APM へのリンクを使用して、完全なトレースを検査します。

Splunk APM で続ける

Splunk APM内で、トレースに以下のようなThousandEyesメタデータが含まれていることを確認します：

thousandeyes.account.id
thousandeyes.test.id
thousandeyes.permalink
thousandeyes.source.agent.id

thousandeyes.permalink フィールドまたはトレースウォーターフォールビューの Go to ThousandEyes test ボタンを使用して、元のThousandEyesテストに戻ります。

推奨される学習シナリオ

ワークショップ中に以下のフローを使用してください：

複数のサービスを呼び出す内部APIルートに対するThousandEyesテストを作成します。
ThousandEyesに最初に問題を表示させ、クラスがネットワークと合成モニタリングの観点から始められるようにします。
ThousandEyesで Service Map を開き、レイテンシーやエラーがどこから始まるかを特定します。
スパンレベルの分析のために Splunk APM にジャンプします。
テスト、エージェント、ネットワークパスを再度検査するために ThousandEyes に戻ります。

これは、異なるチームが実際に作業する方法を反映しているため、強力な教育ループです：

ネットワークおよびエッジチームは、ThousandEyesから始めることが多いです。
SREおよびプラットフォームチームは、Splunkダッシュボードまたはアラートから始めることが多いです。
アプリケーションチームは、通常Splunk APMのトレースを求めます。

この統合が整っていれば、全員がコンテキストを失うことなく切り替えることができます。

よくある落とし穴

テストがSplunkダッシュボードに表示されていても、トレース相関がない場合があります。これは通常、メトリクス ストリームのみが設定されており、Splunk APM Generic Connector が設定されていないことを意味します。
監視対象のエンドポイントがトレースヘッダーを下流に伝播しない場合、トレースがSplunk APMに存在してもThousandEyesに表示されない場合があります。
/health のような浅いエンドポイントは、設定が正しくても限られたトレース価値しか生成しないことがよくあります。

参考資料

Kubernetes サービステストと相関

20 minutes

AppDynamics テスト推奨機能の再現

AppDynamicsには、アプリケーションのエンドポイントに対するシンセティックテストを自動的に提案する「Test Recommendations」という機能があります。ThousandEyesをKubernetesクラスター内にデプロイすることで、KubernetesのサービスディスカバリとSplunk Observability Cloudの統合ビューを組み合わせて、この機能を再現できます。

ThousandEyes Enterprise Agentはクラスター内部で実行されるため、サービス名をホスト名として使用して内部Kubernetesサービスを直接テストできます。これにより、外部に公開されていないバックエンドサービスを監視する強力な方法が得られます。

仕組み

サービスディスカバリ: kubectl get svc を使用してクラスター内のサービスを列挙します
ホスト名の構築: Kubernetes DNS命名規則を使用してテストURLを構築します: <service-name>.<namespace>.svc.cluster.local
テストの作成: 内部サービスに対して可用性テストとトレース対応トランザクションテストの両方を作成します
Splunk での相関: シンセティックテストの結果をAPMトレースおよびインフラストラクチャメトリクスと並べて表示します

クラスター内テストのメリット

内部サービス監視: インターネットに公開されていないバックエンドサービスをテストできます
サービスメッシュ対応: Istio、Linkerd、その他のサービスメッシュの背後にあるサービスを監視できます
DNS 解決テスト: Kubernetes DNSとサービスディスカバリを検証できます
ネットワークポリシー検証: ネットワークポリシーが適切な通信を許可していることを確認できます
レイテンシベースライン: クラスター内部のネットワークパフォーマンスを測定できます
本番前テスト: Ingress/LoadBalancer経由で公開する前にサービスをテストできます

ステップバイステップガイド

1. Kubernetes サービスの検出

クラスター内または特定のnamespace内のすべてのサービスを一覧表示します:

# Get all services in all namespaces
kubectl get svc --all-namespaces

# Get services in a specific namespace
kubectl get svc -n production

# Get services with detailed output including ports
kubectl get svc -n production -o wide

出力例:

NAMESPACE    NAME           TYPE        CLUSTER-IP      PORT(S)    AGE
production   api-gateway    ClusterIP   10.96.100.50    8080/TCP   5d
production   payment-svc    ClusterIP   10.96.100.51    8080/TCP   5d
production   auth-service   ClusterIP   10.96.100.52    9000/TCP   5d
production   postgres       ClusterIP   10.96.100.53    5432/TCP   5d

2. テストホスト名の構築

Kubernetesサービスは、以下の命名パターンを使用してDNS経由でアクセスできます:

<service-name>.<namespace>.svc.cluster.local

上記のサービスの場合:

api-gateway.production.svc.cluster.local:8080
payment-svc.production.svc.cluster.local:8080
auth-service.production.svc.cluster.local:9000

同じ namespace 内での省略形: ThousandEyesエージェントと同じnamespace内のサービスをテストする場合は、サービス名のみを使用できます:

api-gateway:8080
payment-svc:8080

3. 内部サービス用の ThousandEyes テストの作成

最良の学習成果を得るために、2 種類のテストを作成します:

/health または /readiness エンドポイントに対する可用性テストで、到達可能性と応答時間を検証します
複数のサービスを横断するビジネスエンドポイントに対するトレース対応トランザクションテスト

最初のテストはシンセティック監視を学ぶためのものです。2番目のテストはSplunk APMを使用したクロスツールトラブルシューティングを学ぶためのものです。

ThousandEyes UI 経由

Cloud & Enterprise Agents > Test Settings に移動します
Add New Test → HTTP Server をクリックします
可用性テストを設定します:
- Test Name: [K8s] API Gateway Health
- URL: http://api-gateway.production.svc.cluster.local:8080/health
- Interval: 2 minutes
- Agents: KubernetesにデプロイされたEnterprise Agentを選択します
- HTTP Response Code: 200
トレース対応トランザクションテストを設定します:
- Test Name: [Trace] API Gateway Orders
- URL: http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
- Interval: 2 minutes
- Agents: KubernetesにデプロイされたEnterprise Agentを選択します
- Advanced Settings > Distributed Tracing: Enabled
Create Test をクリックします

ThousandEyes API 経由

curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "testName": "[K8s] API Gateway Health",
    "url": "http://api-gateway.production.svc.cluster.local:8080/health",
    "interval": 120,
    "agents": [
      {"agentId": "<your-k8s-agent-id>"}
    ],
    "httpTimeLimit": 5000,
    "targetResponseTime": 1000,
    "alertsEnabled": 1
  }'

トレース対応バージョンの場合は、url をビジネストランザクションエンドポイントに切り替え、ThousandEyesテスト設定でdistributed tracingを有効にします。

ベストプラクティス

distributed tracingを教えることが目的の場合、/health だけを例として使用することは避けてください。ヘルスチェックは稼働時間の監視には便利ですが、ThousandEyesとSplunk APMの統合を魅力的にするマルチサービストレースを生成することはほとんどありません。

4. アラートルールの設定

一般的な障害シナリオに対するアラートを設定します:

可用性アラート: HTTPレスポンスが200でない場合にトリガーします
パフォーマンスアラート: レスポンスタイムがベースラインを超えた場合にトリガーします
DNS 解決アラート: サービスDNSが解決できない場合にトリガーします

5. Splunk Observability Cloud での結果表示

テストが実行され、Splunkと統合されたら:

Splunk Observability Cloudで ThousandEyes Dashboard に移動します
テスト名でフィルターします（例: [K8s] プレフィックス）、すべてのKubernetes内部テストを表示します
トレース対応テストの場合は、まず ThousandEyes から開始します:
- Service Map を開きます
- サービスレベルのレイテンシとダウンストリームエラーを調べます
- Splunk APM へのリンクをたどります
APM データとの相関:
- シンセティックテストの失敗をAPMエラー率と並べて表示します
- 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを特定します
- Splunkトレースメタデータを使用して、元のThousandEyesテストに戻ります
以下を組み合わせたカスタムダッシュボードを作成します:
- ThousandEyes HTTP可用性メトリクス
- APMサービスレイテンシとエラー率
- Kubernetesインフラストラクチャメトリクス（CPU、メモリ、Pod再起動）

ユースケース例

ユースケース 1: マイクロサービスヘルスチェック

複数のマイクロサービスヘルスエンドポイントをテストします:

http://user-service.production.svc.cluster.local:8080/actuator/health
http://order-service.production.svc.cluster.local:8080/actuator/health
http://inventory-service.production.svc.cluster.local:8080/actuator/health

ユースケース 2: API Gateway エンドポイントテスト

有用なトレースを生成する可能性が高いAPI Gatewayルートをテストします:

http://api-gateway.production.svc.cluster.local:8080/api/v1/users
http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
http://api-gateway.production.svc.cluster.local:8080/api/v1/products

ユースケース 3: データベース接続テスト

ThousandEyesは主にHTTPテスト用ですが、データベースプロキシをテストできます:

# Test PgBouncer or database HTTP management interfaces
http://pgbouncer.production.svc.cluster.local:8080/stats
http://redis-exporter.production.svc.cluster.local:9121/metrics

ユースケース 4: 外部サービス依存関係

クラスター内ThousandEyesエージェントの最も価値のある機能の1つは、サービスと同じネットワークの視点からアプリケーションの外部依存関係を監視することです。これにより、問題がインフラストラクチャ、ネットワークパス、または外部サービス自体のいずれに起因するかを特定できます。

決済ゲートウェイのテスト

重要な決済ゲートウェイエンドポイントの可用性とパフォーマンスを確保するためのテストを作成します:

Stripe API:

# Via ThousandEyes UI
Test Name: [External] Stripe API Health
URL: https://api.stripe.com/healthcheck
Interval: 2 minutes
Agents: Your Kubernetes Enterprise Agent
Expected Response: 200

PayPal API:

Test Name: [External] PayPal API Health
URL: https://api.paypal.com/v1/notifications/webhooks
Interval: 2 minutes
Agents: Your Kubernetes Enterprise Agent
Expected Response: 401 (authentication required, but endpoint is reachable)

ThousandEyes API 経由:

curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "testName": "[External] Stripe API Availability",
    "url": "https://api.stripe.com/healthcheck",
    "interval": 120,
    "agents": [
      {"agentId": "<your-k8s-agent-id>"}
    ],
    "httpTimeLimit": 5000,
    "targetResponseTime": 2000,
    "alertsEnabled": 1
  }'

なぜ外部依存関係を監視するのか？

プロアクティブな問題検出: 顧客から報告される前に決済ゲートウェイの障害を把握できます
ネットワークパス検証: Kubernetesエグレスネットワークが外部サービスに到達できることを確認します
パフォーマンスベースライン: クラスターから外部APIへのレイテンシを追跡します
コンプライアンスと SLA 監視: サードパーティサービスがSLAコミットメントを満たしていることを確認します
根本原因分析: 問題がネットワーク関連か、インフラストラクチャか、外部プロバイダーかを迅速に判断します

監視を推奨する外部サービス

決済プロセッサ: Stripe、PayPal、Square、Braintree
認証プロバイダー: Auth0、Okta、Azure AD
メールサービス: SendGrid、Mailgun、AWS SES
SMS/コミュニケーション: Twilio、MessageBird
CDN エンドポイント: Cloudflare、Fastly、Akamai
クラウドストレージ: AWS S3、Google Cloud Storage、Azure Blob Storage
サードパーティ API: 重要なビジネスパートナー API

ベストプラクティス

テスト名に [External] プレフィックスを使用して、ダッシュボードで内部Kubernetesサービスと外部依存関係を簡単に区別できるようにします。

ベストプラクティス

一貫した命名を使用する: フィルタリングを容易にするため、テスト名に [K8s] または [Internal] プレフィックスを付けます
まずヘルスエンドポイントをテストする: ビジネスロジックをテストする前に /health または /readiness エンドポイントから始めます
適切な間隔を設定する: 重要なサービスには短い間隔（1〜2分）を使用します
テストにタグを付ける: ThousandEyesのラベル/タグを使用してテストをグループ化します:
- 環境（dev、staging、production）
- サービスタイプ（API、database、cache）
- チームオーナーシップ
テストエージェントの健全性を監視する: ThousandEyesエージェントPodが健全で、十分なリソースがあることを確認します
両方のテストタイプを使用する: 各重要なサービスパスに対して、シンプルな可用性テストとトレース対応ビジネストランザクションテストをペアにします
APM との相関: シンセティックデータとAPMデータを並べて表示するSplunkダッシュボードを作成します
トレースラボには計装されたバックエンドを使用する: distributed tracingは、ThousandEyesのターゲットがOpenTelemetryで計装されたサービスによってバックアップされたHTTP ServerまたはAPIエンドポイントである場合に最も効果的です

ヒント

内部サービスを外部に公開する前にテストすることで、問題を早期に発見し、ユーザートラフィックが到達する前にインフラストラクチャが健全であることを確認できます。

ThousandEyes と Splunk RUM

10 minutes

ThousandEyesとSplunk RUMを統合して、ネットワークの問題がエンドユーザーの問題と関連しているかどうかを把握します。

前提条件

Splunk Observability CloudとThousandEyes両方の管理者権限
Splunk RUMにデータを送信しているアプリケーションが少なくとも1つ
Splunk RUMのアプリと同じドメインで、ThousandEyesで以下のタイプのテストが少なくとも1つ実行されていること：

統合手順

ThousandEyesでOAuth Bearerトークンを作成します：
- 右上隅のユーザー名を選択し、Profile を選択します。
- User API Tokensの下で Create を選択してOAuth Bearer Tokenを生成します。
- Observability Cloudのデータ統合ウィザードで使用するため、トークンをコピーまたはメモしておきます。
Splunk Observability Cloudで、Data Management > Available Integrations > ThousandEyes Integration with RUMを開きます。
- 前回の Splunk 統合で使用したものと同じ Ingest トークンを使用するか、RUM統合のデータ使用量をより適切に追跡するために専用の Ingest トークンを作成して選択します。
- ThousandEyesからのOAuth Bearerトークンを入力します。
- テストのマッチングを確認し、必要に応じて選択を変更し、推定データ取り込み量を確認してから Done を選択します。

統合の確認

ThousandEyesテストが実行されているRUMアプリケーションに移動し、Mapを表示します。 ThousandEyesテストも実行されているロケーションにカーソルを合わせると、ThousandEyesメトリクスのプレビューが表示されます：

ThousandEyesでアクティブなアラートがある場合、RUMの該当するロケーションのバブル上にThousandEyesアイコンが表示されます：

該当するリージョンをクリックすると、RUMの他のメトリクスと一緒にネットワークメトリクスが表示されます。View ThousandEyes Tests を開いてThousandEyesの関連テストに移動できます：

カスタムダッシュボードで RUM と ThousandEyes のメトリクスを表示する

これで、関連するThousandEyesテストからのシグナルと他のObservability CloudのKPIを関連付けることができます！

Dashboards > “RUM” で検索 > RUM applications グループ内のすぐに使えるRUMダッシュボードの1つをクリックします。
興味のあるRUM KPIのチャートをコピーするか、右上のダッシュボードのアクションメニューを開いて Save As で自分のダッシュボードグループにコピーを作成します。
新しいダッシュボードで、シグナル network.latency を使用して新しいチャートを作成します。
- extrapolation policyを Last value に変更します。
- 測定単位をTime > Millisecond に変更します。
- Chart Optionsで、Show on-chart legend を選択し、値を thousandeyes.source.agent.name にします。これにより、ThousandEyesのエージェントロケーション別にチャートが分割されます。
新しいチャートに名前を付けて保存し、それをコピーして network.jitter と network.loss の類似チャートを作成します。コピーしたチャートのシグナルでメトリクスを変更し、必要に応じて測定単位と可視化オプションを調整します。

カスタムダッシュボードとチャートの作成に関する詳細なガイダンスは、Dashboard Workshop を参照してください。

ヒント

ThousandEyesのテストメトリクスと並べて表示すると便利なObservability Cloudの他のメトリクスについて考えてみてください。

例えば、SyntheticsでAPIテストを実行している場合は、ロケーション別のAPIテスト成功率のヒートマップを追加することを検討してください。

トラブルシューティング

15 minutes

このセクションでは、KubernetesでThousandEyes Enterprise Agentをデプロイおよび使用する際に遭遇する可能性のある一般的な問題について説明します。

DNS 解決エラーでテストが失敗する

テストがDNS解決エラーで失敗している場合は、ThousandEyes Pod内からDNSを確認してください：

# Verify DNS resolution from within the pod
kubectl exec -n te-demo -it <pod-name> -- nslookup api-gateway.production.svc.cluster.local

# Check CoreDNS logs
kubectl logs -n kube-system -l k8s-app=kube-dns

一般的な原因：

指定されたnamespaceにサービスが存在しない
サービス名またはnamespaceの入力ミス
CoreDNSが正常に機能していない

接続拒否エラー

接続拒否エラーが発生している場合は、以下を確認してください：

# Verify service endpoints exist
kubectl get endpoints -n production api-gateway

# Check if pods are ready
kubectl get pods -n production -l app=api-gateway

# Test connectivity from agent pod
kubectl exec -n te-demo -it <pod-name> -- curl -v http://api-gateway.production.svc.cluster.local:8080/health

一般的な原因：

サービスをバックアップするPodがない（endpointsが空）
PodがReady状態でない
テストURLで間違ったポートが指定されている
サービスセレクターがPodラベルと一致しない

Network Policy がトラフィックをブロックしている

Network PolicyがThousandEyesエージェントからのトラフィックをブロックしている場合：

# List network policies
kubectl get networkpolicies -n production

# Describe network policy
kubectl describe networkpolicy <policy-name> -n production

解決策： te-demo namespaceからサービスへのトラフィックを許可するNetwork Policyを作成します：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-thousandeyes-agent
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-gateway
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: te-demo
    ports:
    - protocol: TCP
      port: 8080

エージェント Pod が起動しない

ThousandEyesエージェントPodが起動しない場合は、Podのステータスとイベントを確認してください：

# Get pod status
kubectl get pods -n te-demo

# Describe pod to see events
kubectl describe pod -n te-demo <pod-name>

# Check logs
kubectl logs -n te-demo <pod-name>

一般的な原因：

リソース不足（memory/CPU）
無効または欠落しているTEAGENT_ACCOUNT_TOKENシークレット
Pod Security Policyによってセキュリティコンテキストのケイパビリティが許可されていない
イメージプルエラー

解決策：

OOMKilledの場合はメモリ制限を増やす
シークレットが正しく作成されているか確認する：kubectl get secret te-creds -n te-demo -o yaml
Pod Security PolicyがNET_ADMINおよびSYS_ADMINケイパビリティを許可しているか確認する
イメージプルを確認する：kubectl describe pod -n te-demo <pod-name>

エージェントが ThousandEyes ダッシュボードに表示されない

エージェントは実行中だがThousandEyesダッシュボードに表示されない場合：

# Check agent logs for connection issues
kubectl logs -n te-demo -l app=thousandeyes --tail=100

一般的な原因：

無効または不正なTEAGENT_ACCOUNT_TOKEN
ネットワークのEgressがブロックされている（ファイアウォールまたはNetwork Policy）
エージェントがThousandEyes Cloudサーバーに到達できない

解決策：

トークンが正しく、適切にbase64エンコードされているか確認する
*.thousandeyes.com へのEgressが許可されているか確認する
エージェントがインターネットに到達できるか確認する：

kubectl exec -n te-demo -it <pod-name> -- curl -v https://api.thousandeyes.com

データが Splunk Observability Cloud に表示されない

ThousandEyesのデータがSplunkに表示されない場合：

統合の設定を確認：

ThousandEyesでOpenTelemetry統合が正しく設定されているか確認する
SplunkインジェストエンドポイントURLがお使いのRealmに対して正しいか確認する
X-SF-Token ヘッダーに有効なSplunkアクセストークンが含まれているか確認する
テストが統合に割り当てられているか確認する

テストの割り当てを確認：

# Use ThousandEyes API to verify integration
curl -v https://api.thousandeyes.com/v7/stream \
  -H "Authorization: Bearer $BEARER_TOKEN"

一般的な原因：

エンドポイントURLのSplunk Realmが間違っている
無効または期限切れのSplunkアクセストークン
テストがOpenTelemetry統合に割り当てられていない
統合が適切に有効化または保存されていない

分散トレーシングが ThousandEyes に表示されない

メトリクスストリームは機能しているが、ThousandEyesの Service Map が空であるか、トレースが見つからない場合：

監視対象のエンドポイントを確認：

HTTPヘッダーを受け入れること
OpenTelemetryで計装されていること
トレースコンテキストを下流に伝播すること
Splunk APMにトレースを送信すること

一般的な原因：

エンドポイントがHTTP ServerまたはAPIターゲットではなくページURLである
サービスが計装されていないため、ThousandEyesはヘッダーを注入できるがトレースは出力されない
エンドポイントがローカルのヘルスレスポンスのみを返し、下流サービスを実行しない

推奨される修正：

ThousandEyesテストを計装されたバックエンドAPIルートに切り替える
そのルートのトレースが既にSplunk APMに存在することを確認する
ThousandEyes分散トレーシングを有効にした後、テストを再実行する

Splunk APM に ThousandEyes リンクが表示されない

トレースがSplunk APMで開くが、ThousandEyesのバックリンクやメタデータが表示されない場合：

一般的な原因：

b3 プロパゲーターが trace_state を上書きし、ThousandEyesがリバースリンクのために保持することを期待している値をクリアする可能性があります。

修正：

計装されたサービスでプロパゲーターを明示的に設定します：

OTEL_PROPAGATORS=baggage,b3,tracecontext

環境変数を変更した後、計装されたワークロードを再起動し、新しいトラフィックを生成します。

Splunk APM Connector の認証エラー

ThousandEyesの Generic Connector がSplunk APMにクエリできない場合：

以下を確認してください：

コネクターのターゲットが https://api.<REALM>.signalfx.com であること
コネクターで使用されているトークンが API スコープを持っていること
トークンを作成するユーザーがSplunk Observability Cloudで必要なロールを持っていること

トークンに関する注意

OpenTelemetryメトリクスストリームはSplunk Ingest トークンを使用します。APM用のThousandEyes Generic Connector はSplunk API トークンを使用します。これらを混同することは、部分的な統合の最も一般的な原因の一つです。

メモリ使用量が高い

ThousandEyesエージェントPodが過剰なメモリを消費している場合：

# Check current memory usage
kubectl top pod -n te-demo

# Check for OOMKilled events
kubectl describe pod -n te-demo <pod-name> | grep -i oom

解決策：

デプロイメントでメモリ制限を増やす：

resources:
  limits:
    memory: 4096Mi  # Increase from 3584Mi
  requests:
    memory: 2500Mi  # Increase from 2000Mi

エージェントに割り当てられた同時テストの数を減らす
エージェントが不要なサービスを実行していないか確認する

Permission Denied エラー

エージェントのログにPermission Deniedエラーが表示される場合：

セキュリティコンテキストを確認：

kubectl get pod -n te-demo <pod-name> -o jsonpath='{.spec.containers[0].securityContext}'

解決策： Podに必要なケイパビリティがあることを確認します：

securityContext:
  capabilities:
    add:
      - NET_ADMIN
      - SYS_ADMIN

注意

厳格なPod Security Policyを持つ一部のKubernetesクラスターでは、これらのケイパビリティが許可されない場合があります。適切なポリシー例外を作成するために、クラスター管理者と協力する必要があるかもしれません。

サポートを受ける

このガイドでカバーされていない問題に遭遇した場合：

ThousandEyes Support: support.thousandeyes.com でThousandEyesサポートに連絡してください
Splunk Support: Splunk Observability Cloudの問題については、Splunk Support をご覧ください
コミュニティフォーラム:
- ThousandEyes Community
- Splunk Community

ヒント

サポートを求める際は、より効果的にトラブルシューティングできるよう、関連するログ、Podの説明、エラーメッセージを必ず含めてください。

Isovalent Enterprise Platform と Splunk Observability Cloud の統合

105 minutes Author Alec Chamberlain

このワークショップでは、Isovalent Enterprise Platform と Splunk Observability Cloud の統合を実演し、eBPFテクノロジーを使用してKubernetesのネットワーキング、セキュリティ、ランタイム動作の包括的な可視性を提供する方法を説明します。

学習内容

このワークショップを完了すると、以下のことができるようになります：

ENIモードでCiliumをCNIとして使用するAmazon EKSをデプロイする
L7可視性を備えたネットワークオブザーバビリティのためのHubbleを設定する
ランタイムセキュリティ監視のためのTetragonをインストールする
OpenTelemetryを使用してeBPFベースのメトリクスをSplunk Observability Cloudと統合する
統合ダッシュボードでネットワークフロー、セキュリティイベント、インフラストラクチャメトリクスを監視する
eBPFによるオブザーバビリティとkube-proxyの置き換えを理解する

セクション

概要 - CiliumアーキテクチャとeBPFの基礎を理解する
前提条件 - 必要なツールとアクセス権
EKS セットアップ - Cilium用のEKSクラスターを作成する
Cilium インストール - Cilium、Hubble、Tetragonをデプロイする
Splunk 統合 - メトリクスをSplunk Observability Cloudに接続する
検証 - 統合を検証する
デモスクリプト - エンドツーエンドのDNS調査シナリオをウォークスルーする

ヒント

この統合は、Linuxカーネル内で直接、高性能で低オーバーヘッドのオブザーバビリティを実現するためにeBPF（Extended Berkeley Packet Filter）を活用しています。

前提条件

適切な認証情報で設定されたAWS CLI
kubectl、eksctl、Helm 3.xがインストールされていること
EKSクラスター、VPC、EC2インスタンスを作成する権限を持つAWSアカウント
アクセストークンを持つSplunk Observability Cloudアカウント
完全なセットアップに約90分

統合のメリット

Isovalent Enterprise PlatformをSplunk Observability Cloudに接続することで、以下のメリットが得られます：

🔍 深い可視性: ネットワークフロー、L7プロトコル（HTTP、DNS、gRPC）、ランタイムセキュリティイベント
🚀 高パフォーマンス: 最小限のオーバーヘッドでeBPFベースのオブザーバビリティを実現
🔐 セキュリティインサイト: プロセス監視、システムコールトレーシング、ネットワークポリシーの適用
📊 統合ダッシュボード: Cilium、Hubble、TetragonのメトリクスをインフラストラクチャおよびAPMデータと並べて表示
⚡ 効率的なネットワーキング: kube-proxyの置き換えとENIモードによるネイティブVPCネットワーキング

ソースリポジトリ

このワークショップで参照されるすべての設定ファイル、Helm values、ダッシュボードJSONファイルは、以下のリポジトリで入手できます：

isovalent_splunk_o11y — Helm values、OTel Collector設定、SplunkダッシュボードJSONファイル、および完全な統合ガイド
isovalent-demo-jobs-app — デモシナリオで使用されるjobs-app Helm chart（エラーインジェクションと修復スクリプトを含む）

Cilium のインストール
ステップ 1: Cilium Enterprise の設定 cilium-enterprise-values.yaml という名前のファイルを作成します。を前のステップで取得したエンドポイントに置き換えてください（https:// プレフィックスは除きます）。
Enable/disable debug logging debug: enabled: false verbose: ~ # Configure unique cluster name & ID cluster: name: isovalent-demo id: 0 # Configure ENI specifics eni: enabled: true updateEC2AdapterLimitViaAPI: true # Dynamically fetch ENI limits from EC2 API awsEnablePrefixDelegation: true # Assign /28 CIDR blocks per ENI (16 IPs) instead of individual IPs enableIPv4Masquerade: false # Pods use their real VPC IPs — no SNAT needed in ENI mode loadBalancer: serviceTopology: true # Prefer backends in the same AZ to reduce cross-AZ traffic costs ipam: mode: eni routingMode: native # No overlay tunnels — traffic routes natively through VPC # BPF / KubeProxyReplacement # Cilium replaces kube-proxy entirely with eBPF programs in the kernel. # This requires a direct path to the API server, hence k8sServiceHost. kubeProxyReplacement: “true” k8sServiceHost: k8sServicePort: 443 # TLS for internal Cilium communication tls: ca: certValidityDuration: 3650 # 10 years for the CA cert # Hubble: network observability built on top of Cilium’s eBPF datapath hubble: enabled: true metrics: enableOpenMetrics: true # Use OpenMetrics format for better Prometheus compatibility enabled: # DNS: query/response tracking with namespace-level label context - dns:labelsContext=source_namespace,destination_namespace # Drop: packet drop reasons (policy deny, invalid, etc.) per namespace - drop:labelsContext=source_namespace,destination_namespace # TCP: connection state tracking (SYN, FIN, RST) per namespace - tcp:labelsContext=source_namespace,destination_namespace # Port distribution: which destination ports are being used - port-distribution:labelsContext=source_namespace,destination_namespace # ICMP: ping/traceroute visibility with workload identity context - icmp:labelsContext=source_namespace,destination_namespace;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity # Flow: per-workload flow counters (forwarded, dropped, redirected) - flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity # HTTP L7: request/response metrics with full workload context and exemplars for trace correlation - “httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity” # Policy: network policy verdict tracking (allowed/denied) per workload - “policy:sourceContext=app|workload-name|pod|reserved-identity;destinationContext=app|workload-name|pod|dns|reserved-identity;labelsContext=source_namespace,destination_namespace” # Flow export: enables Hubble to export flow records to Timescape for historical storage - flow_export serviceMonitor: enabled: true # Creates a Prometheus ServiceMonitor for auto-discovery tls: enabled: true auto: enabled: true method: cronJob # Automatically rotate Hubble TLS certs on a schedule certValidityDuration: 1095 # 3 years per cert rotation relay: enabled: true # Hubble Relay aggregates flows from all nodes cluster-wide tls: server: enabled: true prometheus: enabled: true serviceMonitor: enabled: true timescape: enabled: true # Stores historical flow data for time-travel debugging # Cilium Operator: cluster-wide identity and endpoint management operator: prometheus: enabled: true serviceMonitor: enabled: true # Cilium Agent: per-node eBPF datapath metrics prometheus: enabled: true serviceMonitor: enabled: true # Cilium Envoy: L7 proxy metrics (HTTP, gRPC) envoy: prometheus: enabled: true serviceMonitor: enabled: true # Enable the Cilium agent to hand off DNS proxy responsibilities to the # external DNS Proxy HA deployment, so policies keep working during upgrades extraConfig: external-dns-proxy: “true” # Enterprise feature gates — these must be explicitly approved enterprise: featureGate: approved: - DNSProxyHA # High-availability DNS proxy (installed separately) - HubbleTimescape # Historical flow storage via Timescape ラベルコンテキストが重要な理由各Hubbleメトリクスの labelsContext および sourceContext/destinationContext パラメータは、メトリクスをどのディメンションで分割するかを制御します。labelsContext=source_namespace,destination_namespace を設定すると、すべてのメトリクスにこれら2つのラベルが付与され、カーディナリティの爆発を起こすことなくSplunkでnamespaceによるフィルタリングが可能になります。workload-name|reserved-identity のフォールバックチェーンは、利用可能な場合はワークロード名を使用し、利用できない場合はセキュリティIDにフォールバックすることを意味します。
Splunk Integration
概要 Splunk OpenTelemetry Collectorは、Prometheusレシーバーを使用してすべてのIsovalentコンポーネントからメトリクスをスクレイプします。各コンポーネントは異なるポートでメトリクスを公開しており、CiliumとHubbleは同じPodを共有しています（ポートが異なるだけです）。そのため、Podアノテーションに依存するのではなく、各コンポーネントに対して個別のレシーバーを設定します。コンポーネントポート提供する情報 Cilium Agent 9962 eBPF データパス、ポリシー適用、IPAM、BPF マップ統計 Cilium Envoy 9964 L7 プロキシメトリクス（HTTP、gRPC） Cilium Operator 9963 クラスター全体のアイデンティティとエンドポイント管理 Hubble 9965 ネットワークフロー、DNS、HTTP L7、TCP フラグ、ポリシー判定 Tetragon 2112 ランタイムセキュリティ、ソケット統計、ネットワークフローイベントステップ 1: 設定ファイルの作成 splunk-otel-collector-values.yaml という名前のファイルを作成します。認証情報のプレースホルダーを実際の値に置き換えてください。 terminationGracePeriodSeconds: 30 agent: config: extensions: # k8s_observer watches the Kubernetes API for pod and port changes. # This enables automatic service discovery without static endpoint lists. k8s_observer: auth_type: serviceAccount observe_pods: true receivers: kubeletstats: collection_interval: 30s insecure_skip_verify: true # Cilium Agent (port 9962) and Hubble (port 9965) both run in the # same DaemonSet pod, identified by label k8s-app=cilium. # We use two separate scrape jobs because they’re on different ports. prometheus/isovalent_cilium: config: scrape_configs: - job_name: ‘cilium_metrics_9962’ scrape_interval: 30s metrics_path: /metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_k8s_app] action: keep regex: cilium - source_labels: [__meta_kubernetes_pod_ip] target_label: address replacement: ${__meta_kubernetes_pod_ip}:9962 - target_label: job replacement: ‘cilium_metrics_9962’ - job_name: ‘hubble_metrics_9965’ scrape_interval: 30s metrics_path: /metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_k8s_app] action: keep regex: cilium - source_labels: [__meta_kubernetes_pod_ip] target_label: address replacement: ${__meta_kubernetes_pod_ip}:9965 - target_label: job replacement: ‘hubble_metrics_9965’ # Cilium Envoy uses a different pod label (k8s-app=cilium-envoy) prometheus/isovalent_envoy: config: scrape_configs: - job_name: ’envoy_metrics_9964’ scrape_interval: 30s metrics_path: /metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_k8s_app] action: keep regex: cilium-envoy - source_labels: [__meta_kubernetes_pod_ip] target_label: address replacement: ${__meta_kubernetes_pod_ip}:9964 - target_label: job replacement: ‘cilium_metrics_9964’ # Cilium Operator is a Deployment (not DaemonSet), identified by io.cilium.app=operator prometheus/isovalent_operator: config: scrape_configs: - job_name: ‘cilium_operator_metrics_9963’ scrape_interval: 30s metrics_path: /metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_io_cilium_app] action: keep regex: operator - target_label: job replacement: ‘cilium_metrics_9963’ # Tetragon is identified by app.kubernetes.io/name=tetragon prometheus/isovalent_tetragon: config: scrape_configs: - job_name: ’tetragon_metrics_2112’ scrape_interval: 30s metrics_path: /metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] action: keep regex: tetragon - source_labels: [__meta_kubernetes_pod_ip] target_label: address replacement: ${__meta_kubernetes_pod_ip}:2112 - target_label: job replacement: ’tetragon_metrics_2112’ processors: # Strict allowlist filter: only forward metrics we’ve explicitly named. # Without this, Cilium and Tetragon can generate thousands of metric series # and overwhelm Splunk Observability Cloud with cardinality. filter/includemetrics: metrics: include: match_type: strict metric_names: # — Kubernetes base metrics — - container.cpu.usage - container.memory.rss - k8s.container.restarts - k8s.pod.phase - node_namespace_pod_container - tcp.resets - tcp.syn_timeouts # — Cilium Agent metrics — # API rate limiting — detect if the agent is being throttled - cilium_api_limiter_processed_requests_total - cilium_api_limiter_processing_duration_seconds # BPF map utilization — alerts when eBPF maps are near capacity - cilium_bpf_map_ops_total # Controller health — tracks background reconciliation tasks - cilium_controllers_group_runs_total - cilium_controllers_runs_total # Endpoint state — how many pods are in each lifecycle state - cilium_endpoint_state # Agent error/warning counts — early warning for problems - cilium_errors_warnings_total # IP address allocation tracking - cilium_ip_addresses - cilium_ipam_capacity # Kubernetes event processing rate - cilium_kubernetes_events_total # L7 policy enforcement (HTTP, DNS, Kafka) - cilium_policy_l7_total # DNS proxy latency histogram — key metric for catching DNS saturation - cilium_proxy_upstream_reply_seconds_bucket # — Hubble metrics — # DNS query and response counts — primary indicator in the demo scenario - hubble_dns_queries_total - hubble_dns_responses_total # Packet drops by reason (policy_denied, invalid, TTL_exceeded, etc.) - hubble_drop_total # Total flows processed — overall network activity volume - hubble_flows_processed_total # HTTP request latency histogram and total count - hubble_http_request_duration_seconds_bucket - hubble_http_requests_total # ICMP traffic tracking - hubble_icmp_total # Policy verdict counts (forwarded vs. dropped by policy) - hubble_policy_verdicts_total # TCP flag tracking (SYN, FIN, RST) — connection lifecycle visibility - hubble_tcp_flags_total # — Tetragon metrics — # Total eBPF events processed - tetragon_events_total # DNS cache health - tetragon_dns_cache_evictions_total - tetragon_dns_cache_misses_total - tetragon_dns_total # HTTP response tracking with latency - tetragon_http_response_total - tetragon_http_stats_latency_bucket - tetragon_http_stats_latency_count - tetragon_http_stats_latency_sum # Layer3 errors - tetragon_layer3_event_errors_total # TCP socket statistics — per-connection RTT, retransmits, byte/segment counts # These power the latency and throughput views in Network Explorer - tetragon_socket_stats_retransmitsegs_total - tetragon_socket_stats_rxsegs_total - tetragon_socket_stats_srtt_count - tetragon_socket_stats_srtt_sum - tetragon_socket_stats_txbytes_total - tetragon_socket_stats_txsegs_total - tetragon_socket_stats_rxbytes_total # UDP statistics - tetragon_socket_stats_udp_retrieve_total - tetragon_socket_stats_udp_txbytes_total - tetragon_socket_stats_udp_txsegs_total - tetragon_socket_stats_udp_rxbytes_total # Network flow events (connect, close, send, receive) - tetragon_network_connect_total - tetragon_network_close_total - tetragon_network_send_total - tetragon_network_receive_total resourcedetection: detectors: [system] system: hostname_sources: [os] service: pipelines: metrics: receivers: - prometheus/isovalent_cilium - prometheus/isovalent_envoy - prometheus/isovalent_operator - prometheus/isovalent_tetragon - hostmetrics - kubeletstats - otlp processors: - filter/includemetrics - resourcedetection autodetect: prometheus: true clusterName: isovalent-demo splunkObservability: accessToken: realm: # e.g. us1, us2, eu0 profilingEnabled: true cloudProvider: aws distribution: eks environment: isovalent-demo # Gateway mode runs a central collector deployment that receives from all agents. # Agents send to the gateway, which handles batching and export to Splunk. # This reduces the number of direct connections to Splunk’s ingest endpoint. gateway: enabled: true resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 1Gi # certmanager handles mTLS between the OTel Collector agent and gateway certmanager: enabled: true 重要: 以下を置き換えてください:
デモスクリプト
このデモで示すことこのデモは、すべての運用チームやプラットフォームチームが経験したことのあるストーリーを語ります。何かが壊れていて、ユーザーが不満を訴えていて、どこから始めればよいかわからない状況です。調査は通常の最初のステップを経由します — APMは問題なさそう、インフラストラクチャも問題なさそう — そしてネットワーク層へとピボットします。そこでIsovalentのHubbleオブザーバビリティがSplunkに流れ込み、本当の問題を明らかにします。それは他のすべてのツールからは完全に見えなかったDNS過負荷です。アプリケーションは jobs-app で、tenant-jobs namespaceで実行されるシミュレートされたマルチサービスの採用プラットフォームです。フロントエンド（recruiter、jobposting）、中央API（coreapi）、バックグラウンドデータパイプライン（Kafka + resumes + loader）、および定期的にインターネットへHTTP呼び出しを行う crawler サービスがあります。このcrawlerがこのストーリーの悪役になります。重要なポイント APMとインフラストラクチャのメトリクスは正常に見えます。根本原因であるDNS過負荷は、アプリケーション層より下に存在するため、SplunkのIsovalent Hubbleダッシュボードを通じてのみ見ることができます。開始前の準備これは誰もいない状態で行ってください。デモが始まるときには、クリーンで正常なダッシュボードの前に座っていたいものです — 人々が見ている中でkubectlをいじっているのではなく。 Jobs App のデプロイまだ行っていない場合は、isovalent-demo-jobs-app リポジトリからjobs-app Helm chartをデプロイします。 helm dependency build . helm upgrade –install jobs-app . –namespace tenant-jobs –create-namespace すべてが実行中であることを確認デモ中に驚かないよう、これらのチェックを実行します。

Cilium のインストール

ステップ 1: Cilium Enterprise の設定

cilium-enterprise-values.yaml という名前のファイルを作成します。<YOUR-EKS-API-SERVER-ENDPOINT> を前のステップで取得したエンドポイントに置き換えてください（https:// プレフィックスは除きます）。

# Enable/disable debug logging
debug:
  enabled: false
  verbose: ~

# Configure unique cluster name & ID
cluster:
  name: isovalent-demo
  id: 0

# Configure ENI specifics
eni:
  enabled: true
  updateEC2AdapterLimitViaAPI: true   # Dynamically fetch ENI limits from EC2 API
  awsEnablePrefixDelegation: true     # Assign /28 CIDR blocks per ENI (16 IPs) instead of individual IPs

enableIPv4Masquerade: false           # Pods use their real VPC IPs — no SNAT needed in ENI mode
loadBalancer:
  serviceTopology: true               # Prefer backends in the same AZ to reduce cross-AZ traffic costs

ipam:
  mode: eni

routingMode: native                   # No overlay tunnels — traffic routes natively through VPC

# BPF / KubeProxyReplacement
# Cilium replaces kube-proxy entirely with eBPF programs in the kernel.
# This requires a direct path to the API server, hence k8sServiceHost.
kubeProxyReplacement: "true"
k8sServiceHost: <YOUR-EKS-API-SERVER-ENDPOINT>
k8sServicePort: 443

# TLS for internal Cilium communication
tls:
  ca:
    certValidityDuration: 3650        # 10 years for the CA cert

# Hubble: network observability built on top of Cilium's eBPF datapath
hubble:
  enabled: true
  metrics:
    enableOpenMetrics: true           # Use OpenMetrics format for better Prometheus compatibility
    enabled:
      # DNS: query/response tracking with namespace-level label context
      - dns:labelsContext=source_namespace,destination_namespace
      # Drop: packet drop reasons (policy deny, invalid, etc.) per namespace
      - drop:labelsContext=source_namespace,destination_namespace
      # TCP: connection state tracking (SYN, FIN, RST) per namespace
      - tcp:labelsContext=source_namespace,destination_namespace
      # Port distribution: which destination ports are being used
      - port-distribution:labelsContext=source_namespace,destination_namespace
      # ICMP: ping/traceroute visibility with workload identity context
      - icmp:labelsContext=source_namespace,destination_namespace;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity
      # Flow: per-workload flow counters (forwarded, dropped, redirected)
      - flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity
      # HTTP L7: request/response metrics with full workload context and exemplars for trace correlation
      - "httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"
      # Policy: network policy verdict tracking (allowed/denied) per workload
      - "policy:sourceContext=app|workload-name|pod|reserved-identity;destinationContext=app|workload-name|pod|dns|reserved-identity;labelsContext=source_namespace,destination_namespace"
      # Flow export: enables Hubble to export flow records to Timescape for historical storage
      - flow_export
    serviceMonitor:
      enabled: true                   # Creates a Prometheus ServiceMonitor for auto-discovery
  tls:
    enabled: true
    auto:
      enabled: true
      method: cronJob                 # Automatically rotate Hubble TLS certs on a schedule
      certValidityDuration: 1095      # 3 years per cert rotation
  relay:
    enabled: true                     # Hubble Relay aggregates flows from all nodes cluster-wide
    tls:
      server:
        enabled: true
    prometheus:
      enabled: true
      serviceMonitor:
        enabled: true
  timescape:
    enabled: true                     # Stores historical flow data for time-travel debugging

# Cilium Operator: cluster-wide identity and endpoint management
operator:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

# Cilium Agent: per-node eBPF datapath metrics
prometheus:
  enabled: true
  serviceMonitor:
    enabled: true

# Cilium Envoy: L7 proxy metrics (HTTP, gRPC)
envoy:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

# Enable the Cilium agent to hand off DNS proxy responsibilities to the
# external DNS Proxy HA deployment, so policies keep working during upgrades
extraConfig:
  external-dns-proxy: "true"

# Enterprise feature gates — these must be explicitly approved
enterprise:
  featureGate:
    approved:
      - DNSProxyHA          # High-availability DNS proxy (installed separately)
      - HubbleTimescape     # Historical flow storage via Timescape

ラベルコンテキストが重要な理由

各Hubbleメトリクスの labelsContext および sourceContext/destinationContext パラメータは、メトリクスをどのディメンションで分割するかを制御します。labelsContext=source_namespace,destination_namespace を設定すると、すべてのメトリクスにこれら2つのラベルが付与され、カーディナリティの爆発を起こすことなくSplunkでnamespaceによるフィルタリングが可能になります。workload-name|reserved-identity のフォールバックチェーンは、利用可能な場合はワークロード名を使用し、利用できない場合はセキュリティIDにフォールバックすることを意味します。

ステップ 2: Cilium Enterprise のインストール

新しいノードがEKSクラスターに参加すると、そのノードのkubeletはすぐにCNIプラグインを探してネットワーキングをセットアップします。/etc/cni/net.d/ に存在するCNI設定を読み取り、それを使用してノードを初期化します。ノードグループを先に作成すると、AWS VPC CNI が最初に到達します — そして一度ノードが特定のCNIで初期化されると、別のCNIに切り替えるにはノードをドレインして再初期化する必要があります。

ノードが存在する前にCiliumをインストールすることで、CiliumのCNI設定が kube-system に既に存在し、ノードが起動した瞬間にピックアップされる準備ができていることを保証します。EC2インスタンスが起動すると、CiliumのDaemonSet Podがすぐにスケジュールされ、eBPFプログラムがロードされ、ノードは最初の瞬間からCiliumの制御下で Ready 状態になります。

これは、EKSセットアップのステップ3でクラスターが disableDefaultAddons: true で作成された理由でもあります — これがないと、AWS VPC CNIが自動的にインストールされ、Ciliumと競合することになります。

Helmを使用してCiliumをインストールします：

helm install cilium isovalent/cilium --version 1.18.4 \
  --namespace kube-system -f cilium-enterprise-values.yaml

Pending状態のジョブは正常です

インストール後、いくつかのジョブがPending状態になっているのが見えます — これは正常です。CiliumのHelmチャートにはHubble用のTLS証明書を生成するジョブが含まれており、そのジョブを実行するにはノードが必要です。次のステップでノードが利用可能になると、自動的に完了します。

ステップ 3: ノードグループの作成

nodegroup.yaml という名前のファイルを作成します：

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: isovalent-demo
  region: us-east-1
managedNodeGroups:
- name: standard
  instanceType: m5.xlarge
  desiredCapacity: 2
  privateNetworking: true

ノードグループを作成します（5〜10分かかります）：

eksctl create nodegroup -f nodegroup.yaml

ステップ 4: Cilium インストールの確認

ノードの準備ができたら、すべてのコンポーネントを確認します：

# Check nodes
kubectl get nodes

# Check Cilium pods
kubectl get pods -n kube-system -l k8s-app=cilium

# Check all Cilium components
kubectl get pods -n kube-system | grep -E "(cilium|hubble)"

期待される出力：

2つのノードが Ready 状態
Cilium Podが実行中（ノードごとに1つ）
Hubble relayとtimescapeが実行中
Cilium operatorが実行中

ステップ 5: 拡張ネットワークオブザーバビリティを備えた Tetragon のインストール

Tetragonはそのままでもランタイムセキュリティとプロセスレベルの可視性を提供します。Splunkとの統合 — 特にNetwork Explorerダッシュボード — には、TCP/UDPソケット統計、RTT、接続イベント、DNSをカーネルレベルで追跡する拡張ネットワークオブザーバビリティモードも有効にする必要があります。

tetragon-network-values.yaml という名前のファイルを作成します：

# Tetragon configuration with Enhanced Network Observability enabled
# Required for Splunk Observability Cloud Network Explorer integration

tetragon:
  # Enable network events — this activates eBPF-based socket tracking
  enableEvents:
    network: true

  # Layer3 settings: track TCP, UDP, and ICMP with RTT and latency
  # These enable the socket stats metrics (srtt, retransmits, bytes, etc.)
  layer3:
    tcp:
      enabled: true
      rtt:
        enabled: true     # Round-trip time per TCP flow
    udp:
      enabled: true
    icmp:
      enabled: true
    latency:
      enabled: true       # Per-connection latency tracking

  # DNS tracking at the kernel level (complements Hubble DNS metrics)
  dns:
    enabled: true

  # Expose Tetragon metrics via Prometheus
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

  # Filter out noise from internal system namespaces — we only care about
  # application workloads, not the observability stack itself
  exportDenyList: |-
    {"health_check":true}
    {"namespace":["", "cilium", "tetragon", "kube-system", "otel-splunk"]}

  # Only include labels that are meaningful for the Network Explorer
  metricsLabelFilter: "namespace,workload,binary"

  resources:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 100m
      memory: 256Mi

# Enable the Tetragon Operator and TracingPolicy support.
# With tracingPolicy.enabled: true, the operator manages and deploys
# TracingPolicies (TCP connection tracking, HTTP visibility, etc.) automatically.
tetragonOperator:
  enabled: true
  tracingPolicy:
    enabled: true

これらの値でTetragonをインストールします：

helm install tetragon isovalent/tetragon --version 1.18.0 \
  --namespace tetragon --create-namespace \
  -f tetragon-network-values.yaml

インストールを確認します：

kubectl get pods -n tetragon

表示される内容： TetragonはDaemonSet（ノードごとに1つのPod）とオペレーターとして実行されます。

拡張ネットワークオブザーバビリティが追加するもの

layer3.tcp.rtt.enabled: true を設定すると、TetragonはカーネルのTCPソケット状態にフックし、ラウンドトリップタイム、再送回数、送受信バイト数、セグメント数を含む接続ごとのメトリクスを記録します。これらはSplunkのNetwork Explorerのレイテンシとスループットビューを動かす tetragon_socket_stats_* メトリクスに供給されます。これがないとイベントカウントのみが取得されますが、これがあると接続品質データが取得できます。

TracingPolicies（TCP接続追跡、HTTP可視性など）は、上記のHelm valuesで tetragonOperator.tracingPolicy.enabled: true が設定されている場合、Tetragon Operatorによって自動的に管理されます。

ステップ 6: Cilium DNS Proxy HA のインストール

cilium-dns-proxy-ha-values.yaml という名前のファイルを作成します：

enableCriticalPriorityClass: true
metrics:
  serviceMonitor:
    enabled: true

DNS Proxy HAをインストールします：

helm upgrade -i cilium-dnsproxy isovalent/cilium-dnsproxy --version 1.16.7 \
  -n kube-system -f cilium-dns-proxy-ha-values.yaml

確認します：

kubectl rollout status -n kube-system ds/cilium-dnsproxy --watch

成功

これでCilium CNI、Hubbleオブザーバビリティ、Tetragonセキュリティを備えた完全に機能するEKSクラスターが完成しました！

Splunk Integration

概要

Splunk OpenTelemetry Collectorは、Prometheusレシーバーを使用してすべてのIsovalentコンポーネントからメトリクスをスクレイプします。各コンポーネントは異なるポートでメトリクスを公開しており、CiliumとHubbleは同じPodを共有しています（ポートが異なるだけです）。そのため、Podアノテーションに依存するのではなく、各コンポーネントに対して個別のレシーバーを設定します。

コンポーネント	ポート	提供する情報
Cilium Agent	9962	eBPF データパス、ポリシー適用、IPAM、BPF マップ統計
Cilium Envoy	9964	L7 プロキシメトリクス（HTTP、gRPC）
Cilium Operator	9963	クラスター全体のアイデンティティとエンドポイント管理
Hubble	9965	ネットワークフロー、DNS、HTTP L7、TCP フラグ、ポリシー判定
Tetragon	2112	ランタイムセキュリティ、ソケット統計、ネットワークフローイベント

ステップ 1: 設定ファイルの作成

splunk-otel-collector-values.yaml という名前のファイルを作成します。認証情報のプレースホルダーを実際の値に置き換えてください。

terminationGracePeriodSeconds: 30
agent:
  config:
    extensions:
      # k8s_observer watches the Kubernetes API for pod and port changes.
      # This enables automatic service discovery without static endpoint lists.
      k8s_observer:
        auth_type: serviceAccount
        observe_pods: true

    receivers:
      kubeletstats:
        collection_interval: 30s
        insecure_skip_verify: true

      # Cilium Agent (port 9962) and Hubble (port 9965) both run in the
      # same DaemonSet pod, identified by label k8s-app=cilium.
      # We use two separate scrape jobs because they're on different ports.
      prometheus/isovalent_cilium:
        config:
          scrape_configs:
            - job_name: 'cilium_metrics_9962'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9962
                - target_label: job
                  replacement: 'cilium_metrics_9962'
            - job_name: 'hubble_metrics_9965'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9965
                - target_label: job
                  replacement: 'hubble_metrics_9965'

      # Cilium Envoy uses a different pod label (k8s-app=cilium-envoy)
      prometheus/isovalent_envoy:
        config:
          scrape_configs:
            - job_name: 'envoy_metrics_9964'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium-envoy
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9964
                - target_label: job
                  replacement: 'cilium_metrics_9964'

      # Cilium Operator is a Deployment (not DaemonSet), identified by io.cilium.app=operator
      prometheus/isovalent_operator:
        config:
          scrape_configs:
            - job_name: 'cilium_operator_metrics_9963'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_io_cilium_app]
                  action: keep
                  regex: operator
                - target_label: job
                  replacement: 'cilium_metrics_9963'

      # Tetragon is identified by app.kubernetes.io/name=tetragon
      prometheus/isovalent_tetragon:
        config:
          scrape_configs:
            - job_name: 'tetragon_metrics_2112'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
                  action: keep
                  regex: tetragon
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:2112
                - target_label: job
                  replacement: 'tetragon_metrics_2112'

    processors:
      # Strict allowlist filter: only forward metrics we've explicitly named.
      # Without this, Cilium and Tetragon can generate thousands of metric series
      # and overwhelm Splunk Observability Cloud with cardinality.
      filter/includemetrics:
        metrics:
          include:
            match_type: strict
            metric_names:
            # --- Kubernetes base metrics ---
            - container.cpu.usage
            - container.memory.rss
            - k8s.container.restarts
            - k8s.pod.phase
            - node_namespace_pod_container
            - tcp.resets
            - tcp.syn_timeouts

            # --- Cilium Agent metrics ---
            # API rate limiting — detect if the agent is being throttled
            - cilium_api_limiter_processed_requests_total
            - cilium_api_limiter_processing_duration_seconds
            # BPF map utilization — alerts when eBPF maps are near capacity
            - cilium_bpf_map_ops_total
            # Controller health — tracks background reconciliation tasks
            - cilium_controllers_group_runs_total
            - cilium_controllers_runs_total
            # Endpoint state — how many pods are in each lifecycle state
            - cilium_endpoint_state
            # Agent error/warning counts — early warning for problems
            - cilium_errors_warnings_total
            # IP address allocation tracking
            - cilium_ip_addresses
            - cilium_ipam_capacity
            # Kubernetes event processing rate
            - cilium_kubernetes_events_total
            # L7 policy enforcement (HTTP, DNS, Kafka)
            - cilium_policy_l7_total
            # DNS proxy latency histogram — key metric for catching DNS saturation
            - cilium_proxy_upstream_reply_seconds_bucket

            # --- Hubble metrics ---
            # DNS query and response counts — primary indicator in the demo scenario
            - hubble_dns_queries_total
            - hubble_dns_responses_total
            # Packet drops by reason (policy_denied, invalid, TTL_exceeded, etc.)
            - hubble_drop_total
            # Total flows processed — overall network activity volume
            - hubble_flows_processed_total
            # HTTP request latency histogram and total count
            - hubble_http_request_duration_seconds_bucket
            - hubble_http_requests_total
            # ICMP traffic tracking
            - hubble_icmp_total
            # Policy verdict counts (forwarded vs. dropped by policy)
            - hubble_policy_verdicts_total
            # TCP flag tracking (SYN, FIN, RST) — connection lifecycle visibility
            - hubble_tcp_flags_total

            # --- Tetragon metrics ---
            # Total eBPF events processed
            - tetragon_events_total
            # DNS cache health
            - tetragon_dns_cache_evictions_total
            - tetragon_dns_cache_misses_total
            - tetragon_dns_total
            # HTTP response tracking with latency
            - tetragon_http_response_total
            - tetragon_http_stats_latency_bucket
            - tetragon_http_stats_latency_count
            - tetragon_http_stats_latency_sum
            # Layer3 errors
            - tetragon_layer3_event_errors_total
            # TCP socket statistics — per-connection RTT, retransmits, byte/segment counts
            # These power the latency and throughput views in Network Explorer
            - tetragon_socket_stats_retransmitsegs_total
            - tetragon_socket_stats_rxsegs_total
            - tetragon_socket_stats_srtt_count
            - tetragon_socket_stats_srtt_sum
            - tetragon_socket_stats_txbytes_total
            - tetragon_socket_stats_txsegs_total
            - tetragon_socket_stats_rxbytes_total
            # UDP statistics
            - tetragon_socket_stats_udp_retrieve_total
            - tetragon_socket_stats_udp_txbytes_total
            - tetragon_socket_stats_udp_txsegs_total
            - tetragon_socket_stats_udp_rxbytes_total
            # Network flow events (connect, close, send, receive)
            - tetragon_network_connect_total
            - tetragon_network_close_total
            - tetragon_network_send_total
            - tetragon_network_receive_total

      resourcedetection:
        detectors: [system]
        system:
          hostname_sources: [os]

    service:
      pipelines:
        metrics:
          receivers:
            - prometheus/isovalent_cilium
            - prometheus/isovalent_envoy
            - prometheus/isovalent_operator
            - prometheus/isovalent_tetragon
            - hostmetrics
            - kubeletstats
            - otlp
          processors:
            - filter/includemetrics
            - resourcedetection

autodetect:
  prometheus: true

clusterName: isovalent-demo

splunkObservability:
  accessToken: <YOUR-SPLUNK-ACCESS-TOKEN>
  realm: <YOUR-SPLUNK-REALM>           # e.g. us1, us2, eu0
  profilingEnabled: true

cloudProvider: aws
distribution: eks
environment: isovalent-demo

# Gateway mode runs a central collector deployment that receives from all agents.
# Agents send to the gateway, which handles batching and export to Splunk.
# This reduces the number of direct connections to Splunk's ingest endpoint.
gateway:
  enabled: true
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 1Gi

# certmanager handles mTLS between the OTel Collector agent and gateway
certmanager:
  enabled: true

重要: 以下を置き換えてください:

<YOUR-SPLUNK-ACCESS-TOKEN> をSplunk Observability Cloudのアクセストークンに
<YOUR-SPLUNK-REALM> をレルム（例: us1、us2、eu0）に

厳格なメトリクス許可リストを使用する理由

Ciliumは、ワークロード、名前空間、プロトコルの詳細に関するすべてのラベルの組み合わせを考慮すると、数千のユニークなメトリクスシリーズを出力する可能性があります。filter/includemetrics 許可リストがないと、負荷の高いクラスターでは50,000以上のアクティブシリーズが簡単に生成され、Splunkのインジェストに過負荷をかける可能性があります。上記のリストは、CiliumとHubbleのダッシュボードを動作させるために必要なメトリクスと、Network Explorerに必要なTetragonソケット統計を正確に含むようにキュレートされています。後で新しいダッシュボードを追加する場合は、このリストにメトリクスを追加できます。

Tetragonソケット統計で可能になること

tetragon_socket_stats_* メトリクスは、SplunkのNetwork Explorerで接続ごとのレイテンシとスループット分析を可能にするものです。srtt_count/srtt_sum は、ワークロードごとの平均TCPラウンドトリップタイムを提供します。retransmitsegs_total は、パケットロスと輻輳を表面化します。txbytes/rxbytes は、接続ごとの帯域幅を示します。これらはAPMや標準のインフラストラクチャメトリクスでは確認できません。

ステップ 2: Splunk OpenTelemetry Collector のインストール

コレクターをインストールします:

helm upgrade --install splunk-otel-collector \
  splunk-otel-collector-chart/splunk-otel-collector \
  -n otel-splunk --create-namespace \
  -f splunk-otel-isovalent.yaml

ロールアウトが完了するまで待ちます:

kubectl rollout status daemonset/splunk-otel-collector-agent -n otel-splunk --timeout=60s

ステップ 3: メトリクス収集の確認

コレクターがメトリクスをスクレイプしていることを確認します:

kubectl logs -n otel-splunk -l app=splunk-otel-collector --tail=100 | grep -i "cilium\|hubble\|tetragon"

各コンポーネントのスクレイプが成功していることを示すログエントリが表示されるはずです。

次のステップ

メトリクスがSplunk Observability Cloudに送信されています！ダッシュボードを確認するには、検証に進んでください。

デモ — Isovalent と Splunk を使用した DNS 問題の調査

このデモで示すこと

このデモは、すべての運用チームやプラットフォームチームが経験したことのあるストーリーを語ります。何かが壊れていて、ユーザーが不満を訴えていて、どこから始めればよいかわからない状況です。調査は通常の最初のステップを経由します — APMは問題なさそう、インフラストラクチャも問題なさそう — そしてネットワーク層へとピボットします。そこでIsovalentのHubbleオブザーバビリティがSplunkに流れ込み、本当の問題を明らかにします。それは他のすべてのツールからは完全に見えなかったDNS過負荷です。

アプリケーションは jobs-app で、tenant-jobs namespaceで実行されるシミュレートされたマルチサービスの採用プラットフォームです。フロントエンド（recruiter、jobposting）、中央API（coreapi）、バックグラウンドデータパイプライン（Kafka + resumes + loader）、および定期的にインターネットへHTTP呼び出しを行う crawler サービスがあります。このcrawlerがこのストーリーの悪役になります。

重要なポイント

APMとインフラストラクチャのメトリクスは正常に見えます。根本原因であるDNS過負荷は、アプリケーション層より下に存在するため、SplunkのIsovalent Hubbleダッシュボードを通じてのみ見ることができます。

開始前の準備

これは誰もいない状態で行ってください。デモが始まるときには、クリーンで正常なダッシュボードの前に座っていたいものです — 人々が見ている中でkubectlをいじっているのではなく。

Jobs App のデプロイ

まだ行っていない場合は、isovalent-demo-jobs-app リポジトリからjobs-app Helm chartをデプロイします。

helm dependency build .
helm upgrade --install jobs-app . --namespace tenant-jobs --create-namespace

すべてが実行中であることを確認

デモ中に驚かないよう、これらのチェックを実行します。

# Confirm your nodes are healthy
kubectl get nodes

# Confirm Cilium and Hubble are running on both nodes
kubectl get pods -n kube-system | grep -E "(cilium|hubble)"

# Confirm the Splunk OTel Collector is running — this is what ships metrics to Splunk
kubectl get pods -n otel-splunk

# Confirm the jobs-app is fully deployed and healthy
kubectl get pods -n tenant-jobs

重要

続行する前に、すべてのPodが Running 状態である必要があります。OTel Collectorが起動していない場合、Splunkにメトリクスが表示されず、デモが成功しません。

アプリを正常なベースラインにリセット

crawlerが穏やかで通常のペースで実行されていることを確認します — 1レプリカ、0.5から5秒ごとにクロール：

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

その後、少なくとも 5 分待ちます。Splunkがクリーンなベースラインを取り込む時間が必要で、これから作成するスパイクが視覚的に明らかになります。これをスキップすると、チャートが明確なストーリーを伝えません。

問題を注入

デモ開始の約5〜10分前（または効果を出すためにデモ中にライブで）、以下を実行します：

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=5 \
  --set crawler.crawlFrequencyLowerBound=0.2 \
  --set crawler.crawlFrequencyUpperBound=0.3 \
  --set resumes.replicas=2

これによりcrawlerが1 Podから5にスケールアップし、クロール間隔が0.2〜0.3秒に短縮されます。各crawler Podは api.github.com にHTTPリクエストを行い、それらのリクエストごとに最初にDNSルックアップが必要です。5つのPodが毎秒複数回DNSを叩くと、約15〜25のDNSクエリが持続的に発生します — DNSプロキシを飽和させ、応答レイテンシを蓄積させるのに十分な量です。DNSに依存するnamespace内の他のサービスが断続的な障害を経験し始めます。これがまさにチケットに記載されている内容です。

Act 1 — チケットが届く

まず状況を描写します。まだ何もクリックする必要はありません — シーンを設定するだけです。

「普通の午後で、ITSM チケットが届きました。jobs アプリケーションチームから、エンドユーザーが recruiter と job posting ページで断続的な 500 エラーを報告していて、過去 15 分ほどでロード時間が明らかに悪化したと言っています。P2 にエスカレートされました。調査しましょう。」


チケット	INC-4072
優先度	P2 — 高
概要	jobs-app での断続的な障害と応答時間の遅延
説明	Recruiter と job posting ページが断続的に 500 エラーを返しています。ユーザーは過去 15 分間でページロードが大幅に遅くなったと報告しています。エンジニアリングは最近のデプロイメントを行っていません。
報告者	アプリケーションサポートチーム
影響を受ける namespace	tenant-jobs

「最近のデプロイメントはない — これが実は興味深い点です。責めるべき明らかな変更イベントがありません。だから自分たちで何が変わったかを把握する必要があります。どこから始めましょう？APM です。」

Act 2 — APM を確認（行き止まり）

ここはほとんどの人が最初に行くところで、それがポイントです。APMを表示し、役に立たないことを見つけ、それを使ってより深いものが必要であるケースを構築します。

移動先： Splunk Observability Cloud → APM → Service Map

tenant-jobs 環境のサービスマップはトポロジーを示します：recruiter と jobposting は両方とも coreapi を呼び出し、coreapiはElasticsearchに接続します。resumes と loader サービスはバックグラウンドでKafkaを介して通信します。

「これがサービスマップです。すべてのサービスが点灯しています — すべて応答していて、すべて接続されています。数字が実際に何を示しているか見てみましょう。
リクエストレートは正常に見えます。レイテンシはわずかに上昇しているかもしれませんが、ユーザー向けのエラーを説明するほどのものではありません。coreapi のエラーレートを見てください — 約 10% です。これが問題だと思うかもしれませんが、そうではありません。このアプリはセットアップの一部として設定可能なエラーレートが組み込まれています。10 パーセントはベースラインであり、リグレッションではありません。
つまり APM が教えてくれるのは：サービスは生きていて、トラフィックは流れていて、エラーレートは変化していないということです。アプリケーショントレースには根本原因を示すものがありません。インフラストラクチャを試してみましょう。」

なぜAPMではこれが見えないのか

APMはアプリケーションコードを計装します — サービス内部で何が起こっているかを観察します。接続が確立される前にネットワーク層で何が起こっているかは見えません。DNS解決、接続の切断、パケットレベルのイベントは、設計上APMからは見えません。

Act 3 — インフラストラクチャを確認（行き止まり）

インフラを表示し、クリーンであることを見つけ、聴衆にまだ答えがないフラストレーションを感じさせます。

移動先： Splunk Observability Cloud → Infrastructure → Kubernetes → Cluster: isovalent-demo

「クラスター自体を見てみましょう。何かリソースが制約されているかもしれません — ノードが高負荷、Pod が OOMKilled されている、そのようなことです。
両方のノードは正常に見えます。CPU とメモリは正常範囲内です。Pod を掘り下げると — すべて Running 状態で、再起動なし、退去もされていません。コンテナ自体もリソース制限に達していません。
これで少し不快な状況になりました。チケットにはユーザーがエラーを見ていると書いてあります。APM はアプリが実行中だと言っています。インフラストラクチャはクラスターが正常だと言っています。これでどうなりますか？
これは実際に非常によくある状況です。アプリケーション層より下、インフラストラクチャ層より下に存在する問題のクラス全体があります — 従来のモニタリングツールでは単純に見えないネットワークレベルで起こっていること。DNS 障害、接続の切断、ポリシー拒否、トラフィックの非対称性。これらはトレースや Pod メトリクスには現れません。ネットワーク自体を観察できるものが必要です。そこで Isovalent の出番です。」

Act 4 — ネットワークが真実を語る

これがデモの核心です。ここはゆっくり時間をかけてください。

移動先： Splunk Observability Cloud → Dashboards → Hubble by Isovalent

「Cilium — 私たちの CNI、すべてのノードで実行されているネットワーキング層 — には Hubble という組み込みのオブザーバビリティコンポーネントがあります。Hubble は eBPF を使用してクラスター内のすべてのネットワークフローをリアルタイムで監視します。サンプリングではなく、近似でもなく — すべての接続、すべての DNS リクエスト、すべてのパケットドロップ。そして OpenTelemetry Collector がそれらの Hubble メトリクスをスクレイプして Splunk に転送するように設定しているので、APM やインフラストラクチャを見ていたのと同じプラットフォームでそれらすべてを見ることができます。
Hubble ダッシュボードを表示しましょう。」

DNS クエリが制御不能

DNS Queries チャートを指し、次に DNS Overview タブに移動します。

「ありました。DNS クエリ量を見てください — 約 15 分前に急激にスパイクしています。このタイムスタンプはチケットが開かれた時間とぴったり一致します。
見ているのは hubble_dns_queries_total で、ソース namespace ごとに分類されています。スパイクは完全に tenant-jobs — アプリケーション namespace から来ています。アプリケーション内の何かが大量の DNS トラフィックを生成し始め、DNS プロキシが追いつくのに苦労し始めました。
しかし右下を見てください — Missing DNS Responses チャートです。これはアラートが発火しているものです。値が深くマイナスになっています。これは DNS クエリが送信されているのに、応答が一度も戻ってこないことを意味します。DNS プロキシが圧倒され、接続は静かにタイムアウトしています。これがユーザーの 500 エラーとして現れている波及効果です。」

トップ DNS クエリが原因を明らかに

Top 10 DNS Queries チャートを指します。

「これらすべての DNS リクエストを行っているものを特定しましょう。Top 10 DNS Queries チャートは最も頻繁にクエリされるドメインを分類しており、1 つの名前が圧倒的に目立っています：api.github.com。
これはクラスター内部のサービスではありません — 外部エンドポイントです。そしてアプリ内で外部エンドポイントと通信するのは crawler サービスだけです。crawler はジョブシミュレーションの一部として外部 URL への HTTP 呼び出しを行います。その HTTP 呼び出しを行うたびに、最初に DNS を通じて api.github.com を解決する必要があります。
通常これは問題ありません。1 つの crawler Pod が数秒ごとにリクエストを行うのは完全に管理可能です。しかし、どれだけ積極的に実行されているかについて何かが明らかに変化しています。」

ドロップされたフローが影響範囲を示す

Dropped Flows チャートを指します。

「Dropped Flows チャートは別の注目すべきことを示しています。Hubble は成功した接続だけを追跡するのではありません — 拒否またはドロップされたすべての接続と、その理由コードをキャプチャします。DNS スパイクと全く同じ時間にドロップの増加が見られます。
これらのドロップは DNS 過負荷の下流の結果です。namespace 内のサービスが接続を試み、DNS が遅すぎるか失敗すると、それらの接続試行はタイムアウトしてドロップされます。これが APM がレイテンシの上昇として見ていたものです — しかし APM にはその下に DNS 問題があることは全くわかりませんでした。」

ネットワークフロー量がパターンを確認

Metrics & Monitoring タブに移動します。

「そして Metrics & Monitoring タブを見ると、全体像がさらに明確になります。ノードごとの処理フロー数が垂直に上昇しています — これは生のネットワークトラフィック量です。Forwarded vs Dropped チャートは、それらのフローのかなりの割合が転送されずにドロップされていることを示しています。そして Drop Reason の内訳は、TTL_EXCEEDED と DROP_REASON_UNKNOWN の混合であることを教えてくれます — DNS タイムアウトがカスケードし始めたときにまさに予想されるものです。特定の時点で何かが変わり、その時点以降のすべてがベースラインとは異なって見えます。」

L7 HTTP トラフィックが興味深いストーリーを語る

L7 HTTP Metrics タブに移動します。

「L7 HTTP Metrics タブで指摘する価値のあることがあります。これは実際に APM が役に立たなかった理由を補強するからです。受信リクエスト量はゼロではありません — トラフィックはまだ流れています。成功率チャートはほとんど緑に見えます。HTTP レベルの可視性だけを見ていた場合、アプリは問題ないと結論づけるかもしれません。
しかし Incoming Requests by Source チャートを見てください。crawler が不釣り合いなシェアのトラフィックを生成しています — 他のサービスから分離しているのが見えます。HTTP 呼び出しを成功させているので、APM はフラグを立てません。問題は 1 つ下の層、DNS で、HTTP 接続が確立される前に起こっています。」

Act 5 — 根本原因の確認

ここで点と点をつなぎ、証明します。

「これが全体像です：ある時点で、crawler サービスが 1 レプリカから 5 にスケールアップされ、クロール間隔が非常に積極的に設定されました — 0.2 から 0.3 秒ごと。これは 5 つの Pod が、それぞれ api.github.com を解決するために DNS ルックアップを毎秒複数回発火させています。合計すると、毎秒 15 から 25 の DNS クエリが持続的に発生します。DNS プロキシは単一のワークロードからそのような負荷を処理するようには作られていないので、キューイング、スローダウン、そして最終的にはリクエストのドロップを開始します。DNS 解決を必要とする namespace 内の他のすべてのサービスが巻き添えを食います。
それが何を見ているか確認しましょう。」

# Confirm the current crawler replica count — you'll see 5
kubectl get deploy crawler -n tenant-jobs

# Pull the environment config to see the crawl frequency settings
kubectl get deploy crawler -n tenant-jobs \
  -o jsonpath='{.spec.template.spec.containers[0].env}' | jq .

オプションとして、Cilium by Isovalent dashboard → Policy: L7 Proxy タブに切り替えます。

「Hubble 側ではなく Cilium 側からこれを見たい場合は、Cilium by Isovalent dashboard に切り替えて Policy: L7 Proxy タブを見てください。FQDN の L7 Request Processing Rate — これが DNS です — が 21,000 リクエストを超えています。これは分あたりではありません。DNS プロキシは非常に大量の FQDN ルックアップを処理しており、すべて受信されて転送されているため、バックアップし始めました。このビューは DNS Proxy Upstream Reply レイテンシも表示しており、プロキシが圧力下にあることを確認できます。」

「ありました。5 レプリカ、0.2 から 0.3 秒ごとにクロール。
APM ではこれが見えません。コードを計装しているのであって、DNS ではないからです。インフラストラクチャモニタリングでもこれは見えません。Pod は正常です — 設定されたとおりに正確に動作しています。これをキャッチできる唯一のツールは、eBPF レベルで動作し、すべてのパケット、すべての DNS リクエスト、すべての接続試行をリアルタイムで監視するものです。それが Hubble です。そして Splunk に接続しているので、他のすべてに使用しているのと同じダッシュボードでキャッチしました。」

Act 6 — ライブで修正

この部分は満足感があります。チャートがリアルタイムで回復するのを見ることができるからです。

「修正は簡単です — crawler をスケールダウンして、通常のクロール間隔を復元します。」

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

Hubble by Isovalent ダッシュボードに戻り、1分ほど待ちます。

「DNS Queries チャートを見てください — ほぼ即座に下がってくるのが見えます。1〜2 分以内にベースラインに戻ります。ドロップされたフローはゼロになります。ネットワークフロー量は通常に戻ります。
そして今 APM に戻ると、レイテンシが正常化し、エラーレートが予想される 10% のベースラインに落ち着くのが見えるでしょう。
チケットをクローズできます。根本原因：crawler の設定ミスによる DNS 飽和。解決策：Helm を使用して crawler のレプリカ数とクロール間隔を元に戻す。解決までの時間：チケットが開かれてから約 15 分。」

修復完了

DNSクエリレートがベースラインに戻り、ドロップされたフローがクリアされ、アプリケーションの健全性が回復します — すべてHubbleダッシュボードでライブで確認できます。

Act 7 — これが実際に意味すること

ズームアウトして、価値のステートメントを具体的に感じさせて終わります。

「ここで何が起こったか考えてみましょう。本番スタイルの本当の問題がありました — エンドユーザーにとって何かが壊れていて — 標準的なプレイブックを経由しました。APM は何も問題ないと言いました。インフラストラクチャも何も問題ないと言いました。Hubble がなければ、次のステップはおそらく戦争部屋の通話、ログを見つめる人々、namespace 全体の再起動を期待して行うことだったでしょう。
代わりに、Hubble ダッシュボードを開いた瞬間から 3 分以内に見つけました。私たちが賢いからではなく、正しい層への可視性があったからです。
これが機能する理由は eBPF です。Cilium の Hubble コンポーネントは Linux カーネルにフックし、ソースでネットワークイベントを観察します — アプリケーションコードに到達する前に、Pod ログに現れる前に、APM のトレースになる前に。そして OpenTelemetry Collector を通じてそれらのメトリクスを Splunk に送信することで、APM データやインフラストラクチャデータと同じプラットフォームに並んでいます。ツールを切り替えたり、5 つの異なるダッシュボード間でコンテキストスイッチする必要はありません。以前なかった可視性の層を追加し、チームがすでに知っているワークフローに保持します。
これがストーリーです。ネットワークオブザーバビリティはニッチなニーズではありません — APM とインフラストラクチャモニタリングが残すギャップです。Isovalent がそのギャップを埋め、Splunk でそれを見ることができます。」

クイックリファレンス

問題を注入（デモの約10分前に実行）：

helm upgrade jobs-app . -n tenant-jobs --reuse-values \
  --set crawler.replicas=5 \
  --set crawler.crawlFrequencyLowerBound=0.2 \
  --set crawler.crawlFrequencyUpperBound=0.3 \
  --set resumes.replicas=2

修復（Act 6でライブ実行）：

helm upgrade jobs-app . -n tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

設定ミスを確認：

kubectl get deploy crawler -n tenant-jobs
kubectl get deploy crawler -n tenant-jobs \
  -o jsonpath='{.spec.template.spec.containers[0].env}' | jq .

Splunk ナビゲーションパス： APM → Service Map → （クリーンであることを表示） → Infrastructure → Kubernetes → （クリーンであることを表示） → Dashboards → Hubble by Isovalent → （DNS スパイクを表示）

タイミングガイド

セクション	概算時間
Act 1 — チケット	約 1 分
Act 2 — APM（行き止まり）	約 2〜3 分
Act 3 — インフラストラクチャ（行き止まり）	約 1〜2 分
Act 4 — Hubble ダッシュボード	約 4〜5 分
Act 5 — 根本原因の確認	約 2 分
Act 6 — ライブで修正	約 2 分
Act 7 — 価値のまとめ	約 2 分
合計	約 14〜17 分

Splunk Observability Workshops

Splunk Observabilityワークショップへようこそ

Splunk Observability Workshopsのサブセクション

Splunk4Rookies ワークショップ

Splunk4Rookies ワークショップのサブセクション

Observability Cloud

Observability Cloudのサブセクション

ワークショップ概要

OpenTelemetryとは何か、なぜ重要なのか？

OpenTelemetry

なぜ重要なのか？

UI - クイックツアー 🚌

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

はじめに

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

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

ホームページ

Real User Monitoring概要

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

Real User Monitoring ホームページ

Application Performance Monitoring概要

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

Application Performance Monitoring ホームページ

Log Observer概要

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

Log Observerホームページ

Synthetics概要

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

Syntheticsホームページ

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

ショッピングに行きましょう 💶

Splunk RUM

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

1. RUMダッシュボード

2. Tag Spotlight

3. セッションリプレイ

4. ユーザーセッション

Splunk APM

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

1. APM探索

2. APMサービスビュー

3. APM Tag Spotlight

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

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

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

Splunk Log Observer

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

1. ログフィルタリング

2. ログエントリの表示

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

4. ログビューチャート

Splunk Synthetics

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

1. Syntheticsダッシュボード

2. Syntheticsテスト詳細

3. SyntheticsからAPMへ

4. Synthetics Detector

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

9. サービスヘルスダッシュボードのサブセクション

ダッシュボードの強化

カスタムチャートの追加

ワークショップ まとめ 🎁

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

主要なポイント

Splunk4Ninjas Workshops

Splunk4Ninjas Workshopsのサブセクション

自動ディスカバリーワークショップ

自動ディスカバリーワークショップのサブセクション

PetClinic モノリスワークショップ

PetClinic モノリスワークショップのサブセクション

OpenTelemetry Collector のインストール

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

3. Real User Monitoring

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

4. Log Observer

Kubernetes 上の Spring PetClinic SpringBoot ベースのマイクロサービス

PetClinic Kubernetes ワークショップのサブセクション

アーキテクチャ

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

2. 準備のサブセクション

ワークショップまとめ 🎁

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