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 uses OpenTelemetry to correlate telemetry types. To do this, your telemetry field names or metadata key names must exactly match the metadata key names used by both OpenTelemetry and 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.
関連コンテンツで問題が発生している場合は、メタデータのキー名を確認し、必要に応じて更新してください。
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, any other 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 🔗
To enable Related Content for APM use one of these span tags:
service.name
trace_id
Optionally, you can also use deployment.environment
with 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 🔗
To enable Related Content for IM use one of these metadata combinations:
host.name
. It falls back onhost
,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
(optional) +k8s.pod.name
k8s.cluster.name
+k8s.node.name
(optional) +k8s.pod.name
(optional) +container.id
service.name
service.name
+deployment.environment
(optional) +k8s.cluster.name
(optional)
Splunk Distribution of the OpenTelemetry Collector のデフォルト設定を使用している場合、必要な Infrastructure Monitoring メタデータが提供されます。詳しくは Install the Collector for Kubernetes using Helm を参照してください。
OpenTelemetry Collector の他のディストリビューションや、Splunk ディストリビューションのデフォルト以外の設定を使用してインフラストラクチャデータを収集している場合、関連コンテンツはそのままでは動作しません。
Splunk logs 🔗
To enable Related Content for logs use one of these fields:
host.name
service.name
span_id
trace_id
Log ObserverとRelated Contentの両方が完全に機能するように、ログイベントフィールドが正しくマッピングされていることを確認してください。正しいログフィールドマッピングは、組み込みのログフィルタリングを可能にし、APMと Infrastructure Monitoring 機能にログを埋め込み、関連コンテンツバーと同様に高速検索を可能にします。
If the key names in the preceding list use different names in your log fields, remap them to the key names listed here. For example, if you don’t see values for host.name in the Log Observer UI, check to see whether your logs use a different field name, such as host_name. If your logs do not contain the default field names exactly as they appear in the preceding list, remap your logs using one of the methods in the following section.
注釈
Splunk Observability Cloud の Splunk Log Observer エンタイトルメントをお持ちのお客様は、2023年12月までに Log Observer から Log Observer Connect に移行する必要があります。Log Observer Connect を使用すると、より多様なデータソースからより多くのログをインジェストし、より高度なログパイプラインを利用し、セキュリティロギングに拡張できます。その方法については、Accomplish logs pipeline rules in Splunk platform を参照してください。
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
Use one of these tag combinations to enable Related Content:
k8s.cluster.name
+k8s.node.name
k8s.cluster.name
+k8s.node.name
(optional) +k8s.pod.name
k8s.cluster.name
+k8s.node.name
(optional) +k8s.pod.name
(optional) +container.id
Collector for Kubernetesの詳細については、Collector for Kubernetesを使い始める を参照してください。
ログフィールドの再マップ 🔗
以下の表は、ログフィールドを再マッピングする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 にアクセスできません。
追加のログ処理ルールを作成することで、インデックス作成容量を使用したくありません。
インデックス時にデータを変換したくありません。
新しいエイリアスは、エイリアスを作成する前の時点から入ってきたものであっても、すべてのログメッセージに影響するようにしたいと思います。
メタデータのキー名を変更する方法 🔗
メトリクス名とトレース名の変更 🔗
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:
ログ名を変更する 🔗
必要なキー名がログフィールドで異なる名前を使用している場合は、ログフィールドの再マップ に記載されている方法のいずれかを使用して、それらを再マッピングします。
このページは 2024年12月18日 に最終更新されました。