取り込み指標の概要

以下でサポートされています。

Google SecOps は、セキュリティ データ パイプラインの健全性、量、処理ステータスを可視化するために、詳細な取り込み指標を提供します。これらの指標をモニタリングすることは、データが正しく流れていることを確認し、潜在的な問題を特定して、Google SecOps のデプロイを最適化するために不可欠です。

取り込み指標が重要な理由

  • ヘルス モニタリング: データフィードと収集エージェントのステータスを追跡します。
  • トラブルシューティング: データのドロップ、解析エラー、接続の問題などの問題を迅速に診断します。
  • ボリューム トラッキング: さまざまなソースから取り込まれるデータ量を把握します。容量計画と費用管理に役立ちます。
  • 正規化の分析情報: 統合データモデル（UDM）に解析されるログの成功率をモニタリングします。
  • アラート: データフローの異常、エラー、ボリュームの変更に関する通知を構成します。

取り込み指標にアクセスする場所

  • Google Cloud Monitoring:

    • Google SecOps の指標を Cloud Monitoring に統合し、取り込まれたログの数、サイズ、正規化イベントなどの指標のしきい値に基づいてダッシュボードを作成し、アラート ポリシーを設定できます。
    • 指標は、Chronicle Collector や Chronicle Log Type などの接頭辞で利用できます。
    • リファレンス: 取り込みの分析情報に Cloud Monitoring を使用する

  • Google SecOps Health Hub:

    • Health Hub は、Google SecOps プラットフォーム内でデータソースのステータス、取り込み量、解析の健全性をモニタリングするための一元的なビューを提供します。エラーがハイライト表示され、詳細を確認するためのリンクが表示されます。
    • 参照: ヘルスハブを使用する

  • BigQuery Export:

主要な指標のカテゴリとフィールド

取り込み指標は、取り込みパイプラインのさまざまなコンポーネント（フォワーダー、Ingestion API、正規化、フィードなど）ごとに分類されます。以下に、よく使用される主なフィールドを示します。

  • ボリューム指標:

    • log_count: 受信または処理された未加工のログエントリの数。
    • log_volume: 受信または処理されたログの合計サイズ（バイト単位）。
    • event_count: 解析後に生成された UDM イベントの数。

  • 正規化指標:

    • state: ログの正規化プロセスの結果（parsed、failed_parsing、failed_validation など）。
    • total_events: 検証に成功した UDM イベントの数。
    • total_error_events: 解析または検証に失敗したイベントの数。
    • drop_reason_code: ログまたはイベントがドロップされた理由。

  • Health & Performance:

    • last_heartbeat_time: コレクタまたはフィードが最後にアクティブになった時刻を示します。
    • drop_count: コンポーネントによってドロップされたログの数。
    • cpu_used、memory_used、disk_used: Bindplane Agent や以前の Forwarder などのオンプレミス コンポーネントのリソース使用率。
    • latency_count: 取り込みから正規化までの所要時間に関連する指標。

  • 割り当て指標（取り込み API）:

    • quota_rejected_long_term_log_volume: 割り当て上限を超えたために拒否されたログの量。

ディメンションについて

指標は通常、ディメンション別に分類され、データをフィルタリングしてグループ化できます。

  • component: 指標が参照する取り込みパイプラインの部分（Forwarder、Ingestion API、Normalizer、Out-of-Band Processor など）。
  • log_type: ログソースのタイプ（WINDOWS_DNS、CS_EDR など）。
  • collector_id / feed_id: 特定のコレクタ インスタンスまたはデータフィードの固有識別子。
  • namespace: ログの整理に使用されます。API の取り込みでよく使用されます。

注: 取り込み指標スキーマに記載されているように、集計取り込み指標は、特定の期間の正確な数ではなく、おおよその量の指標として扱う必要があります。

未加工のログ容量とダッシュボードのログ容量の不一致

Google SecOps ダッシュボードに報告される ingestion.log_volume の合計（ingestion.component = "Ingestion API" のクエリ時など）は、インスタンスに保存されている未加工ログの合計量と大きく異なる場合があります。Google SecOps インターフェースには、インスタンスがプロビジョニングされた時点からの累積取り込みカウンタは表示されません。各レポートツールには最大ルックバック ウィンドウが適用されるため、インスタンスがツールの保持上限を超えると、累積合計を計算できなくなります。

こうした違いは、次の理由で発生します。

  • 期間とルックバックの上限が異なる:

    • 未加工ログの保存: 構成されたインスタンスの保持ポリシーに従ってデータを保持します。インスタンスは、プロビジョニング以降、複数年にわたってログを取り込んでいる可能性があります。
    • Google SecOps ダッシュボード: 選択した期間（最長 365 日間（Cloud Monitoring の Bring Your Own Project（BYOP）インスタンスの場合は最長 24 か月間））の ingestion.log_volume のみを計算します。インスタンスが 365 日を超えてデータを取り込んでいる場合、ダッシュボード クエリは、累積の過去の取り込み量よりも少ない合計を報告します。

  • さまざまなデータソースと収集パイプライン:

    • 未加工ログ ストレージ: Google SecOps に保存されている、取り込まれた未加工ログバッチの直接バイトサイズを記録します。
    • Google SecOps ダッシュボード: ingestion_metrics テーブルから ingestion.log_volume をクエリします。このテーブルは、約 5 分間隔で非同期にテレメトリーを収集します。このテレメトリー パイプラインでは、収集レイテンシ、サンプリング、一時的な指標の低下が発生する可能性があるため、ダッシュボード クエリでは正確なバイト数ではなく、おおよそのボリュームが提供されます。

