监控

概述 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 的视频文件，源站出口带宽照样被打满。...

概述 你大概率经历过这种场景：凌晨三点被告警吵醒，爬起来看 Grafana，发现 CPU 使用率飙到 85%。你紧张了半天，查了一圈，最后发现——这台数据库服务器每天凌晨 2:50 到 3:10 都会跑定时备份任务，CPU 本来就该到这个数。 问题出在哪？你不知道这台机器"正常"是什么样子。没有基线，85% 是高还是低，你根本判断不了。 性能基线（Performance Baseline）解决的就是这个问题：在系统健康的时候，把关键指标记录下来，形成一份"体检报告"。以后出了异常，拿当前数据跟基线一对比，是真故障还是正常波动，一眼就能看出来。 这篇文章讲的是怎么从零建立一套可落地的 Linux 性能基线体系。不是泛泛而谈"监控很重要"，而是从方法论选择、指标采集、基线建模、异常识别到自动化落地，每一步都给你能直接用的配置和代码。 为什么静态阈值不靠谱 大多数团队的告警配置是这样的：CPU > 80% 告警，内存 > 90% 告警，磁盘 > 85% 告警。这就是静态阈值——一个拍脑袋定的数字，挂在所有机器上。 静态阈值有三个致命问题： 第一，不同业务、不同时段的正常值不一样。 一台跑批处理任务的服务器，CPU 峰值在工作时间冲到 95% 是正常的；一台 API 网关，CPU 持续 70% 就得警惕了。用同一个 80% 阈值套上去，前者天天误报，后者出了事还不报。 第二，绝对值掩盖趋势。 某台机器 CPU 从 30% 缓慢爬到 60%，持续两周。静态阈值看不到——没到 80% 嘛。但这种缓慢上升往往是内存泄漏或连接堆积的前兆，等真到 80% 的时候已经炸了。 第三，无法识别"不正常的好"。 某个核心服务的 QPS 突然从 5000 掉到 200，CPU 使用率跟着降到 10%。静态阈值觉得一切正常——CPU 低着呢。但实际上上游可能挂了，流量根本没进来。 基线解决这些问题的思路很简单：不设固定阈值，而是让系统自己学什么算正常。当实际表现偏离了历史学到的"正常模式"，才触发告警。 USE 方法论：基线采集的骨架 建立基线之前，先得知道采什么指标。乱采一通，采了 200 个指标，80% 没人看，纯属浪费。...

概述 你有没有遇到过这种情况：用户反馈"系统好卡"，你打开 Grafana 看了一堆面板，CPU 正常、内存正常、网络也正常，但用户就是说慢。这时候你需要的不是更多的指标面板，而是一条完整的请求链路——从用户点下按钮到数据库返回结果，每一跳花了多少时间，卡在哪一步。 这就是 APM（Application Performance Monitoring，应用性能监控）干的事。 简单说：日志告诉你发生了什么，指标告诉你系统是否健康，APM 告诉你为什么慢、慢在哪里、影响了谁。三者各管一摊，缺一不可。 本文从实际选型角度出发，拆解主流开源和商业 APM 工具的架构差异、适用场景和坑点。不吹不黑，每家都有适合的场景，关键看你的团队规模、技术栈和预算。 APM 要解决什么问题 先说清楚为什么需要 APM，而不是直接跳到工具对比。 微服务架构下的"链路黑盒" 单体应用时代，一个请求从入口到数据库都在一个进程里完成，打个断点就能调试。微服务拆分后，一个用户请求可能经过 API 网关 → 认证服务 → 订单服务 → 支付服务 → 消息队列 → 库存服务 → 数据库，中间还穿插着 Redis 缓存和第三方 API 调用。 任何一个环节变慢，整体就慢。但你看日志只能看到单个服务的视角，没法把整条链路串起来。这就像你在医院看病，内科查完说没问题让你去外科，外科查完说没问题让你去骨科——每个科室都说自己没问题，但你就是难受。APM 就是那个能把你所有科室检查结果串起来看的"全科医生"。 APM 的三个核心能力 能力 解决什么问题 类比 分布式追踪（Distributed Tracing） 一个请求经过哪些服务、每跳花了多久 快递物流追踪，每个中转站都有时间戳 性能剖析（Profiling） 某个函数执行慢，CPU 花在哪了 体检报告，精确到每个器官的指标 错误追踪（Error Tracking） 异常发生在哪个服务的哪行代码 车辆故障码，直接定位到故障部件 分布式追踪是 APM 最核心的能力。它通过在请求入口生成一个唯一的 Trace ID，然后通过 HTTP Header 或 RPC 上下文传递到下游服务，每个服务在自己的处理过程中记录一个 Span（你可以理解为链路上的一个节点），最终拼出完整的调用树。 关键概念速览 术语 含义 说明 Trace 一次完整的请求链路 由多个 Span 组成的有向无环图（DAG） Span 链路上的一个操作节点 包含操作名、起止时间、标签、日志 Context Propagation 上下文传递 Trace ID 通过 HTTP Header 在服务间传递 Sampling 采样 不可能记录所有请求，按策略采样部分 Instrumentation 探针/埋点 代码层面自动或手动注入追踪逻辑 采样策略很关键。线上流量大的时候，全量记录 Trace 会把存储和 CPU 吃干。常见做法是头部采样（Head-based Sampling）——在请求入口决定是否记录，要么整条链路全记，要么全不记。尾部采样（Tail-based Sampling）更精细——在链路结束时根据条件（比如耗时超过阈值、出现错误）决定是否保留，但实现复杂度高，需要中间层缓存完整链路。...

