想象你在郊外拥有一栋智能豪宅：温湿度传感器、监控摄像头、门窗磁吸、烟雾报警器遍布每个角落。平常一切正常时，你不会去在意它们；可当某天清晨恒温泳池水温异常，你需要立刻知道：是加热器坏了、水管冻住了，还是电力系统出了问题？答案不在任何一个单一传感器里，而藏在它们拼起来的时间线中。 GCP 的 Cloud Monitoring，就是这栋 AI 豪宅的中央安防室。它为跑在云上的 AI 服务（训练任务、推理端点、数据管道）安装“传感器”（监控指标）、记录“影像”（日志）、还原“人走过的路径”（链路追踪），并把所有信息汇聚到一面仪表盘墙上。异常出现时，它会按你预设的“安全规则”（告警策略）拉响通知，甚至通过历史数据预判“今晚可能有人闯入”（异常检测），再帮你一步步锁定真正的“作案者”（根因分析）。 这篇文章，就是教你把这间中央安防室从零搭建起来——从规划传感器、装监控墙、设规则，到看录像、追轨迹、做预判、破悬案，让 AI 服务出问题时，你不再是四处乱撞的“糊涂屋主”。

岗位关联

掌握全栈可观测能力，意味着 AI 服务出故障时你能在几分钟内定位根因。这是 AI 工程师从“能跑通”迈向“能运维”的分水岭，也是 MLOps 岗位的核心竞争力。

目录
  1. 可视化演示
  2. 可观测性基础
  3. 指标采集配置
  4. 监控仪表盘
  5. 告警规则设计
  6. 日志分析
  7. 链路追踪
  8. 异常检测
  9. 根因分析
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

三步展示GCP全栈可观测：指标/日志/追踪三支柱关联、应用/平台/基础设施三层监控、以及SLO/健康/资源漏斗式仪表盘设计。

本节配有交互动效（进入视口后自动加载，约 3KB）。

可观测三支柱 指标：量化性能 日志：事件记录 追踪：请求链路 三支柱联动 日志中关联trace ID, span挂载指标。

可观测性基础

盖一栋智能豪宅，第一步不是买传感器，而是先画一张“安防规划图”：门口装门磁、客厅放摄像头、厨房配烟雾报警器。AI 服务上云之前，同样要先想清楚——“我凭什么知道它现在健不健康？”GCP 把这个答案概括为三大支柱：指标、日志、链路追踪。

三根支柱各有分工：指标是“体温计”，回答“系统现在怎么样”；日志是“监控录像”，回答“当时发生了什么细节”；链路追踪是“轨迹还原”，回答“一次请求到底走了哪条路、在哪一步卡住”。任何一个 AI 服务，只有同时拿到这三类数据，才算得上真正“可观测”。

Cloud Monitoring 在 GCP 中统一承载这三类能力。对 AI 负载来说，“全栈”意味着从底层 GKE 节点的 CPU/GPU 利用率，到中间数据管道的吞吐，再到上层模型推理的延迟与错误率，每一层都有数据可查。最常见的 SLA 衡量指标是服务可用率，公式如下：

有了这张“安防规划图”，下一步就是动手安装传感器——配置指标采集。

A=SsuccessTtotalA = \displaystyle\frac{S_{success}}{T_{total}}
可用率 = 成功请求数 ÷ 总请求数。它回答“服务到底靠不靠谱”这个最朴素的问题。
  1. 总请求数T_{total} 表示统计窗口内发往 AI 服务的全部请求数量，是分母，刻画“服务被调用了多少次”。
    TtotalT_{total}
  2. 成功请求数S_{success} 表示其中返回成功结果（如 HTTP 2xx、推理成功）的请求数量，是分子。
    SsuccessS_{success}
  3. 可用率二者相除得到 A，数值越接近 1 说明服务越可靠；例如 0.99 表示 99% 的请求成功，通常对应 SLA 的承诺目标。
    A=SsuccessTtotalA = \displaystyle\frac{S_{success}}{T_{total}}

指标采集配置

传感器的安装位置很有讲究：温度计要放空调出风口才能感知制冷效果，烟雾报警器要放厨房才能及时预警。AI 服务的指标采集同样是“选位置、定类型”的工程。

