搭建可观测性基础栈

适用场景

为应用和基础设施搭建指标、日志、追踪和告警。典型组合：Prometheus + Alertmanager + Grafana + Loki + Tempo + OpenTelemetry Collector。

前置条件

• 一台或一组监控节点，独立磁盘。
• 明确采集范围、保留期和告警接收渠道。
• 应用/节点暴露指标端点，日志可采集。
• 准备对象存储（长期指标/日志/追踪，可选）。

步骤

1. 部署 Prometheus 和 Alertmanager：

# prometheus.yml
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['node1:9100', 'node2:9100']
  - job_name: app
    static_configs:
      - targets: ['app:8080']

2. 部署 node_exporter、应用 metrics 和告警规则。

3. 部署 Grafana，添加 Prometheus/Loki/Tempo 数据源。

4. 部署 Loki + 采集器（Alloy/Promtail/Fluent Bit）：

clients:
  - url: http://loki:3100/loki/api/v1/push

5. 部署 Tempo 和 OpenTelemetry Collector，接收 OTLP 追踪。

6. 配置告警路由、静默和通知渠道。

7. 导入/编写看板，覆盖黄金指标（延迟、流量、错误、饱和度）。

验证

• Prometheus targets 全部 UP。
• Grafana 能查询指标、日志和追踪。
• 告警能触发并送达。
• 保留期和磁盘使用符合预期。

回滚

• 各组件独立部署，可单独回滚。
• 保留配置和 dashboard JSON。
• 停止采集器/告警规则可快速降级。

常见坑

• 指标标签基数过高会拖垮 Prometheus；先治理。
• 日志标签基数高会拖垮 Loki；不要把请求 ID 做标签。
• 保留期和磁盘/对象存储成本要一起规划。
• 告警规则没有 for 会导致抖动。
• 采集器版本和协议（OTLP gRPC/HTTP）要匹配。
• 监控组件本身也要监控和告警。

相关命令

• promtool — 规则校验
• amtool — 告警管理
• logcli — 日志查询
• otel-cli — 链路验证

读完自测

合上页面，先回答，再展开对照。

1. 搭建前需要明确哪些采集范围、保留期和告警前置条件？
2. 如何验证可观测性栈端到端可用？
3. 为什么不能把请求 ID 做成日志标签？告警规则缺少 for 会怎样？