📚 课程目录第2章 Cloud Monitoring基础与指标探索

2. Cloud Monitoring基础与指标探索

Cloud Monitoring 是 Google Cloud 可观测性体系的核心组件，它负责采集、存储、查询和可视化来自 GCP 资源、应用以及自定义代码的时序数据。理解它的数据模型，是后续做告警、SLO 和故障诊断的前提。本节围绕五个关键概念展开：指标类型、时间序列、资源标签、Metrics Explorer 的使用，以及自定义指标的创建与查询。

一、指标类型：数据从哪来，长什么样

Cloud Monitoring 中的指标（Metric）是对某个可测量属性的命名定义，例如 compute.googleapis.com/instance/cpu/utilization。每个指标有明确的类型（Metric Kind）和值类型（Value Type），二者共同决定了数据如何被写入和读取。

GAUGE（瞬时值）：表示某一时刻的采样值，如 CPU 利用率、内存占用。每次写入覆盖当前时间点的值，查询时取最近一次采样。
DELTA（增量）：表示自上次采样以来的变化量，如请求计数。查询时通常需要按时间窗口做求和或速率计算。
CUMULATIVE（累计值）：从某个起点持续累加，如进程启动以来的总请求数。查询时常用 rate() 或 delta() 转换为速率。

值类型则分为 INT64、DOUBLE、BOOL、STRING、DISTRIBUTION。其中 DISTRIBUTION 用于直方图类指标（如延迟分布），查询时可用百分位函数（如 percentile）提取 P50、P99。理解这两组属性，能避免“为什么我的计数指标画出来是一条直线”这类常见困惑——那通常是把 CUMULATIVE 当 GAUGE 直接读了。

二、时间序列与资源标签：数据的坐标系统

一个指标加上一组标签（Labels），就构成一条时间序列（Time Series）。标签是键值对，分为两类：资源标签（Resource Labels）描述数据来源，如 project_id、instance_id、zone；指标标签（Metric Labels）描述数据本身的维度，如 response_code、method。同一指标下，标签组合不同，就是不同的时间序列。

查询的本质，就是“选指标 + 过滤标签 + 聚合”。例如要查某项目下所有实例的 CPU 利用率，可以按 instance_id 分组，也可以跨实例求平均。标签的基数（Cardinality）直接影响查询成本和性能：高基数标签（如 user_id）会产生海量时间序列，应谨慎使用。

三、Metrics Explorer：交互式探索指标

Metrics Explorer 是 Cloud Console 中用于临时探索指标的图形化工具，适合在写告警策略或仪表盘之前先确认“数据是否存在、标签长什么样、聚合方式是否合理”。典型操作路径如下：

在 Metrics Explorer 中点击 Select a metric，输入关键字（如 cpu utilization），从资源类型和指标列表中选中目标指标。
在 Filter 区域添加标签过滤条件，例如 zone = us-central1-a，观察曲线数量是否收敛到预期。
在 Aggregation 区域设置 Alignment period（对齐周期，如 1 分钟）、Aligner（如 mean、rate）和 Group by（如 instance_id）。
切换图表类型（折线、堆叠面积、热图），并调整时间范围，确认数据形态与业务预期一致。

一个常见误区是忽略对齐周期。若原始采样间隔为 60 秒，而对齐周期设为 10 秒，会出现大量空点；若设为 10 分钟，则会平滑掉短时尖刺。建议对齐周期不小于原始采样间隔，并根据告警灵敏度需求选择。

四、自定义指标：把业务数据接入 Monitoring

当内置指标无法覆盖业务逻辑时，可以通过 Cloud Monitoring API 或 OpenTelemetry 写入自定义指标。自定义指标分为两类：自定义指标（Custom Metric，以 custom.googleapis.com/ 开头）和基于日志的指标（Log-based Metric）。前者适合应用主动上报，后者适合从日志中提取计数或分布。

创建自定义指标描述符的典型流程是：先调用 projects.metricDescriptors.create 定义指标类型、Kind 和 Value Type，再通过 projects.timeSeries.create 写入数据点。以下是一个使用 gcloud 创建 GAUGE 类型自定义指标的示例：

gcloud monitoring metrics-descriptors create \
  --project=my-project \
  --metric-type=custom.googleapis.com/business/order_count \
  --metric-kind=GAUGE \
  --value-type=INT64 \
  --description="Number of orders processed" \
  --unit="1"

写入数据点时，需要指定 metric.type、resource.type（如 global 或 gce_instance）、标签以及 points 数组。每个 point 包含 interval.endTime 和 value.int64Value。写入后，在 Metrics Explorer 中搜索 custom.googleapis.com/business/order_count 即可看到曲线。

自定义指标的标签基数应尽量低。若把订单 ID 作为标签，会瞬间产生数十万条时间序列，不仅查询缓慢，还可能触发配额限制。建议只保留可聚合的维度，如 region、status、channel。

五、查询与验证：从曲线判断数据是否正确

写入自定义指标后，验证步骤不可省略。可以在 Metrics Explorer 中执行以下检查：

数据是否存在：时间范围选最近 1 小时，确认曲线非空。若为空，检查指标描述符是否创建成功、写入时间戳是否在有效窗口内（Monitoring 拒绝超过 25 小时前的数据点）。
数值是否合理：对比应用日志中的计数与曲线积分值。例如每分钟写入一次 order_count，曲线在 1 小时内的 sum 应接近实际订单数。
标签是否正确：在 Group by 中选择自定义标签，确认分组数量与预期维度一致。
聚合是否恰当：GAUGE 用 mean 或 max，DELTA/CUMULATIVE 用 rate 或 sum。选错 Aligner 会导致曲线形态失真。

自定义指标写入存在配额限制，默认每个项目每分钟约 200 个时间序列写入请求。高频写入场景应使用批量 API 或 OpenTelemetry Collector 做聚合缓冲，避免因限流导致数据丢失。

掌握以上五点后，你已经能够独立完成“定义指标 → 写入数据 → 过滤聚合 → 可视化验证”的完整链路。这套链路也是后续配置告警策略和构建仪表盘的基础：告警条件本质上就是对某条时间序列的聚合结果做阈值判断，而仪表盘则是多个查询的并排展示。把指标类型、标签和时间序列的关系理清，后续的排障和优化都会事半功倍。