乐趣区

关于运维:Grafana-系列文章十五Exemplars

jiezi

Exemplars 简介

Exemplar 是用一个特定的 trace，代表在给定工夫距离内的度量。Metrics 善于给你一个零碎的综合视图，而 traces 给你一个繁多申请的细粒度视图；Exemplar 是连贯这两者的一种形式。

假如你的公司网站正经验着流量的激增。尽管超过百分之八十的用户可能在两秒内拜访网站，但有些用户的响应工夫超过了失常程度，导致用户体验不佳。

为了确定造成提早的因素，你必须将疾速响应的 trace 与迟缓响应的 trace 进行比拟。鉴于典型生产环境中的大量数据，这将是十分费劲和耗时的工作。

应用 Exemplar 来帮忙隔离你的数据分布中的问题，办法是在一个工夫距离内找出体现出高提早的查问痕迹。一旦你把提早问题定位到几个示范跟踪，你就能够把它与其余基于零碎的信息或地位属性联合起来，更快地进行根本原因剖析，从而疾速解决性能问题。

对 Exemplar 的反对 仅实用于 Prometheus数据源。一旦你启用该性能，Exemplar 数据默认是可用的。

Grafana 在 “Explore” 视图和仪表盘中与指标一起显示 Exemplar。每个 Exemplar 显示为高亮的星星。你能够将光标悬停在 Exemplar 上，查看惟一的 traceID，它是一个键值对的组合。要进一步剖析，请点击 “traceID “ 属性旁边的蓝色按钮。示例如下：

背景

Exemplars 是最近可察看性畛域的一个热门话题，这是有起因的。

与 Prometheus 如何在 2012 年开始破而后立了大规模存储指标的老本构造，并在 2015 年真正实现，以及 Grafana Loki 如何在 2018 年破而后立了大规模存储日志的老本构造相似，Exemplar 也在对 trace 做同样的事件。为了理解起因，让咱们看看云原生生态系统中可察看性的历史，以及 Exemplar 可能实现哪些优化。

外围是，Exemplar 是一种通过 ID 从有意义的指标和日志跳到追踪的形式。Grafana Tempo，Grafana Labs 的 开源、大规模分布式跟踪后端，就是围绕这个想法建设的，因为 Exemplar 使分布式跟踪的老本和性能特色变得好了。现实状况下，你永远不须要对你的追踪进行采样，而 Tempo 让这成为事实。

Prometheus

临时疏忽 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

OpenMetrics

早在 2015-2016 年，相干开发者就打算同样的标签集也利用于日志和追踪。这就是为什么 OpenMetrics 自 2017 年以来始终处在一个叫做 OpenObservability 的 GitHub 组织中，而不是 “ 仅仅 “ 一个叫做 OpenMetrics 的组织。

Grafana Loki

有了 Loki，这个幻想在 2018 年实现了。在你的指标和日志之间无缝挪动，没有问题。这就是 “Like Prometheus but for logs” 的标语的由来。

这让咱们不得不将标签集利用于 trace，对吗？

OpenMetrics & OpenCensus

2017 年，OpenMetrics 和 OpenCensus 散会，试图看看这两个我的项目是否能够合并。尽管因为设计指标、经营模式和数据模型的不兼容而没有胜利，但这次会议还是扭转了 OpenMetrics 和 Prometheus 的命运，也是引出了 Grafana Tempo 的外围设计。

Exemplars 设计思路

实质上，Exemplar 就是以下三个想法：

  1. 将 trace 与其余可察看性数据紧密结合。
  2. 只通过 ID 跳入 trace。
  3. 只有当你晓得对哪个 trace 感兴趣，以及为什么感兴趣的时候，才跳入该 trace。防止 “ 频繁跳入跳出 ”。

紧密结合

通过 exemplars 将 trace ID 附加到指标上是非常简单的。在你的度量值（可能还有工夫戳）前面加一个 “#”，示意有一个 exemplars 存在，而后增加你的数据。

借用 OpenMetrics 标准 中的例子：

# TYPE foo histogram
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 的 trace。

显示 10 秒以下提早的直方图桶有一个运行工夫为 9.8 秒的 trace，工夫为1520879607.789，ID 为oHg5SJYRHA0。

就是这样！

仅限 ID

索引是低廉的。把残缺的上下文和元数据放在 trace 上意味着你须要通过它们来搜寻 trace，这就意味着对它们进行索引。然而你想在你的指标、日志和 trace（以及 conprof、crashdumps 等）上有雷同的标签。然而，因为你在其余数据上曾经有了这些元数据，重用雷同的索引以节省成本和工夫如何？

通过在一个特定的工夫点上将 trace 附在一个特定的工夫序列或日志上，你就能够做到这一点。对于 trace 自身，你只需对 ID 进行索引，就能够了。

仅限感兴趣的 traces

