监控告警

概述 告警是监控系统的"最后一公里"，也是最难做好的一环。一个常见的困境是：服务器上跑着几十个告警规则，每天产生上百条告警通知，值班工程师在微信/钉钉/邮件的轮番轰炸下逐渐麻木——真正紧急的告警被淹没在噪声中，直到客户投诉才发现系统早已出问题。 SRE 的黄金法则是：每一条告警都应该有明确的处理动作。如果一个告警收到后既不需要立即处理，也不需要记录跟踪，那它就不应该存在。从告警疲劳问题出发，详细梳理告警分级、SLO-based 告警设计、抑制与聚合策略、告警度量指标和治理方法，帮助你从"告警噪声"中提取出真正的"信号"。 参考来源：Google SRE Book《Monitoring Distributed Systems》、Prometheus 告警好的实践 一、告警疲劳：问题的根源 1.1 告警泛滥的典型表现 某团队告警统计（一周）： ┌──────────────────────────┬────────┬──────────┐ │ 告警类型 │ 数量 │ 实际处理 │ ├──────────────────────────┼────────┼──────────┤ │ CPU 使用率 > 80% │ 156 │ 3 │ │ 磁盘使用率 > 70% │ 89 │ 2 │ │ Pod 重启 │ 34 │ 5 │ │ HTTP 5xx 错误率 > 1% │ 12 │ 4 │ │ 数据库连接数 > 80% │ 8 │ 1 │ │ 证书即将过期 │ 3 │ 1 │ │ 服务不可达 │ 2 │ 2 │ ├──────────────────────────┼────────┼──────────┤ │ 总计 │ 304 │ 18 │ └──────────────────────────┴────────┴──────────┘ 有效告警率：18/304 = 5....

概述 Prometheus 默认是单节点架构，这在生产环境中是一个危险的隐患。一个 Prometheus 实例挂掉意味着整个监控体系失明——你无法在故障期间看到任何指标，告警也会因为规则不评估而完全失效。当数据量增长到单机存储和处理能力的极限时，还会面临写入超时、查询缓慢、磁盘爆满等问题。 本文系统性地分析 Prometheus 高可用和水平扩展方案，从最简单的双副本到 Thanos、Mimir、VictoriaMetrics、Cortex 等远程存储方案，帮助你根据实际场景做出正确的技术选型。 参考来源：Prometheus 官方文档 — HA、Thanos 官方文档 一、单点问题分析 1.1 单点 Prometheus 的风险 ┌──────────────┐ ┌───────────────┐ ┌──────────┐ │ Exporters │ ──→ │ Prometheus │ ──→ │ Grafana │ │ (targets) │ │ (单节点) │ │ Alertmgr│ └──────────────┘ └───────────────┘ └──────────┘ │ ┌──────┴──────┐ │ 本地 TSDB │ │ (15-30 天) │ └─────────────┘ 这个架构的脆弱点： 风险点 影响 发生概率 Prometheus 进程崩溃 监控完全中断，告警失效 中 宿主机宕机 同上，且可能丢失最近数据 中 磁盘故障 历史数据丢失 低-中 磁盘空间耗尽 写入失败，数据丢失 中-高 单机内存/CPU 不足 写入延迟、查询超时 高（数据量增长后） 网络分区 部分 target 无法采集 中 1....

概述 在 Prometheus 的监控体系中，服务发现（Service Discovery，简称 SD）是连接"被监控目标"与"采集引擎"的桥梁。当你的基础设施从几台虚拟机扩展到数百个 Kubernetes Pod、跨可用区云主机、Consul 注册节点时，手动维护 static_configs 就变成了一场灾难——每次扩容、缩容、迁移都要改配置、重启 Prometheus，告警还会因为 target 不可达而误报。 Prometheus 原生支持十余种服务发现机制，能够在目标变更后自动感知，无需重启。我将从静态配置出发，逐步深入 file_sd、kubernetes_sd、consul_sd、dns_sd、ec2_sd 等主流方案，并详细讲解 relabel_configs 标签管理这一核心能力，最后给出多集群监控的落地实践。 参考来源：Prometheus 官方文档 — Configuration 一、为什么需要服务发现 1.1 静态配置的局限 先看一个最简单的静态配置： scrape_configs: - job_name: 'node' static_configs: - targets: - '192.168.1.10:9100' - '192.168.1.11:9100' - '192.168.1.12:9100' labels: env: 'production' region: 'beijing' 这在服务器数量固定时没什么问题。但考虑以下场景： 场景 静态配置的痛点 Kubernetes Pod 扩缩容 Pod IP 每次重建都变，手动改配置不现实 云厂商 Auto Scaling 弹性伸缩后新实例无法被监控，存在盲区 蓝绿部署 / 金丝雀发布 新版本实例需要自动加入监控 多机房迁移 IP 段变更，需要批量修改配置 容器化微服务 实例数量随时变化，生命周期短 1.2 服务发现的核心价值 ┌─────────────┐ ┌───────────────────┐ ┌──────────────┐ │ 服务注册中心 │ ← 感知 → │ Prometheus SD │ ← 采集 → │ Target 实例 │ │ (Consul/K8s) │ │ (自动更新 target) │ │ (Exporter) │ └─────────────┘ └───────────────────┘ └──────────────┘ │ ▼ ┌───────────────────┐ │ relabel_configs │ │ (标签过滤/改写) │ └───────────────────┘ 服务发现机制让 Prometheus 从"被动配置"变为"主动感知"：...

