注入指标概览

支持的服务：

Google SecOps 提供详细的注入指标，以便您了解安全数据流水线的运行状况、数据量和处理状态。监控这些指标对于确保数据正确传输、发现潜在问题以及优化 Google SecOps 部署至关重要。

注入指标为何重要

  • 运行状况监控 ：跟踪数据 Feed 和收集代理的状态。
  • 问题排查 ：快速诊断数据丢失、解析错误或连接性问题等问题。
  • 数据量跟踪 ：了解从各种来源注入的数据量，有助于进行容量规划和费用管理。
  • 规范化分析 ：监控日志解析为统一数据模型 (UDM) 的成功率。
  • 提醒 ：为数据流异常、错误或数据量变化配置通知。

在哪里查看注入指标

  • Google Cloud Monitoring：

    • 将 Google SecOps 指标集成到 Cloud Monitoring 中，以便您根据注入的日志计数、大小和规范化事件等指标的阈值创建信息中心和设置提醒政策。
    • 指标位于 Chronicle Collector 和 Chronicle Log Type 等前缀下。
    • 参考文档：使用 Cloud Monitoring 了解注入分析

  • Google SecOps Health Hub：

    • Health Hub 在 Google SecOps 平台内提供集中式视图，用于监控数据源状态、注入量和解析运行状况。它会突出显示错误并提供深入了解的链接。
    • 参考文档：使用 Health Hub

  • BigQuery Export：

主要指标类别和字段

注入指标按注入流水线的不同组件（例如转发器、注入 API、规范化器、Feed）进行细分。以下是一些您会遇到的关键字段：

  • 数据量指标：

    • log_count：收到的或处理的原始日志条目数。
    • log_volume：收到的或处理的日志总大小（以字节为单位）。
    • event_count：解析后生成的 UDM 事件数。

  • 规范化指标：

    • state：日志规范化过程的结果（例如 parsed、failed_parsing、failed_validation）。
    • total_events：成功验证的 UDM 事件数。
    • total_error_events：解析或验证失败的事件数。
    • drop_reason_code：日志或事件被丢弃的原因。

  • 运行状况和性能 ：

    • last_heartbeat_time：表示收集器或 Feed 上次处于活动状态的时间。
    • drop_count：组件丢弃的日志数。
    • cpu_used、memory_used、disk_used：本地组件（例如 Bindplane 代理或旧版转发器）的资源利用率。
    • 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：特定收集器实例或数据 Feed 的唯一标识符。
  • namespace：用于整理日志，通常用于 API 注入。

注意 ：如 注入指标架构中所述， 汇总注入指标应被视为近似 数据量的指标，而不是任何给定时间范围内的确切计数。

原始日志量与信息中心日志量之间的差异

Google SecOps 信息中心中报告的总 ingestion.log_volume（例如，在查询 ingestion.component = "Ingestion API" 时）可能与实例中存储的原始日志总量存在显著差异。Google SecOps 界面不会显示自实例预配以来的所有时间累计注入计数器。由于每个报告工具都会强制执行最长回溯期，因此一旦实例的使用时间超过工具的保留期限，您就无法计算所有时间的累计总数。

出现这些差异的原因如下：

  • 不同的时间范围和回溯期限制：

    • 原始日志存储：根据您配置的实例保留政策保留数据。自预配以来，您的实例可能已注入多年的日志。
    • Google SecOps 信息中心：仅针对所选时间范围计算 ingestion.log_volume，最长回溯期为 365 天（对于自带项目 (BYOP) 实例，在 Cloud Monitoring 中最长为 24 个月）。如果您的实例注入数据的时间超过 365 天，信息中心查询报告的总数将低于您的累计历史注入量。

  • 不同的数据源和收集流水线：

    • 原始日志存储：记录存储在 Google SecOps 中的注入原始日志批次的直接字节大小。
    • Google SecOps 信息中心：从 ingestion_metrics 表中查询 ingestion.log_volume，该表以大约 5 分钟的间隔异步收集遥测数据。由于此遥测流水线可能会遇到收集延迟、抽样或瞬时指标下降的情况，因此信息中心查询提供的是近似数据量，而不是确切的字节数。

在哪里计算注入量以及值有何不同

由于 Google SecOps 界面不会显示自实例开始时间以来的所有时间累计注入计数器，因此请根据所需的时间范围，使用以下位置计算注入量：

  • Google SecOps 信息中心（最长 365 天）：

    • 在哪里计算：依次打开信息中心和报告 > 信息中心，然后在主要或数据注入和运行状况信息中心（包括注入 - 吞吐量（所有时间）图表）中查看吞吐量 widget。您还可以针对 sum($event.ingestion.log_volume) 运行自定义信息中心查询，并按 $event.ingestion.component = "Ingestion API" 进行过滤。
    • 最长时间范围：查询最多只能查询 365 天，即使在精选的 注入 - 吞吐量（所有时间） 图表上也是如此。
    • 值有何不同：信息中心查询异步 ingestion_metrics 表，该表以大约 5 分钟的间隔收集遥测数据，并且可能会遇到收集延迟或瞬时指标下降的情况。这些值是近似值，仅反映在所选时间范围内通过注入 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"} 运行查询（如需分步说明，请参阅查看结算的注入量）。
    • 最长时间范围：查询最多只能查询 24 个月，具体取决于 Cloud Monitoring 指标保留期限。
    • 值有何不同：Cloud Monitoring 会查询所选时间范围内收集器级别的注入字节数。这些值涵盖的回溯期比 Google SecOps 信息中心更长（最长 24 个月，而不是 365 天），但如果实例的使用时间超过 24 个月，则不会反映所有时间的总数。

  • BigQuery Export（超过 365 天，具体取决于数据集保留期限）：

    • 在哪里计算：导出 ingestion_metrics 表后，打开 BigQuery 项目，然后针对 SUM(log_volume)（或 total_size_bytes 在 Looker 和 BigQuery 中）运行查询，并按 component = "Ingestion API" 进行过滤。
    • 最长时间范围：查询受限于为 BigQuery 表配置的保留期限（从启用导出时开始），而不是 365 天的信息中心限制。
    • 值有何不同：BigQuery 查询的异步 ingestion_metrics 表与 Google SecOps 信息中心相同。对于相同的时间范围，这些值与信息中心查询的值一致，但它们仍然是近似遥测指标，而不是所有时间的原始日志字节数或最终结算量。

使用注入指标

  • 问题排查 ：在规范化器指标中按 log_type 和 state（例如 failed_parsing）进行过滤，以查找解析问题。检查 drop_count 和 drop_reason_code 以了解数据丢失情况。

  • 提醒：在 Cloud Monitoring 中设置提醒，以监控关键日志源的 log_count 突然下降或 total_error_events 的高比率。如需根据合同限制监控每日注入量，请使用注入的日志总大小 (chronicle.googleapis.com/ingestion/log/bytes_count) 指标。请勿将 chronicle.googleapis.com/ingestion/quota_limit 指标用于每日数据量提醒，原因如下：

    • quota_limit 指标衡量的是与动态后端限制的接近程度，而不是实际注入的数据量。
    • 如果将 quota_limit 用于每日数据量提醒，则在后端阈值调整时可能会导致误报。

    如需了解设置每日数据量提醒政策的步骤，请参阅 设置示例政策以监控每日注入量。

  • 容量规划 ：在 BigQuery 中分析 log_volume 趋势，以预测未来的需求。

  • 验证配置 ：设置新的数据源后，检查指标以确认数据是否按预期传输和解析。

通过定期监控和了解这些注入指标，您可以确保 Google SecOps 实例的数据流水线可靠高效。

需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。