云原生下的可观测性实战：日志、指标、链路追踪三支柱的落地与调优

云原生下的可观测性实战：日志、指标、链路追踪三支柱的落地与调优

思否首发 | 作者：某互联网公司 SRE 团队负责人

写在前面

我们去年将核心业务迁移至 Kubernetes（腾讯云 TKE），微服务数量从 20 个膨胀到 80+。随之而来的是故障定位从“看日志”变成了“大海捞针”。可观测性不是锦上添花，而是云原生时代的生存刚需。

本文将分享我们基于 Prometheus + Grafana + Loki + Tempo 构建统一可观测性平台的完整历程，包括技术选型、部署配置、数据模型设计、以及三个典型故障的排查实录。全部代码均已脱敏，但核心逻辑可直接复用。

一、可观测性三大支柱的技术选型

1.1 选型标准

• 云原生友好：支持 Kubernetes 服务发现、自动注入 Sidecar
• 低侵入性：业务代码无感知，优先使用 Agent 或 Operator
• 成本可控：数据采样、存储分层、长期归档
• 社区活跃：避免踩坑无人问津

1.2 最终选型清单

注：若您的团队已有 ELK 或 Jaeger 经验，也可平滑迁移，但 Loki+Tempo 的组合在成本上更具优势。

二、部署架构与配置详解

2.1 整体数据流

业务Pod (注入OTel Agent)
    ↓ (gRPC)
OpenTelemetry Collector (DaemonSet)
    ├── Metrics → Prometheus (通过Remote Write)
    ├── Logs → Loki (通过Push API)
    └── Traces → Tempo (通过gRPC)
         ↓
    Grafana (统一查询)
         ↓
    AlertManager → 钉钉/企业微信

2.2 Prometheus 高可用 + Thanos 长期存储

我们使用 Prometheus Operator 部署，开启 remoteWrite 到 Thanos Receiver：

# prometheus-operator 配置片段
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    remote_write:
      - url: http://thanos-receiver:19291/api/v1/receive
        queue_config:
          capacity: 5000
          max_shards: 20
        write_relabel_configs:
          - source_labels: [__name__]
            regex: 'container_.*|kube_.*|apiserver_.*'
            action: keep

Thanos 使用对象存储（腾讯云 COS）作为长期存储，保留 2 年数据，每月成本仅数百元。

2.3 Loki 日志采集与标签设计

Loki 的核心思想是使用标签而非全文索引。我们自定义 Promtail 的 pipeline_stages 提取业务字段：

# promtail-config.yaml
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs: ...
    pipeline_stages:
      - cri: {}  # 解析容器日志格式
      - regex:
          expression: '^(?P<timestamp>\d{4}-\d{2}-\d{2}T.*?)\s+(?P<level>\w+)\s+(?P<trace_id>[a-f0-9]{32})\s+(?P<message>.*)$'
      - labels:
          level:
          trace_id:
          namespace: kubernetes_namespace
          pod: kubernetes_pod_name
      - drop:
          source: level
          expression: 'debug'  # 丢弃 debug 日志以减少存储

关键经验：标签基数不能太高（如 user_id 会导致高基数爆炸），我们只保留 namespace、pod、level 等低基数标签，业务查询用 trace_id 关联。

2.4 Tempo 链路追踪配置

我们使用 OpenTelemetry Collector 自动注入 Trace，并配置采样策略：

# otel-collector-config.yaml
processors:
  probabilistic_sampler:
    sampling_percentage: 10   # 10% 采样，减少数据量
  tail_sampling:
    policies:
      - name: errors-policy
        type: status_code
        status_code: {status_codes: [ERROR]}  # 错误请求全量采集
      - name: slow-policy
        type: latency
        latency: {threshold_ms: 500}          # 慢请求全量采集

exporters:
  otlp:
    endpoint: tempo:4317
    tls: { insecure: true }

这样既能控制成本，又能抓住关键异常。

三、实战案例：三个典型故障的定位过程

3.1 案例一：某服务内存泄漏导致的 OOMKilled

现象：Grafana 面板显示 container_memory_working_set_bytes 持续上升，每 2 小时重启一次。

排查过程：