概述 凌晨三点，手机震动。你从被窝爬起来，打开电脑，SSH 上去，发现某个服务 CPU 飙升。Kill 进程，重启服务，12 分钟搞定——但你彻底清醒了。四点半又来一条告警：磁盘使用率超 85%。又爬起来，du -sh 定位，删掉过期日志，15 分钟。 这是无数运维工程师的日常。监控做了，告警配了，脚本也写了——但最后一步还是人在跑。而且偏偏在凌晨。 根据 Google SRE Book 的数据，一个典型的 SRE 团队每天接收 50-100 条告警，其中 80% 是噪音，超过 60% 的告警是重复处理过的已知问题。 告警自动化的目标不是消灭告警，而是把人的判断和操作转化为系统的自动响应。我将从告警降噪、分级路由、Runbook 自动化、自愈平台架构、AI 辅助治理五个维度，详细梳理如何构建告警自动化处理体系。 告警现状：为什么需要自动化 告警风暴的根源 告警风暴通常不是监控配置不足，而是配置泛滥的产物。以下是生产环境中最常见的告警问题模式： 问题模式 典型表现 根因 告警泛滥 每天 100+ 条告警，80% 无需人工介入 静态阈值过敏感，缺少聚合和去重 告警疲劳 工程师忽略告警通知，真正故障被淹没 信号噪声比太低，缺少优先级分级 重复告警 同一问题触发多条告警，不同监控视角 缺少告警关联和聚合机制 响应延迟 从告警到人工处理平均 15-30 分钟 缺少自动化响应，依赖人工介入 重复劳动 超过 60% 的告警处理流程完全相同 没有将已知操作沉淀为自动化 Runbook 告警生命周期的五个阶段 一个成熟的告警自动化系统应该覆盖告警的完整生命周期： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 1. 产生 │────▶│ 2. 降噪 │────▶│ 3....

为什么需要分布式追踪 微服务架构下，一个用户请求往往要穿越多个服务。当某个接口耗时从 200ms 飙升到 2s 时，日志散落在 N 台机器上，你很难判断瓶颈在哪一层——是网关转发慢、下游 DB 查询慢、还是某个服务间调用排队？ 分布式追踪（Distributed Tracing）解决的就是这个问题：它为每个请求生成一个全局唯一的 Trace ID，在服务间透传，最终在 UI 上画出一条完整的调用链路树，让每一段耗时一目了然。 Jaeger（发音类似"耶格"）由 Uber 开源，现为 CNCF 毕业项目。本文基于 Jaeger v1.60+ 和 OpenTelemetry SDK 进行实践。官方文档 分布式追踪核心概念 Trace 一个 Trace 代表一次完整的分布式请求链路，由唯一的 128-bit Trace ID 标识。它是一棵由多个 Span 组成的树形结构： Trace (TraceID: a1b2c3...) ├── Span: HTTP GET /api/orders [gateway] │ ├── Span: RPC GetUser [user-service] │ │ └── Span: SELECT * FROM users [mysql] │ └── Span: RPC GetOrderList [order-service] │ └── Span: Redis GET [redis] Span Span 是追踪的最小单元，记录一次操作的开始和结束。关键字段：...

