监控告警

概述 凌晨两点，支付系统告警炸了。看了半天日志发现不是下游服务挂了，而是 API 网关的连接池打满了——请求堆在网关这一层根本没转发出去。但你的监控大盘上只有 CPU 和内存曲线，压根看不到网关层的延迟、连接数和错误率。 这不是个例。我见过太多团队把 API 网关当"高级 Nginx"用，监控只看 nginx_active_connections，出事了才去翻日志。问题是网关是所有流量的咽喉，一旦这层出问题，影响面是全局的。 这篇文章讲清楚三件事：Kong、APISIX、Envoy 各自暴露哪些指标、怎么用 Prometheus 采集、告警规则怎么设计才能在故障扩散前收到通知。不是泛泛而谈的"最佳实践"，是我在生产环境踩过坑后整理出来的方案。 为什么 API 网关需要专门的监控 你可能会想：网关后面已经有服务监控了，为什么还要单独监控网关？ 因为网关和后端服务看到的世界不一样。举个例子： 维度 网关视角 后端服务视角 请求延迟 包含路由匹配、插件执行、上游转发全链路 只看到自己处理那段 错误来源 可能是路由不存在、插件拦截、上游超时、连接池满 只知道返回了 500 连接状态 能看到与上游的连接池使用率 只知道自己收了多少请求 限流触发 网关层限流命中了哪些规则 服务端可能根本不知道被限了 简单说，网关是流量高速公路的收费站。收费站堵了，后面所有车都堵。你不在收费站装监控，等问题传导到后端服务再排查，黄花菜都凉了。 三大主流网关的指标体系对比 Kong 的指标暴露 Kong 通过 prometheus 插件暴露指标，启用方式很简单： # 启用 Prometheus 插件（全局级别） curl -X POST http://kong-admin:8001/plugins \ --data "name=prometheus" \ --data "config.per_consumer=true" \ --data "config.status_code_metrics=true" \ --data "config.latency_metrics=true" \ --data "config.upstream_health_metrics=true" 启用后访问 http://kong-proxy:8001/metrics 就能拿到 Prometheus 格式的指标。Kong 的核心指标分四类：...

概述 后端监控做得再花，用户打开页面白屏 5 秒，你的 SLO 全绿也是白搭。 这话不是我故意唱反调。很多团队的监控大盘里全是 CPU、内存、QPS、P99 延迟，看着一片祥和。可真实用户的投诉邮件已经在客服那边堆成山了——“页面打开慢”、“点不动”、“图片一直闪”。问题出在哪？你监控的是服务器视角，用户看到的是浏览器视角，中间隔着 CDN 缓存、DNS 解析、第三方脚本阻塞、渲染管线，任何一环拉胯，用户的体验就崩了。 这篇文章要解决的问题是：怎么把"用户实际感受到的性能"量化成指标，采集起来，配上告警，最后形成优化闭环。核心是两件事——Core Web Vitals 指标体系和真实用户监控（RUM，Real User Monitoring）。 前端性能监控和后端监控有一个本质区别：后端监控的是"我的服务处理得快不快"，前端监控的是"用户等得久不久"。同一个接口，后端 P99 是 50ms，但用户在 4G 网络下等了 3 秒才看到内容——中间差的那 2.95 秒，只有前端监控能看到。 Core Web Vitals：用户感受的"体温计" 三大核心指标 Google 定义的 Core Web Vitals 是目前业界最主流的前端体验量化标准，聚焦三个维度： 指标 全称 衡量什么 良好阈值 需改进 差 LCP Largest Contentful Paint 最大内容绘制时间 ≤ 2.5s 2.5-4.0s > 4.0s INP Interaction to Next Paint 交互到下一帧绘制延迟 ≤ 200ms 200-500ms > 500ms CLS Cumulative Layout Shift 累计布局偏移 ≤ 0....

概述 Prometheus 的常规监控是"从内向外看"——Prometheus 采集 Exporter 指标，了解系统内部状态。但用户访问你的服务时，走的是"从外向内"的路径：DNS 解析 → 网络路由 → 负载均衡 → 后端服务。一条从内部看完全健康的链路，可能因为 DNS 配置错误、CDN 缓存问题或 SSL 证书过期而导致用户完全无法访问。 Blackbox Exporter 解决的是"从外部探测"的问题。它模拟用户行为，从外部对 HTTP/TCP/ICMP/DNS 端点发起探测，让你获得"用户视角"的可用性数据。详细梳理 Blackbox Exporter 的配置、各类探测方式、SSL 证书监控、多地域拨测方案和可用性 SLO 度量。 参考来源：Blackbox Exporter 官方文档 一、为什么需要外部探测 1.1 内部监控的盲区 用户请求路径： 用户 → DNS → CDN → 负载均衡 → Ingress → Pod → 数据库 内部监控覆盖： ✓ Pod 指标 ✓ 数据库指标 ✓ Ingress 指标 ✓ LB 指标 外部盲区： ✗ DNS 解析是否正常？ ✗ CDN 缓存是否正确？ ✗ SSL 证书是否过期？ ✗ 网络路由是否通畅？ ✗ 从用户地域访问是否可达？ 内部监控无法覆盖的典型场景：...

