👉️URL: https://grafana.com/blog/2020…
✍Author: Robert Fratto • 17 Nov 2020
📝Description:
Here’s your starter guide to configuring the Grafana Agent to collect traces and ship them to Tempo, our new distributed tracing system.
编者注：代码片段已于 2021-06-23 更新。
早在 3 月份，咱们 介绍 了 Grafana Agent，这是 Prometheus 的一个子集，为托管指标而建。它应用了很多与 Prometheus 雷同的通过实战测验的代码，能够节俭 40% 的内存应用。
自推出以来，咱们始终在为 Agent 增加性能。当初，新增性能有：集群机制，额定的 Prometheus exporters，以及对 Loki 的反对。
咱们的最新性能。Grafana Tempo! 这是一个易于操作、规模大、成本低的分布式追踪零碎。
在这篇文章中，咱们将探讨如何配置 Agent 来收集跟踪，并将其发送到 Tempo。
配置 Tempo 反对
在你现有的 Agent 配置文件中增加 trace 反对很简略。你所须要做的就是增加一个tempo 块。相熟 OpenTelemetry Collector 的人可能会认出以下代码块中的一些设置。
# other Agent settings
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
# Replace <Grafana API Key> below with an API key that
# has the "Metrics Publisher" role
password: <Grafana API Key>接收器 容许 Grafana Agent 承受来自泛滥零碎的追踪数据。咱们目前反对从 Jaeger、Kafka、OpenCensus、OTLP 和 Zipkin 接管跨度。
尽管 OpenTelemetry Collector 容许你配置指标和日志接收器，但咱们目前只公开了与追踪无关的接收器。咱们置信 Agent 内现有的 Prometheus 和 Loki 反对将满足其余支柱察看能力的须要。
如果你违心，你能够将代理配置为承受每一个接收器的数据。
tempo:
# 键，配置启用一个接收器或其协定。# 把它设置为空值能够启用该接收器或协定的默认配置。receivers:
# 反对 grpc14250 端口的 spans，# 6832 端口的 thrift_binary，# 6831 端口的 thrift_compact，# 以及 14268 端口的 thrift_http。# 具体的端口号能够 特定的端口号能够在协定的配置中自定义。jaeger:
protocols:
grpc:
thrift_binary:
thrift_compact:
thrift_http:
# 配置 opencensus 反对。span 能够通过端口 55678 发送，# 这是默认的。opencensus:
# 配置 otlp 反对。Spans 能够被发送到 55680 端口，# 这是默认的。otlp:
protocols:
grpc:
http:
# 配置 zipkin 反对。Spans 能够被发送到 9411 端口，# 这是默认的。zipkin:另一方面，属性 使操作者可能操作发送到 Grafana Agent 的传入 span 上的标签。当你想增加一组固定的元数据时，这真的很有用，比方备注一个环境。
attributes:
actions:
- action: upsert
key: env
value: prod下面的配置例子为所有收到的 span 设置了一个 env标签，其值为 prod。upsert 动作意味着具备现有 env标签的 span 将被笼罩。这对于保障你晓得哪个 Agent 收到了 span 以及它在哪个环境下运行是很有用的。
属性 (Attributes) 真的很弱小，并且反对超出这里的例子的应用状况。请查看 OpenTelemetry 对于它们的文档 以理解更多信息。
但在 Grafana Labs，咱们并没有仅仅应用 OpenTelemetry Collector 的一个子集就了事；咱们减少了对 Prometheus 格调的 scrape_configs 的反对，能够用来依据发现指标的元数据主动标记传入的 span。
用 Prometheus 服务发现附加元数据
Promtail 是一个日志客户端，用于收集日志并将其发送到 Loki。它最弱小的性能之一是反对应用 Prometheus 的服务发现机制。这些服务发现机制使你可能将雷同的元数据附加到你的日志和你的指标上。
当你的指标和日志有雷同的元数据时，你就能够升高在零碎之间切换的认知开销，并且让有一种你的所有数据都贮存在一个零碎中的 “ 感觉 ”。咱们心愿这种能力也能扩大到追踪方面。
Joe Elliott 在 Agent 的追踪子系统中减少了雷同的 Prometheus 服务发现机制。它的工作原理是将发送 span 的零碎的 IP 地址与发现的服务发现指标的地址相匹配。
对于 Kubernetes 用户来说，这意味着你能够动静地附加发送 span 的容器的命名空间、pod 和 container 名称的元数据。
tempo:
configs:
- name: default
receivers:
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/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: false
# remote_write, etc不过，这个性能不仅仅对 Kubernetes 用户有用。这里反对 Prometheus 的所有 各种服务发现机制。这意味着你能够在你的度量、日志和追踪之间应用雷同的 scrape_configs 来取得雷同的标签集，当从你的度量、日志和追踪中切换时，能够轻松地在你的可察看性数据之间转换。
配置 Span 的推送形式
当然，仅仅收集 span 并不非常有用！配置 Tempo 反对的最初局部是通过 remote_write 局部。remote_write形容了一个相似于 Prometheus 的配置块，用来管制收集的 span 被发送到哪里。
对于好奇的人来说，这是对 OpenTelemetry Collector 的 OTLP exporter 的一个封装。因为 Agent 导出 OTLP 格局的 span，这意味着你能够将 span 发送到任何反对 OTLP 数据的零碎。咱们明天的重点是 Tempo，但你甚至能够让 Agent 发送跨度到另一个 OpenTelemetry 采集器。
除了端点和认证，remote_write容许你管制 span 的排队和重试性能。批处理 (Batching)是在 remote_write 之外治理的，能够更好地压缩 span，缩小用于向 Tempo 传输数据的出站连接数。和后面一样，OpenTelemetry 在这方面有一些 相当好的文档。
tempo:
configs:
- name: default
# span 的批处理设置。在收集 10,000 个跨度后
# 或 10s 后（以先到者为准）实现一个批次。batch:
send_batch_size: 10000
timeout: 10s
# remote_write, etc在 remote_write方面，queues和 retries 容许你配置在内存中保留多少个批次，以及如果一个批次碰巧失败了，你将重试多长时间。这些设置与 OpenTelemetry’s OTLP exporter 的 retry_on_failure 和sending_queue设置雷同。
tempo:
configs:
- name: default
remote_write:
- endpoint: tempo-us-central1.grafana.net:443
basic_auth:
username: 12345
password: api_key
# 将默认的队列大小增加一倍，以便在内存中保留更多的批次，# 但在 5 秒后放弃重试失败的 span。sending_queue:
queue_size: 10000
retry_on_failure:
max_elapsed_time: 5s尽管把最大重试工夫设置得很高很迷人，但它很快就会变得很危险。重试会减少从 Agent 到 Tempo 的网络流量总量，与其一直重试，不如放弃 span。另一个危险是内存的应用。如果你的后端产生故障，高重试工夫将迅速填满 span 队列，并可能以 Out Of Memory 谬误使 Agent 宕机。
因为对于一个有大量 span 吞吐量的零碎来说，100% 的 span 被存储是不事实的，管制批处理、队列和重试逻辑以满足你的特定网络应用，对于无效追踪是至关重要的。
下回见
咱们曾经谈到了如何手动配置 Grafana Agent 以取得 tracing 反对，但要想理解一个理论的例子，请查看 production-ready tracing Kubernetes manifest。这个清单附带的配置波及到这里的所有内容，包含服务发现机制，以主动将 Kubernetes 元数据附加到传入的 span 上。
我非常感谢 Joe 从他忙碌的 Tempo 工作中抽出工夫，在 Agent 中增加跟踪反对。我很快乐 Grafana Agent 当初反对大部分的 Grafana 堆栈，而且我对接下来的产品更感兴趣
原文内置：
开始应用 Tempo 的最简略办法是在 Grafana Cloud。咱们有收费的（包含 50GB 的痕迹）和付费的 Grafana Cloud 打算，以满足各种应用状况 – 当初注册收费。
词汇表
| 英文 | 中文 | 备注 |
|---|---|---|
| Receivers | 接收器 | Grafana Agent 组件 |
| Trace | 追踪 | |
| span | 跨度 | Tracing 专有名词 |
Grafana 系列文章
Grafana 系列文章