概述 在可观测性的三大支柱（Metrics、Logs、Traces）中，日志是最贴近应用层的数据。当线上服务出现异常，第一反应往往是"看日志"。ELK Stack（Elasticsearch + Logstash + Kibana）是日志分析领域的事实标准，在全文检索、日志解析、可视化分析方面功能强大。 随着 Loki 等"轻量级"日志方案兴起，ELK 面临着"存储成本高、运维复杂"的质疑。但 ELK 在全文检索、复杂文本分析、结构化日志聚合等方面的能力仍然无可替代。从架构原理到部署配置，详细梳理 ELK 日志分析平台的建设实践，并与 Loki 做对比分析，帮助你判断何时该选 ELK、何时该选 Loki。 参考来源：Elastic 官方文档 一、ELK Stack 架构 1.1 整体架构 ┌──────────────────────────────────────────────────────────────┐ │ ELK Stack 完整架构 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ App/Node│ │ App/Node│ │ App/Node│ ← 日志源 │ │ │ log file│ │ log file│ │ log file│ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │Filebeat │ │Filebeat │ │Filebeat │ ← 轻量采集器 │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ └────────────┼────────────┘ │ │ ▼ │ │ ┌────────────┐ │ │ │ Logstash │ ← 日志解析/过滤/转换 │ │ │ (可选) │ │ │ └──────┬─────┘ │ │ ▼ │ │ ┌──────────────────────────────────────┐ │ │ │ Elasticsearch 集群 │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ │ │Node1│ │Node2│ │Node3│ ← 存储 + 检索│ │ │ │ │(数据)│ │(数据)│ │(主从)│ │ │ │ │ └─────┘ └─────┘ └─────┘ │ │ │ └──────────────────┬───────────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────┐ │ │ │ Kibana │ ← 可视化 + 查询 │ │ └────────────┘ │ └──────────────────────────────────────────────────────────────┘ 1....

Grafana 是云原生时代最主流的可视化平台，但"能用"和"好用"之间隔着一套设计方法论。一个混乱的仪表盘会让值班人员在海量面板中迷失，而一个设计良好的仪表盘能在 5 秒内传递系统健康状态。从设计原则出发，覆盖变量系统、面板选型、告警集成，最后用一个完整的 SLO 仪表盘串联所有知识点。 参考来源：Grafana 官方文档 一、仪表盘设计原则 1.1 五秒规则 一个仪表盘应该在 5 秒内回答最核心的问题：系统现在是否正常？ 超过 5 秒才理解，说明信息层次不对。 实践方法： 顶部放置全局状态行：用 Stat 或 Gauge 面板展示 SLO 达成率、核心错误率、P99 延迟，绿/黄/红阈值一目了然。 中部放置趋势图：Time series 面板展示过去 1-6 小时的指标趋势。 底部放置明细表：Table 面板列出实例级明细，供深入排障。 1.2 从左到右、从上到下 人类阅读习惯是从左上到右下，仪表盘的信息流应顺应这一规律： ┌─────────────────────────────────────────────┐ │ [SLO] [错误率] [P99延迟] [流量] │ ← 第一行：一眼看状态 ├─────────────────────────────────────────────┤ │ CPU 趋势图 │ 内存趋势图 │ ← 第二行：趋势 │ 请求量趋势图 │ 错误率趋势图 │ ├─────────────────────────────────────────────┤ │ 实例明细表 │ ← 第三行：明细 └─────────────────────────────────────────────┘ 1.3 其他设计要点 一个仪表盘只服务一个主题：不要把"数据库监控"和"业务指标"混在一个仪表盘里。 合理利用阈值颜色：绿色=正常，黄色=警告，红色=严重，不要滥用颜色。 默认时间范围设为"最近 1 小时"：值班场景最常用。 命名清晰：面板标题写"CPU 使用率 (%)“而非"cpu”。 二、变量模板系统 变量（Variables）是仪表盘可复用性的核心。通过变量可以实现"一套模板，多环境切换"。...

