Splunk Observability Cloudの関連コンテンツ 🔗
関連コンテンツパネルは、Splunk Observability Cloud 内の異なるビュー間のデータを自動的に関連付け、表示します。Splunk Cloud Platform にも関連コンテンツパネルがあり、ユーザーは検索アプリの検索結果に相関する観測可能性データのプレビューを見ることができます。詳細については、Preview Splunk Observability Cloud data を参照してください。
関連コンテンツを使用する 🔗
関連コンテンツバーでタイルを選択すると、Splunk Observability Cloud のあるビューから別のビューへシームレスに移動できます。次のアニメーションは、ユーザーが APM から Infrastructure Monitoring、Log Observer へと移動する様子を示しています。
先の例では、ユーザーは以下の順序でナビゲートします。
ユーザーはAPMでサービス依存マップを探索することから始めます。エラー率が高いので、Frontend サービスを選択します。
画面下部のRelated Contentバーで、ユーザーは関連するEC2インスタンスを示すInfrastructureタイルを確認し、それを選択します。結果はコンポーネントごとにグループ化されます。たとえば、インフラストラクチャ、ログ、APM。タイルの上にカーソルを置くと、表示する関連コンテンツの結果があるかどうかが示されます。
Splunk Observability Cloudは、ユーザーをインフラストラクチャに導き、CPU使用率が最も高い最初のEC2インスタンスを選択させます。
関連コンテンツバーに、EC2インスタンスに関連するログを表示するタイルがあるので、ユーザーはそれをクリックします。
Splunk Observability Cloud は、ユーザーを Log Observer に導き、そこで関連ログをドリルダウンして問題の根本原因を見つけることができます。
注釈
関連コンテンツは、データリンクとは別の機能であり、閲覧しているプロパティに関するコンテキスト情報をリソースに動的に転送し、関連情報にすばやくアクセスできるようにするものです。データリンクの詳細については、APMのサービス、トレース、スパンを関連リソースにリンクする を参照してください。
必要な Collector コンポーネント 🔗
Splunk Distribution of OpenTelemetry Collector、Collector の別のディストリビューション、または アップストリームコレクター を使用していて、Splunk Observability Cloud の関連コンテンツが正しく動作するようにしたい場合は、SignalFx エクスポーターが設定に含まれていることを確認してください。このエクスポーターは hostmetrics レシーバーからのメトリクスを集約し、metrics および traces パイプラインで有効にする必要があります。
Collectorは、SignalFxエクスポーターの相関フラグを使用して、関連するAPIコールを行い、スパンとインフラストラクチャ・メトリクスを相関させます。このフラグはデフォルトで有効になっています。相関オプションをさらに調整するには、SignalFx エクスポーターのオプション 設定 を参照してください。
必須メタデータフィールド 🔗
関連コンテンツは、APM、Infrastructure Monitoring、Log Observer が Splunk Observability Cloud にフィルタを渡すための特定のメタデータに依存しています。
以下のセクションは、Splunk Observability Cloud の各ビューで関連コンテンツを有効にするために必要なメタデータキー名の一覧です。データにここに記載されているフィールド名がない場合、Splunk Observability Cloud は関連データを関連付けることができません。
Splunk APM 🔗
関連コンテンツを有効にするには、以下のAPMスパンタグが必要です。
service.namedeployment.environment
Splunk Distribution of the OpenTelemetry Collector のデフォルト設定では、これらのスパンタグがすでに提供されています。関連コンテンツの完全な機能を確保するため、Splunk OTel Collector が提供するメタデータキー名やスパンタグは変更しないでください。
詳細：
Splunk APM のスパンタグについては、Splunk APMでサービス、スパン、トレースを管理する を参照してください。
Splunk APM のデプロイ環境については、Splunk APMでデプロイ環境を設定する を参照してください。
APM とポッド固有の Kubernetes データのための関連コンテンツの活用 🔗
APMの関連コンテンツタイルが特定のKubernetesポッド( k8s.pod.name )のデータにリンクするには、まず特定のKubernetesクラスタ( k8s.cluster.name )でフィルタリングする必要があります。Kubernetesポッド名はクラスタ間で一意である必要はないため、APMは両方の値がない場合、Infrastructure Monitoringの正確なRelated Content Kubernetesポッドデスティネーションを保証できません。
例えば、Related Contentが Pod-B という名前のKubernetesポッドのデータを返す必要があるシナリオを考えてみましょう。以下の図に示すように、Kubernetesの実装では、同じ名前の複数のポッドを持つことができます。Related Contentが正しい Pod-B のデータを返すには、ポッドが存在するKubernetesクラスタの名前も提供する必要があります。この場合、その名前は Cluster-West または Cluster-East のいずれかになります。クラスタ名とポッド名でフィルタリングするこの組み合わせは、Infrastructure MonitoringでRelated Contentが正しいポッドデータにリンクするために必要な一意の組み合わせを作成します。
Splunk Infrastructure Monitoring 🔗
関連コンテンツを有効にするには、以下のInfrastructure Monitoringメタデータキーが必要です。
host.namek8s.cluster.namek8s.node.namek8s.pod.namecontainer.idk8s.namespace.namekubernetes.workload.name
Splunk Distribution of the OpenTelemetry Collector のデフォルト設定を使用している場合、必要な Infrastructure Monitoring メタデータが提供されます。詳しくは Install the Collector for Kubernetes using Helm を参照してください。
OpenTelemetry Collector の他のディストリビューションや、Splunk ディストリビューションのデフォルト以外の設定を使用してインフラストラクチャデータを収集している場合、関連コンテンツはそのままでは動作しません。
Splunk Log Observer 🔗
注釈
Splunk Observability Cloud の Splunk Log Observer エンタイトルメントをお持ちのお客様は、2023年12月までに Log Observer から Log Observer Connect に移行する必要があります。Log Observer Connect を使用すると、より多様なデータソースからより多くのログをインジェストし、より高度なログパイプラインを利用し、セキュリティロギングに拡張できます。その方法については、Splunk Log Observer の移行 を参照してください。
Log Observerの関連コンテンツを有効にするには、以下のキー名が必要です。
service.namedeployment.environmenthost.nametrace_idspan_id
Log ObserverとRelated Contentの両方が完全に機能するように、ログイベントフィールドが正しくマッピングされていることを確認してください。正しいログフィールドマッピングは、組み込みのログフィルタリングを可能にし、APMと Infrastructure Monitoring 機能にログを埋め込み、関連コンテンツバーと同様に高速検索を可能にします。
前のリストのキー名がログのフィールドで異なる名前を使用している場合、それらをここにリストされたキー名に再マップしてください。例えば、host.name の値がLog Observer UIに表示されない場合、host_name のような異なるフィールド名を使用していないか確認してください。ログに前述のリストに表示されているようなデフォルトのフィールド名が含まれていない場合は、次のセクションのいずれかの方法を使用してログを再マップしてください。
ログフィールドの再マップ 🔗
以下の表は、ログフィールドを再マッピングする4つの方法について説明しています。
再マッピング方法 |
手順 |
|---|---|
Splunk Observability クラウドログのパイプライン管理 |
フィールドコピープロセッサを作成し、適用します。方法については、ログ処理ルールでデータを変換する の フィールドコピープロセッサ セクションを参照してください。注: Splunk Observability Cloud の Splunk Log Observer エンタイトルメントを持つお客様のみがこの方法を使用できます。Log Observer Connect を使用している場合は、この表の他の方法のいずれかを使用してください。 |
ログフィールドのエイリアシング |
フィールドエイリアスを作成し、有効にします。方法は フィールドエイリアスの作成 を参照してください。次のセクションでは、ログフィールドのエイリアシングを使用するタイミングについて説明します。 |
クライアント側 |
必要なフィールドを再マップするようにアプリを設定します。 |
Collector側 |
Fluentd か FluentBit の設定を使います。ログを送るために Fluentd を設定する を見てください。 |
ログフィールドのエイリアシングの使用時期 🔗
Use Log Field Aliasing to remap fields in Splunk Observability Cloud when you cannot or do not want to create a copy processor because any of the following are true:
ログデータの取得に Log Observer Connect を使用しており、Log Observer Pipeline Management にアクセスできません。
追加のログ処理ルールを作成することで、インデックス作成容量を使用したくありません。
インデックス時にデータを変換したくありません。
新しいエイリアスは、エイリアスを作成する前の時点から入ってきたものであっても、すべてのログメッセージに影響するようにしたいと思います。
Kubernetesのログフィールド 🔗
Splunk Distribution of the OpenTelemetry Collector は、以下のフィールドを Kubernetes ログに注入します。関連コンテンツを使用する場合は、これらを変更しないでください。
k8s.cluster.namek8s.node.namek8s.pod.namecontainer.idk8s.namespace.namekubernetes.workload.name
Collector for Kubernetesの詳細については、Collector for Kubernetesを使い始める を参照してください。
メタデータのキー名を変更する方法 🔗
メトリクス名とトレース名の変更 🔗
Use the Splunk Distribution of the OpenTelemetry Collector to ensure that your metrics and traces have the metadata key names required to use Splunk Observability Cloud’s Related Content feature. If you did not use the Collector and your metrics or traces do not include the required metadata key names, you can instrument your applications and serverless functions to include them. See the following pages to learn how:
ログ名を変更する 🔗
必要なキー名がログフィールドで異なる名前を使用している場合は、ログフィールドの再マップ に記載されている方法のいずれかを使用して、それらを再マッピングします。