17.11.7 可观测性落地与持续改进机制

可观测性落地的目标是让监控从“看得到”转为“用得上”，形成指标、日志、链路与事件的闭环。落地时应明确业务与系统的SLO，围绕可用性、延迟、错误率与饱和度建立核心指标集，并结合服务拓扑与依赖关系定义黄金信号。将监控责任嵌入研发与运维流程，确保新服务上线即具备基础观测能力。

原理草图（可观测性闭环与改进循环）：

持续改进机制强调“度量—分析—行动—复盘”的循环。基于告警与故障的RCA输出可量化的改进项，定期评审指标有效性、告警噪声与缺失覆盖；对无效指标与冗余告警进行治理，对关键路径补齐探针与业务埋点。通过SLO周报、变更评审与容量评估，推动指标与SLA的动态校准。

实施路径与示例（含安装、配置与验证）：

1) 指标治理：统一命名规范、标签标准与采集口径，控制高基数标签
示例：为一个业务服务增加SLO与黄金信号面板

# /etc/prometheus/rules/slo_api.yaml
groups:
- name: api-slo
  rules:
  - record: job:http_requests:rate5m
    expr: sum(rate(http_requests_total{job="api"}[5m])) by (job)
  - record: job:http_errors:rate5m
    expr: sum(rate(http_requests_total{job="api",code=~"5.."}[5m])) by (job)
  - alert: API_SLO_BurnRate_High
    expr: (job:http_errors:rate5m / job:http_requests:rate5m) > 0.01
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "API错误率超过1%"
      description: "错误率超标，可能影响SLO。"

2) 告警优化：SLO告警与阈值告警并行，设置抑制/分组策略与恢复通知
示例：Alertmanager分组与抑制

# /etc/alertmanager/alertmanager.yml
route:
  group_by: ['alertname','job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  receiver: 'oncall'
  routes:
  - matchers: [severity="warning"]
    receiver: 'ops'
inhibit_rules:
- source_matchers: [severity="critical"]
  target_matchers: [severity="warning"]
  equal: ['alertname','job']
receivers:
- name: 'oncall'
  email_configs:
  - to: oncall@example.com
- name: 'ops'
  email_configs:
  - to: ops@example.com

3) 观测资产管理：纳入配置管理与版本控制，规则/仪表盘可追溯
示例：Prometheus加载规则并热更新

# 校验规则文件
promtool check rules /etc/prometheus/rules/slo_api.yaml

# 触发Prometheus热加载（需开启 --web.enable-lifecycle）
curl -X POST http://127.0.0.1:9090/-/reload

# 预期：Prometheus日志无报错，规则生效

4) 绩效联动：MTTR、告警噪声比、SLO达成率纳入评估
示例：PromQL计算告警噪声比（告警触发/有效告警）

sum(increase(ALERTS{alertstate="firing"}[7d])) 
/
sum(increase(ALERTS{alertstate="firing",alertname=~"^SLO_.*"}[7d]))

5) 容量与成本：基于历史趋势做容量规划与下采样
示例：Prometheus容量基线估算（示意）

# 过去30天TSDB样本写入速率
sum(rate(prometheus_tsdb_head_samples_appended_total[5m]))

安装与验证（可观测性落地的最小化环境）：

# 安装Prometheus与Alertmanager（Ubuntu示例）
sudo apt-get update
sudo apt-get install -y prometheus alertmanager

# 启用并启动服务
sudo systemctl enable prometheus alertmanager
sudo systemctl start prometheus alertmanager

# 验证服务端口
ss -lntp | grep -E '9090|9093'
# 预期：Prometheus 9090，Alertmanager 9093 处于监听

示例：为新服务添加基础观测（Node Exporter + 应用Exporter）

# 安装node_exporter
sudo useradd -M -r -s /sbin/nologin node_exporter
wget -qO /tmp/node_exporter.tar.gz https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz
tar -xf /tmp/node_exporter.tar.gz -C /usr/local/
sudo ln -s /usr/local/node_exporter-1.6.1.linux-amd64/node_exporter /usr/local/bin/node_exporter

# systemd
cat <<'EOF' | sudo tee /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target
[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

# Prometheus添加采集目标
cat <<'EOF' | sudo tee -a /etc/prometheus/prometheus.yml

  - job_name: 'node'
    static_configs:
    - targets: ['127.0.0.1:9100']
EOF

sudo systemctl reload prometheus

排错与常见问题处理：
- 规则不生效

promtool check rules /etc/prometheus/rules/slo_api.yaml
curl -s http://127.0.0.1:9090/api/v1/rules | jq '.data.groups[].rules[].name'

目标不可达

curl -s http://127.0.0.1:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, health: .health, lastError: .lastError}'
# 处理：检查防火墙、端口监听、服务启动与DNS解析

高基数标签导致内存飙升

topk(10, count by (label)({__name__=~".+"}))

处理：删除高基数标签，改为低基数字段或使用记录规则聚合。

练习与复盘（带可执行操作）：
1) 为“api”服务定义一个90%可用性的SLO，并在Prometheus中生成SLO告警规则。
2) 为Prometheus新增一个记录规则，统计每个job 5分钟请求量，并在Grafana中建面板。
3) 制造一个5xx错误并验证告警触发与恢复（可用curl模拟），记录告警到恢复的时间。

# 模拟错误（示意，需应用支持）
for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" http://api.example.com/fail; done

落地验收标准（可检查项）：
1) 关键业务具备SLO与对应告警；
2) 故障定位时间明显缩短（MTTR统计可追溯）；
3) 告警噪声持续下降（周报体现）；
4) 指标、规则、仪表盘变更可追溯（Git记录）；
5) 有稳定的周/月度观测评审机制（含改进项闭环）。