概述 先说个场景：凌晨三点，你被告警吵醒，爬起来打开 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="....

概述 AIOps 异常检测：从静态阈值到智能告警的演进是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要AIOps 异常检测 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。AIOps 异常检测能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 AIOps 异常检测的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是AIOps 异常检测的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 监控即代码：用 Terraform 和 YAML 管理告警规则是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要监控即代码 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。监控即代码能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 监控即代码的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是监控即代码的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 监控系统本身也需要被监控。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 聚合"三个核心环节展开：...

概述 容量规划是 SRE 的核心职责之一。Google SRE Book 将容量规划视为"前瞻性工作"，强调基于数据预测而非凭经验猜测。一个没有容量规划的团队，要么在高峰期被流量打垮，要么在低谷期浪费大量资源成本。 从指标采集、数据建模、Kubernetes 弹性扩容配置、陷阱规避四个层面，详细梳理容量规划的工程实践。 关于容量规划的系统方法论，可参考 Google SRE Book - Capacity Planning 中关于容量规划与级联故障的讨论。 一、容量规划的核心思想：基于数据而非猜测 容量规划的三个层次 当前容量评估：系统现在能扛多少？水位是多少？ 容量趋势预测：按当前增长趋势，什么时候需要扩容？ 弹性伸缩策略：面对突发流量，如何自动应对？ 容量规划的前提：可观测性 没有度量就没有管理。容量规划的基础是完善的监控体系，需要持续采集以下指标： 指标类别 具体指标 采集工具 CPU 使用率、负载（1m/5m/15m） node_exporter / cAdvisor 内存 使用量、可用量、OOM 次数 node_exporter / cAdvisor 网络 入站/出站带宽、连接数、丢包率 node_exporter 磁盘 I/O IOPS、读写延迟、队列深度 node_exporter 应用层 QPS、延迟分布、错误率 Prometheus / 自定义指标 中间件 连接池使用率、队列长度、缓存命中率 Exporter / 自定义指标 容量水位定义 不是所有指标都同等重要。需要定义关键资源的容量水位： # 容量水位定义示例 capacity_thresholds: cpu: warning: 60% # 60% 开始关注 critical: 80% # 80% 需要扩容 limit: 90% # 90% 紧急扩容 memory: warning: 70% critical: 85% limit: 95% disk_io: warning: 60% critical: 80% limit: 90% connection: warning: 60% # 连接池使用率 critical: 80% limit: 90% 关键原则：水位线不是拍脑袋定的，而是基于压测数据和历史故障分析得出的。如果你的应用在 CPU 85% 时开始出现延迟劣化，那么 warning 就应该设在 70% 以下。...

概述 凌晨三点，手机震动。你从被窝爬起来，打开电脑，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....