illegalCreed

中文

English

中文

English

Appearance

LGTM 生态：Loki、Tempo、Mimir 与 Pyroscope ​

基于 Grafana 11.x · 核于 2026-08

速查 ​

  • LGTM 含义：Grafana Labs 的可观测性后端栈首字母——Loki（日志）+ Grafana（可视化）+ Tempo（追踪）+ Mimir（指标长期存储）；2024 年收购 Pyroscope（剖析）补齐第四支柱，常称「LGTM + Pyroscope」或「可观测性四支柱」。
  • Loki：日志聚合系统（「Prometheus 的日志版」）——只索引 label，不索引日志内容，日志原文压缩存对象存储，按 label + 时间范围查询后用 grep 式过滤——存储成本远低于全索引的 ES。
  • Tempo：分布式追踪后端（存 trace/span）——不索引属性，按 traceID 查找（Ehprus/S3 存储压缩），或 Tempo 的新 Search API 按属性检索；与 OpenTelemetry/Jaeger 客户端兼容，是 Jaeger 的 Grafana 系替代。
  • Mimir：Prometheus 兼容的指标长期存储（多租户、水平扩展）——接收 Prometheus 的 remote_write，存对象存储，提供 PromQL 全局查询；是 Thanos/Cortex 的 Grafana 商业进化版。
  • Pyroscope：持续剖析（Continuous Profiling）——周期采集进程的 CPU/内存火焰图，存为时序，在 Grafana 画火焰图。2022 年多模态化（与 Loki/Tempo 同架构），2024 年被 Grafana Labs 收购整合。
  • 关联查询（核心价值）：四支柱共享 traceID/label——点 Mimir/Prometheus 指标曲线的 Exemplar 跳 Tempo trace，再从 trace span 跳 Loki 日志，形成「指标 → 追踪 → 日志」根因分析闭环。
  • LogQL/TraceQL/FlameQL：Loki 用 LogQL（PromQL + grep 风格过滤）、Tempo 用 TraceQL（按属性查 trace）、Pyroscope 用 flamegraph 直观呈现——每个后端有专用查询语言，Grafana UI 统一。
  • 成本对比：Loki 存储 ≈ ES 的 1/10（不索引内容）；Mimir 用对象存储比本地 TSDB 便宜；Tempo 不索引属性比 Jaeger 省存储。

一、Loki：日志聚合（轻量 ES 替代） ​

Loki 是「Prometheus 的日志版」——借鉴 Prometheus 的 label 模型，但只索引 label，不索引日志内容：

日志流（stream）= label 集合（{app="order", env="prod"}）+ 日志行序列
索引：只索引 label（app/env）→ 快速定位日志流
存储：日志原文压缩（zstd）存对象存储（S3），不索引内容
查询：先按 label + 时间范围定位流，再在流内 grep 过滤
  • 为什么省存储：ES 索引每个词（倒排索引），存储和索引成本高（1GB 日志可能要 2-3GB 索引）；Loki 只索引 label，日志原文压缩存——存储成本约为 ES 的 1/10。
  • 代价：内容检索比 ES 慢（要先把日志流拉出来再 grep），不适合「全文模糊搜索」。但绝大多数日志查询是「按 label 定位 + 关键词过滤」（如查某服务的 ERROR 日志），Loki 完全够用且便宜。
  • LogQL：{app="order"} |= "error" | json | latency > 1000——label 选择器（定位流）+ 管道过滤（grep/JSON 解析/数值过滤）。还能算指标（rate({...}[5m])），把日志当指标用。
  • 采集：Promtail（Loki 官方 agent）采日志文件，加 label 后 push 到 Loki；也可用 Fluent Bit/Vector。

二、Tempo：分布式追踪后端 ​

Tempo 是 Grafana 系的分布式追踪后端，存 OpenTelemetry/Jaeger 格式的 trace/span：

  • 不索引属性，按 traceID 查：Tempo 把 trace 压缩存对象存储，按 traceID（唯一标识一条请求链路）查找——查某条请求的完整链路。早期 Tempo 不支持按属性查（只能 traceID），新版本 Search API 支持按 service/latency/status 等属性检索。
  • 与 OTel/Jaeger 兼容：应用用 OpenTelemetry SDK 埋点，导出到 Tempo；也可接收 Jaeger/Zipkin 格式。是 Jaeger 的 Grafana 系替代。
  • TraceQL（新）：{ service.name = "order" && status = error } 按属性查 trace——补齐「不知道 traceID 时怎么找问题 trace」的短板。
  • 与 Loki/Mimir 联动：trace 的 span 里有 traceID，点击 Mimir 指标 Exemplar → Tempo trace → span 的日志（Loki）——根因分析闭环。