GCP 把指标分成两大类：系统指标与自定义指标。前者由云平台自动采集，开箱即用；后者需要你亲自“布线”——通过 API 把业务数据写入 Cloud Monitoring 的时间序列，就像在书房里额外加装一个“图书借阅计数器”。

系统指标包括 CPU 利用率、内存、磁盘 IO、网络流量、GPU 利用率等，装上采集代理（Ops Agent）即可自动上报。自定义指标则通过 monitoring API 写入，适合记录“推理请求数”“token 吞吐量”这类业务量。指标按语义分为 GAUGE（瞬时值，如当前内存）、DELTA（增量，如每秒请求数）、CUMULATIVE（累计值，如总调用次数）。采集的精细程度用采样率来衡量：

传感器装好后，就要把它们接到“监控墙”上——这就是下一步的仪表盘。

r=nsampledntotalr = \displaystyle\frac{n_{sampled}}{n_{total}}
采样率 = 实际采集点数 ÷ 理论上应产生的点数。采样率越低，观测越粗糙，越容易漏掉短促的异常尖峰。
  1. 采样数n_{sampled} 表示实际被采集代理上报并写入 Cloud Monitoring 的指标点数量。
    nsampledn_{sampled}
  2. 总数n_{total} 表示在同样时间段内理论上应该产生的全部指标点数量。
    ntotaln_{total}
  3. 采样率r 是两者比值，代表监控覆盖的完整程度；r = 1 表示 100% 采集，r = 0.1 表示每 10 个点只采 1 个。
    r=nsampledntotalr = \displaystyle\frac{n_{sampled}}{n_{total}}

监控仪表盘

中央安防室的墙上挂满屏幕：左边是花园实时画面，中间是各房间温度曲线，右边是门禁开关记录。一眼扫过去，整栋房子的状态尽收眼底。Cloud Monitoring 的仪表盘就是这面墙。

仪表盘由图表组件组成，每个组件绑定一个或多个指标查询，相当于监控墙上的“一块屏幕”。组件类型直接影响信息传达效率：折线图看趋势、柱状图看对比、热力图看分布。

布局设计遵循“总览→分层→明细”：总览页放核心 SLA 指标，第二层放各服务维度的细分视图，明细页留给排障时下钻使用。刷新频率按需设置，如 1 分钟或 5 分钟——刷新太快消耗配额，太慢又不够实时。延迟类指标建议用百分位而非平均值，因为平均会被少数极端值拉偏，掩盖“大部分请求其实很慢”的事实：

监控墙搭好了，但你不可能 24 小时盯着屏幕——需要设几条“安防规则”，让系统在异常时主动喊你。

P95=x(k),k=⌈0.95×n⌉P_{95} = x_{(k)}, \quad k = \lceil 0.95 \times n \rceil
P95 的含义是：把延迟从小到大排序，95% 的请求延迟都小于等于这个值。它比平均延迟更诚实。
  1. 排序后的序列x_{(k)} 表示把 n 个延迟观测值从小到大排序后形成的有序列表，下标 k 对应第 k 个位置的元素。
    x(k)x_{(k)}
  2. 百分位位置k = \lceil 0.95 \times n \rceil 用向上取整把 95% 的位置换算成数组下标，例如 100 个点对应第 95 个位置。
    k=⌈0.95×n⌉k = \lceil 0.95 \times n \rceil
  3. P95 值P_{95} 就是该位置对应的延迟值，表示 95% 请求的延迟都不超过它；P95 比 P50 更能暴露“尾部慢请求”问题。
    P95P_{95}

告警规则设计

聪明的安防系统不会“一有风吹草动就打电话”，而是设规矩：“室温高于 32°C 且持续 5 分钟才通知”。告警设计就是给监控系统立规矩，立得好，值班的人不会被半夜吵醒；立得差，要么天天狼来了，要么真出事时静悄悄。

