可观测性的三支柱与运维新范式
在云原生和微服务架构时代,传统监控已无法满足复杂分布式系统的运维需求。可观测性(Observability)作为监控的进化,由三大支柱构成:指标(Metrics)、日志(Logs)和链路追踪(Traces)。三者相互补充,共同回答三个核心问题:系统出了什么问题?为什么出问题?问题影响了哪些请求链路?
Prometheus作为云原生监控的事实标准,擅长指标采集与告警;Grafana作为可视化平台,将多维度数据转化为直观图表;Loki处理日志聚合;Tempo负责分布式追踪。本文聚焦Prometheus+Grafana体系,从零搭建一套覆盖基础设施、应用层和业务层的全栈可观测性方案。
Prometheus架构与核心概念
Prometheus采用拉取(Pull)模型,主动从目标端点抓取指标数据。其核心架构包括:
- Prometheus Server:负责指标抓取、存储和规则评估
- Pushgateway:为短生命周期任务提供指标推送中转
- Alertmanager:告警去重、分组、路由和通知
- Exporters:将第三方系统指标转换为Prometheus格式
# prometheus.yml 基础配置
global:
scrape_interval: 15s # 全局抓取间隔
evaluation_interval: 15s # 规则评估间隔
scrape_timeout: 10s # 抓取超时
scrape_configs:
- job_name: 'node-exporter'
static_configs:
- targets: ['10.0.1.10:9100', '10.0.1.11:9100']
labels:
cluster: 'production'
env: 'prod'
- job_name: 'application'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['10.0.1.20:8080', '10.0.1.21:8080']
- job_name: 'pushgateway'
honor_labels: true
static_configs:
- targets: ['10.0.1.30:9091']
指标设计:Four Golden Signals与RED方法
Google SRE提出的Four Golden Signals是服务监控的黄金标准:
- 延迟(Latency):请求处理时间分布
- 流量(Traffic):请求吞吐量(QPS)
- 错误(Errors):失败请求比例
- 饱和度(Saturation):资源使用率(CPU/内存/连接池)
对于请求驱动型服务,RED方法更实用:Rate(请求速率)、Errors(错误率)、Duration(延迟分布)。下面是Spring Boot应用的Prometheus指标暴露配置:
# application.yml - Micrometer Prometheus端点
management:
endpoints:
web:
exposure:
include: prometheus,health,info
metrics:
export:
prometheus:
enabled: true
tags:
application: ${spring.application.name}
distribution:
percentiles-histogram:
http.server.requests: true
slo:
http.server.requests: 100ms,200ms,500ms,1s,5s
# 关键指标示例
# http_server_requests_seconds_count{uri="/api/orders",status="200",method="GET"}
# http_server_requests_seconds_sum{uri="/api/orders",status="200",method="GET"}
# http_server_requests_seconds_bucket{le="0.1",uri="/api/orders"}
自定义业务指标与Instrumentation
除了基础设施和应用运行时指标,业务指标对于运维和产品决策同样重要:
// Java业务指标埋点示例
@Component
public class OrderMetrics {
private final Counter orderCreatedCounter;
private final Counter orderFailedCounter;
private final Timer orderProcessingTimer;
private final AtomicLong activeOrdersGauge;
public OrderMetrics(MeterRegistry registry) {
orderCreatedCounter = Counter.builder("orders.created.total")
.description("Total orders created")
.tag("type", "standard")
.register(registry);
orderFailedCounter = Counter.builder("orders.failed.total")
.description("Total failed orders")
.register(registry);
orderProcessingTimer = Timer.builder("orders.processing.duration")
.description("Order processing duration")
.publishPercentiles(0.5, 0.95, 0.99)
.publishPercentileHistogram()
.register(registry);
activeOrdersGauge = registry.gauge("orders.active",
new AtomicLong(0));
}
public void recordOrderCreated() {
orderCreatedCounter.increment();
}
public void recordOrderProcessing(Runnable task) {
orderProcessingTimer.record(task);
}
}
Grafana Dashboard设计最佳实践
优秀的Dashboard应遵循从宏观到微观的信息层次:全局概览面板 → 服务健康面板 → 详情面板。推荐使用变量(Template Variables)实现多环境切换:
# Dashboard JSON变量定义
{
"templating": {
"list": [
{
"name": "cluster",
"type": "query",
"datasource": "Prometheus",
"query": "label_values(up, cluster)"
},
{
"name": "instance",
"type": "query",
"datasource": "Prometheus",
"query": "label_values(up{cluster=""}, instance)"
}
]
}
}
# 关键PromQL查询语句
# CPU使用率
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# 内存使用率
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
# 请求P99延迟
histogram_quantile(0.99, sum by(le) (rate(http_server_requests_seconds_bucket[5m])))
# 错误率
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
/ sum(rate(http_server_requests_seconds_count[5m])) * 100
# 连接池使用率
hikaricp_connections_active / hikaricp_connections_max * 100
智能告警:从阈值到多条件组合
简单阈值告警容易产生噪音。多条件组合告警能更精准地捕捉真实问题:
# alert_rules.yml - Prometheus告警规则
groups:
- name: service-alerts
interval: 30s
rules:
# 高错误率告警(需要持续3分钟)
- alert: HighErrorRate
expr: |
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
/ sum(rate(http_server_requests_seconds_count[5m])) > 0.05
for: 3m
labels:
severity: critical
team: backend
annotations:
summary: "服务 {{ .application }} 错误率过高"
description: "5xx错误率 {{ | humanizePercentage }},持续3分钟"
# P99延迟告警 + 高QPS条件(低流量下延迟告警无意义)
- alert: HighLatencyWithTraffic
expr: |
histogram_quantile(0.99,
sum by(le) (rate(http_server_requests_seconds_bucket[5m]))
) > 2
and sum(rate(http_server_requests_seconds_count[5m])) > 100
for: 5m
labels:
severity: warning
team: backend
annotations:
summary: "P99延迟超过2秒且QPS > 100"
# 连接池即将耗尽
- alert: ConnectionPoolExhaustion
expr: |
(hikaricp_connections_active / hikaricp_connections_max) > 0.85
for: 2m
labels:
severity: warning
annotations:
summary: "数据库连接池使用率超过85%"
Alertmanager路由与通知策略
# alertmanager.yml
route:
receiver: 'default'
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: critical
receiver: 'pagerduty'
group_wait: 10s
repeat_interval: 1h
- match:
team: backend
receiver: 'backend-team'
routes:
- match:
alertname: HighErrorRate
receiver: 'oncall-backend'
receivers:
- name: 'default'
webhook_configs:
- url: 'http://alertmanager-webhook:8080/notify'
- name: 'backend-team'
webhook_configs:
- url: 'http://feishu-webhook:8080/backend'
send_resolved: true
可观测性建设是一个持续迭代的过程。从基础监控开始,逐步引入业务指标和智能告警,最终形成从指标发现到问题定位的闭环。Prometheus+Grafana的强大之处在于其灵活的查询语言和丰富的生态——当你需要时,几乎总能找到对应的Exporter或Dashboard模板。