概述 在云原生和微服务时代，一个请求可能跨越数十个服务节点。传统的监控方式将 Metrics、Logs、Traces 分散在不同系统中——Prometheus 看指标、ELK 搜日志、Jaeger 追链路，三者之间没有统一的关联方式。当线上故障发生时，你需要在三个系统之间来回切换，手动拼接关联信息，效率低下。 OpenTelemetry（简称 OTel）是 CNCF 主导的可观测性统一标准，目标是用一套 SDK/API 统一采集三大信号（Metrics、Logs、Traces），通过统一的 Collector 处理后发送到任意后端。它不替代后端存储和可视化，而是解决"数据采集层碎片化"的问题。本文深入讲解 OTel 的规范、架构、实践和迁移策略。 参考来源：OpenTelemetry 官方文档、CNCF OpenTelemetry 规范 一、为什么需要 OpenTelemetry 1.1 可观测性碎片化问题 传统可观测性架构（碎片化）： 应用代码 ├── Prometheus Client (Metrics) │ └── → Prometheus → Grafana ├── Logback + Filebeat (Logs) │ └── → Elasticsearch → Kibana └── Jaeger Client (Traces) └── → Jaeger → Jaeger UI 问题： 1. 三套 SDK，三套配置，三套运维 2. Metrics / Logs / Traces 之间无关联（TraceID 未关联到日志） 3....

概述 传统的监控方式是"被动式"的——等待用户访问触发系统行为，然后采集指标和日志。这种方式有一个根本缺陷：当监控发现问题时，用户已经受到影响。如果你的首页加载了 10 秒，你的监控告警可能在 5 分钟后才触发，而此时已有上千用户体验了糟糕的性能。 合成监控（Synthetic Monitoring）是"主动式"的监控方式——它通过模拟真实用户行为，定期访问关键路径，在用户感知到问题之前就发现并修复。就像一名"虚拟用户"24 小时不间断地测试你的系统，任何异常都能在第一时间被捕获。详细梳理合成监控的原理、实践和工具选型。 参考来源：Grafana Synthetic Monitoring 文档、Datadog Synthetics 文档 一、合成监控原理 1.1 什么是合成监控 合成监控通过预定义的脚本或配置，模拟用户行为（打开页面、点击按钮、提交表单、调用 API），定期执行并记录结果： ┌──────────────────────────────────────────────────────┐ │ 合成监控工作流程 │ │ │ │ ┌──────────────┐ │ │ │ 探测节点集群 │ ← 全球分布的探测节点 │ │ │ (Beijing/ │ │ │ │ Shanghai/ │ │ │ │ Overseas) │ │ │ └──────┬───────┘ │ │ │ │ │ │ 定时执行探测脚本 │ │ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 模拟用户行为 │ ──→ │ 目标系统 │ │ │ │ • 打开页面 │ │ (Web/API) │ │ │ │ • 点击按钮 │ └──────┬───────┘ │ │ │ • 填写表单 │ │ │ │ │ • 调用 API │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌──────────────┐ │ │ │ │ 记录结果 │ ←─────────┘ │ │ │ • 状态码 │ │ │ │ • 响应时间 │ │ │ │ • 页面内容 │ │ │ │ • 截图 │ │ │ │ • Trace │ │ │ └──────┬───────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ 告警 + 仪表盘│ │ │ └──────────────┘ │ └──────────────────────────────────────────────────────┘ 1....

概述 Prometheus 作为云原生监控的事实标准，几乎成为了微服务和 Kubernetes 监控的默认选择。然而，随着业务规模增长，Prometheus 的本地存储架构逐渐暴露出明显瓶颈：单机存储容量有限（默认 15 天保留期）、缺乏原生水平扩展能力、高基数场景下内存飙升、历史数据查询困难。很多团队在时间序列突破百万级别后，开始面临磁盘 IO 压力、存储成本膨胀和查询延迟增长的"三重困境"。 为解决这些问题，社区涌现了 Thanos、Cortex、VictoriaMetrics 等多种长期存储方案。其中 VictoriaMetrics（以下简称 VM）凭借卓越的压缩率、极简的运维复杂度和出色的查询性能，成为越来越多团队的首选。 将详细梳理 VictoriaMetrics 的架构设计、部署模式、数据迁移、性能调优和生产环境好的实践，帮助你在实际项目中做出正确的技术选型和落地。 为什么选择 VictoriaMetrics Prometheus 的存储瓶颈 理解 VictoriaMetrics 的价值，首先需要明白 Prometheus 的存储瓶颈在哪里： 问题 原因 影响 数据保留期短 默认 TSDB 仅保留 15 天 无法做长期趋势分析 无法水平扩展 单实例架构，无分片机制 单机内存和磁盘成为硬上限 高基数内存膨胀 标签组合爆炸导致内存索引激增 OOM 频发，监控不可用 全局查询困难 多实例数据分散 跨集群查询需额外方案 远程存储延迟 remote_write 同步模型 网络问题导致数据丢失 VictoriaMetrics 的核心优势 VictoriaMetrics 的设计理念是：在完全兼容 Prometheus 生态的前提下，提供更高的性能和更低的资源消耗。 1. 卓越的数据压缩 VM 采用自研的列式存储引擎，针对时间序列数据特征深度优化。根据官方基准测试和大量社区实践，在存储相同监控数据时，VM 所需磁盘空间通常只有 Prometheus TSDB 的 1/5 到 1/7。 # 数据压缩效果对比（基于 100 万活跃时间序列，30 天数据） 存储方案 磁盘占用 压缩比 内存占用 ───────────────────────────────────────────────────────── Prometheus (本地) 350 GB 1x 8 GB Thanos (S3) 120 GB 2....

概述 告警是监控系统的"最后一公里"，也是最难做好的一环。一个常见的困境是：服务器上跑着几十个告警规则，每天产生上百条告警通知，值班工程师在微信/钉钉/邮件的轮番轰炸下逐渐麻木——真正紧急的告警被淹没在噪声中，直到客户投诉才发现系统早已出问题。 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 从"被动配置"变为"主动感知"：...

概述 在可观测性的三大支柱（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....