Cloud Monitoring 的告警策略 = 触发条件 + 持续时间 + 通知渠道，三个要素缺一不可。触发条件最简单的是阈值告警：指标值大于（或小于）某个固定值。但固定阈值难以适应流量波动，实践中常用统计口径，以历史均值加上若干倍标准差作为动态阈值。持续时间用于过滤瞬时抖动，比如“越界状态持续 60 秒才触发”。组合条件支持多指标 AND/OR，例如“GPU 利用率 > 90% 且错误率 > 1%”才告警，能大幅减少噪音。通知渠道则包括邮件、短信、Slack 消息，以及调用 Webhook 触发自动化处理流程。

告警只告诉你“出事了”，要快速弄清“发生了什么细节”，还得回头看监控录像——日志。

θ=μ+kσ\theta = \mu + k\sigma
告警阈值 = 历史均值 + k 倍标准差。k 是“容忍度旋钮”：k 越小越敏感，误报越多；k 越大越迟钝，漏报越多。
  1. 历史均值\mu 是过去一段时间指标的平均水平，代表“正常基线”，例如过去 24 小时 GPU 利用率平均 45%。
    μ\mu
  2. 标准差\sigma 描述指标波动的离散程度，σ 大说明指标本身忽高忽低，阈值就要放宽。
    σ\sigma
  3. 阈值\theta = \mu + k\sigma 把基线上移 k 个标准差；k 通常取 3，表示“比正常高点再多 3 倍波动才算异常”。
    θ=μ+kσ\theta = \mu + k\sigma

日志分析

传感器只能告诉你“泳池水温不对”，但摄像头和门口登记本能还原那个时间点的一切：凌晨 3 点机房有人进出、加热器日志连续报错。日志就是 AI 服务的“录像 + 登记本”，是排查问题时信息量最大的素材。

Cloud Logging 统一收集 GKE 上每个 Pod、每台 VM、每个服务的标准输出与文件日志，让“登记本”集中在一处。日志分析围绕三个操作展开：聚合、过滤、导出。

聚合把海量日志按字段归类计数，比如统计每个服务的 ERROR 条数，快速判断“谁在报错”；过滤用查询语法精确圈定范围，例如 service="transformer" AND level=ERROR 就能只看翻译模型服务的错误；导出则把日志流接入 BigQuery 做长期分析。错误计数可以直接作为告警的输入信号：

日志告诉你“哪里报错了”，但一次请求为什么慢、瓶颈在哪个服务，需要跟着它的脚印走一遍——链路追踪。

cerror=∑i=1N1[leveli=ERROR]c_{error} = \displaystyle\sum_{i=1}^{N} \mathbb{1}[level_i = \text{ERROR}]
这个公式把 N 条日志中所有 level 为 ERROR 的条目数累加起来，得到一个可触发告警、可画趋势图的数字。
  1. 指示函数\mathbb{1}[level_i = \text{ERROR}] 是一种“翻译开关”，当第 i 条日志等级为 ERROR 时取 1，否则取 0。
    1[leveli=ERROR]\mathbb{1}[level_i = \text{ERROR}]
  2. 累加求和\displaystyle\sum_{i=1}^{N} 把 N 条日志逐条过一遍“翻译开关”，把结果全部加起来。
    ∑i=1N\sum_{i=1}^{N}
  3. 错误计数c_{error} 就是窗口内的错误日志条数，数值突增往往对应线上故障，是告警和报表的重要指标。
    cerrorc_{error}

链路追踪

客人从大门走进书房，每个房间的摄像头都记下“进入时间”和“离开时间”。想知道他在哪儿耽误最久，把每段停留时间排个序即可。分布式追踪对每个请求做的正是这件事。

Cloud Trace 为每次请求分配一个 trace ID，并在服务间传递。每个服务处理请求时记录一个 span：开始时间、结束时间、标签信息。所有 span 按父子关系拼起来，就是请求的完整路线图。对微服务化的 AI 推理系统来说，这几乎是定位性能瓶颈的必备工具。

一条典型的推理链路包括：API 网关鉴权 → 数据预处理 → 模型推理 → 后处理 → 结果持久化。假设共 n 个环节，每个环节耗时 d_i，总延迟等于各段之和：

有了路线图，你已经能应对“出了事怎么查”。但更高阶的玩法，是让系统“提前预判要出事”——异常检测。

