パイプラインの更新とメトリクスの可視化

コンテキストの重要性 #

前のセクションでは、生の Kubernetes 監査ログを確認し、それらをメトリクスに変換して Splunk Observability Cloud に送信する Ingest Processor Pipeline を作成しました。

このパイプラインが定義されたことで、Splunk Observability Cloud で新しいメトリクスを収集しています。これは素晴らしい出発点ですが、特定の期間における Kubernetes 監査イベントの合計数を示す単一のメトリクスしか表示されません。イベントタイプ、ユーザー、レスポンスステータスなどでメトリクスを分割できるように、ディメンションを追加する方がはるかに価値があります。

このセクションでは、Ingest Processor Pipeline を更新して、Kubernetes 監査ログから収集されるメトリクスに追加のディメンションを含めます。これにより、監査ログの特定の側面をさらにフィルタリング、グループ化、可視化、およびアラート設定できるようになります。

メトリクスのカーディナリティが重要な理由 #

メトリクス名とそのディメンション値の一意の組み合わせごとに、個別の Metric Time Series (MTS) が作成されます。アクティブな MTS の数（カーディナリティとも呼ばれます）が、Splunk Observability Cloud でのメトリクス使用量を決定します。ディメンションを追加するとメトリクスはより有用になりますが、すべてのディメンションが保持する価値があるわけではありません。高カーディナリティのディメンション（すべてのイベントで一意またはほぼ一意の値を持つもの）は、MTS の数を爆発的に増加させ、分析的な価値を追加することなく使用量を膨らませる可能性があります。

これを実証するために、パイプラインに auditID ディメンションを追加します。Kubernetes はすべての監査イベントに一意の auditID を割り当てるため、このフィールドは必ず一意になります。これをディメンションとして追加すると、すべてのメトリクスデータポイントがまったく新しい MTS を生成し、小さく整理されたメトリクスであるべきものが数千の使い捨て時系列に変わります。これはカーディナリティ爆発の典型的な例であり、チームが便利だが過度に粒度の細かいディメンションをデータに追加する際に、容易に偶発的に発生しうるものです。

Metrics Pipeline Management による最適化 #

このノイズの多いディメンションが配置されたら、Splunk Observability Cloud の Metrics Pipeline Management (MPM) を使用して、カーディナリティを制御下に戻します。MPM を使用すると、データが到着した後にメトリクスとディメンションを集約、アーカイブ、または削除できるため、取り込みエンドポイント（コレクター、Ingest Processor Pipeline、またはデータを送信するアプリケーション）を変更することなく使用量を最適化できます。これは重要な利点です。すべてのチーム間で変更を調整したり、取り込みパイプラインを再定義したりすることなく、UI から直接メトリクスを完全に制御できます。

一意の auditID ディメンションを削除した、新しい低カーディナリティのメトリクスにデータをロールアップする集約ルールを作成し、不要になった生の高カーディナリティメトリクスを削除します。その過程で、MTS の正確な削減量を確認し、回収した使用量の具体的な測定値を得ることができます。

メトリクスを最適化した後、ログに関連するさまざまな種類のアクションのステータスを表示する新しいダッシュボードを作成します。