概述 监控系统选型时，最纠结的问题之一是"用商业平台还是自建开源方案"。Datadog 是商业可观测性平台的标杆，开箱即用、功能全面、集成丰富，但价格不菲。Prometheus + Grafana 是开源自建方案的代表，灵活可控、无许可费用，但需要投入运维人力。 这不是一个简单的"省钱 vs 省事"的选择。对于快速增长的创业公司，Datadog 的开箱即用可能比省下的许可费更有价值；对于大规模基础设施，开源方案的边际成本优势会越来越明显。从功能、成本、运维、风险等多个维度系统对比两类方案，提供结构化的选型决策框架。 参考来源：Datadog 官网定价、CNCF 可观测性调查 一、Datadog 功能概览 1.1 产品矩阵 Datadog 提供了一个覆盖可观测性全生命周期的产品矩阵： ┌──────────────────────────────────────────────────────┐ │ Datadog 产品矩阵 │ │ │ │ 基础设施层 │ │ ├── Infrastructure Monitoring (主机/容器监控) │ │ ├── Network Monitoring (网络性能监控) │ │ └── Serverless (AWS Lambda/云函数监控) │ │ │ │ APM 层 │ │ ├── APM (分布式追踪) │ │ ├── Database Monitoring (数据库监控) │ │ ├── Continuous Profiling (性能分析) │ │ └── Real User Monitoring (前端 RUM) │ │ │ │ 日志层 │ │ ├── Log Management (日志采集+分析) │ │ └── Log Patterns (日志模式自动分类) │ │ │ │ 合成监控 │ │ ├── Synthetics (API/浏览器拨测) │ │ └── Continuous Testing (CI 集成测试) │ │ │ │ 安全与合规 │ │ ├── Cloud Security Management (云安全态势) │ │ └── Cloud SIEM (安全事件管理) │ │ │ │ 其他 │ │ ├── Incident Management (事件管理) │ │ ├── CI Visibility (CI/CD 可视化) │ │ └── Watchdog (AI 异常检测) │ └──────────────────────────────────────────────────────┘ 1....

PromQL（Prometheus Query Language）是 Prometheus 监控系统的查询语言，也是整个云原生监控体系的核心。无论是构建 Grafana 仪表盘、编写告警规则，还是进行故障排查时的临时查询，都离不开 PromQL。我将从数据模型出发，逐步深入到聚合操作、常用函数和实战查询，最后覆盖子查询等高级技巧。 参考来源：Prometheus 官方文档 — Querying basics 一、PromQL 数据模型 PromQL 有四种基本数据类型，理解它们是写对查询的前提： 类型 说明 示例 即时向量（Instant Vector） 一组时间序列在当前时刻的采样值 node_cpu_seconds_total 范围向量（Range Vector） 一组时间序列在过去一段时间内的所有采样值 node_cpu_seconds_total[5m] 标量（Scalar） 一个简单的数值 3.14、1024 字符串（String） 字符串值（较少使用） "hello" 最常用的两种： 即时向量：仪表盘和告警中最常见，返回"当前这一刻"各序列的值。 范围向量：用于 rate()、increase() 等函数计算，必须带时间窗口 [...]。 # 即时向量：返回当前所有序列 up # 范围向量：返回过去5分钟内的所有采样点 up[5m] # 标量 1 - 0.3 二、基础查询 2.1 Metric 选择与标签过滤 通过标签选择器可以精确过滤目标序列： # 选择名为 node_cpu_seconds_total 的所有序列 node_cpu_seconds_total # 按 mode 标签过滤 node_cpu_seconds_total{mode="idle"} # 多标签组合（AND 关系） node_cpu_seconds_total{instance="node-1:9100", mode="idle"} # 标签正则匹配 node_cpu_seconds_total{instance=~"node-[0-9]+:9100"} # 标签反向匹配（排除某些值） node_cpu_seconds_total{mode!...

为什么选择 Loki 传统 ELK（Elasticsearch + Logstash + Kibana）方案虽然功能强大，但存在两个核心痛点： 存储成本高：Elasticsearch 将日志全文索引化，每条日志的索引膨胀可达原始数据的 3-5 倍 运维复杂：ES 集群扩缩容、分片再平衡、索引生命周期管理复杂，生产集群维护成本高 Loki 由 Grafana Labs 开源，设计理念是"像 Prometheus 那样做日志"。它只对日志的标签（Labels）做索引，不对日志正文建索引，通过 LogQL 进行全文检索。这种设计使存储成本降低 10 倍以上。 本文基于 Loki 3.x，参考 Loki 官方文档 Loki vs ELK 对比 维度 ELK (Elasticsearch) Loki 索引方式 全文倒排索引 仅索引标签，正文不索引 存储成本 高（索引膨胀 3-5x） 低（标签索引 + 压缩正文） 查询语言 Lucene Query / KQL LogQL（类 PromQL 语法） 扩展性 水平扩展，分片复杂 微服务模式，组件独立扩展 适用场景 全文检索、复杂分析 日志监控、指标化查询、与 Grafana 联动 资源消耗 高（JVM，内存大） 低（Go 编写，内存友好） Loki 并非要完全替代 ES。如果你的核心需求是全文检索和复杂文本分析，ES 仍是更好的选择。但对于 SRE 日志监控、指标告警、排障定位这类场景，Loki + Grafana 的组合在成本和效率上优势明显。...