D=∑i=1ndiD = \displaystyle\sum_{i=1}^{n} d_i
总延迟 = 各环节耗时之和。把每个 span 的耗时可视化成一个瀑布图，最宽的那一段就是瓶颈所在。
  1. 各段耗时d_i 表示请求在第 i 个服务或环节的耗时，例如模型推理阶段耗时 320ms。
    did_i
  2. 累加求和\displaystyle\sum_{i=1}^{n} 把从网关到存储共 n 个环节的耗时全部相加，得到一次完整请求的总延迟。
    ∑i=1n\sum_{i=1}^{n}
  3. 总延迟D 是端到端延迟；对比各 d_i 与 D 的占比，就能算出“哪个环节最拖后腿”。
    DD

异常检测

顶级安防系统会学习住户的生活规律：每天早上 8 点出门、晚上 7 点回家。于是“凌晨 3 点大门被打开”就会被标记为异常。Cloud Monitoring 的智能异常检测原理类似：让历史数据教会系统“正常长什么样”，再自动找出偏离正常的行为。

基于历史时序数据，系统用预测模型估计未来一段时间的数值范围，形成一条动态的“正常通道”。真实值落在通道内则视为正常，明显跳出通道则触发异常标记。这种方法比固定阈值聪明：它知道“工作日的 GPU 利用率本来就该比凌晨高”，不会对正常的昼夜波动误报。

统计上最直观的异常判定方法是 z-score，即计算当前值偏离历史均值多少个标准差。它被广泛用于自定义告警条件和离线分析：

异常检测能告诉你“有个地方不对劲”，但真正收尾的，是把所有线索拼起来找出“罪魁祸首”——根因分析。

z=x−μσz = \displaystyle\frac{x - \mu}{\sigma}
z 分数表示“当前值离正常中心有多远”，以标准差为单位。|z| > 3 通常视为显著异常，如同“凌晨 3 点的大门”。
  1. 当前观测值x 是最新一个指标点，例如此刻的 GPU 利用率 97%。
    xx
  2. 均值与标准差\mu 和 \sigma 来自历史窗口的统计量，一起刻画“正常波动”的分布范围。
    μσ\mu \quad \sigma
  3. z 分数z 表示 x 偏离均值多少个标准差；z = 2 表示偏了 2 个标准差，|z| > 3 时通常判为异常。
    z=x−μσz = \displaystyle\frac{x - \mu}{\sigma}

根因分析

全屋断电时，有经验的安防员不会只盯着保险丝，而是把传感器的读数、摄像头的时间戳、门禁记录按时间排成一条线，看哪个环节最先异常。先发生异常的那个环节，往往就是根因。

Cloud Monitoring 的根因分析实践，核心是把三类信号按同一时间轴对齐、互相印证：指标回答“哪个资源从几点开始异常”，日志回答“那个时段具体报了什么错”，链路回答“哪个服务的耗时最先飙升”。三者对得上，结论才站得住脚。

常用方法有两个：关联分析和告警降噪。关联分析量化两个指标之间的相关性，判断“CPU 上升”与“延迟上升”是否真的强相关；告警降噪把同一时段、同一资源的多条告警聚合成一条事件，避免排查时被通知轰炸。相关系数是最常用的量化工具：

至此，这间“中央安防室”就完整了：方案 → 传感器 → 监控墙 → 规则 → 录像 → 轨迹 → 预判 → 破案。每一环都是 AI 服务稳定运行的守护者。

ρ=cov(X,Y)σXσY\rho = \displaystyle\frac{\text{cov}(X, Y)}{\sigma_X \sigma_Y}
相关系数把两个指标的共同变化量化到 [-1, 1]：接近 +1 表示同涨同跌，接近 -1 表示此消彼长，接近 0 表示基本无关。
  1. 协方差\text{cov}(X, Y) 度量两个指标 X、Y 一起偏离各自均值的程度，同向变化时为正、反向时为负。
    cov(X,Y)\text{cov}(X, Y)
  2. 归一化分母\sigma_X \sigma_Y 是两个指标标准差的乘积，把协方差压缩到 [-1, 1] 区间，让不同量纲的指标可比。
    σXσY\sigma_X \sigma_Y
  3. 相关系数\rho 越接近 ±1，两个指标联动越强；例如 CPU 与延迟的 ρ = 0.9，可推测 CPU 打满是延迟飙高的诱因。
    ρ\rho