1. 查看 Pod 的 kube_pod_container_status_restarts_total 指标，确认重启频繁。
2. 点击 Pod 名称，自动跳转到 Loki 日志，使用 {pod="payment-service-xxx"} |= "OutOfMemoryError" 找到错误堆栈。
3. 通过日志中的 trace_id 关联到 Tempo，查看该请求的调用链，发现调用了一个大文件处理接口，未释放资源。
4. 修复代码后，指标曲线恢复平稳。

关键点：Grafana 的 Explore 功能打通三支柱，从指标→日志→链路无缝跳转，大大缩短了定位时间（从 2 小时缩短到 15 分钟）。

3.2 案例二：Kubernetes 节点网络延迟抖动

现象：客服反馈偶发超时，但业务接口响应时间 P99 正常，无法复现。

排查过程：

1. 查看 Prometheus 的 node_network_receive_packets_dropped_total 指标，发现某节点在特定时间点有丢包。
2. 通过 Loki 查询该节点的系统日志（/var/log/messages），发现网卡 rx_csum_errors 增加。
3. 进一步检查 Tempo 链路，发现所有经过该节点的请求都出现 100ms 的额外延迟。
4. 联系运维更换网卡驱动，问题解决。

经验：可观测性要覆盖基础设施层，不能只看应用。

3.3 案例三：慢 SQL 导致的 P99 飙升

现象：订单查询接口在晚高峰（20:00-21:00）响应时间从 50ms 飙升到 2s。

排查过程：

1. 通过 Tempo 找到慢链路，展开 span 发现数据库查询耗时 1.8s。
2. 在 Loki 中搜索该 trace_id 对应的 SQL 日志（我们业务日志包含 SQL），找到具体语句。
3. 查看 Prometheus 的 mysql_slow_queries_total 确认慢查询数量激增。
4. 优化索引后，P99 恢复。

实践：我们为业务日志增加了 trace_id 和 span_id 字段，通过 OTel 的 Context 传递，确保日志和链路可关联。

四、性能调优与成本控制

4.1 指标存储优化

• 降低采集频率：非核心指标从 15s 改为 30s
• Recording Rules：预计算高频聚合（如 QPS、错误率），减少查询压力
• 启用 WAL 压缩：Prometheus 增加 --storage.tsdb.wal-compression

4.2 日志成本降低 60% 的方法

• 使用 Loki 的 chunk_target_size 提高压缩比
• 设置 retention_period 为 7 天，热数据保存 3 天（Loki 支持多阶段保留）
• 对 debug 级别日志进行 drop 或 sample（如仅保留 1%）

4.3 链路追踪采样调优

• 错误和慢请求全采，正常请求按比例采样
• 设置 max_traces_per_second 限制 Tempo 写入速率
• 使用 probabilistic_sampler 结合 tail_sampling 实现动态策略

五、告警体系建设

我们基于 Prometheus AlertManager 构建分级告警：

告警规则示例（PromQL）：

groups:
  - name: service_alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])) > 0.05
        for: 1m
        labels:
          severity: P0
        annotations:
          summary: "{{ $labels.service }} 错误率超过5%"

同时结合 Grafana 的 Alerting 能力，支持在面板内直接配置告警，降低学习门槛。

六、踩坑与避坑指南

6.1 OTel Collector 资源限制

Collector 如果内存不足会被 OOMKilled，需设置 memory_limiter 处理器：

processors:
  memory_limiter:
    check_interval: 5s
    limit_mib: 512
    spike_limit_mib: 128

6.2 Loki 查询性能问题

当标签数量多且范围大时，Loki 查询会超时。解决：

• 尽量缩小时间范围
• 使用 filter 表达式（如 |= "error"）在标签筛选后再进行全文过滤
• 增加 querier 副本数

6.3 多集群统一查询

我们使用 Thanos Querier 聚合多个 Prometheus 实例（按环境或地域），实现全局视图。但要注意 --query.replica-label 去重。

6.4 安全与权限

为 Grafana 启用 OAuth（LDAP），不同团队仅能查看自己的 Namespace 数据，使用 grafana 的 DataSource 的 allowedCookies 进行隔离。

七、效果数据与总结

核心心得：

• 可观测性是工具×文化的结合，团队要养成“先看面板，再问人”的习惯。
• 三支柱必须关联（通过 trace_id 和 labels），否则仍会割裂。
• 成本控制要前置，采样策略是艺术，不是一劳永逸。

后续我们将引入 eBPF 采集更细粒度的内核指标，并探索 智能根因分析（基于 AI 关联变更事件和异常指标）。