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のサービス、トレース、スパンを関連リソースにリンクする を参照してください。
関連コンテンツはどこで見ることができますか? 🔗
次の表では、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 の両方で使用されるメタデータキー名と完全に一致している必要があります。
Related Content works out-of-the-box when you deploy the Splunk Distribution of the OpenTelemetry Collector with its default configuration to send your telemetry data to Splunk Observability Cloud. With the default configuration the Collector automatically maps your metadata key names correctly. To learn more about the Collector, see Splunk Distribution of the OpenTelemetry Collector の利用開始.
注意
If you don’t use the Splunk Distribution of OpenTelemetry Collector, or you use a non-default configuration, or you use non-Splunk OpenTelemetry, your telemetry data might have metadata key names that are not consistent with those used by Splunk Observability Cloud and OpenTelemetry, and Related Content might not work.
If you’re experiencing issues with Related Content, verify your metadata key names, and update them if necessary.
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 コンポーネント 🔗
If you’re using the Splunk Distribution of the OpenTelemetry Collector, another distribution of the Collector, or the upstream Collector and want to ensure Related Content in Splunk Observability Cloud behaves correctly, verify that the SignalFx exporter is included in your configuration. This exporter aggregates the metrics from the hostmetrics
receiver and must be enabled for the metrics
and traces
pipelines.
Collectorは、SignalFxエクスポーターの相関フラグを使用して、関連するAPIコールを行い、スパンとインフラストラクチャ・メトリクスを相関させます。このフラグはデフォルトで有効になっています。相関オプションをさらに調整するには、SignalFx エクスポーターのオプション 設定 を参照してください。
必須メタデータフィールド 🔗
関連コンテンツは、APM、Infrastructure Monitoring、Log Observer が Splunk Observability Cloud にフィルタを渡すための特定のメタデータに依存しています。
以下のセクションは、Splunk Observability Cloud の各ビューで関連コンテンツを有効にするために必要なメタデータキー名の一覧です。データにここに記載されているフィールド名がない場合、Splunk Observability Cloud は関連データを関連付けることができません。
Splunk APM 🔗
関連コンテンツを有効にするには、以下のAPMスパンタグが必要です。
service.name
deployment.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.name
k8s.cluster.name
k8s.node.name
k8s.pod.name
container.id
k8s.namespace.name
kubernetes.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 を使用すると、より多様なデータソースからより多くのログをインジェストし、より高度なログパイプラインを利用し、セキュリティロギングに拡張できます。その方法については、Accomplish logs pipeline rules in Splunk platform を参照してください。
Log Observerの関連コンテンツを有効にするには、以下のキー名が必要です。
service.name
deployment.environment
host.name
trace_id
span_id
Log ObserverとRelated Contentの両方が完全に機能するように、ログイベントフィールドが正しくマッピングされていることを確認してください。正しいログフィールドマッピングは、組み込みのログフィルタリングを可能にし、APMと Infrastructure Monitoring 機能にログを埋め込み、関連コンテンツバーと同様に高速検索を可能にします。
前のリストのキー名がログのフィールドで異なる名前を使用している場合、それらをここにリストされたキー名に再マップしてください。例えば、host.name の値がLog Observer UIに表示されない場合、host_name のような異なるフィールド名を使用していないか確認してください。ログに前述のリストに表示されているようなデフォルトのフィールド名が含まれていない場合は、次のセクションのいずれかの方法を使用してログを再マップしてください。
ログフィールドの再マップ 🔗
以下の表は、ログフィールドを再マッピングする4つの方法について説明しています。
再マッピング方法 |
手順 |
---|---|
ログフィールドのエイリアシング |
フィールドエイリアスを作成し、有効にします。方法は フィールドエイリアスの作成 を参照してください。次のセクションでは、ログフィールドのエイリアシングを使用するタイミングについて説明します。 |
クライアント側 |
必要なフィールドを再マップするようにアプリを設定します。 |
ログフィールドのエイリアシングの使用時期 🔗
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.name
k8s.node.name
k8s.pod.name
container.id
k8s.namespace.name
kubernetes.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:
ログ名を変更する 🔗
必要なキー名がログフィールドで異なる名前を使用している場合は、ログフィールドの再マップ に記載されている方法のいずれかを使用して、それらを再マッピングします。
This page was last updated on 2024年11月06日.