监控与告警
监控采集系统状态，告警触发需要处理的事件。本文负责 Prometheus、指标设计和告警规则。
1. 面试核心
先记住这几条，再读正文- 采集与通知。 Prometheus 采集并计算规则，Alertmanager 管理通知。卡 · Prometheus 的组成
- 时间序列身份。 指标名称与完整标签集共同标识时间序列。
- 跨实例聚合。 Counter 速率应先按序列计算，再跨实例求和。卡 · 分位数聚合与速率
- 服务指标。 服务指标包含延迟、流量、错误与饱和度。卡 · 服务与资源指标
- 告警收敛。
for约束持续触发时间，分组和抑制减少重复通知。卡 · 告警设计
2. Prometheus 的组成
| 组件 | 分工 |
|---|---|
| Prometheus Server | 发现目标、抓取、存储、查询和计算规则 |
| 应用客户端库 | 在应用内记录并暴露指标 |
| Exporter | 将系统状态转换成可抓取指标 |
| Pushgateway | 为特定批处理任务保留推送指标 |
| Alertmanager | 分组、去重、抑制、静默和路由 |
| Grafana | 展示查询和看板 |
| 远程存储 | 支持长期保存或跨集群查询 |
默认抓取路径为 /metrics，可按目标配置。发现机制提供目标，relabel 规则筛选并改写标签。Kubernetes 可发现 Pod、Service 和 EndpointSlice。Operator 的 ServiceMonitor、PodMonitor 用来声明抓取配置。
up == 0 表示某个已发现目标抓取失败。目标从发现结果消失后，原 up 序列也会消失。该情形还需缺失检测或预期目标数量校验。
2.1 指标类型
| 类型 | 含义与用途 |
|---|---|
| Counter | 累计事件数，可在重启时重置 |
| Gauge | 当前值，可上升或下降 |
| Histogram | 保存分布，可聚合后计算分位数 |
| Summary | 提供 sum、count 及预先计算的分位数 |
每个标签组合都会形成独立序列。用户 ID、完整 URL 等高基数标签会扩大存储和查询成本。HTTP 路径可用模板值，例如 /users/:id。
Zabbix 提供主机模板及多种主动、被动采集。Prometheus 以标签和 PromQL 组织时序分析。选型应结合采集对象、服务发现与维护成本。
2.2 Pushgateway 与监控高可用
Pushgateway 适合服务级短生命周期批处理任务。它保留已推送的数据，直到显式删除。任务消失后，旧成功指标仍会继续被抓取。因此，任务完成时间和旧序列清理都需设计。
长期服务优先暴露抓取端点。多个 Prometheus 可独立抓取同一目标。Alertmanager 集群协作去重通知。查询侧仍需处理重复序列，具体依赖远程存储方案。
外部心跳接收端检查通知是否按时到达。它用于验证规则、通知和接收链路。心跳接收端应独立于被监控系统。
3. 服务与资源指标
| 黄金信号 | 示例 |
|---|---|
| 延迟 | 成功与失败请求分别统计 P50、P99 |
| 流量 | QPS、并发连接、新连接速率 |
| 错误 | 5xx、业务失败、超时比例 |
| 饱和度 | 队列积压、池等待、资源压力 |
USE 分别检查资源使用率、饱和度与错误。CPU 可结合运行队列与限流。内存可结合 PSI、回收和 OOM。磁盘检查空间、inode、I/O 延迟和设备错误。
代理服务还需监控每个上游的延迟与失败。TLS 证书期限、文件描述符和连接数也影响接入。业务层补充交易成功率，用户侧补充外部拨测。
4. 告警设计
需要立即响应的告警，应对应用户影响或明确风险。每条规则需写清负责人、影响和处置入口。资源指标还可用于工单与容量规划。
| 机制 | 作用 |
|---|---|
for: 5m | 条件持续成立后进入 firing |
keep_firing_for | 条件消失后继续保留 firing 一段时间 |
| 分组 | 合并同服务或同事故的通知 |
| 抑制 | 已有上层故障时，抑制关联衍生告警 |
| 静默 | 按匹配器和时间窗口暂停通知 |
| 路由 | 根据标签选择接收人和通知渠道 |
规则先进入 pending，持续满足 for 后进入 firing。Alertmanager 的 group_wait 是等待聚合首批通知。repeat_interval 则控制重复通知间隔。它们处理的是不同阶段。
迟滞需要独立的进入和退出条件。单独设置 for 只增加持续时间，无法实现双阈值。keep_firing_for 提供延迟恢复，语义也不同。
SLO 消耗告警可组合长短窗口，见 SRE 的职责与工作方式。磁盘趋势预测可使用 predict_linear。流量低或数据缺失时，应另行核对统计有效性。
严重告警需要值班确认与超时升级。升级可由外部值班系统实现。Alertmanager 的通知路由本身没有人工确认流程。
5. 分位数聚合与速率
以下示例针对经典 Histogram，并保留 job 维度。
histogram_quantile(
0.99,
sum by (job, le) (
rate(http_request_duration_seconds_bucket[5m])
)
)
rate 先处理各实例的计数重置。sum 再合并同一服务的桶。le 保留桶边界，最后计算整体 P99。参与合并的经典直方图应使用一致的桶边界。
Summary 的分位数无法直接相加或平均成整体分位数。它的 sum 与 count 仍可聚合以计算均值。
服务错误率应使用错误总速率除以请求总速率。
sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
/
sum by (job) (rate(http_requests_total[5m]))
该计算按各实例请求量加权。直接平均实例错误率会让低流量实例获得过高权重。还需处理零请求和错误序列未初始化的情形。数据缺失检测可使用 absent_over_time。动态服务也需维护预期目标的独立信息。
6 · 面试题卡片
本页题目与参考回答
6.1 Prometheus 的架构是怎样的？它怎样发现和抓取目标？与 Zabbix 有什么区别？
考察重点
- Server、Exporter、Pushgateway、Alertmanager 的分工和拉取模型。
- 服务发现与 relabel；指标类型；与 Zabbix 的定位差异。
相关内容：Prometheus 的组成。
参考回答
Prometheus Server 发现并抓取目标，存储时序并计算规则。
应用埋点或 Exporter 提供指标。Alertmanager 管理分组、去重、静默、抑制与通知。
服务发现提供目标，relabel 筛选并改写标签。Operator 可用 ServiceMonitor 或 PodMonitor 描述采集。抓取失败会产生 up=0，目标消失还需缺失检测。
Zabbix 提供主机模板及主动、被动采集。Prometheus 用标签与 PromQL 分析动态目标。两者选择取决于对象、查询及运维需求。
6.2 如果要监控一个生产环境的服务（例如一台代理服务器），你会监控哪些指标？
考察重点
- 用黄金信号、USE 方法组织指标，而不是罗列。
- 分层覆盖：资源、中间件、应用、业务、用户侧。
相关内容：服务与资源指标。
参考回答
服务应覆盖延迟、流量、错误和饱和度。
再用 USE 方法检查 CPU、内存、磁盘与网络。
代理服务重点看上游分布、连接数与建立速率。还需检查 TLS 证书、文件描述符和超时。业务成功率与外部拨测用于验证用户实际结果。
看板用于定位原因，紧急告警用于触发明确处置。每条告警应能关联影响、负责人和处理入口。
6.3 告警怎样设置才合理？一个指标在阈值附近反复触发、一天告警几百次，怎样降下来？告警怎样收敛和升级？
考察重点
- 告警关联用户影响，并给出可执行动作。
- 持续时间、迟滞、平滑、分组、抑制等降噪手段；分级与升级；告警系统自身的可用性。
相关内容：告警设计。
参考回答
告警应对应用户影响或需要处理的容量风险。
阈值结合 SLO、基线与处置时限设定。
瞬时尖峰可用 for 过滤。恢复抖动可用 keep_firing_for 缓解。双阈值迟滞需要额外状态逻辑，for 本身无法实现。
Alertmanager 按标签分组，并抑制关联衍生告警。静默用于计划维护。值班确认与升级可交给外部值班系统。外部心跳检测规则到通知的完整链路。
6.4 多个实例的 P99 能直接平均吗？错误率怎样跨实例聚合？
考察重点：分布合并、计数重置与流量加权。
相关内容：分位数聚合与速率。
参考回答
整体 P99 要从聚合后的 Histogram 计算，错误率要用错误总速率除以请求总速率。
直接平均各实例 P99 会丢失请求数量和延迟分布信息。
经典 Histogram 先按序列计算 rate，再按 job 和 le 求和，最后用 histogram_quantile 计算分位数。Summary 的分位数无法这样合并，但 sum 和 count 可以聚合。
6.5 目标消失为什么不一定触发 up==0？Pushgateway 有什么生命周期问题？
考察重点：目标缺失、旧序列与独立检测。
相关内容：Prometheus 的组成、Pushgateway 与监控高可用。
参考回答
up=0 对应仍被发现但抓取失败的目标。
目标被移除后，up 序列会消失。缺失检测需结合 absent_over_time 和预期目标信息。Pushgateway 则保留推送序列，直到显式删除。旧成功指标会掩盖任务停止，应检查完成时间。