AI 应用场景

AI 推理服务健康巡检

阶段：模型部署与运维（MLOps）

解决的问题：传统方式靠“用户投诉了才知道出问题”，或逐个 SSH 到机器上手动看资源，效率低且被动。Cloud Monitoring 自动采集 GPU 利用率、推理延迟、错误率并汇聚到统一仪表盘，异常时数分钟内触达值班人员。

具体案例：一家在线翻译公司用 20 个 GKE 节点部署翻译模型。某次上线新版模型后，P95 延迟从 200ms 涨到 800ms，阈值告警在 5 分钟内发到值班群；随后通过链路追踪发现“分词服务”耗时占比从 20% 飙到 70%，回滚新版本后恢复。

大模型训练任务异常发现

阶段：模型训练

解决的问题：大模型训练可能持续数周，GPU 掉卡、显存 OOM、loss 异常飙升若不能及时发现，会浪费巨额算力成本。人工盯曲线不现实，需要自动化的异常检测。

具体案例：训练团队在仪表盘上同时展示 GPU 利用率、显存占用和 loss 曲线，并对显存配置了 z-score 异常检测。某次因数据加载线程泄漏导致显存缓慢爬升，在触发 OOM 前 2 小时就收到告警，团队及时扩容并修复，避免了整节点崩溃。

多租户 AI 平台故障归因

阶段：平台运营

解决的问题：多个团队共享一个推理平台时，出问题常表现为“租户 A 说慢、租户 B 说错”。传统方式难以判断是平台整体故障还是某个租户负载拖垮了共享资源。

具体案例：平台 SRE 为每个租户单独打 label 采集指标，结合链路追踪定位到某租户的批量任务打满了共享 GPU 池。告警降噪把同一时段 20 条告警合并为 1 条事件，SRE 迅速为该租户配置了资源配额，恢复其他租户的服务质量。

Python 演示

python71 行
"""Cloud Monitoring 指标查询与异常检测演示."""import statisticsfrom datetime import datetime, timedelta METRIC_NAME = "ai_training_gpu_utilization"TIME_SERIES = [42, 45, 39, 48, 44, 41, 47, 43, 46, 44,               45, 42, 96, 98, 97, 95, 99, 100, 98, 97,               46, 44, 43, 45, 42, 41, 47, 44, 40, 43]  def detect_anomaly_zscore(values, threshold=3.0):    """基于 z-score 的异常检测, |z| > threshold 判定为异常."""    mean = statistics.mean(values)    stdev = statistics.pstdev(values)    anomalies = []    for i, value in enumerate(values):        z = (value - mean) / stdev if stdev > 0 else 0.0        if abs(z) > threshold:            anomalies.append((i, value, round(z, 2)))    return anomalies  def query_metric(metric_type=METRIC_NAME):    """模拟 Cloud Monitoring timeSeries.list 的返回结构."""    return {        "project_id": "my-ai-project",        "metric.type": metric_type,        "points": [            {"timestamp": datetime.utcnow() - timedelta(minutes=30 - i),             "value": TIME_SERIES[i]}            for i in range(30)        ]    }  def build_alert_condition(metric_type, threshold_value=90):    """构造 Cloud Monitoring 阈值告警条件."""    return {        "display_name": "GPU util too high",        "condition_threshold": {            "filter": 'metric.type = "' + metric_type + '"',            "threshold_value": threshold_value,            "comparison": "COMPARISON_GT",            "duration": "60s"        }    }  def evaluate_alert(points, condition):    """按告警条件评估指标点是否越界."""    th = condition["condition_threshold"]["threshold_value"]    return [p["value"] for p in points if p["value"] > th]  if __name__ == "__main__":    series = query_metric()    points = [p["value"] for p in series["points"]]    print("指标: " + series["metric.type"])    print("最近 30 个点: " + str(points))     anomalies = detect_anomaly_zscore(points)    if anomalies:        print("检测到异常点(索引, 数值, z): " + str(anomalies))    else:        print("未检测到异常点")     condition = build_alert_condition(METRIC_NAME)    over = evaluate_alert(points, condition)    print("超过阈值 90 的点数: " + str(len(over)))    if over:        print("越界值: " + str(over))
目的：模拟从 Cloud Monitoring 拉取 GPU 利用率时间序列，先做 z-score 异常检测，再按阈值告警条件评估哪些点越界，演示“异常检测 + 告警”的完整链路。
  1. z = (value - mean) / stdev if stdev > 0 else 0.0计算每个数据点偏离均值多少个标准差，z 越大越可疑；stdev 为 0 时返回 0 避免除零。
  2. statistics.pstdev(values)计算整个数据集的总体标准差，描述“正常波动”的宽度。
  3. "comparison": "COMPARISON_GT"告警比较方向设为“大于”，指标值超过阈值才触发。
  4. "duration": "60s"要求越界状态持续 60 秒才告警，过滤瞬时抖动造成的误报。
  5. datetime.utcnow() - timedelta(minutes=30 - i)为第 i 个模拟点生成“30 分钟前到当前”的时间戳，还原真实时间序列结构。
  6. abs(z) > threshold取 z 的绝对值判断，上下两个方向的大幅偏离都算异常。

