Splunk Observability Workshops

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

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

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

OpenTelemetry

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

GitHub

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

Twitter

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

Pet Clinic Java ワークショップ

JavaアプリケーションをつかったSplunk Oservabilityのワークショップです

OpenTelemetry Collector

OpenTelemetry Collectorのコンセプトを学び、Splunk Observability Cloudにデータを送信する方法を理解しましょう。

よくある質問とその回答

オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。

ディメンション、プロパティ、タグ

ディメンションとプロパティの比較で、どちらかを使うべきかというのはよく議論されます。

OpenTelemetryでのタグ付け

大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、規則が遵守されるようにガバナンスプロセスを確立することが重要です。

Splunk4Rookies ワークショップ

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

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

Ninja Workshops

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でのタグ付け

よくある質問とその回答

オブザーバビリティ、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 コレクター内で動作するプロセッサーを通じて自動的に収集される方法について説明しました。

最後に、リソースセマンティック規約が組織のニーズに十分でない場合に、属性名を作成するためのベストプラクティスを共有しました。

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. ワークショップ まとめのサブセクション

主要なポイント

Ninja Workshops

Ninja Workshopsのサブセクション

Pet Clinic Java ワークショップ

Pet Clinic Java ワークショップのサブセクション

OpenTelemetry Collectorをインストールする

1. はじめに

2. 環境変数を設定する

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

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

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

マニュアル計装

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

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

Real User Monitoring

1. RUMを有効にする

2. PetClinicを再ビルドする

ワークショップまとめ 🎁

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