Prometheus

概述 凌晨三点，告警群炸了。 5 个 Pod 在 10 分钟内陆续 OOMKilled 重启。值班同学打开 Grafana 看内存曲线，事发前所有 Pod 的 working_set 离 limit 还有 200MB，使用率 80%。监控显示一切正常，Pod 照样死了。 这不是个例。在某新能源物流平台做 K8s 迁移时，这类"监控绿着 Pod 就死了"的事故我处理过不下 10 次。根因每次都一样：运维团队只盯了一个指标，而且盯的那个指标会骗人。 容器内存不是单一数值。cAdvisor 暴露了四个维度的内存指标，大部分团队只用 container_memory_working_set_bytes 做告警基线。问题在于，当 page cache 已经很小时，working_set 显示 80% 可能意味着实际只剩 5% 的可分配额度——你看到的 20% 余量根本不存在。 本文拆解容器内存监控的四层指标迷雾，给出 5 个生产级预警决策，包含完整的 PromQL recording rules、告警规则和 Grafana 查询。这套配置在某新能源物流平台 120+ 微服务集群上跑了 6 个月，OOM 预警准确率从 60% 提升到 95%，误报率从 40% 降到 5%（相关文章：告警策略设计：从噪声到信号）。 容器内存的四层指标迷雾 cAdvisor 暴露了什么 cAdvisor（Container Advisor）是 K8s 节点上 kubelet 内置的容器监控组件，通过 /metrics 端点暴露 Prometheus 格式的指标。在内存维度，它暴露了四个关键指标，每个都对应不同的 cgroup 底层字段：...

概述 CDN 接入后，很多团队的监控就停留在厂商控制台看个命中率数字。命中率 90%？挺好，不管了。直到某天源站带宽被打满、页面加载 8 秒、用户投诉炸了，才发现那个 90% 是请求命中率而不是字节命中率——大文件全在回源，小请求被缓存命中拉高了数字。 这篇文章拆解一套我在生产环境中落地过的 CDN 监控体系。不是堆指标罗列，而是围绕"缓存命中率、回源带宽、边缘节点健康度"三个核心维度，讲清楚每个指标怎么采集、怎么看、出了问题怎么排查。最后用 5 个真实排障案例串起来，每个都带具体数据和决策过程。 先说清楚 CDN 监控和普通应用监控的区别：应用监控是你自己部署的组件，指标完全可控；CDN 监控的对象是第三方或自建的边缘网络，很多指标得从厂商 API 拉取或者从日志里算，采集链路更长，排查时干扰因素更多。 一、CDN 监控的核心指标体系 1.1 三个维度，别贪多 CDN 涉及的指标不下 30 个，但真正影响业务决策的就三类： 维度 核心指标 告诉你什么 数据来源 缓存效率 请求命中率、字节命中率 CDN 有没有把流量挡在边缘 厂商 API / 日志分析 回源压力 回源 QPS、回源带宽、回源错误率 源站扛不扛得住 厂商 API / 源站 Nginx 日志 边缘健康 节点可用率、边缘延迟 P95/P99、CDN → 源站延迟 用户到 CDN 这一段通不通 拨测 / RUM / 厂商 API 很多团队只看命中率，不看回源带宽。这就好比只看超市收银台开了几个，不看仓库门有没有被搬空。命中率 95% 听着不错，但如果那 5% 的回源全是 50MB 的视频文件，源站出口带宽照样被打满。...

概述 凌晨两点，支付系统告警炸了。看了半天日志发现不是下游服务挂了，而是 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 的核心指标分四类：...

