在 Kubernetes 管理数百个微服务之后，你会发现传统的"监控"已经不够用了。一个请求从网关进入，经过 6 个服务、3 个中间件、2 次数据库调用，最后返回 500——问题出在哪？是网络抖动、数据库慢查询、还是某个 Pod OOM？如果没有一套完整的可观测性体系，排障就像在黑箱里摸象。本文系统梳理云原生可观测性的技术栈，从三大支柱到具体落地方案，帮你建立全局视角。
2026/6/13大约 12 分钟
Grafana 核心功能
Grafana 是一个开源的数据可视化和监控平台，自 2014 年发布以来已成为云原生可观测性领域的事实标准。当前主流版本为 Grafana 11.x，其核心能力围绕「查询任何数据源、以任意方式可视化、在任何场景下告警」展开。
数据源（Datasource）支持
Grafana 通过插件化架构接入多种数据源，分为三类：
- Metrics 数据源：Prometheus（原生支持，最常用）、InfluxDB、Graphite、OpenTSDB、Datadog
- Logs 数据源：Loki（Grafana 自研日志聚合系统）、Elasticsearch
- Traces 数据源：Tempo（Grafana 自研分布式追踪后端）、Jaeger、Zipkin
- 关系型数据库：MySQL、PostgreSQL、Microsoft SQL Server
- 其他：ClickHouse、Redis、CloudWatch、Azure Monitor
2026/6/13大约 12 分钟
Prometheus 是云原生监控的事实标准，但随着监控规模增长，Prometheus 在写入吞吐、存储压缩、高可用等方面逐渐成为瓶颈。VictoriaMetrics 作为兼容 Prometheus 生态的高性能时序数据库，在不改变现有采集和查询方式的前提下，提供了数量级的性能提升。本文从架构设计到生产部署，全面讲解 VictoriaMetrics 的核心组件与最佳实践。
2026/6/13大约 13 分钟
生产集群部署
在正式环境中，推荐使用 VictoriaMetrics 集群版（vmcluster）而非单机版。集群版各组件可独立扩缩容，适合大规模指标采集场景。
推荐拓扑
一个中等规模（1000 万活跃时间序列）的生产部署推荐拓扑如下：
- 3 x vmagent（采集层）
- 3 x vminsert（写入层）
- 3 x vmstorage（存储层，建议至少 100GB SSD 每节点）
- 2 x vmselect（查询层）
- 2 x vmalert（告警层）
2026/6/13大约 9 分钟
整体架构
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 分钟
PromQL 数据模型基础
PromQL（Prometheus Query Language）是 Prometheus 的原生查询语言，理解其数据类型是写出高效查询的前提。
即时向量 vs 范围向量
即时向量（Instant Vector） 返回某一时刻的一组时间序列，每个序列只有一个采样值：
# 当前时刻所有实例的 CPU 空闲时间
node_cpu_seconds_total{mode="idle"}2026/6/13大约 12 分钟