主动跟踪剖析是一个宽泛的畛域；大量精湛的工程力量被用于使这个干草堆可被搜寻。

如果有一个更便宜、更无效的办法呢？

日志曾经能够通知你一个谬误状态或相似的状况。你不须要剖析 trace 来找到那个谬误。

指标中的计数器、直方图等曾经是一种高度稀释和优化的数据模式，被提炼成在这种状况下重要的货色。你不须要剖析所有的 trace 来找到那个显示高提早的 trace。

你的日志和你的指标曾经通知你 为什么 一个 trace 是须要深入调查的。你的标签给了你如何和在哪里产生 trace 的背景。在跳入 trace 的时候，你曾经晓得你在寻找什么和为什么。这就大大放慢了发现的速度。

Prometheus 启用 Exemplar storage Feature

📚️ Reference:
Exemplars storage | Prometheus Doc

--enable-feature=exemplar-storage

OpenMetrics 介绍了刮削指标为某些度量规范增加 Exemplars 的能力。典型利用场景是对 MetricSet 之外的数据的援用。一个常见的用例是 trace ID。

Exemplar 存储是作为一个固定大小的圆形缓冲区实现的，它将所有系列的 exemplar 存储在内存中。启用此性能将使 Prometheus 刮削来的 exemplar 的存储成为可能。配置文件块 storage/exemplars 能够用来管制循环缓冲区的大小。一个只有 traceID=<jaeger-trace-id> 的 exemplar 通过内存中的 exemplar 存储大概应用 100 字节的内存。如果 exemplar 存储被启用，咱们也会将 exemplar 追加到 WAL 中进行本地长久化（在 WAL 持续时间内）。

在 Prometheus 数据源中配置 Exemplar

📚️ Reference:

无关 Exemplar 配置和如何启用 Exemplar 的更多信息，请参阅 在 Prometheus 数据源中配置 Exemplar

📝 Notes:

该性能在 Prometheus 2.26+ 和 Grafana 7.4+ 上可用。

Grafana 7.4 及当前的版本可能在 Explore 和仪表盘中显示与指标相干的 Exemplar 数据。Exemplar 数据是一种将特定事件中的高权重元数据与传统工夫序列数据分割起来的形式。

通过增加内部或外部链接，在数据源设置中配置 Exemplars。

查看 Exemplar 数据

📚️ Reference:

请参考 查看 exemplar 数据, 理解如何从指标和日志中钻取和查看 Exemplar trace 细节。

当 prometheus 数据源启用对 exemplar 反对时，你能够在 Explore 视图或从 Loki 日志细节中查看 exemplar 数据。

Explore

Explore 将 exemplar 的跟踪数据可视化为高亮的星星和指标数据。对于 Explore 如何将跟踪数据可视化的更多信息，请参考 Explore 中的跟踪。

要查看 exemplar 跟踪的细节。

  1. 将你的光标放在一个 exemplar（突出显示的星星）上。依据你的后端 trace 数据源，你会看到一个蓝色的按钮，标签是 Query with <DataSource Name>。在上面的例子中，Trace 的数据源是 Tempo。

  2. 点击 traceID 属性旁边的 Query with Tempo 选项。Trace 的细节，包含 trace 中的 span 都列在左边的独立面板中。

Logs

你也能够在 Explore 中查看 Loki 日志中的 exemplar 跟踪细节。在 Loki 的 Derived fields 链接中应用 regex 来提取 traceID 信息。当初当你开展 Loki 日志时，你能够在 检测字段 局部看到 traceID 属性。要理解更多对于如何将日志信息的一部分提取到外部或内部链接中，请参考 在 Loki 中应用衍生字段。

要查看 exemplar 跟踪的细节：

  1. 开展一个日志行，向下滚动到 “ 检测到的字段 “ 局部。依据你的后端跟踪数据源，你会看到一个蓝色的按钮，标签是< 数据源名称 >。
  2. 点击 traceID 属性旁边的蓝色按钮。通常状况下，它将有后端数据源的名称。在上面的例子中，追踪的数据源是 Tempo。追踪的细节，包含追踪中的 span 都列在左边的独立面板中。

总结

Exemplars 就是这样的。工程设计始终是为了适应设计指标和约束条件而进行的衡量。

Prometheus 将整个行业转移到一套新的衡量规范，发明了云原生察看能力的基石。Grafana Loki 也在做同样的日志工作。Grafana Tempo 正在通过 exemplars 的力量为分布式追踪做这件事。

Tempo 的工作是存储大量的跟踪，把它们放在对象存储中，并通过 ID 来检索它们。因为所有这些都遵循一个整体设计，在指标、日志和追踪之间的无缝挪动曾经成为可能，而且是真正的云原生规模。

Exemplars 曾经 从 7.4 开始在 Grafana 中失去反对。

参考文档

  • Exemplars 介绍，实现 Grafana Tempo 的大规模分布式追踪

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.

退出移动版