常见误区

误区把 Cloud Monitoring 搭好等同于“做几张漂亮的折线图挂在屏幕上”。图能看到，系统就算可观测了。

正解仪表盘只是中央安防室的“监控墙”。真正的可观测性，是当你遇到一个没见过的问题时，能靠指标、日志、链路三者的组合快速回答“发生了什么、在哪里、为什么”。只摆传感器、不接告警、不存录像、不还原路径，等于白装。

为何常见：图表最直观，是大多数人接触监控的第一印象，容易产生“做完仪表盘就大功告成”的错觉。

误区阈值设得越紧越好，最好任何风吹草动都通知我，宁可错杀一千，不可放过一个。

正解告警哨兵太多，系统会天天半夜把你吵醒，最后你会习惯性关掉所有通知，真正出事时反而没人响应。告警设计要权衡误报与漏报：θ = μ + kσ 中 k 太小误报多，k 太大漏报多，通常从 k = 3 起步再按实际体验调整。

为何常见：人天生厌恶不确定性，想把所有异常都兜在网里，忽略了“告警疲劳”带来的更大代价。

误区CPU、GPU 利用率都正常，模型服务肯定没问题，其他指标不用看。

正解资源指标像“房间温度、电量”，但 AI 服务的健康还包括“推理结果是否正确、延迟是否达标、错误率是否上升”。完全可能出现 GPU 满载但大量请求超时的情况，必须结合日志与链路追踪才能看到全貌。

为何常见：资源指标开箱即用、最容易拿到，让人误以为它就是可观测性的全部。

误区开启了智能异常检测，模型会自动适应一切变化，永远不用再管。

正解异常检测的基线来自历史数据。当流量模式、模型版本、数据分布发生变化后，旧基线会失准——就像安防系统要随着住户作息变化重新学习“正常”的样子。需要周期性校准、重训练或调整阈值参数。

为何常见：厂商宣传强调“智能、自动”，让人高估了模型的自适应能力，忽略了数据时效性。

面试题

Q1. 以下哪项不属于可观测性三大支柱？

单选题 · easy

  • A.指标监控
  • B.日志分析
  • C.链路追踪
  • D.容器编排← 正确答案

答案：D。三大支柱是指标、日志、链路追踪。容器编排是部署层面的技术，回答的是“用什么跑”，而不是“怎么知道它跑得好不好”，因此不属于可观测性支柱。

Q2. Cloud Monitoring 中的“系统指标”通常指的是什么？

单选题 · easy

  • A.应用自定义的业务指标
  • B.云资源自带的 CPU 内存指标← 正确答案
  • C.用户上传的 CSV 统计文件
  • D.模型训练时的超参数配置

答案：B。系统指标由云平台自动采集，例如 CPU 利用率、内存、磁盘 IO、GPU 利用率，开箱即用。自定义业务指标需要额外通过 API 上报，CSV 和超参数都不是监控指标的概念。

Q3. 阈值公式 θ = μ + kσ 中，若 k 设置得过大，最可能出现什么后果？