概述 凌晨三点，手机被告警轰炸。Kafka 某个消费者组的 Lag 从 200 飙到 50 万，下游实时报表全部卡住，数据团队在群里疯狂 at 你。你爬起来连上跳板机，敲 kafka-consumer-groups.sh --describe，看到 Lag 列一串刺眼的数字。接下来半小时，你要回答三个问题：积压在哪个分区？消费者是死了还是慢了？加机器能救吗？ 消息队列是分布式系统的"下水道"——平时没人关注，一旦堵了整栋楼都得停工。Consumer Lag（消费者延迟）就是下水道的流量计，它告诉你生产者往里灌水的速度和消费者抽水的速度差了多少。这个差值持续增大，说明系统出了问题；差值突然归零，也可能出问题（消费者挂了，offset 不再提交，Lag 反而看起来正常）。 这篇文章覆盖 Kafka、RabbitMQ、Redis 三种主流消息队列的监控方案，从指标采集、Prometheus 规则、告警阈值到排障思路，都是我在生产环境踩过坑的实战经验。不讲理论，直接上配置。 为什么 Consumer Lag 是最核心的指标 先说清楚 Lag 到底是什么。Kafka 里每个分区有一个 LogEndOffset（LEO，最新消息位置），消费者组有一个 CurrentOffset（已提交位置）。两者的差值就是 Lag： Lag = LogEndOffset - CurrentOffset Lag 为 0 说明消费者完全跟上。但生产环境小幅波动很正常，单分区 Lag < 100 基本不用管。真正要警惕的是三种模式： Lag 模式 典型原因 危险程度 持续线性增长 消费速度 < 生产速度，处理能力不足 高，不处理会雪崩 突然跳变 消费者重启/崩溃后 offset 回退，或生产者批量灌数据 中，需确认是否预期 突然归零 消费者挂了或跳过提交，offset 停滞但 LEO 也没涨 低但不正常，常被误判为"健康" 第三种最坑人。我见过一个案例：消费者线程死锁，但 auto.commit.enable=true 还在自动提交 offset，导致消息被标记为"已消费"但实际没处理。Lag 显示 0，业务方以为一切正常，直到下游发现数据丢了三天。...

概述 数据库慢了，业务就慢了。这句话每个运维都听过，但真正把数据库监控做到位的团队，说实话不多。 我见过太多团队的数据库监控长这样：Zabbix 模板跑着十年前的指标，告警只有"CPU 超过 90%“和"磁盘满了"两条，数据库内部的连接数、锁等待、缓存命中率、复制延迟——这些真正能提前预警的指标，压根没采。等业务方跑来说"接口好慢”，你才发现数据库连接池早就满了，慢查询堆积了几百条。 数据库监控的核心难点不在于"装个 exporter"，而在于你知道该看哪些指标、怎么设阈值、怎么从指标变化中读出数据库的健康状况。这篇文章就把这些讲透。 覆盖 MySQL 和 PostgreSQL 两大主流数据库，从 exporter 部署、核心指标解读、告警规则设计到 Grafana 仪表盘配置，全链路打通。技术栈基于 Prometheus + Grafana，这是目前开源数据库监控的事实标准。 数据库监控的三层架构 在动手之前，先理清监控的层次。数据库监控不是一股脑把所有指标都采上来就完了，得分层： ┌──────────────────────────────────────────────────┐ │ 业务应用层 │ │ 核心接口响应时间 | 业务操作成功率 | 业务吞吐量 │ │ → 这些指标直接关联用户体验 │ ├──────────────────────────────────────────────────┤ │ 数据库内核层 │ │ 连接数 | QPS/TPS | 慢查询 | 锁等待 | 缓存命中率 │ │ 复制延迟 | 死锁 | WAL写入 | 事务回滚率 │ │ → 这些指标反映数据库内部运行状态 │ ├──────────────────────────────────────────────────┤ │ 服务器资源层 │ │ CPU | 内存 | 磁盘IO | 网络 | 文件系统 │ │ → 这些指标是数据库运行的物理基础 │ └──────────────────────────────────────────────────┘ 参考 数据库性能监控体系构建 的三层架构设计，每一层关注的问题不同：...

概述 先说个场景：凌晨三点，你被告警吵醒，爬起来打开 Grafana，发现几十个 Dashboard 里找不到一条有用的信息。指标倒是有几百万条——但全是垃圾。 这不是个例。我见过太多团队，Prometheus 部署完就不管了，指标只增不减，告警规则越写越多，最后监控系统自己先挂了：Prometheus 内存 OOM、查询超时 30 秒、告警评估延迟 5 分钟以上。监控系统成了最大的故障源，这话说出去都讽刺。 监控数据治理解决的就是这个问题。它不是什么高深理论，说白了就一句话：搞清楚你有哪些指标、哪些有用、哪些该删、怎么管它们的一生。 这篇文章从指标生命周期管理的角度，拆解监控数据治理的五个阶段：指标定义、采集策略、存储优化、质量度量、废弃淘汰。每个阶段都配实操代码和踩坑经验。 指标爆炸的根因：不是数据多了，是管不住 指标为什么会膨胀 指标膨胀不是一夜之间发生的。通常的路径是这样的： 初期：Node Exporter + cAdvisor，几百条指标，Prometheus 跑得好好的 业务接入：每个服务埋点，每个中间件装 Exporter，指标涨到几万条 高基数炸弹：有人把 user_id、request_id、session_id 塞进了标签，时序数据量从几万条直接爆炸到百万级 灾难：Prometheus 内存飙升、磁盘写满、查询卡死 这里的核心罪魁祸首是高基数标签。 Prometheus 的时间序列模型是：指标名{标签1="值1", 标签2="值2"} → 数值。每增加一个标签值组合，就多一条时间序列。举个例子： # 低基数：3 条时间序列 http_requests_total{method="GET",status="200"} http_requests_total{method="POST",status="200"} http_requests_total{method="GET",status="404"} # 高基数炸弹：100万用户 = 100万条时间序列 http_requests_total{method="GET",status="200",user_id="12345"} http_requests_total{method="GET",status="200",user_id="12346"} ... 第二行代码看起来人畜无害，但如果 user_id 有 100 万个值，就是 100 万条时间序列。Prometheus 单实例承载上限大约 50 万条 TimeSeries（受内存和磁盘 I/O 约束），直接超限。 高基数标签的常见来源 来源 典型场景 危害程度 替代方案 用户 ID http_requests_total{user_id="..."} 致命 用日志记录，或聚合为百分位 请求 ID http_request_duration{trace_id="....