取り込み量を計算する場所と値の違い

Google SecOps インターフェースには、インスタンスの開始時刻からの累積取り込みカウンタが表示されないため、必要な期間に応じて次の場所を使用して取り込み量を計算します。

  • Google SecOps ダッシュボード（最大 365 日）:

    • 計算場所: [ダッシュボードとレポート] > [ダッシュボード] を開き、[メイン] または [データの取り込みと健全性] ダッシュボード（[取り込み - スループット（全期間）] グラフを含む）で [スループット] ウィジェットを表示します。$event.ingestion.component = "Ingestion API" でフィルタされた sum($event.ingestion.log_volume) のカスタム ダッシュボード クエリを実行することもできます。
    • 最大期間: クエリは、キュレートされた [Ingestion - Throughput (All-Time)] グラフでも、最大 365 日に制限されます。
    • 値の違い: ダッシュボードは非同期の ingestion_metrics テーブルをクエリします。このテーブルは、約 5 分間隔でテレメトリーを収集し、収集の遅延や一時的な指標の低下が発生する可能性があります。値は概算であり、選択した期間に Ingestion API を介して取り込まれたログのみが反映されます。全期間の未加工ログバイト数や最終的な請求対象ボリュームは反映されません。

  • Cloud Monitoring の Metrics Explorer（BYOP インスタンスの場合は最大 24 か月）:

    • 計算場所: Google Cloud コンソールで [Monitoring] > [Metrics Explorer] を開き、chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"} のクエリを実行します（詳細な手順については、課金対象の取り込み量を表示するをご覧ください）。
    • 最大期間: クエリは、Cloud Monitoring の指標の保持期間に基づいて、最大 24 か月に制限されます。
    • 値の差異: Cloud Monitoring は、選択した期間のコレクタレベルの取り込みバイト数をクエリします。値は Google SecOps ダッシュボードよりも長いルックバック ウィンドウ（365 日ではなく最大 24 か月）を対象としていますが、インスタンスが 24 か月より古い場合は、全期間の合計は反映されません。

  • BigQuery Export（365 日を超えて、データセットの保持期間に基づく）:

    • 計算場所: ingestion_metrics テーブルをエクスポートした後、BigQuery プロジェクトを開き、component = "Ingestion API" でフィルタされた SUM(log_volume)（Looker と BigQuery では total_size_bytes）のクエリを実行します。
    • 最大時間範囲: クエリは、ダッシュボードの 365 日の上限ではなく、エクスポートを有効にした時点から BigQuery テーブルに設定された保持期間に制限されます。
    • 値の違い: BigQuery は、Google SecOps ダッシュボードと同じ非同期 ingestion_metrics テーブルをクエリします。値は同じ期間のダッシュボード クエリと一致しますが、全期間の未加工ログバイト数や最終的な課金対象ボリュームではなく、近似テレメトリー指標のままです。

取り込み指標の使用

  • トラブルシューティング: Normalizer 指標で log_type と state（failed_parsing など）でフィルタして、解析の問題を見つけます。drop_count と drop_reason_code でデータ損失を確認します。

  • アラート: Cloud Monitoring でアラートを設定して、重要なログソースの log_count の急激な減少や total_error_events の高い割合をモニタリングします。契約上の上限に対して 1 日の取り込み量をモニタリングするには、取り込まれたログの合計サイズ（chronicle.googleapis.com/ingestion/log/bytes_count）指標を使用します。次の理由から、1 日のボリューム アラートに chronicle.googleapis.com/ingestion/quota_limit 指標を使用しないでください。

    • quota_limit 指標は、実際に取り込まれたデータ量ではなく、動的バックエンドの上限までの近接性を測定します。
    • 1 日のボリューム アラートに quota_limit を使用すると、バックエンドのしきい値が調整されたときに誤ったアラームが発生する可能性があります。

    1 日のボリューム アラート ポリシーを設定する手順については、1 日の取り込み量をモニタリングするサンプル ポリシーを設定するをご覧ください。

  • キャパシティ プランニング: BigQuery で log_volume の傾向を分析して、将来のニーズを予測します。

  • 構成の検証: 新しいデータソースを設定したら、指標をチェックして、データが流れ、想定どおりに解析されていることを確認します。

これらの取り込み指標を定期的にモニタリングして把握することで、Google SecOps インスタンスの信頼性と効率性に優れたデータ パイプラインを確保できます。

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。