Grafana Stack 深入：Loki、Tempo、Mimir 构建统一可观测性平台

Grafana Stack 深入：Loki、Tempo、Mimir 构建统一可观测性平台

Grafana 不只是一个可视化工具，它正在演变为一个统一的可观测性平台（Grafana Stack），通过集成 Loki（日志）、Tempo（追踪）、Mimir（指标存储），实现了 Metrics、Logs、Traces 三大支柱的深度融合。

本文将深入详解这三个核心组件，帮助你构建一个端到端、可关联、可扩展的现代可观测性系统。

---

一、Grafana Stack 架构概览

graph LR
    A[Applications] -->|Metrics| B(Prometheus/Mimir)
    A -->|Logs| C(Loki)
    A -->|Traces| D(Tempo)
    B --> E(Grafana)
    C --> E
    D --> E
    E --> F[统一 Dashboard]
    F --> G[点击跳转]
    G --> H[Metrics → Logs → Traces]

✅ “三位一体”：Grafana 作为统一入口，实现 M-L-T 联动。

---

二、1. Loki：日志聚合系统

Loki 是由 Grafana Labs 开发的水平可扩展、高可用、多租户日志聚合系统，专为 Prometheus 和 Grafana 设计。

2.1 核心设计理念

特点	说明
✅ 无索引日志	不对日志内容建立全文索引，仅索引标签（Labels）
✅ 低成本	存储开销远低于 Elasticsearch
✅ 与 Prometheus 类似	使用标签（Labels）进行多维查询
✅ LogQL 查询语言	类似 PromQL，支持管道操作

📌 “Loki 不是用于搜索日志，而是用于发现日志。”

---

2.2 架构组件

组件	作用
Promtail	日志采集 Agent（类似 node_exporter）
Distributor	接收日志，做一致性哈希
Ingester	暂存近期日志，刷盘到对象存储
Querier	查询历史和实时日志
Ruler	评估日志告警规则

---

2.3 使用 LogQL 查询日志

基本语法

{<label filter>} | <pipeline>

示例查询

# 所有来自 job="api" 的日志
{job="api"}

# 包含 "error" 的日志
{job="api"} |= "error"

# JSON 日志字段过滤
{job="api"} | json | level="error"

# 统计日志量
count_over_time({job="api"}[5m])

---

2.4 与指标联动（Metrics → Logs）

在 Grafana 中实现 “点击指标图表，跳转到对应时间的日志”。

配置步骤：

1. 在 Panel 的 Panel links 中添加链接
2. Type: Link
3. Title: View Logs
4. URL: /explore?orgId=1&left=%5B%22now-1h%22,%22now%22,%22Loki%22,%7B%22expr%22:%22%7Bjob=%5C%22api%5C%22%7D%22%7D, %22Logs%22%5D
5. 或使用变量动态生成：

   /explore?left=[["${__from:date}","${__to:date}","Loki",{"expr":"{job=\\"api\\"}"}]]
   

✅ 实现：在 CPU 高峰时段，一键查看当时的应用日志。

---

三、2. Tempo：分布式追踪系统

Tempo 是 Grafana Labs 开发的无依赖、低成本、高扩展性的分布式追踪后端。

3.1 核心优势

特点	说明
✅ 无数据库依赖	使用对象存储（S3/GCS）存储追踪数据
✅ 低成本	不需要 Cassandra、Elasticsearch 等重型存储
✅ 与 Grafana 深度集成	原生支持 Tempo 数据源
✅ 支持 OpenTelemetry	标准协议

---

3.2 架构

✅ 与 Loki 架构高度相似，运维成本低。

---

3.3 在 Grafana 中使用 Tempo

步骤：

1. Add data source → 选择 Tempo
2. 配置：
   • URL: http://tempo:3200
3. Save & Test

---

3.4 与 Metrics/Logs 联动（Tracing → Logs/Metrics）

场景：从追踪定位到日志

1. 在 Grafana Explore 中选择 Tempo 数据源
2. 搜索 Trace（如通过 HTTP 路径 /api/users）
3. 点击 Span → “View logs for this span”
   • 自动跳转到 Loki，显示该 Span 时间范围内的日志
4. 点击 “View metrics”
   • 跳转到 Prometheus，查看该时间段的指标

✅ 实现：从慢请求追踪 → 查看日志 → 分析系统指标。

---

四、3. Mimir：Prometheus 的长期存储与集群方案

Mimir（原 Cortex）是 Grafana Labs 开发的多租户、水平扩展、长期存储的 Prometheus 兼容系统。

4.1 为什么需要 Mimir？

Prometheus 本地存储的局限：

• ❌ 存储有限（通常 15-90 天）
• ❌ 无高可用
• ❌ 无法水平扩展

Mimir 解决了这些问题。

---

4.2 核心特性

特性	说明
✅ 无限存储	基于对象存储（S3/GCS）
✅ 高可用	多副本、自动故障转移
✅ 水平扩展	可扩展到 PB 级数据
✅ 多租户	支持多团队、多项目隔离
✅ 全局查询	跨多个 Prometheus 实例聚合查询
✅ 降采样	长期数据自动聚合（如 1h avg）

---

4.3 架构组件

与 Loki/Tempo 架构统一，运维体验一致。

---

4.4 与 Thanos 对比

方案	Mimir	Thanos
架构	微服务架构	Sidecar + Store Gateway
多租户	✅ 原生支持	❌ 需额外设计
运维复杂度	中	低
社区	Grafana Labs 主导	CNCF 毕业项目
适用场景	多租户 SaaS、大企业	通用长期存储

✅ Mimir 更适合需要多租户和强扩展性的场景

---

五、三者联动：实现真正的可观测性

5.1 统一查询入口

在 Grafana 中：

• 一个 Dashboard 同时展示：
  • Mimir：长期指标趋势
  • Loki：错误日志量
  • Tempo：请求延迟分布

---

5.2 关联分析实战

场景：支付接口变慢

1. Metrics：发现 http_request_duration_seconds P99 上升
2. Traces：在 Tempo 中查看慢请求的调用链，发现 risk-check 服务耗时长
3. Logs：点击 Span，跳转到 Loki，查看 risk-check 服务的日志，发现数据库连接超时
4. Metrics：查看数据库连接池指标，确认连接耗尽

✅ 完整闭环：指标发现 → 追踪定位 → 日志分析 → 根因确认

---

六、部署建议

6.1 小型团队

services:
  grafana: ...
  prometheus: ...
  loki: ...
  tempo: ...

• 使用 Prometheus + Loki + Tempo + Grafana

6.2 中大型企业

services:
  mimir: ...        # 长期存储
  loki: ...         # 日志
  tempo: ...        # 追踪
  grafana: ...      # 统一入口

• 统一使用对象存储（S3/GCS）
• 通过 Grafana 统一管理

---

七、最佳实践

实践	说明
✅ 统一存储后端	Loki、Tempo、Mimir 共用 S3/GCS
✅ 标准化标签	tenant, service, env 三者一致
✅ 启用降采样	减少长期存储成本
✅ 配置告警	在 Grafana 中为三者设置统一告警
✅ 权限控制	基于团队/租户隔离数据

---

八、总结

Grafana Stack 的三大支柱：

组件	作用	查询语言
Mimir	长期指标存储	PromQL
Loki	高效日志聚合	LogQL
Tempo	低成本分布式追踪	OpenTelemetry

核心价值：

“一个平台，统一管理 Metrics、Logs、Traces，实现端到端可观测性。”