单选题 · mid

  • A.误报增多，告警疲劳
  • B.漏报增多，异常被忽略← 正确答案
  • C.告警触发速度变快
  • D.指标采集直接停止

答案：B。k 是“容忍度旋钮”，k 越大阈值越高，只有偏离更远才告警，于是轻微的异常被当作正常放行，漏报增多。误报增多对应 k 过小；告警速度和采集行为与 k 无关。

Q4. 在 Cloud Monitoring 中，自定义业务指标应通过什么方式上报？

单选题 · mid

  • A.修改控制台的主题配置
  • B.调用 API 写入时间序列← 正确答案
  • C.发送电子邮件给管理员
  • D.在 GKE 节点创建文本文件

答案：B。自定义指标需要调用 Monitoring API 的 timeSeries 写入接口，把业务数值按时间戳上传。控制台主题、邮件、文件都与指标上报无关，属于对监控机制的常见误解。

Q5. P95 延迟指标的正确含义是？

单选题 · mid

  • A.延迟平均值的百分之九十五
  • B.百分之九十五的请求延迟低于该值← 正确答案
  • C.百分之九十五的请求延迟高于该值
  • D.延迟最大值的平方再取百分之九十五

答案：B。把延迟从小到大排序，P95 是第 95% 位置的延迟值，表示 95% 的请求都比它快，用来暴露“尾部慢请求”。平均值会被极端值拉偏，而 P95 更真实地反映大部分用户的体验。

Q6. 链路追踪中，一个 span 记录的主要内容是什么？

单选题 · mid

  • A.单个服务段的开始与结束时间← 正确答案
  • B.日志文件的存储路径
  • C.容器的镜像版本号
  • D.指标的名称与计量单位

答案：A。span 是链路追踪的基本单元，记录某个服务处理请求的起止时间及标签信息。多个 span 按父子关系组成完整 trace；日志路径、镜像版本、指标单位都不是 span 的职责。

Q7. z-score 异常检测中，某点 z = 2.5 且判定阈值为 3，应如何处理？

单选题 · hard

  • A.判定为异常，立即触发告警
  • B.判定为正常，未越过异常阈值← 正确答案
  • C.无法判断需要人工介入
  • D.属于系统编译错误

答案：B。z = 2.5 表示偏离均值 2.5 个标准差，但阈值设定为 3，意味着只有 |z| > 3 才算显著异常。2.5 在阈值之内，应判为正常波动，不触发告警。这体现了阈值 k 对灵敏度的控制。

Q8. Cloud Monitoring 告警的通知渠道可以包含哪些？（多选）

多选题 · easy

  • A.电子邮件通知← 正确答案
  • B.短信与 Slack 消息← 正确答案
  • C.Webhook 回调接口← 正确答案
  • D.数据库表的字段新增

答案：ABC。邮件、短信、Slack、Webhook 都是官方支持的通知渠道，Webhook 还能联动自动化处理。数据库字段新增是存储操作，不是告警通知渠道，与告警分发无关。

Q9. 以下哪些做法属于构建 AI 服务可观测性的合理手段？（多选）

多选题 · mid

  • A.采集 GPU 利用率时间序列← 正确答案
  • B.聚合模型推理错误日志← 正确答案
  • C.追踪单次推理请求的全链路← 正确答案
  • D.屏蔽所有异常告警通知

答案：ABC。采集指标、聚合日志、链路追踪正好对应三大支柱，是建设可观测性的核心。屏蔽所有告警等于拆掉安防室的警报器，会让异常无人响应，属于错误做法。

Q10. 关于根因分析中的关联分析，以下说法正确的有哪些？（多选）

多选题 · hard

  • A.相关系数接近 +1 表示两个指标同向变化← 正确答案
  • B.相关系数接近 -1 表示两个指标反向变化← 正确答案
  • C.相关系数接近 0 表示两个指标基本无关← 正确答案
  • D.相关系数为 -1 表示两个指标完全正相关

答案：ABC。相关系数 ρ 取值 [-1,1]：+1 附近同涨同跌，-1 附近此消彼长，0 附近基本无关。D 把 -1 说成“完全正相关”是错误的，-1 是完全负相关。