在 Kubernetes 管理数百个微服务之后，你会发现传统的"监控"已经不够用了。一个请求从网关进入，经过 6 个服务、3 个中间件、2 次数据库调用，最后返回 500——问题出在哪？是网络抖动、数据库慢查询、还是某个 Pod OOM？如果没有一套完整的可观测性体系，排障就像在黑箱里摸象。本文系统梳理云原生可观测性的技术栈，从三大支柱到具体落地方案，帮你建立全局视角。
2026/6/13大约 12 分钟
在云原生体系中，Prometheus 已经成为监控领域的事实标准。而真正让监控系统发挥价值的，不是安装 Prometheus 本身，而是你是否拥有丰富、准确、有业务含义的指标。本文从 Prometheus 数据模型出发，深入讲解如何使用 Go 客户端库开发自定义 Exporter，为你的应用和业务注入可观测性能力。
2026/6/13大约 16 分钟
告警管理核心概念
告警管理是 SRE 工作的核心能力之一。一个设计良好的告警体系能帮助团队在故障发生时快速定位问题，而设计糟糕的告警体系则会让 On-Call 工程师陷入"狼来了"的困境。
告警生命周期
每一条告警都有明确的生命周期：
┌──────────┐ 条件满足 ┌──────────┐ 条件恢复 ┌───────────┐
│ Pending │──────────────>│ Firing │──────────────>│ Resolved │
│ (等待中) │ (等待for时长) │ (触发中) │ (指标恢复正常) │ (已恢复) │
└──────────┘ └──────────┘ └───────────┘2026/6/13大约 11 分钟
整体架构
Prometheus 是云原生监控的事实标准，采用 Pull 模型采集指标，内置时序数据库（TSDB），配合 Alertmanager 实现告警管理。以下是其完整架构：
┌─────────────────────────────────────────┐
│ Prometheus Server │
│ │
┌───────────────┐ │ ┌──────────┐ ┌──────────────────┐ │
│ Service │──────> │ Retrieval│───>│ TSDB │ │
│ Discovery │ │ │ (Scrape) │ │ (Time Series DB) │ │
│ (K8s/Consul/ │ │ └──────────┘ └───────┬──────────┘ │
│ DNS/File) │ │ │ │
└───────────────┘ │ ┌──────────┐ │ │
│ │ Rules │<───────────┘ │
│ │ Engine │───┐ │
│ └──────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌──────────┐ │ ┌──────────────┐ │
│ │ HTTP │ └──>│ Alertmanager │ │
│ │ Server │ │ (路由/分组/ │ │
│ │ (Query/ │ │ 抑制/静默) │ │
│ │ API) │ └──────┬───────┘ │
│ └──────────┘ │ │
└────────────────────────────┼────────────┘
│
┌─────────────────────────┼──────────────┐
│ ▼ │
│ ┌──────────────┐ │
│ │ 通知渠道 │ │
│ │ Email/Slack/ │ │
│ │ WeChat/PagerD│ │
│ └──────────────┘ │
│ Grafana / API Consumers │
└───────────────────────────────────────┘
┌───────────────┐ ┌───────────────┐
│ Targets │ │ Pushgateway │
│ (/metrics) │<──────│ (临时任务 │
│ Exporter/App │ Pull │ 中转站) │
└───────────────┘ └───────────────┘2026/6/13大约 10 分钟
Prometheus 单实例在可靠性和数据保留周期上都存在先天不足。进程崩溃、磁盘故障、节点宕机都会导致监控数据丢失；本地 TSDB 的存储容量也决定了数据保留时间有限。当监控规模从几十个节点扩展到数千个、合规要求将数据保留周期从 15 天拉长到 1 年甚至更久时，就必须引入高可用和长期存储方案。
Prometheus 高可用方案对比
目前社区的主流方案各有侧重，选型时需要在复杂度、成本和功能之间做权衡：
| 方案 | 高可用 | 长期存储 | 全局视图 | 多租户 | 复杂度 | 适用规模 |
|---|---|---|---|---|---|---|
| 多副本部署 | 部分（数据重复） | 否 | 否 | 否 | 低 | 中小规模 |
| 联邦（Federation） | 部分 | 否 | 部分 | 否 | 中 | 中等规模 |
| Remote Write | 是（依赖远端） | 是 | 依赖远端 | 依赖远端 | 中 | 中大规模 |
| Thanos | 是 | 是（对象存储） | 是 | 否 | 高 | 大规模 |
| Cortex | 是 | 是 | 是 | 是 | 高 | 大规模/多租户 |
| Grafana Mimir | 是 | 是 | 是 | 是 | 高 | 大规模/多租户 |
2026/6/13大约 11 分钟
PromQL 数据模型基础
PromQL（Prometheus Query Language）是 Prometheus 的原生查询语言，理解其数据类型是写出高效查询的前提。
即时向量 vs 范围向量
即时向量（Instant Vector） 返回某一时刻的一组时间序列，每个序列只有一个采样值：
# 当前时刻所有实例的 CPU 空闲时间
node_cpu_seconds_total{mode="idle"}2026/6/13大约 12 分钟