最终用户问答系列：在 Farfetch 使用 OTel
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
由 Rynn Mancuso (Honeycomb) 和 Reese Lee (New Relic) 贡献。
2023 年 5 月 25 日，星期四，OpenTelemetry (OTel) 最终用户工作组举办了 2023 年第三次最终用户问答会议。由于 KubeCon Europe 的原因，我们稍微中断了一下，但现在我们回来了！本系列是每月一次与在生产环境中使用 OpenTelemetry 的团队进行的非正式讨论。目标是了解他们的环境、他们的成功以及他们面临的挑战，并与社区分享，以便我们共同努力，让 OpenTelemetry 变得更加出色！
本月，我与Iris Dyrmishi（Farfetch 的平台工程师）进行了交流。
概述
Iris 是可观测性和 OpenTelemetry 的忠实拥趸，她对这两个主题的热爱极具感染力。
在本次会议中，Iris 分享了
- 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)。尽管在该职位上 POC 并未取得进一步进展，但当 Iris 加入 Farfetch 并再次提到 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 的热情、驱动力和推动，Iris 很自豪地分享他们现在已在生产环境中使用 OpenTelemetry。
您的团队花了多长时间才将 OpenTelemetry 投入生产？
Iris 和她的团队计划在 2023 年 1 月开始使用 OpenTelemetry。这包括初步的调查和信息收集。到 3 月中旬，他们已经将第一批产品投入生产。
他们尚未完全完成
- 在生成指标和追踪数据方面，仍然很大程度上依赖于 Prometheus 和 Jaeger。
- 并非所有应用程序都已使用 OpenTelemetry 进行插桩
尽管如此，Iris 和她的团队正在利用OpenTelemetry Collector 的强大功能来收集数据并将其发送到各种可观测性后端。自从她和她的团队开始使用 OpenTelemetry 以来，他们开始插桩更多的追踪数据。事实上，在他们目前的设置下，Iris 高兴地报告说，他们每秒处理的 span 从 1000 个增加到了 40000 个！
您目前是如何收集追踪数据的？
追踪数据是通过手动和自动插桩的组合来收集的。
一些应用程序正在通过 OpenTelemetry 进行手动插桩，而另一些应用程序仍然使用 [遗留 OpenTracing使用适配器进行插桩。
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 和她的团队发现 cert-manager 和 OTel Operator 之间存在紧密耦合。他们无法使用自己的自定义证书，并且在他们的集群中不支持 cert-manager，因此他们发现很难在我们的集群中使用该 Operator。他们通过提交一个 PR 来解决这个问题——opentelemetry-helm-charts PR #760！
她喜欢 OpenTelemetry 的一点是，当她试图解决 Prometheus 未能将指标发送到 Collector 的问题时，因此无法从中创建警报。然后一位同事建议使用 OpenTelemetry 来调试 OpenTelemetry。
您或您的团队成员或 Farfetch 的任何人是否已经开始尝试 OTel 日志记录？
Iris 已经尝试过 OTel 日志记录，主要是从Kafka topic 消费日志。这个实验不包括日志关联，但 Iris 希望将来能进一步探索。
由于日志尚未稳定，Iris 预计日志记录在 Farfetch 尚无法投入生产。Farfetch 有大量的日志（比追踪数据多），因此他们不希望在情况更稳定之前开始转换为 OTel 日志记录。
注意：OTel 日志的某些部分是稳定的。有关详情，请参阅规范状态摘要。
您是如何收集指标信号的？
自动插桩会发出一些 OTLP 指标；然而，大部分指标仍然来自 Prometheus。
该团队目前使用Prometheus Receiver 从Consul抓取指标。具体来说，他们使用 Consul 获取要抓取的 target 和端口。Receiver 的抓取配置与 Prometheus 中的相同，因此从 Prometheus 迁移到 Prometheus Receiver（直接迁移）相对容易。
他们还计划从 Kubernetes 收集 OTLP 指标。这得益于 Prometheus Receiver 对OTel Operator 的 Target Allocator 的支持。
Prometheus 目前仍在其他领域用于指标收集，并且可能会保持这种状态，尤其是在从虚拟机收集指标时。
您正在观测多少个 Kubernetes 集群？
正在观测 100 个 Kubernetes 集群和数千台虚拟机。Iris 和她的团队负责管理所有这些集群的 OTel Operator，因此她们也接受了 Kubernetes 培训，以便能够维护集群上的堆栈。
您是否尝试过 Kubernetes 中的任何 OTel 实验性功能？
这个问题是指 Kubernetes 组件发出 OTLP 追踪的能力，然后 OTel Collector 可以对其进行消费。更多信息，请参阅Kubernetes 系统组件的追踪。此功能目前处于 Beta 版，最早在Kubernetes 1.25 中引入。
Iris 和她的团队尚未尝试过此 Beta 功能。
您如何部署 OTel Collector？
由于 Kubernetes 集群数量众多，单一的 OTel Collector 会在负载和单点故障方面成为瓶颈。该团队目前每个 Kubernetes 集群都有一个OpenTelemetry Collector Agent。最终目标是用OTel Operator 取代这些 Agent，它允许您部署和配置 OTel Collector，并注入和配置自动插桩。
然后所有数据都会发送到每个数据中心的一个中心 OTel Collector（即OTel Collector Gateway），在那里进行数据屏蔽（使用transform processor 或redaction processor）、数据采样（例如tail sampling processor 或probabilistic sample processor）和其他处理。然后它将追踪数据发送到 Grafana Tempo。
中心 OTel Collector 位于另一个完全属于 Farfetch 可观测性团队的 Kubernetes 集群上，该团队运行 Collector 和属于该团队的其他应用程序。
如果中心 Collector 发生故障会怎样？
该团队有备用集群，因此如果中心 Collector 发生故障，备用集群将取而代之。卫星集群配置为将数据发送到备用集群上的中心 Collector，因此如果中心集群发生故障，备用集群可以启动，而不会中断 OTel 数据流。
设置自动伸缩策略以确保 Collector 拥有足够的内存和 CPU 来处理数据负载也有助于保持系统的高可用性。
在部署 OTel Collector 时，您遇到过哪些挑战？
最大的挑战是了解 Collector 并有效地使用它。Farfetch 非常依赖自动伸缩，因此团队首先要做的就是为 Collector 启用自动伸缩，并调整设置以确保它能够处理大量数据。
该团队还严重依赖OTel Helm charts以及 OTel 社区以获得额外的支持。
您目前在 OTel Collector 上使用任何处理器吗？
该团队目前正在试验处理器，主要是用于数据屏蔽（transform processor 或redaction processor），尤其是当他们开始使用 OTel Logs 时，它将包含敏感数据，他们不想将其传输到他们的可观测性后端。然而，目前他们只使用batch processor。
您是否知道有任何团队在使用 span events？
一个span event在追踪中提供额外的瞬时信息。它本质上是 span 内的一个结构化日志。
目前还没有，但他们希望能进行探索。当可观测性团队刚开始时，对追踪的兴趣不大。当他们开始实施 OpenTelemetry 和追踪时，他们将追踪提升为一流公民，现在它引起了工程师的兴趣，因为他们开始看到追踪的相关性。
您是否遇到过对 OpenTelemetry 持抵触情绪的人？
Farfetch 是一个非常重视可观测性的文化，可观测性团队并没有真正遇到过反对可观测性或 OpenTelemetry 的人。一些工程师可能对此漠不关心，但他们也不反对。
您或您的团队是否对 OpenTelemetry 做出了任何贡献？
该团队，在架构师的领导下，最近对 OTel Operator 在证书方面做出了贡献。OTel Operator 依赖cert-manager 来处理证书，而不是自定义证书。他们最初提出了一个功能请求，然后决定自己开发该功能，并提交了一个拉取请求。
听众提问
消耗多少内存和 CPU？
当他们的 Collector 处理大约每秒 30,000 个 span 时，有 4 个 Collector 实例，使用了大约 8GB 内存。
您是否在指标数据、追踪数据和日志数据之间进行关联？
这是目前正在探索的一个领域。该团队正在通过 OpenTelemetry 探索追踪/指标关联（exemplars）；然而，他们发现这种关联可以通过他们的追踪后端 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 的故事要分享，我们很乐意倾听！分享方式
- 加入 #otel-endusers 频道，该频道位于 CNCF Community Slack
- 加入我们每月一次的终端用户讨论小组电话会议
- 加入我们的OTel in Practice 会话
- 报名参加我们的月度访谈/反馈会话
- 加入LinkedIn 上的 OpenTelemetry 群组
- 在OpenTelemetry 博客上分享您的故事
请务必在 Mastodon 和 Twitter 上关注 OpenTelemetry，并使用 #OpenTelemetry 标签分享您的故事！