三、Mimir：Prometheus 指标长期存储 ​

Mimir 是 Grafana 系的 Prometheus 兼容指标存储，解决 Prometheus 本地 TSDB 的扩展性问题：

  • 接收 remote_write：Prometheus 把样本通过 remote_write 推给 Mimir，Mimir 做长期存储 + 多租户 + 水平扩展。
  • PromQL 全局查询：Mimir 兼容 PromQL，Grafana 查询时透明——多个 Prometheus 实例的数据在 Mimir 汇成全局视图。
  • 对象存储：数据存 S3/OSS/GCS，成本远低于本地磁盘；查询时拉取所需 block。
  • 多租户：原生多租户（tenant ID 隔离），适合做 metrics-as-a-service。
  • vs Thanos：Thanos 是开源方案（sidecar + 对象存储 + Store Gateway），Mimir 是 Grafana 商业产品（更易运维、水平扩展更强、Cortex 的进化版）。

四、Pyroscope：持续剖析（第四支柱） ​

持续剖析（Continuous Profiling）是可观测性的第四支柱——周期采集进程的 CPU/内存使用快照，存为火焰图时序：

  • 剖析什么：CPU（哪些函数耗 CPU）、内存（哪些函数分配内存）、锁竞争、goroutine 等。
  • 持续采集：不像传统 profiler 要手动触发，Pyroscope 持续低开销采集（eBPF/SDK），存为时序。
  • 火焰图：在 Grafana 画 flame graph Panel，定位「CPU 都花在哪」「内存泄漏在哪」——比指标更细（函数级）。
  • 与其他支柱联动：指标告诉你「CPU 高」，剖析告诉你「哪个函数」，追踪告诉你「哪个请求」，日志告诉你「发生了什么」——四支柱拼成完整图景。

五、关联查询：指标 → 追踪 → 日志 ​

LGTM + Pyroscope 的核心价值是跨支柱关联，形成根因分析闭环：

┌─ Grafana Dashboard ────────────────────────────┐
│ ① Mimir/Prometheus 指标曲线（P99 突增）         │
│    ↓ 点 Exemplar（带 traceID 的采样点）          │
│ ② Tempo 追踪瀑布图（找到慢 span）                │
│    ↓ 点 span 跳转                                │
│ ③ Loki 日志（该 span 的 ERROR 日志）             │
│    ↓ 进一步                                      │
│ ④ Pyroscope 剖析（该函数 CPU 火焰图）            │
└─────────────────────────────────────────────────┘
  • Exemplar：Prometheus/Mimir 的指标采样点可附带 traceID（高基数但只用一次），点击跳转到 Tempo 对应 trace——是「从指标进追踪」的入口。
  • traceID 贯穿：应用在日志里打 traceID，在指标 Exemplar 带 traceID，在追踪 span 带日志——一个 ID 串起四支柱。

六、与单点工具的对比 ​

维度Grafana LGTM单点工具组合
日志Loki（轻量、省存储）ELK（ES 全索引，强全文检索但贵）
指标Prometheus + Mimir（长期）Prometheus + Thanos
追踪Tempo（traceID 优先）Jaeger（属性检索强）
剖析Pyroscope独立工具（pprof/async-profiler）
可视化统一 Grafana UI每个工具自带 UI（碎片化）
关联traceID 贯穿四支柱需手动跳转
  • 选 Loki 还是 ELK：要省钱、查询模式是「按 label 定位 + 关键词过滤」→ Loki；要全文模糊检索、复杂聚合 → ELK。
  • 选 Tempo 还是 Jaeger：已上 Grafana 栈、要四支柱联动 → Tempo；要强属性检索、CNCF 生态 → Jaeger。

下一步 ​

掌握了 LGTM 生态后，可看本叶参考（Panel 类型速查、数据源清单、易错点），或横向对比其他可观测性工具——Prometheus（指标采集）、ELK Stack（日志）、Sentry（错误）、Jaeger（追踪）。