2. Kubernetes集群可观测性基础:Prometheus、Grafana、Loki、Tempo在K8s中的部署架构与数据采集链路

在构建DORA度量体系之前,必须首先建立稳固的集群可观测性底座。Kubernetes集群的复杂性要求我们采用指标(Metrics)、日志(Logs)、链路(Traces)三支柱协同的观测策略。本章将深入剖析Prometheus、Grafana、Loki、Tempo四件套在K8s环境中的标准部署模式与数据采集链路,为后续SLI口径计算提供可靠的数据源。

2.1 四件套在K8s中的角色定位与数据流

每个组件承担不同的观测职责,数据流从集群底层向上汇聚:

组件 观测类型 核心职责 数据存储 查询接口
Prometheus 指标(Metrics) 采集Pod/Node/Service的CPU、内存、请求速率、错误率等时序数据 TSDB(本地/远端) PromQL
Grafana 可视化面板 统一仪表盘,聚合Metrics/Logs/Traces,展示DORA四关键指标 无(连接各数据源) 面板编辑器 + 告警
Loki 日志(Logs) 采集容器stdout/stderr、应用日志,支持标签索引与全文检索 对象存储(MinIO/S3/GCS) LogQL
Tempo 链路(Traces) 接收OpenTelemetry/Jaeger协议,追踪请求在微服务间的完整路径 对象存储 + 内存缓存 TraceQL
关键设计原则:Prometheus负责高频数值采集,Loki负责非结构化日志,Tempo负责请求因果链。三者通过Grafana统一关联,实现从"指标异常→日志定位→链路根因"的快速诊断闭环。

2.2 部署架构:Operator模式与组件拓扑

生产环境推荐使用Helm Chart + Operator方式部署,以kube-prometheus-stack为例,其架构包含以下核心组件:

  • Prometheus Operator:管理Prometheus实例的生命周期,自动发现ServiceMonitor、PodMonitor、Probe等CRD。
  • Prometheus Server:StatefulSet部署,挂载PVC持久化数据,配置远程写(Remote Write)到Thanos或VictoriaMetrics。
  • Alertmanager:处理告警路由、分组、抑制与静默,对接钉钉/邮件/PagerDuty。
  • Grafana:Deployment部署,配置多个数据源(Prometheus、Loki、Tempo),预置DORA仪表盘模板。
  • Loki:微服务模式(Distributor、Ingester、Querier、Compactor),依赖对象存储。
  • Tempo:同样微服务化(Distributor、Ingester、Querier、Compactor),支持多租户。
K8s可观测性四件套部署架构与数据采集链路 Kubernetes Cluster 数据源层(Data Sources) Node Exporter Kube State Metrics cAdvisor OpenTelemetry SDK 采集与存储层(Collection & Storage) Prometheus Server Loki (Distributor) Tempo (Distributor) Alertmanager 可视化与查询层(Visualization & Query) Grafana(数据源:Prometheus / Loki / Tempo) SRE / 开发人员

2.3 数据采集链路详解

2.3.1 指标采集链路(Prometheus)

Prometheus采用拉(Pull)模式采集指标,核心链路如下:

  1. 自动发现:Prometheus Operator通过Kubernetes API Watch Pod/Service/Endpoint变化,动态生成采集目标。
  2. 指标暴露:应用Pod通过/metrics端点暴露Prometheus格式指标;Node Exporter暴露节点级指标;cAdvisor暴露容器级指标。
  3. 拉取与存储:Prometheus Server按配置的scrape_interval(默认15s)拉取指标,写入本地TSDB。
  4. 远程写:配置remote_write将数据副本发送到Thanos/VictoriaMetrics实现长期存储。
DORA度量关键指标示例:
rate(http_requests_total{status=~"5.."}[5m]) → 变更失败率分母
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) → 服务恢复时间(部分场景)

2.3.2 日志采集链路(Loki)

Loki采用推(Push)模式,推荐使用Promtail作为日志采集Agent:

  • Promtail:DaemonSet部署在每个Node上,读取容器日志文件(/var/log/pods/*/*/*.log),添加K8s标签(namespace、pod、container等),通过HTTP/gRPC推送到Loki Distributor。
  • Distributor:验证数据合法性,根据标签哈希分片转发到对应的Ingester。
  • Ingester:将日志数据批量写入对象存储(如MinIO),同时维护内存中的最近数据用于快速查询。
  • Querier:接收Grafana的LogQL查询,合并内存与对象存储中的结果返回。

2.3.3 链路追踪采集链路(Tempo)

Tempo兼容OpenTelemetry(OTLP)和Jaeger协议,典型链路:

  1. 应用埋点:微服务通过OpenTelemetry SDK自动注入Trace上下文(TraceID、SpanID、ParentSpanID)。
  2. 数据上报:应用通过OTLP Exporter将Span数据发送到Tempo Distributor(gRPC/HTTP)。
  3. 哈希路由:Distributor根据TraceID哈希将Span路由到对应的Ingester,保证同一Trace的所有Span进入同一实例。
  4. 存储与查询:Ingester将Span批量写入对象存储,Querier通过TraceQL按TraceID或属性检索。

2.4 关键配置示例

以下为Prometheus采集Kubernetes核心组件的ServiceMonitor配置片段:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-apiserver
  namespace: monitoring
spec:
  endpoints:
  - interval: 30s
    port: https
    scheme: https
    tlsConfig:
      insecureSkipVerify: true
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/
  namespaceSelector:
    matchNames:
    - default
  selector:
    matchLabels:
      component: apiserver
      provider: kubernetes

Loki的Promtail配置示例(采集所有容器日志并添加K8s标签):

scrape_configs:
- job_name: kubernetes-pods
  kubernetes_sd_configs:
  - role: pod
  pipeline_stages:
  - docker: {}
  - labels:
      namespace: ""
      pod: ""
      container: ""
  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_app]
    target_label: app

2.5 部署注意事项与避坑指南

生产部署关键检查项:
  • 资源预留:Prometheus Server建议预留2核4GB内存/1000个Pod,Loki Ingester需要足够内存缓存近期日志。
  • 持久化:Prometheus使用PVC(建议SSD),Loki/Tempo依赖对象存储(MinIO需独立部署)。
  • 网络策略:确保Prometheus能访问所有Pod的/metrics端口,Promtail能读取宿主机日志目录。
  • 高可用:Prometheus采用双实例+Sidecar(Thanos Sidecar)实现HA;Loki/Tempo通过副本+一致性哈希实现。
  • 数据保留:Prometheus本地保留7~15天,Loki/Tempo根据对象存储容量保留30~90天。

2.6 与DORA度量的关联

四件套为DORA四关键指标提供原始数据支撑:

DORA指标 数据来源 采集组件 典型查询
部署频率 CI/CD事件 + 应用版本变更 Prometheus(自定义指标) rate(deploy_events_total[7d])
变更前置时间 代码提交到生产部署的时间差 Loki(日志时间戳) + Prometheus LogQL提取commit时间 + PromQL计算差值
变更失败率 部署后错误率/回滚率 Prometheus(HTTP错误率) sum(rate(http_5xx[5m])) / sum(rate(http_total[5m]))
服务恢复时间 故障开始到恢复的时间 Prometheus + Tempo 告警触发时间 → 告警恢复时间 / Trace错误Span持续时间
实践建议:在Grafana中创建DORA专用仪表盘,将上述查询配置为面板,并设置SLO告警。例如:变更失败率超过15%触发P1告警,服务恢复时间超过1小时触发P2告警。后续章节将详细讲解SLI口径的PromQL/LogQL/TraceQL实现。