终端用户问答系列：在 Farfetch 使用 OTel

借由 Adriana Villela (Lightstep) |

由Rynn Mancuso（Honeycomb）和Reese Lee（New Relic）提供贡献。

2023年5月25日星期四，OpenTelemetry（OTel）终端用户工作组举办了2023年的第三次终端用户问答活动。由于KubeCon Europe，我们有了一段时间空档，但现在我们回来了！这个系列是一个月度的非正式讨论，与一个在生产中使用OpenTelemetry的团队进行交流。目标是更多地了解他们的环境、成功和面临的挑战，并与社区分享，以便我们共同使OpenTelemetry变得更好！

这个月，我与Farfetch的平台工程师Iris Dyrmishi进行了对话，了解了如下内容：

  • Farfetch对OpenTelemetry的使用过程
  • 如何将指标和跟踪工具应用于实际环境
  • OpenTelemetry Collector的部署和配置

问答

介绍一下你的角色

Iris是一个中心团队的成员，该团队为Farfetch的所有工程团队提供工具，用于监控其服务的跟踪、指标、日志和警报。该团队负责维护观测工具、管理与观测工具相关的部署，并教育团队如何使用OpenTelemetry对代码进行仪表化。

Iris最初从事软件工程师的职业，专注于后端开发。后来，她转向了DevOps工程师的角色，并在此角色中通过诸如Amazon CloudWatch和Azure App Insights等产品接触到了云监控。随着对监控的了解越来越深入，监控成为了她的热情。

然后，她转到另一个工作岗位，接触到了OpenTelemetry、Prometheus和Grafana，并且更深入地接触了观测领域。这个角色成为她目前在Farfetch的工作的一个很好的过渡，她已经从事这个工作有一年多的时间了。

你是如何了解到OpenTelemetry的？

Iris最初是在LinkedIn上听说了OpenTelemetry。当时她所在的公司没有使用跟踪的概念，并开始探索使用跟踪的可能性，寻找跟踪解决方案。在阅读了关于OpenTelemetry的资料后，Iris为她的经理制作了一个小的概念验证（POC）。虽然在那个职位上没有进一步推动，但当Iris加入Farfetch并且OpenTelemetry再次出现时，她迫不及待地开始了与OpenTelemetry合作的机会。

Farfetch的体系结构是什么样的？OpenTelemetry是如何发挥作用的？

Farfetch目前拥有2000多名工程师，具有复杂而多样的体系结构，其中包括云原生、Kubernetes和运行在三个不同云提供商上的虚拟机。有大量的信息来自各个方面，缺乏采集信息的标准化方法。例如，Prometheus主要用于收集指标；然而，在某些情况下，工程师发现Prometheus不符合他们的需求。通过引入OpenTelemetry，Farfetch能够标准化指标和跟踪的收集，并使得能够收集以前无法采集信号的服务的遥测信号成为可能。

你能描述一下在Farfetch的构建和部署过程吗？

Farfetch使用Jenkins进行CI/CD，有一个独立的团队负责管理这个过程。

你们使用哪些观测工具？

Iris的团队主要使用开源工具，以及团队内部创建的一些工具。在开源工具方面：

  • 使用Grafana来生成仪表板
  • 使用OpenTelemetry来发送跟踪信号，使用Grafana Tempo作为跟踪后端
  • 仍然在某些情况下使用Jaeger来发送跟踪信号，并作为跟踪后端，因为一些团队尚未完全转向使用OpenTelemetry进行跟踪仪表化（通过Jaeger对OpenTracing API的实现）。
  • 使用Prometheus Thanos（高可用的Prometheus）来收集和存储指标
  • 也使用OpenTelemetry来收集指标

告诉我们一下Farfetch在使用OpenTelemetry的过程中的经历

Farfetch是一个非常注重观测的组织，所以当高层管理层提出将OpenTelemetry引入组织时，得到了整个组织的支持。围绕OpenTelemetry的最大挑战是实施的时间安排；然而，一旦开始了OpenTelemetry的工作，每个人都全力以赴。

你和你的团队是如何通过OpenTelemetry实现观测的？

当Iris加入Farfetch时，大部分关于观测的困难和挑战已经过去。当观测首次在组织内引入时，它对许多工程师来说是非常新的，他们对此一无所知，而与所有的新事物一样，都需要一个学习过程。

当Iris和她的团队接手在整个组织推动OpenTelemetry使用的任务时，观测作为一个概念已经被广泛接受。他们在将OpenTelemetry引入Farfetch的最大挑战是确保工程师的工作不会受到重大干扰，同时仍然从使用OpenTelemetry中获益。OpenTelemetry与现有的观测技术栈中的许多工具（包括Jaeger和Prometheus）兼容，这对于维持现有工程师的工作流有很大帮助。

由于Iris和她的同事（Farfetch的一位架构师）对OpenTelemetry的热情、推动和努力，她自豪地分享他们现在正在生产环境中使用OpenTelemetry。

你们的团队花了多长时间将OpenTelemetry投入生产环境？

