OpenTelemetry教程:使用InfluxDB 3.0、Jaeger和Grafana收集跟踪、日志和指标

导航至

在这里,InfluxData最近宣布了InfluxDB 3.0,它扩展了InfluxDB可行的用例数量。InfluxDB 3.0所采用的新的存储引擎的主要优势之一是能够在单个数据库中存储跟踪、指标、事件和日志。

这些类型的时间序列数据都有其独特的工作负载,这留下了一些未解决的问题。例如

  • 我应该遵循什么模式?
  • 我该如何将跟踪转换为行协议?
  • InfluxDB如何与更大的可观察性生态系统相连接?

幸运的是,这正是我们OpenTelemetry工作发挥作用的领域。如果您想了解更多关于OpenTelemetry的信息,我们推荐阅读Charles Mahler的这篇博客。然而,本博客的目的是通过一个OpenTelemetry和InfluxDB 3.0的实际示例向您展示。

运行演示

让我们先从运行演示开始,然后讨论其背后的理论。下面是我们将要部署的演示

hot-rod-demo

此演示使用Hot R.O.D.模拟跟踪、日志和度量。然后我们使用OpenTelemetry Collector收集这些数据并将其写入InfluxDB 3.0。最后,我们使用Grafana和Jaeger UI以高度汇总的方式可视化这些数据。

要运行演示,您可以使用这个KillerCoda演示环境

只需创建一个账户,按照教程运行演示,无需担心本地安装。对于本地安装,我们已经在GitHub仓库中提供了所有信息,因此请查看仓库readme以获取最新的安装说明。

概述

让我们与Killercoda一起运行演示,让您了解可以期待什么

  1. 您将看到在第一次加载时,演示的配置脚本正在运行。这不会花费太多时间。一旦出现InfluxDB OTEL Demo,您就知道它已经加载完成。influxdb-otel-demo
  2. 如果您还没有一个账户,请按照以下步骤创建一个免费的InfluxDB 3.0云账户用于演示。free-InfluxDB-cloud-account请确保按照说明在InfluxDB中创建一个名为otel的桶,并为新的otel桶生成一个读写令牌。
  3. 接下来,我们提供InfluxDB 3.0的凭据,以便演示可以写入和查询我们的otel桶。为此,在Killercoda中选择Editor标签页,导航到influxdb-observability/.env。这是我们更新连接凭据的地方。注意:请确保将INFLUXDB_ADDR更新为指向您的InfluxDB云区域。此外,请从地址中删除任何协议(例如,HTTPS://)。 editor-killercoda
  4. 一旦我们完成环境更新,我们就可以开始运行演示了。只需点击此命令以启动演示:Step-2-Run the Docker Composer docker-compose --file demo/docker-compose.yml --project-directory
  5. 现在我们进入有趣的部分!让我们生成一些跟踪。首先,让我们打开HotROD应用程序。在本地安装中,它通过localhost:8080运行。要访问此地址,请遵循下面的截图中提供的超链接。generate-trace-activity
  6. 从那里,我们可以通过点击不同的按钮开始生成跟踪。每个按钮都模拟为指定的任务订购一辆车,这会触发后台服务调用并创建跟踪。Hot R.O.D.
  7. 如果您访问您的 InfluxDB 3.0 云实例,您可以探索 otel 存储桶模式,以了解我们如何将 OpenTelemetry 数据结构转换为 InfluxDB 的行协议,该协议由测量值、标签和字段组成。(注意:我们将在下一篇博客中更深入地介绍行协议。otel-bucket-schema
  8. 如果我们回到我们的 Killercoda 实例并打开 Grafana,我们可以探索我们的 OpenTelemetry 仪表板和配置。opentelemetry-dashboard

Grafana 解释

本节将介绍 Grafana 仪表板的一些关键功能。让我们从数据源开始。

grafana-dashboard-features

如您所见,我们连接了两个数据源——Flight SQL 和 Jaeger。这两个源都直接从 InfluxDB 3.0 拉取数据,但我们将详细讨论它们的工作原理和区别,在下一篇博客中。现在,您只需了解以下内容

  • Flight SQL——这是 InfluxDB 3.0 的直接 SQL 查询接口。它非常适合通用的时间序列查询和指标摘要。
  • Jaeger——这是 InfluxDB 3.0 和 Grafana 可视化之间的指标、日志和跟踪的桥梁接口。

让我们再次查看我们的仪表板,并将数据源映射到不同的面板。

map-data-sources

我们使用 Flight SQL 生成我们的通用导航和概览

  • 服务查询 InfluxDB 以获取在 otel 存储桶中找到的所有唯一服务。我们将服务名称用作其他可视化的数据链接。例如,点击 redis 将我的概览结果和跟踪列表仅包含服务 redisservices-queries
  • 持续时间返回所选时间段内每个 spanID 的持续时间(纳秒)。作为 SQL 查询的一部分,我们将此值转换为秒以提高可读性。duration-nanoseconds
  • 错误率根据在 otel.status 列中标记的错误数量计算服务错误率,以百分比表示。error-rate

我们使用 Jaeger 通过以下可视化来深入跟踪

  • 服务延迟直方图根据服务中跟踪的延迟创建直方图。此面板根据检测到的延迟范围分组跟踪跨度。service-latency-histogram
  • 跟踪提供与所选服务关联的跟踪表。该表包括跟踪名称、开始时间和持续时间。用户可以选择 TraceID 以生成下一个两个可视化:关系和跟踪。table-of-traces
  • 关系:在跟踪面板中选择 TraceID 后,用户可以使用跨度树在跟踪内导航跨度关系。我们将在下一篇博客中详细介绍这一点。traces-panel-relationships
  • 跟踪:此面板允许用户导航所选 TraceID 的原始跟踪数据和相关的日志数据。navigate-raw-trace-data

结论

我们希望这篇教程为您提供了学习更多关于OpenTelemetry以及InfluxDB 3.0如何在未来的可观察性解决方案中发挥关键作用的基础。请继续关注下一篇博客,我们将深入探讨OpenTelemetry的理论,分解演示架构中的每个组件,并讨论数据模式。在此之前,请尽情尝试演示,克隆仓库,看看您是否可以将这些组件应用于自己的用例。如果您有任何问题,请随时通过Slack与我们联系。