OpenTelemetry Collector 反模式
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
OpenTelemetry Collector 是我最喜欢的 OpenTelemetry (OTel) 组件之一。它是一个灵活而强大的数据管道，允许您从一个或多个源摄取 OTel 数据，对其进行转换（包括批处理、过滤和屏蔽），并将其导出到一个或多个可观测性后端进行分析。它是供应商中立的。它是可扩展的，这意味着您可以为其创建自己的自定义组件。有什么不喜欢的呢？
不幸的是，正如许多工具一样，也很容易养成一些坏习惯。今天，我将深入探讨五个 OpenTelemetry Collector 反模式，以及如何避免它们。让我们开始吧！
反模式
1- 错误使用 Collector 部署模式
仅仅使用 Collector 是不够的。还关乎您的 Collector 在组织中的部署方式。没错，是 Collectors，复数。因为一个通常是不够的。
Collector 有两种部署模式：代理模式和网关模式，两者都需要。
在代理模式下，Collector 位于应用程序旁边或与应用程序在同一主机上。
在网关模式下，遥测数据被发送到一个负载均衡器，然后负载均衡器决定如何将负载分配给一组 Collector。因为您有一组 Collector，如果该池中的一个 Collector 发生故障，池中的其他 Collector 可以接管。这可以确保数据不间断地流向您的目的地。网关模式通常按集群、数据中心或区域进行部署。
那么您应该使用哪种模式？两者都要。
如果您正在为您的应用程序收集遥测数据，请在应用程序旁边放置一个 Collector 代理。如果您正在为基础设施收集数据，请在您的基础设施旁边放置一个 Collector 代理。无论您做什么，都不要使用单个 Collector 收集所有基础设施和应用程序的遥测数据。这样，如果一个 Collector 发生故障，其余的遥测数据收集将不受影响。
然后，您的 Collector 代理中的遥测数据可以发送到一个 Collector 网关。因为网关位于负载均衡器后面，所以您不会因为导出遥测数据（通常是到您的可观测性后端）而出现单点故障。
底线：拥有正确的 Collector 部署配置以将数据发送到您的可观测性后端，可以确保您的遥测数据收集基础设施具有更高的可用性。
2- 未监控您的 Collector
部署多个 Collector 代理和 Collector 网关很好，但这还不够。您不想知道其中一个 Collector 是否出现故障，或者数据是否正在丢失吗？这样，您就可以在情况升级之前采取行动。这就是监控您的 Collector 可以非常有用之处。
但是如何监控 Collector 呢？OTel Collector 已经发布了用于自身监控的指标。然后可以将这些指标发送到您的可观测性后端进行监控。
3- 未使用正确的 Collector 分发版（或未构建自己的分发版）
OpenTelemetry Collector 有两个官方分发版：Core 和Contrib。
Core 分发版是 OTel 开发人员用于开发和测试的 Collector 的精简版。它包含一组基本的扩展、连接器、接收器、处理器和导出器。
Contrib 分发版供非 OTel 开发人员进行实验和学习。它还扩展了 Core 分发版，并包含第三方（包括供应商和社区个人成员）创建的组件，这些组件对整个 OpenTelemetry 社区都很有用。
Core 或 Contrib 单独使用都不适合您的生产环境。单独使用 Core 太过于精简，无法满足组织的需要。（尽管它的组件绝对是必需的！）虽然许多 OpenTelemetry 从业者在其各自的组织中部署 Contrib，但它包含许多组件，您可能不需要每一个导出器、接收器、处理器、连接器和扩展。这会过度配置，并且您的 Collector 实例最终会不必要地臃肿，从而可能增加攻击面。
但是如何选择您需要的组件呢？答案是构建您自己的分发版，您可以使用一个名为 OpenTelemetry Collector Builder (OCB) 的工具来实现这一点。此外，在某个时候，您可能需要创建自己的自定义 Collector 组件，例如处理器或导出器。OCB 允许您集成自定义组件并选择您需要的 Contrib 组件。
还值得一提的是，一些供应商构建了自己的Collector 分发版。这些是 OTel Collector 分发版，经过精选，包含该供应商特有的 Collector 组件。它们可能是自定义的、供应商开发的组件以及精选的 Collector Contrib 组件的组合。使用供应商特定的分发版可以确保您只使用所需的 Collector 组件，从而再次减少整体的臃肿。
底线：使用正确的分发版可以减少臃肿，并允许您仅包含所需的 Collector 组件。
4- 未更新您的 Collector
这一条简短明了。保持软件更新很重要，Collector 也不例外！通过定期更新 Collector，您可以及时了解最新版本，从而利用新功能、错误修复、性能改进和安全修复。
5- 未在适当的情况下使用 OpenTelemetry Collector
OpenTelemetry 允许您通过以下两种方式之一将遥测信号从应用程序发送到可观测性后端：
对于非生产系统，从应用程序“直接发送”遥测数据是可以的，如果您刚开始使用 OpenTelemetry。但对于生产系统，这种方法既不合适也不推荐。相反，OpenTelemetry 文档推荐使用 OpenTelemetry Collector。为什么呢？
根据 OTel 文档，Collector “允许您的服务快速卸载数据，并且 Collector 可以处理其他操作，如重试、批处理、加密或甚至敏感数据过滤。”
查看 Collector 的其他好处
- Collector 可以提高应用程序发出的遥测质量，同时最大限度地降低成本。例如：对 span 进行采样以降低成本，用额外的元数据丰富遥测数据，以及生成新的遥测数据，例如从 span 派生的指标。
- 使用 Collector 摄取遥测数据可以轻松更改为新的后端或以不同格式导出数据。如果我们想更改遥测数据的处理或导出方式，该更改将发生在一处（Collector！），而不是在组织中的多个应用程序中进行相同的更改。
- Collector 允许您接收各种格式的数据并将其转换为所需的导出格式。在从其他遥测解决方案迁移到 OTel 时，这会非常有用。
- Collector 允许您摄取非应用程序遥测数据。这包括来自 Azure、Prometheus 和 Cloudwatch 等基础设施的日志和非应用程序指标。
也就是说，在某些用例中，人们不希望或无法使用 Collector。例如，在从物联网设备收集边缘数据时，考虑到边缘资源的限制，最好直接将数据发送到其可观测性后端，而不是本地 Collector。
底线：总的来说，使用 OpenTelemetry Collector 可以为您管理遥测数据提供更大的灵活性。
最后的想法
OpenTelemetry Collector 是一个强大而灵活的工具，用于摄取、操作和导出 OpenTelemetry 数据。通过充分发挥其潜力并避免这五个陷阱，您的组织就可以朝着实现卓越的可观测性迈进。