ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Grafana Tempo 自动日志(Automatic Logging):通过日志实现 Trace 发现与定位

Grafana Tempo 自动日志(Automatic Logging):通过日志实现 Trace 发现与定位 Grafana Tempo 自动日志Automatic Logging通过日志实现 Trace 发现与定位【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo当你运行一个已接入分布式追踪instrumented的系统时最大的难题之一往往是如何知道系统中存在哪些 Trace。Grafana Tempo 生态中的Automatic logging自动日志功能通过让 Grafana Alloy 为流经追踪管道的每个 span、root span 或 process 生成格式良好的日志行把 Trace ID 直接写进日志从而让你在 Loki 中按键值对检索 Trace并从一条日志一键跳转到 Grafana 中的对应 Trace 视图。读完本文你将掌握自动日志的完整配置方法OTLP 端点与 Loki 两种目标、默认日志字段与自定义属性、Loki 中的 LogQL 查询技巧以及用 TraceQL 实现等价检索的原生替代方案。Automatic logging 与 TraceQL 的定位差异自动日志解决的是Trace 可发现性问题在没有自动日志时日志与 Trace 彼此割裂排查问题时往往要从海量日志里手工翻找 Trace ID。而 Automatic logging 则让 Alloy 在追踪管道中自动生成包含 Trace ID 的日志行写入 Loki使日志成为进入 Trace 世界的入口。不过Tempo 的原生 TraceQL 检索现在已经能提供与自动日志等价的 Trace 发现能力而且不需要部署 Loki、也不会额外产生日志数据量。TraceQL 可以按服务名service name、span 名、持续时间、状态码以及自定义属性检索 Trace如果需要可视化、免写查询的探索方式也可以使用 Grafana 的 Traces Drilldown。自动日志仍然有它的适用场景如果你的工作流以 Loki 为中心例如排障时习惯先看应用日志自动日志会把 Trace ID 和 span 元数据与你的应用日志放在一起让你在调查日志数据的同时发现 Trace而不必切换到独立的 Trace 检索界面。这正是日志优先logs-first工作流的典型诉求。开始前的前置条件使用 Automatic logging 需要以下组件就绪Grafana Alloy已安装并正在从你的应用接收 Trace。Alloy 是 Tempo 文档中推荐的采集端兼容 OpenTelemetry Collector 与 Prometheus Agent其配置使用 Alloy 配置语法见 Grafana Alloy 章节。Loki 实例用于存储自动日志生成的日志数据。Tempo 实例用于存储 Trace以便从日志导航到 Trace。Grafana配置好 [Loki 数据源] 与 Tempo 数据源二者缺一不可。配置 Automatic loggingAutomatic logging 的核心是otelcol.connector.spanlogs这个 connector 组件它接收 Trace 并生成日志行但不会把原始 Trace 继续向下游转发。因此配置时必须把 Trace 同时发给spanlogsconnector 与你的 Trace 后端否则 Trace 数据会丢失。对于高吞吐系统如果对每个 span 都写日志日志量可能过大。此时应改为按 root span 或 process 粒度记录。connector 会在 span 或 resource 属性中检索一组配置的键并将其作为日志中的键值对输出随后你就可以在 Loki 中按这些键值对进行检索。将 root span 日志发送到 OTLP 端点下面的示例记录 root span 的日志并把生成的日志发送到 OTLP 端点。同时Trace 也被转发到同一端点确保 Trace 数据不丢失otelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.default.input, ] } } otelcol.connector.spanlogs default { roots true output { logs [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(OTLP_ENDPOINT) } }这个配置体现了 Alloy 管道接收器 → 处理器/连接器 → 导出器的架构可参考 Alloy 追踪管道架构说明 中的alloy-pipeline-architecture.svg图示otelcol.receiver.otlp的 output 是一个数组把 Trace 同时分发fan-out给 spanlogs connector 与 OTLP exporter这正是上文不能丢失 Trace的关键写法。roots true表示只对 root span 生成日志适合高吞吐场景控制日志量。将带自定义属性的 root span 日志发送到 Loki下面的示例记录 root span并额外携带http.method与http.target属性随后把生成的日志发送到 Loki 实例。Trace 则单独转发到 Tempo 实例。由于otelcol.exporter.loki默认不会把日志属性提升为 Loki 标签你必须使用otelcol.processor.attributes添加一个loki.attribute.labels提示把traces属性提升为 Loki 标签这样就能按日志类型过滤otelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.tempo.input, ] } } otelcol.connector.spanlogs default { roots true span_attributes [http.method, http.target] output { logs [otelcol.processor.attributes.default.input] } } otelcol.processor.attributes default { action { key loki.attribute.labels action insert value traces } output { logs [otelcol.exporter.loki.default.input] } } otelcol.exporter.loki default { forward_to [loki.write.local.receiver] } loki.write local { endpoint { url http://loki:3100/loki/api/v1/push } } otelcol.exporter.otlp tempo { client { endpoint tempo:4317 } }要点拆解span_attributes [http.method, http.target]指定要写入日志的 span 属性键它们会成为日志行中可检索的键值对。otelcol.processor.attributes中action insert、key loki.attribute.labels、value traces这是让 Loki exporter 把traces属性提升为标签的关键步骤否则 LogQL 中无法用{tracesroot}这种标签选择器过滤。otelcol.exporter.loki通过forward_to指向loki.write.local.receiver由loki.write组件最终把日志推送到 Loki 的 push API。Trace 出口与日志出口分离Trace 走otelcol.exporter.otlp.tempo端点tempo:4317即 Tempo 的 OTLP gRPC 端口日志走 Loki各司其职。从仓库示例可以看到这种 Alloy 配置与 example/docker-compose/distributed/config.alloy 中的 OTLP receiver/exporter 写法一脉相承该示例中 receiver 同样同时开启grpc与http端点可以直接作为搭建实验环境时对照的蓝本。预期输出默认日志字段与格式启用自动日志后connector 会根据你开启的选项为每个 span、root 或 process 生成一行日志。每行日志使用logfmt 风格的正文默认键如下KeyDescriptionsvcspan 所属 resource 中的服务名service name。spanspan 的名称。durspan 的持续时间纳秒例如150200000ns。tidTrace ID。statusspan 的状态。仅在状态被显式设置非STATUS_CODE_UNSET时出现。取值为STATUS_CODE_OK或STATUS_CODE_ERROR。你可以通过配置span_attributes、process_attributes或event_attributes来增加更多键也可以用overrides块自定义所有键名。例如一条 root span 日志可能长这样spanHTTP GET dur150200000ns http.methodGET http.target/api/v1/query svcmy-service tid7bba9f33312b3dbb8b2c2c62bb7abe2d除了上述键值对每条日志还带有一个traces属性用来标识日志类型span、root、process或event。如果你按上文 Loki 示例配置了loki.attribute.labels提示这个属性就会变成 Loki 标签可以直接在 LogQL 中过滤。在 Loki 中查询自动日志数据在 Grafana Explore 中使用 LogQL 查询自动日志。查找所有 root span 日志{tracesroot}过滤某个服务的慢请求时长超过 2 秒{tracesroot} | logfmt | dur 2s and svcmy-service这里| logfmt解析器把 logfmt 格式的日志正文解析为字段之后就能直接对dur纳秒与svc做比较运算。TraceQL 等价查询下面这些 TraceQL 查询提供了与上述 LogQL 查询相同的 Trace 发现能力且不需要自动日志也不需要 Loki 实例。查找某个服务的全部 Trace{ resource.service.name my-service }查找某个服务的慢 Trace持续时间超过 2 秒{ resource.service.name my-service span:duration 2s }查找错误 Trace{ status error }按特定属性检索{ span.http.method GET span.http.target /api/v1/query }需要说明的是TraceQL 中的span:duration表示单个 span 的起止时间差end - start而非整条 Trace 端到端的trace:duration二者语义不同详见 构造 TraceQL 查询 中关于 duration 的说明。此外status error这种按状态过滤的写法以及resource.service.name、span.http.method这类属性选择器都在 construct-traceql-queries.md 的示例中有对应的完整用法如{resource.service.name frontend name POST /api/orders status error}。TraceQL 是 Tempo 的原生查询语言其语法与语义与 PromQL、LogQL 相似见 TraceQL 总览如果你已熟悉日志查询上手成本很低。从日志跳转到 Trace要把日志行与其 Tempo 中的 Trace 直接关联起来需要在 Grafana 的 Loki 数据源上配置derived fields派生字段进入ConnectionsData sources选择你的 Loki 数据源。在Derived fields中添加新字段设置如下NameTraceIDTypeLabelMatch field nametid勾选Internal link并指向你的 Tempo 数据源保存数据源配置。配置完成后Explore 中的日志结果会在tid字段旁边显示一个链接点击即可直接跳转到对应 Trace 的瀑布视图。Tempo 首页也提到借助 Grafana 的 derived fields 支持可以在 LogQL 过滤出关心的请求后一键跳转到 Trace参见 Tempo 项目首页。总结Automatic logging 通过otelcol.connector.spanlogs组件把 Trace 元数据自动落成日志适合以 Loki 为中心的排障工作流日志行默认携带svc、span、dur、tid、status键可扩展自定义 span/process/event 属性配合loki.attribute.labels提示实现按traces标签过滤再通过 derived fields 实现日志 → Trace的一键跳转。若你不需要 Loki 且希望减少日志量Tempo 原生的 TraceQL 提供了完全等价且更轻量的检索路径两种方案互为补充你可以根据团队现有的观测技术栈选择。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表