Iris和她的团队计划在2023年1月开始使用OpenTelemetry，包括初始调查和信息收集。到了3月中旬，他们的第一批数据就投入了生产环境。

他们还没有完全达到目标：

  • 生成指标的很多依赖仍然是Prometheus，生成跟踪信号的很多依赖仍然是Jaeger
  • 并没有所有的应用都已经使用OpenTelemetry进行仪表化

尽管如此，自从她和她的团队开始使用OpenTelemetry以来，他们开始让更多的跟踪信号进行仪表化。实际上，通过目前的设置，Iris很高兴地报告他们的跟踪信号处理量从每秒1,000个跨度增加到每秒40,000个跨度！

你们目前是如何收集跟踪信号的？

跟踪信号通过手动和自动仪表化相结合进行收集。

一些应用程序通过OpenTelemetry进行手动仪表化，其他一些应用程序仍然使用遗留的OpenTracing（使用shims）进行仪表化。

OpenTelemetry Operator正在实施自动对Java和.NET代码进行仪表化。OTel Operator支持在.NET、Java、Python和Node.js中注入和配置自动仪表化。Iris希望将来自动仪表化Go代码也能够实现。要跟踪自动仪表化在Go中的进展，请参阅OpenTelemetry Go自动仪表化。

尽管这将是一个冗长且耗时的过程，但团队的目标是将所有应用程序都使用OpenTelemetry进行仪表化。

你的团队为手动仪表化提供了哪些支持？

按设计，Iris和她的团队不会为其他团队的代码进行仪表化。相反，他们提供手动仪表化的文档和指南，并在适用的情况下引导团队查阅OpenTelemetry的文档。他们还与工程师进行会议，向他们展示围绕仪表化自己代码的最佳实践。这是一个团队的运动！

你能分享一下你使用OTel Operator的经验吗？

OTel Operator目前只在部分生产环境中使用，并且目前并不适用于所有人。Iris和她的团队真的很喜欢OTel Operator，但他们需要一点时间来适应它。Iris和她的团队发现OTel Operator与cert-manager之间存在紧密的耦合。他们不能使用自己的自定义证书，并且他们的集群不支持cert-manager，所以他们发现在集群中使用Operator很困难。他们通过提交了一个PR opentelemetry-helm-charts PR #760 来解决这个问题！

在使用OpenTelemetry解决Prometheus无法向Collector发送指标数据，从而无法从中创建警报的问题时，Iris对OpenTelemetry的一个想法特别感到喜欢。

你或者你的团队在Farfetch内开始尝试使用OTel Logging了吗？

Iris在研究日志时尝试过一些OTel日志（主要是从Kafka topic中消费日志）。这个实验没有包括日志关联，但这是Iris希望进一步探索的内容。

由于日志尚未稳定，Iris不指望日志很快在Farfetch中投入生产。Farfetch的日志量非常大（比跟踪信号还要多），因此在事情变得更加稳定之前，他们不打算开始转向OTel日志。

注意：OTel日志的某些部分是稳定的。有关详细信息，请参阅规范状态摘要。

你是如何收集指标信号的？

自动仪表化会生成一些OTLP指标信号；然而，大部分指标还是来自于Prometheus。

团队目前使用Prometheus Receiver从Consul中抓取指标。具体而言，他们使用Consul获取目标和抓取的端口。Receiver的抓取配置与Prometheus中的相同，因此从Prometheus迁移到Prometheus Receiver（升级和迁移）相对较容易。

他们还计划从Kubernetes中收集OTLP指标。这是通过Prometheus Receiver支持OTel Operator的Target Allocator实现的。

Prometheus当前还在其他领域的指标收集中使用，这种情况可能会保持不变，特别是在从虚拟机收集指标时。

你们正在监视多少个Kubernetes集群？

Farfetch正在监视100个Kubernetes集群和数千个虚拟机。Iris和她的团队负责跨所有这些集群管理OTel Operator，并因此也接受了Kubernetes的培训，以便在集群上维护他们的堆栈。

你们在Kubernetes的OTel实验性功能上有过任何尝试吗？

这个问题指的是Kubernetes组件发布OTLP跟踪信号的功能，这些信号可以被OTel Collector接收。有关更多信息，请参阅用于Kubernetes系统组件的跟踪信息。这个功能目前处于测试阶段，并在Kubernetes 1.25中首次推出。

Iris和她的团队没有尝试过这个测试功能。

你是如何部署OTel Collectors的？

由于存在大量的Kubernetes集群，拥有一个单独的OTel Collector将成为负载和单点故障。团队目前每个Kubernetes集群有一个OpenTelemetry Collector代理。最终的目标是使用OTel Operator替换这些代理，它允许您部署和配置OTel Collector，并注入和配置自动仪表化。

然后，所有数据都发送到每个数据中心的一个中央OTel Collector（即OTel Collector网关），在那里进行数据脱敏（使用transform processor或redaction processor）、数据抽样（例如tail sampling processor或probabilistic sample processor）等操作。然后将跟踪信号发送到Grafana Tempo。

