Sean's Blog

Grafana LGTM

9分钟阅读

Grafana LGTM（Grafana LGTM Stack）是 Grafana 生态中的一套可观测性组合：Loki 负责日志，Grafana 负责查询、可视化和告警，Tempo 负责链路追踪，Mimir 负责指标。

它不是单个二进制或单个数据库，而是一组分工明确的组件。名字里的四个字母分别是：

字母组件主要信号解决的问题
LLoki日志存储和查询服务、容器、主机或设备产生的事件文本
GGrafana查询与展示层把多个后端的数据源组织成 dashboard、Explore、告警和跳转
TTempo链路追踪保存一次请求跨服务经过的 span，帮助定位慢在何处
MMimir指标保存 Prometheus/OpenTelemetry 风格的时间序列指标

核心问题

真实系统的问题通常不会只落在一种信号里。一次线上延迟升高可能表现为：

  • 指标里出现 P95 延迟、错误率或队列长度上升。
  • 链路追踪里某个下游 RPC、数据库查询或外部 API span 变慢。
  • 日志里记录了超时、重试、限流或配置错误。

如果三类数据分别放在互不关联的工具里，排障者就要手工在多个界面之间复制服务名、时间窗口、请求 ID 和错误关键字。LGTM 的目标是让这些信号进入同一套 Grafana 体验：先从指标看趋势，再跳到 trace 看路径，最后用 trace ID 或标签定位相关日志。

核心对象

对象在 LGTM 中的角色关键输入关键输出
业务服务产生遥测数据请求、任务、错误、资源使用情况log record、metric sample、span
Grafana Alloy 或 OpenTelemetry Collector采集和转发层应用 SDK、文件日志、Prometheus scrape、OTLP转发到 Loki、Tempo、Mimir 或其他后端
Loki日志后端带 label 的日志流LogQL 查询结果和原始日志行
Tempotrace 后端span、trace ID、服务拓扑关系trace 查询结果、span 明细、部分 span-derived metrics
Mimirmetrics 后端metric name、label set、sample value、timestampPromQL 查询结果、recording rule、alert rule
Grafana控制台和关联层多个 data source、dashboard、alert rule统一视图、告警、跨信号跳转

LGTM 里最重要的不是“所有数据放进同一个表”，而是各组件保留适合自己信号的数据模型，同时通过稳定的关联键把它们串起来。

常见关联键可以写成：

correlation_key = service.name + environment + trace_id + span_id + labels

这里的 service.name 是产生数据的服务名，environment 是环境或集群，trace_id 标识一次完整请求链路，span_id 标识其中一个调用片段，labels 是日志和指标上用于过滤、聚合的键值对。这个表达式不是严格数学公式，而是工程上建立跳转和筛选的线索集合。缺少其中一部分时，系统仍能存数据，但跨信号定位会变弱。

核心机制

1. 采集层把不同信号送到合适后端

应用和基础设施先产生遥测数据：

application / host / container
  -> SDK, exporter, file log, scrape endpoint
  -> Alloy or OpenTelemetry Collector
  -> Loki / Tempo / Mimir
  -> Grafana
  • 日志通常来自 stdout、文件、journald 或应用 logger，采集后进入 Loki。
  • 指标通常来自 Prometheus scrape、remote write 或 OpenTelemetry metrics，进入 Mimir。
  • traces 通常来自 OpenTelemetry SDK、Jaeger、Zipkin 或 OTLP exporter，进入 Tempo。

采集层负责接收、批处理、重试、加标签、脱敏和路由。后端负责存储和查询。Grafana 本身通常不是这些原始信号的长期数据库。

2. 三个后端按信号特征选择不同索引策略

日志、指标和 traces 的数据形态不同，不能用同一套索引策略粗暴处理：

  • Loki 倾向于索引日志流标签，而不是全文索引每一行日志。这能降低日志量很大时的索引成本，但要求 label 设计稳定。
  • Mimir 使用 Prometheus 风格的时间序列模型，核心查询单元是 metric name 加 label set 后形成的 series。
  • Tempo 主要保存 trace 和 span，用 trace ID、时间窗口、部分属性索引和对象存储中的 block 来支持查询。

这也是 LGTM 的关键边界：它是组合式可观测性栈，不是把所有信号塞进一个万能数据库。

3. Grafana 做跨信号导航

Grafana 通过 data source 和 dashboard 把不同后端连起来。典型排障路径是：

  1. 在 dashboard 中看到 Mimir 查询出来的错误率或延迟异常。
  2. 通过 exemplars、服务名或时间窗口跳到 Tempo 中的相关 trace。
  3. 在 trace 中找到慢 span 或错误 span。
  4. 用 trace_id、service.name、pod、host 或 labels 跳到 Loki 日志。
  5. 根据日志和 span 属性判断是依赖变慢、超时配置错误、资源耗尽还是代码路径异常。

这个机制依赖一致的命名和上下文传播。仅仅部署四个组件，不会自动让所有日志、指标和 trace 正确关联。

工程用途

  • 微服务排障：把服务级指标、请求链路和具体日志放在同一时间窗口内分析。
  • 平台运维：用统一 dashboard 观察 Kubernetes、主机、数据库、中间件和应用服务。
  • 告警闭环：指标告警触发后，直接跳到对应服务的 trace 和日志，缩短定位时间。
  • OpenTelemetry 迁移：应用侧用 OpenTelemetry 和 OTLP 输出标准信号，后端可以是自建 LGTM 或 Grafana Cloud。
  • 成本分层：日志、指标和 traces 分别按保留期、采样率、标签基数和对象存储策略治理。

观察 LGTM 自身时，重点看采集端 drop/retry、remote write 延迟、Loki 查询延迟、Tempo ingest/query 延迟、Mimir active series、对象存储错误、告警规则执行时间和 Label Cardinality。

边界与常见坑

  • LGTM 不是 Grafana 一个软件：Grafana 是可视化和查询入口，Loki、Tempo、Mimir 才分别承担日志、trace、metrics 后端。
  • LGTM 不是 OpenTelemetry 的替代品：OpenTelemetry 定义 API、SDK、语义约定和传输协议；LGTM 是接收、存储、查询和展示这些信号的一套后端组合。
  • 部署组件不等于有可观测性：如果没有稳定的 service.name、环境标签、trace context 传播和日志 trace ID，Grafana 很难自动建立有用跳转。
  • 不要把高基数字段随便做 label：用户 ID、请求 ID、完整 URL、错误文本等字段如果进入指标或日志标签，会导致 series 或 stream 数暴涨。
  • 采样会影响 trace 解释：如果 traces 被头部采样或尾部采样丢弃，指标异常时可能找不到对应 trace，不能误判为“没有发生过”。
  • 对象存储不是可选细节：Tempo 和 Mimir 的长期数据通常依赖对象存储；权限、生命周期、延迟和一致性都会影响查询和保留。
  • Grafana Cloud 与自建 OSS 边界要分清：二者都可以使用 LGTM 思路，但鉴权、多租户、容量规划、升级和运维责任不同。

相关术语

外部参考

目录

关系图谱

反向链接