介绍范例，使Grafana Tempo在大规模的分布式跟踪

•2021年3月31日•6分钟

范例是最近可观察性领域的一个热门话题，这是有充分理由的。

类似于普罗米修斯从2012年开始大规模存储度量的成本结构被打乱，到2015年才真正实现Grafana洛基在2018年，大规模存储日志的成本结构被打乱，样品也在对痕迹进行同样的操作。为了理解原因，让我们看看云原生生态系统中可观察性的历史，以及优化范例支持什么。

在其核心，范例是一种通过ID从有意义的度量和日志跳转到跟踪的方法。Grafana节奏， bob电竞频道Grafana实验室的开源、高规模的分布式跟踪后端，是围绕这一思想建立的，作为范例使分布式跟踪的成本和性能特点很多更好的。理想情况下，你永远不需要对你的痕迹进行采样，Tempo让这变得很现实。

历史

普罗米修斯

暂时忽略Prometheus出色的可伸缩性、压缩和性能，让我们关注标签集:它们是关于时间序列的元数据。什么集群、什么服务、哪个客户、什么部署级别等等都可以用非层次键值对编码。如果你正在阅读这篇文章，我很可能不需要说服你这种改变对行业的破坏性、影响力和持久性;我只是想提醒你们一下，因为它与正文的其余部分有关。

这在几年前还是革命性的:

acme_http_router_request_seconds_sum{path="/api/v1"，method="GET"} 9036.32 acme_http_router_request_seconds_count{path="/api/v1"，method="GET"} 807283.0 acme_http_router_request_seconds_sum{path="/api/v2"，method="POST"} 479.3 acme_http_router_request_seconds_count{path="/api/v2"，method="POST"} 34.0 . acme_http_router_request_seconds_sum{path="/api/v2"，method="POST"

OpenMetrics

早在2015-2016年，我就打算将相同的标签集应用到日志和跟踪。这就是为什么OpenMetrics一直住在GitHub一个叫OpenObservability而不仅仅是一家名为OpenMetrics的组织。

Grafana洛基

有了Loki，这个梦想在2018年实现了:在参数和日志之间无缝切换，没有任何问题。这就是广告语“像普罗米修斯，但为了原木”的由来。

剩下的就是将标签集应用到痕迹上，对吧?

OpenMetrics & OpenCensus

2017年，OpenMetrics和OpenCensus会面，试图看看两个项目是否可以合并。尽管由于设计目标、操作模型和数据模型的不兼容而未能实现，但这次会议仍然改变了OpenMetrics和Prometheus的命运，并成为催生Grafana Tempo的核心。

我提出了将《Prometheus》的标签集应用于指标和追踪的想法，但在场的一些谷歌人却认为这是一种追踪;他们告诉我搜索是不可扩展的。

让我强调这一点:谷歌员工告诉我搜索痕迹不能扩展．

如果谷歌告诉你，寻找某样东西是无法扩展的，你最好听从并让它成为你的快乐之路。

而会议指出不幸的是，我没有抓住谁提出了这一点，所以我不能赞扬他们，也不能说太多的例子，这在当时是很重要的，应该写下来;如果只是一个字。

有趣的是，在这些笔记中，你可以看到OpenMetrics当时仍处于个人回购状态:https://github.com/RichiH/OpenMetrics．

第二个有趣的事实:最初https://github.com/OpenObservability/OpenMetrics是从https://github.com/RichiH/OpenMetrics．GitHub必须在数据库中手动更改这一点，因为当时没有支持这一点的进程。

今天;或者是范例101

从本质上讲，范例是关于三个想法的:

与其他可观察性数据紧密耦合的痕迹。
仅通过ID跳转到跟踪。
只有当您知道跟踪是有趣的，以及原因时，才会进入跟踪。避免大海捞针。

紧耦合的

通过范例将跟踪id附加到度量是非常容易的。放一个＃在您的度量值(以及可能的时间戳)之后，以表明示例的存在，并添加您的数据。

借用的例子OpenMetrics规范：

# TYPE foo直方图foo_bucket{le="0.01"} 0 foo_bucket{le="0.1"} 8 # {} 0.054 foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67 foo_bucket{le="10"} 17 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789 foo_bucket{le="+Inf"} 17 foo_count 17 foo_sum 324789.3 foo_created 1520430000.123

如果trace_id标签名称和值提醒您提出的规范W3C分布式跟踪工作组，这不是巧合。我们故意采用了W3C规范，但并没有强制使用它。这允许我们在现有规范工作的基础上进行构建，同时在分布式跟踪空间稳定下来之前不会束缚OpenMetrics。

让我们看看里面的实际例子:

显示延迟小于1秒的直方图桶有一个运行时为0.67秒的跟踪，ID为KOO5S4vxi0o。

显示10秒以下延迟的直方图桶有一个运行时为9.8秒的跟踪，时间为1520879607.789,ID为oHg5SJYRHA0。

这是。它。