用Jaeger做数据分析｜跟踪告诉我们更多！
作者：Pavol Loffay
我将直接切入主题，Jaeger目前只可视化收集来自测仪应用程序的数据。它不执行任何后处理（除了服务依赖关系图）或任何计算，以从它收集的跟踪中获得其他有趣的指标或特性。这是一个遗憾，因为跟踪包含了所有遥测信号中最丰富的信息！
在Jaeger中，我们希望解决这个问题，并为数据科学家和操作人员提供一个平台，以验证一个假设，并最终回答是什么导致停机或为什么系统以某种方式运行的问题。除了随需应变的事件调查外，目标还包括从Jaeger作为标准Jaeger部署的一部分收集的所有跟踪信息中获得见解。因此，让我们先看看一些用例，然后再看看技术细节。
指标
在我们深入研究平台概述之前，我想讨论一下从跟踪中可以派生出哪些指标标准。当然，不同的后处理工作将产生不同结构的结果，但现在我们只看一下指标，因为指标系统可以直接使用这些指标，所以解决方案不需要任何自定义存储和表示层。
网络延迟
服务A和服务B之间的网络延迟。
跟踪包含关于请求/事务的端到端信息。通过做一些最小的计算，我们能够获得客户机和服务器调用之间的网络延迟。结果可以导出为直方图，并按客户端和服务器服务标签进行划分。示例生成的Prometheus指标：
network_latency_seconds_bucket{client="frontend",server="driver",le="0.005",} 8.0network_latency_seconds_bucket{client="frontend",server="driver",le="0.01",} 9.0network_latency_seconds_bucket{client="frontend",server="driver",le="0.025",} 12.0network_latency_seconds_bucket{client="frontend",server="driver",le="0.05",} 15.0network_latency_seconds_bucket{client="frontend",server="driver",le="0.075",} 20.0进一步的改进是将主机用作标签，因为服务可以跨多个主机进行负载平衡，并且具有不同的网络特性。
此指标的另一个变体可能是消息传递系统中的使用者和生产者之间的持续时间。
跟踪和服务深度
服务深度为三的调用图——根服务和叶服务之间的最大跳数。
有时，在微服务架构中验证调用图的结构是很重要的。例如，我们可能想知道我们的调用图的最大深度是多少，它可以用来查找具有不同寻常的深度结构的异常跟踪。
服务深度是指在根跨（root span）和叶跨（leaf span）之间的最大网络跃点。
服务依赖关系
属于跟踪结构类别的另一个指标是：
一些依赖项。
一个服务的许多附属服务。
跟踪质量
毫无疑问，适当的跟踪工具是在组织中展开跟踪基础设施的最困难的部分。因此，指标在程序的应用在评估跟踪采用方面的表现如何是很重要的。这些指标可以使用：
jaeger_client_version - 在应用程序中使用适当的Jaeger客户机版本。
server_span和client_span — 跟踪包含服务器和客户机跨度的正确组合。例如，如果有客户端跨度，则应该有适当的服务器跨度。可以将相同的指标用于消息传递范围 — 生产者和消费者，以确定是否对通道的两端进行了检测。
unique_span_id — 跟踪中的span包含惟一的span id。
trace_quality_minimum_client_version_total{pass="false",service="route",version="Go-2.21.1",} 100.0trace_quality_minimum_client_version_total{pass="false",service="redis",version="Go-2.21.1",} 119.0trace_quality_minimum_client_version_total{pass="false",service="customer",version="Go-2.21.1",} 10.0trace_quality_minimum_client_version_total{pass="false",service="driver",version="Go-2.21.1",} 10.0trace_quality_server_tag_total{pass="false",service="mysql",} 10.0trace_quality_server_tag_total{pass="true",service="customer",} 8.0trace_quality_client_tag_total{pass="true",service="frontend",} 67.0trace_quality_client_tag_total{pass="false",service="driver-client",} 2.0这些质量指标最初是由Uber在Jaeger的Flink仓库中开源的。该解决方案计算指标并将结果存储在Cassandra表中。结果只是计数器，因此我们可以将它们导出到任何指标系统。但是，前一种解决方案还提供指向未通过某个质量指示器的跟踪的链接。这被证明是非常有用的。要完全支持这个特性，我们必须等到OSS指标系统支持跟踪范例。但是，如果必须将数百个跟踪链接到单个指标数据点，那么即使是跟踪范例也可能是不够的。
https://github.com/jaegertracing/jaeger-analytics-flink
https://v.qq.com/x/page/f30309o38o8.html
跟踪DSL
好的，我们已经讨论了一些用例，并且定义了我们的目标，即提供一个平台，在那里这些用例可以作为标准Jaeger部署的一部分轻松地实现和执行。为了使在跟踪和特征提取中编写聚合作业、过滤、导航变得非常简单，我们还应该提供一个API和一个库来处理跟踪或一组跟踪。
跟踪是一个有向无环图（directed acyclic graph，DAG），因此将它表示为一个图很有意义。我们决定重用现有的图API和Apache TinkerPop项目中的查询/遍历语言Gremlin。该项目还提供了一个内存中的数据库TinkerGraph，一旦我们从存储中加载跟踪（Kafka, Jaeger-query），我们就会使用它。
让我们看一下跟踪DSL的一些示例。第一个示例回答了“是否存在持续时间为120微秒的客户跨度？”
TraceTraversal<Vertex, Vertex> traversal = graph.traversal(TraceTraversalSource.class) .hasTag(Tags.SPAN_KIND.getKey(), Tags.SPAN_KIND_CLIENT) .duration(P.gt(120));您可能已经注意到，查询使用了跟踪DSL中的两个方法：hasTag和duration。这些方法是通过TraceTraversalSource.class添加到Gremlin核心API中的。结果是一个满足这个查询的顶点/span列表。从顶点/span我们可以导航到跟踪的其他部分。
第二个例子回答了这个问题：“名为child2的span是root span的直接后代吗？”
TraceTraversal<Vertex, Vertex> traversal = graph.traversal(TraceTraversalSource.class) .hasName("root") .repeat(__.out()) .until(__.hasName("child2"));这个查询更加复杂，它使用核心的Gremlin API调用，如repeat(__.out())来遍历到传出边缘。如果变得常用，那么将该查询作为Gremlin API扩展提供也是有意义的。我承认编写Gremlin查询并不简单，因此特性完整的跟踪DSL应该能够简化工作。
架构
下图描述了数据分析集成的Jaeger流架构。
Jaeger流架构图与数据分析集成。
分析平台有两个部分：所有传入数据的Spark流和按需Jupyter笔记本。
Spark流连接到Jaeger收集流水线使用的相同Kafka主题。它使用并分析数据，将结果作为Prometheus指标公开，或将结果写入存储器。
第二个集成路径是通过Jupyter笔记本完成的。该笔记本可以连接到Kafka以获取数据流或从Jaeger查询中获取历史数据。然后进行分析并将结果显示在笔记本上或发布到Prometheus或存储。
结论
我们讨论了Jaeger的数据分析平台的原因和用例。我们的目标是为这项工作建立一个社区，以帮助开发模型，并在实际部署中验证它们。最终，分析功能应该为我们提供更多关于应用程序行为的见解，以及用于事件分析的高级用户界面。该项目仍处于早期开发阶段，我们希望听到您的反馈！不要犹豫直接联系我们或在仓库中创建特性请求。
https://github.com/jaegertracing/jaeger-analytics-java
参考文献
Jaeger Java analytics：https://github.com/jaegertracing/jaeger-analytics-java
Jaeger analytics flink：https://github.com/jaegertracing/jaeger-analytics-flink
Apache TinerPop Gremlin：https://tinkerpop.apache.org/gremlin.html
Apache TinkerGraph docs：http://tinkerpop.apache.org/docs/current/reference/#tinkergraph-gremlin
点击文末<<阅读原文>>进入网页了解更多。
扫描二维码联系我们，加入中国最终用户支持者计划！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。