监控告警

概述 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....

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....