Splunk Observability Cloudの関連コンテンツ 🔗
「関連コンテンツ」パネルは、Splunk Observability Cloud内の異なるビュー間のデータを自動的に関連付け、表示します。APMなどのSplunk Observability Cloud内の1つのビューに、「関連コンテンツ」バーが表示され、他のビュー内の関連コンテンツにリンクされます。
Splunk Cloud Platformにも「関連コンテンツ」パネルがあり、ユーザーは、検索アプリの検索結果と相互関係を持つオブザーバビリティデータのプレビューを見ることができます。詳細については、「 Splunk Observability Cloudのデータのプレビュー 」を参照してください。
関連コンテンツを使用する 🔗
関連コンテンツバーでタイルを選択すると、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のサービス、トレース、スパンを関連リソースにリンクする を参照してください。
APMの関連ログ 🔗
Splunk APMはデフォルトで関連ログを関連コンテンツバーに表示します。リソースを節約するために、統合IDおよびLog Observer Connectのお客様は、Splunk APMで関連ログの表示を無効にすることができます。APMでログの関連コンテンツを非アクティブにするには、管理者は 設定 にアクセスし、一般設定 を選択して、ログの関連コンテンツを非アクティブにする にスイッチを切り替える必要があります。
APMでログの関連コンテンツを再び表示したい場合は、設定 を選択し、一般設定 を選択して、ログの関連コンテンツを有効にする にスイッチを切り替えます。
関連コンテンツはどこで見ることができますか? 🔗
次の表では、Splunk Observability Cloud のいつ、どこで関連コンテンツを見ることができるかを説明します:
開始点 |
可能な宛先 |
---|---|
APMサービス |
サービス、AWS EC2、GCP GCE、Azure VM、サービスのすべてのログ行でフィルタリングされた関連Kubernetesクラスタ |
データベースサービス |
関連するデータベース・ホストまたはインスタンス |
データベースインスタンス |
関連データベース・クエリ・パフォーマンス、関連APMサービス |
ホストまたはクラウドコンピュートインスタンス(AWS EC2、GCP GCE、Azure VM) |
関連するAPMサービス、特定のインスタンスのログ行 |
Kubernetesクラスタ、ノード、ポッド、コンテナ |
ノードの関連ログ行 |
Kubernetesポッドまたはコンテナ |
そのポッドまたはコンテナの関連APMサービス、そのポッドまたはコンテナのログ行 |
特定のログライン |
関連APMサービス、トレース、Kubernetesノード/ポッド/コンテナ、ホストまたはコンピュートインスタンス(AWS EC2、GCP GCE、Azure VM) |
特定のトレースID |
関連ログ行 |
Splunk Distribution of the OpenTelemetry Collector を使用して関連コンテンツを有効にする 🔗
Splunk Observability Cloud は OpenTelemetry を使用してテレメトリタイプを相関させます。そのためには、テレメトリフィールド名またはメタデータキー名が、OpenTelemetry と Splunk Observability Cloud の両方で使用されるメタデータキー名と完全に一致している必要があります。
Splunk Distribution of the OpenTelemetry Collector をデフォルト設定でデプロイしてテレメトリデータを Splunk Observability Cloud に送信すると、関連コンテンツがすぐに機能します。デフォルトの設定では、Collectorはメタデータキー名を自動的に正しくマッピングします。Collectorの詳細については、Splunk Distribution of the OpenTelemetry Collector の利用開始 を参照してください。
注意
Splunk Distribution of OpenTelemetry Collectorを使用していない場合、またはデフォルト以外の設定を使用している場合、またはSplunk OpenTelemetry以外を使用している場合、テレメトリデータのメタデータキー名が Splunk Observability Cloud および OpenTelemetry で使用されているものと一致しておらず、関連コンテンツが機能しない可能性があります。
関連コンテンツで問題が発生している場合は、メタデータのキー名を確認し、必要に応じて更新してください。
APMを有効にする Collector の設定関連コンテンツ 🔗
APM サービスのダッシュボードには、基盤となるインフラストラクチャの健全性を示すチャートが含まれています。Splunk Distribution of the OpenTelemetry Collector のデフォルト設定では、自動的にこの設定が行われますが、カスタム設定を使用している場合は、InfraおよびAPMの関連コンテンツを有効にするために Collector を設定する をお読みください。
メタデータの互換性の例 🔗
例えば、Splunk Observability Cloudが次のようなテレメトリデータを受信したとします:
Splunk APM は、メタデータキー
trace_id:2b78e7c951497655
を持つトレースを受信します。Splunk Log Observer は、メタデータキー
trace.id:2b78e7c951497655
を持つログを受信します。
これらは同じトレース ID 値を参照していますが、trace_id
と trace.id
というフィールド名が一致しないため、Splunk Observability Cloud ではログとトレースを関連付けることができません。
これを解決するには、ログパイプライン管理のフィールドコピープロセッサーを使用して、ログのメタデータキー trace.id
の名前を trace_id
に変更します。または、メタデータキー名を揃えるために、ログコレクションを再測定することもできます。
APM と Log Observer のフィールド名が一致すると、同じトレース ID 値を持つトレースとログを Splunk Observability Cloud で関連付けることができます。その後、APM でトレースを表示しているときに、同じトレース ID 値を持つログを直接選択し、Log Observer で関連付けられたログを表示できます。
必要な Collector コンポーネント 🔗
Splunk Distribution of OpenTelemetry Collector、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.name
trace_id
オプションで、deployment.environment
を service.name
と使うこともできます。
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 🔗
IM の関連コンテンツを有効にするには、以下のメタデータの組み合わせのいずれかを使用します:
host.name
。host
、aws_private_dns_name
(AWS)、instance_name
(GCP)、azure_computer_name
(Azure)にフォールバックします。k8s.cluster.name
k8s.cluster.name
+k8s.node.name
k8s.cluster.name
+k8s.node.name
(オプション) +k8s.pod.name
k8s.cluster.name
+k8s.node.name
(オプション) +k8s.pod.name
(オプション) +container.id
service.name
service.name
+deployment.environment
(オプション) +k8s.cluster.name
(オプション)
Splunk Distribution of the OpenTelemetry Collector のデフォルト設定を使用している場合、必要な Infrastructure Monitoring メタデータが提供されます。詳しくは Helmを使用してCollector for Kubernetesをインストールする を参照してください。
OpenTelemetry Collector の他のディストリビューションや、Splunk ディストリビューションのデフォルト以外の設定を使用してインフラストラクチャデータを収集している場合、関連コンテンツはそのままでは動作しません。
Splunk ログ 🔗
ログの関連コンテンツを有効にするには、以下のフィールドのいずれかを使用します:
host.name
service.name
span_id
trace_id
Log ObserverとRelated Contentの両方が完全に機能するように、ログイベントフィールドが正しくマッピングされていることを確認してください。正しいログフィールドマッピングは、組み込みのログフィルタリングを可能にし、APMと Infrastructure Monitoring 機能にログを埋め込み、関連コンテンツバーと同様に高速検索を可能にします。
前のリストのキー名がログのフィールドで異なる名前を使用している場合、それらをここにリストされたキー名に再マップしてください。例えば、host.name の値が Log Observer UI に表示されない場合、host_name のような異なるフィールド名を使用していないか確認してください。ログに前述のリストに表示されているようなデフォルトのフィールド名が含まれていない場合は、次のセクションのいずれかの方法を使用してログを再マップしてください。
注釈
Splunk Observability Cloud の Splunk Log Observer エンタイトルメントをお持ちのお客様は、2023年12月までに Log Observer から Log Observer Connect に移行する必要があります。Log Observer Connect を使用すると、より多様なデータソースからより多くのログをインジェストし、より高度なログパイプラインを利用し、セキュリティロギングに拡張できます。その方法については、Splunk プラットフォームでログのパイプラインを完成する を参照してください。
Kubernetesのログフィールド 🔗
Splunk Distribution of the OpenTelemetry Collector は、以下のフィールドを Kubernetes ログに注入します。関連コンテンツを使用する場合は、これらを変更しないでください。
k8s.cluster.name
k8s.node.name
k8s.pod.name
container.id
k8s.namespace.name
kubernetes.workload.name
これらのタグの組み合わせを使用して、以下の関連コンテンツを有効にします:
k8s.cluster.name
+k8s.node.name
k8s.cluster.name
+k8s.node.name
(オプション) +k8s.pod.name
k8s.cluster.name
+k8s.node.name
(オプション) +k8s.pod.name
(オプション) +container.id
Collector for Kubernetesの詳細については、Collector for Kubernetesを使い始める を参照してください。
ログフィールドの再マップ 🔗
以下の表は、ログフィールドを再マッピングする4つの方法について説明しています。
再マッピング方法 |
手順 |
---|---|
ログフィールドのエイリアシング |
フィールドエイリアスを作成し、有効にします。方法は フィールドエイリアスの作成 を参照してください。次のセクションでは、ログフィールドのエイリアシングを使用するタイミングについて説明します。 |
クライアント側 |
必要なフィールドを再マップするようにアプリを設定します。 |
ログフィールドのエイリアシングの使用時期 🔗
以下のいずれかに該当するため、コピープロセッサーを作成できない、または作成したくない場合は、ログフィールドのエイリアシングを使用してSplunk Observability Cloudのフィールドを再マッピングします。
ログデータの取得に Log Observer Connect を使用しており、Log Observer Pipeline Management にアクセスできません。
追加のログ処理ルールを作成することで、インデックス作成容量を使用したくありません。
インデックス時にデータを変換したくありません。
新しいエイリアスは、エイリアスを作成する前の時点から入ってきたものであっても、すべてのログメッセージに影響するようにしたいと思います。
メタデータのキー名を変更する方法 🔗
メトリクス名とトレース名の変更 🔗
Splunk Distribution of the OpenTelemetry Collectorを使用して、メトリクスとトレースにSplunk Observability CloudのRelated Content機能を使用するために必要なメタデータキー名が含まれていることを確認します。Collectorを使用せず、メトリクスやトレースに必要なメタデータキー名が含まれていない場合は、アプリケーションやサーバーレス関数にそれらを含めるようにインストルメンテーションを行うことができます。方法については、次のページを参照してください:
ログ名を変更する 🔗
必要なキー名がログフィールドで異なる名前を使用している場合は、ログフィールドの再マップ に記載されている方法のいずれかを使用して、それらを再マッピングします。
このページは 2025年02月04日 に最終更新されました。