中央OTel Collector位于另一个Kubernetes集群上，该集群仅属于Farfetch的Observability团队，负责运行Collector和团队的其他应用程序。

如果中央Collector出现故障会怎么样？

团队有备用集群，因此如果中央Collector发生故障，将使用备用集群。卫星集群的配置被设置为将数据发送到备份集群的中央Collector，因此如果中央集群发生故障，则可以启动备份集群，而不会中断OTel数据流。

为了保持系统高可用性，确保Collector具有足够的内存和CPU来处理数据负载的自动缩放策略也是必需的。

在部署OTel Collector方面你们遇到了哪些挑战？

最大的挑战是了解Collector以及如何高效使用它。Farfetch非常依赖自动缩放，因此团队最先要做的是为Collectors启用自动缩放，并调整设置以确保它能够处理大量的数据。

团队还大量使用OTel Helm charts，并依赖OTel社区提供的额外支持。

你们目前在OTel Collector上使用了哪些processors？

团队目前正在进行处理器实验，尤其是数据脱敏（transform processor或redaction processor），特别是在使用OTel日志时，这些日志将包含他们不希望传输到观测后端的敏感数据。然而，他们目前只使用了batch processor。

你是否知道有哪些团队正在使用Span Events？

Span Events提供了跟踪中的额外时点信息。它基本上是一个跨度内的结构化日志。

目前没有，但这是他们想要探索的内容。当Observability团队刚开始的时候，对跟踪的兴趣不大。随着他们开始实施OpenTelemetry和跟踪，他们已经使跟踪成为重要的工具，并且现在工程师对此产生了浓厚的兴趣，因为他们开始意识到跟踪的重要性。

你遇到过对OpenTelemetry持反对意见的人吗？

Farfetch非常注重观测的文化，观测团队并没有遇到过反对观测或OpenTelemetry的人。有些工程师可能不太在意，但他们也没有抵触。

你或者你的团队是否对OpenTelemetry做出了贡献？

由架构师领导的团队最近在OTel Operator的证书方面做出了贡献。OTel Operator依赖于cert-manager来获取证书，而不是使用自定义证书。他们最初提交了一个功能请求，然后决定自己开发这个功能，并提交了一个PR opentelemetry-helm-charts PR #760。

受众问题

需要多少内存和CPU？

当他们的Collector处理每秒大约30,000个跨度时，有4个Collector实例，使用了约8GB内存。

你是否对指标数据、跟踪数据和日志数据之间的关联感到关注？

目前正在探索这个问题。团队正在通过OpenTelemetry探索跟踪/指标关联（示例）；然而，他们发现在跟踪后端Tempo中更容易实现这种关联。

你是否担心你所产生、传输和收集的数据量？你是如何确保数据的质量？

这不是一个问题，因为数据量从未变过，团队知道他们可以处理这些大量的数据。团队只是在改变数据的生成、传输和收集方式。Iris还意识到跟踪数据的数量逐渐增加；然而，数据的增加是渐进的，所以团队可以为处理更大数据量做好准备。

团队正在努力建立高质量的数据。对于指标来说，这一点尤为重要，他们正在清理指标数据，以确保自己处理有意义的数据。如果一个团队决定大幅增加所生成的指标的数量，观测团队会事先咨询，以确保增加是有意义的。

由于跟踪的数据量最初较低，他们不需要关注跟踪采样。现在跟踪数据量增加了，他们正在密切关注。

团队还关注日志的数据质量和数量，这意味着研究日志处理器以找到适合他们需求的处理器。最终，他们将发布一套指导开发团队遵循的准则，并在公司内普及这些做法。

反馈

Iris和她的团队在使用OpenTelemetry和OpenTelemetry社区方面有非常积极的经验。

文档

Iris表示有时候文档并不像他们希望的那样清晰，需要工程师额外的努力去理解某个组件是如何工作或如何配置的。例如，她在寻找有关在OpenTelemetry中进行Consul SD配置的文档时遇到了困难。然而，Iris希望通过为文档贡献自己的力量来帮助改善文档。

PR的响应时间

Iris和她的团队对他们的OTel Operator PR被快速接受和合并的反馈时间感到惊讶和高兴。

其他资源

完整的与Iris的对话可在YouTube上观看。

如果有人想继续与Iris交流，可以在#otel-user-research Slack频道与她联系！

她还将在6月8日的OTel in Practice上进行演讲。

最后的思考

OpenTelemetry重视社区，如果没有我们的贡献者、维护者和用户，我们就不会取得现在的成就。了解OpenTelemetry在实际生活中的应用是一个重要的过程。我们重视用户的反馈，并鼓励所有的用户与我们分享您的经验，以便我们能够持续改进OpenTelemetry。❣️

如果您有关于如何在组织中使用OpenTelemetry的故事要分享，我们非常希望能够听到您的声音！分享的方式：

请务必关注OpenTelemetryMastodon和Twitter，并使用**#OpenTelemetry**标签分享您的故事！