概述 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 证书是否过期？ ✗ 网络路由是否通畅？ ✗ 从用户地域访问是否可达？ 内部监控无法覆盖的典型场景：...

概述 监控系统本身也需要被监控。Prometheus 采集了整个基础设施的指标，但如果 Prometheus 自己的配置出了问题、某个 target 掉线了、SSL 证书快过期了、告警规则写得有语法错误——谁来发现这些问题？答案是：一套自动化巡检脚本。本文围绕 Prometheus 生态，构建一套覆盖"拨测→证书检查→配置审计→规则验证→告警模拟→报表生成"的完整巡检工具集。 参考来源：Prometheus 官方文档、Blackbox Exporter 一、批量服务拨测脚本 1.1 基于 Blackbox Exporter 的拨测 Blackbox Exporter 是 Prometheus 官方的黑盒探测工具，支持 HTTP、TCP、ICMP、DNS 等协议。通过 Prometheus API 查询探测结果，可以实现批量服务健康检查： #!/usr/bin/env python3 """ 批量服务拨测脚本 通过 Prometheus API 查询 Blackbox Exporter 探测结果 """ import requests import json from datetime import datetime from typing import List, Dict, Optional from dataclasses import dataclass, asdict import smtplib from email.mime.text import MIMEText import sys @dataclass class ProbeResult: """探测结果""" instance: str module: str # http_2xx, tcp_connect, icmp 等 success: bool status_code: Optional[int] duration: float # 探测耗时（秒） error: Optional[str] last_error: Optional[str] ssl_cert_expiry_days: Optional[float] class PrometheusProber: """Prometheus 拨测器""" def __init__(self, prometheus_url: str, timeout: int = 30): self....

概述 Prometheus 是云原生监控领域的事实标准，但它在长期数据存储和全局查询方面存在明显短板：本地存储默认只保留 15 天数据，单实例无法跨集群聚合查询，高可用方案也相对复杂。Thanos 作为 CNCF 孵化项目，通过将 Prometheus 数据上传到对象存储（如 S3、GCS、MinIO）实现了无限容量的长期存储，并通过分布式查询组件提供跨集群的全局视图。 将深入剖析 Thanos 的架构设计，并结合生产环境实战经验，详细讲解各组件的配置、部署和运维要点。 Thanos 解决了什么问题 在引入 Thanos 之前，我们首先需要理解 Prometheus 原生存储的局限性： 维度 Prometheus 原生 Thanos 增强 数据保留 默认 15 天，受本地磁盘限制 理论无限，依赖对象存储容量 高可用 需要 Thanos Sidecar 或 remote_write 双写 Sidecar + Query 天然支持 全局查询 联邦方案，有限且易丢数据 Query 组件聚合所有 Store API 降采样 不支持 Compactor 自动降采样，优化长周期查询 历史数据查询 超出保留期即丢失 可查询数月甚至数年前数据 跨集群视图 需要额外联邦配置 原生支持多集群统一查询 核心思路是：不改 Prometheus 本身，通过 Sidecar 旁路将数据上传到对象存储，再通过 Query 组件统一查询。这种设计保持了 Prometheus 的简单性，同时获得了企业级存储和查询能力。 核心架构与组件 整体架构 Thanos 的架构围绕"Sidecar 上传、Store 读取、Query 聚合"三个核心环节展开：...

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