跟踪与Grafana云代理和Grafana Tempo

罗伯特·弗拉托

•2020年11月17日•7分钟

编注:代码片段于2021-06-23更新。

早在三月份，我们介绍了Grafana代理，为托管指标而构建的Prometheus的子集。它使用了大量与Prometheus相同的经过战斗测试的代码，可以节省40%的内存使用。

自从发布以来，我们一直在为Agent添加功能。现在，有一个集群机制，额外的普罗米修斯出口商，并支持洛基。

我们的最新特色:Grafana节奏！这是一种操作简单、规模大、性价比高的分布式跟踪系统。

在这篇文章中，我们将探讨如何配置代理来收集跟踪并将它们发送到节奏．

配置Tempo支持

向现有Agent配置文件添加跟踪支持非常简单。你只需要加一个节奏块。那些熟悉OpenTelemetry Collector的人可能会认识以下代码块中的一些设置:

#其他代理设置tempo: configs:—name: default receivers: jaeger: protocols: thrift_compact: attributes: actions:—action: upsert key: env value: prod remote_write:—endpoint: tempo-us-central1.grafana.net:443 basic_auth: username: 12345 #将下面替换为#具有“Metrics Publisher”角色密码:

接收器允许Grafana代理接受来自多个系统的跟踪数据。我们目前支持接收跨度Jaeger，卡夫卡，OpenCensus，OTLP,Zipkin．

虽然OpenTelemetry Collector允许您配置度量和日志接收器，但我们目前只公开与跟踪相关的接收器。我们相信Agent中现有的普罗米修斯和洛基支持将满足其他支柱可观测性的需求。

如果你愿意，你可以配置Agent从每个接收端接收数据:

键配置启用接收方或其协议。将# it设置为空值将启用#该接收方或协议的默认配置。接收器:#配置机甲支持。GRPC支持跨端口# 14250,thrift_binary超过6832,thrift_compact超过6831，#和thrift_http超过14268。特定的端口号可以在协议的配置中#自定义。jaeger: protocols: grpc: thrift_binary: thrift_compact: thrift_http: #配置opencensus支持缺省情况下，span可以通过端口55678 #发送。opencensus: #配置otlp支持。默认情况下，span可以发送到端口55680。配置zipkin支持。 Spans can be sent to port 9411 by # default. zipkin:

属性，另一方面，使操作员能够操作发送到Grafana Agent的传入跨度上的标签。当你想添加一组固定的元数据时，这非常有用，比如记录一个环境:

属性:actions:—action: upsert key: env value: prod

上面的配置示例为所有接收到的值为“prod”的span设置了一个“env”标记。“upsert”动作意味着具有现有“env”标记的span将覆盖其值。这有助于确保您知道哪个Agent接收了一个span，以及它在哪个环境中运行。

属性非常强大，并且支持这里示例之外的用例。看看OpenTelemetry关于它们的文档获取更多信息。

但在Grafabob电竞频道na实验室，我们并不是只使用OpenTelemetry Collector的一个子集就完事了;我们增加了对普罗米修斯风格的支持scrape_configs可用于根据已发现目标的元数据自动标记传入跨度。

用Prometheus服务发现附加元数据

Promtail是一个日志客户端，用于收集日志并发送给Loki。它最强大的功能之一是支持使用Prometheus的服务发现机制。这些服务发现机制使您能够将与度量相同的元数据附加到日志中。

当您的指标和日志具有相同的元数据时，您可以降低在系统之间切换的认知开销，并且它会给人一种“感觉”，即所有数据都存储在一个系统中。我们希望将此功能扩展到跟踪。

乔-艾略特在代理的跟踪子系统中添加了相同的Prometheus服务发现机制。它的工作原理是将系统发送范围的IP地址与发现的服务发现目标的地址相匹配。

对于Kubernetes用户，这意味着您可以动态地附加容器发送跨度的命名空间、pod和容器名称的元数据:

Tempo: configs:—name: default receiver: jaeger: protocols: thrift_compact: scrape_configs:—bearer_token_file: /var/run/secrets/kubernetes。Io /serviceaccount/token job_name: kubernetes-pods kubernetes_sd_configs:—role: pod relabel_configs:—source_labels: [__meta_kubernetes_namespace] target_label: namespace—source_labels: [__meta_kubernetes_pod_name] target_label: pod—source_labels: [__meta_kubernetes_pod_container_name] target_label: container tls_config: ca_file: /var/ runs /secrets/ kubernetes_io /serviceaccount/ca。CRT insecure_skip_verify: false # remote_write，等等

附带Kubernetes服务发现元数据的跨度的截图

然而，这个功能不仅仅对Kubernetes用户有用。普罗米修斯的全部各种服务发现机制这里支持。这意味着你可以使用相同的scrape_configs在您的指标、日志和跟踪之间获得相同的标签集，并在从指标、日志和跟踪移动时轻松地在可观察性数据之间转换。

配置如何推送跨度

当然，只是收集跨度不是很有用!配置Tempo支持的最后一部分是通过remote_write部分。remote_write描述了一个类似普罗米修斯的配置块来控制收集的跨度发送到哪里。

对于好奇的人来说，这是OpenTelemetry收集器的包装OTLP出口国．由于代理导出OTLP格式的跨度，这意味着您可以将跨度发送到支持OTLP数据的任何系统。我们今天关注的是Tempo，但是你甚至可以让Agent发送跨度到另一个OpenTelemetry Collector。

除了端点和身份验证之外，remote_write允许您控制跨度的排队和重试功能。批处理是在remote_write并且允许更好地压缩跨度和减少用于向Tempo传输数据的传出连接的数量。和以前一样，OpenTelemetry也有一些非常好的文档在这。

tempo: configs: - name: default #批量设置跨度。收集10000个跨度后或10秒后完成一批，以先到者为准。批处理:send_batch_size: 10000超时:10s # remote_write等

在remote_write方面,队列而且重试允许您配置将在内存中保留多少批，以及如果批处理失败将重试多长时间。这些设置与retry_on_failure而且sending_queue设置从OpenTelemetry的OTLP出口商：

tempo: configs:—name: default remote_write:—endpoint: tempo-us-central1.grafana.net:443 basic_auth: username: 12345 password: api_key #将默认队列大小增加一倍，以便在内存中保留更多批次#，但在5s后放弃重试失败的span。Sending_queue: queue_size: 10000 retry_on_failure: max_elapsed_time: 5s

虽然将最大重试时间设置得很高很有诱惑力，但它很快就会变得危险。重试将会增加从Agent到Tempo的网络流量总量，并且减少跨度可能比不断重试更好。另一个风险是内存使用:如果您的后端中断，高重试时间将迅速填满span队列，并可能导致代理出现内存不足错误。

由于对于具有很大的span吞吐量的系统来说，存储100%的span是不现实的，因此控制批处理、队列和重试逻辑以满足特定的网络使用情况对于有效跟踪是至关重要的。