在过去的一年里，Cockroach Labs一直在努力为我们的可观察性工具提供一些额外的爱。当涉及到监控我们的云产品时，比如 CockroachDB Dedicated，满足客户的需求是我们的主要目标之一。许多组织已经有了一个平台来监控他们的系统，我们希望他们在监控CockroachDB集群的时候能有宾至如归的感觉。但是，如今在不断变化的可观察性市场上有这么多的平台，比如Datadog、Amazon CloudWatch等等，我们如何在可观察性工具中保持灵活性？当今流行的工具并不能保证经得起时间的考验。因此，我们需要一个第三方监控集成的平台，这个平台要足够灵活，既能支持今天的平台，也能支持未来的平台。
对于Cockroach Labs来说，我们选择了 OpenTelemetry Collector作为这样一个平台，并 与Datadog集成，作为我们希望有朝一日成为大量第三方集成库中的第一个。这篇博文讨论了OpenTelemetry Collector的功能，以及我们如何将其引入我们的云基础设施。
什么是OpenTelemetry收集器？
OpenTelemetry框架是云原生软件的工具、API和SDK的集合，使其能够轻松地检测、收集和导出遥测数据。该项目是通过合并较早的（很快就废弃的）OpenTracing和OpenCensus项目而形成的进化，并得到了云原生计算基金会的有力支持。
如前所述，该计划的一个关键部分是OpenTelemetry采集器。收集器是一个单一的进程，能够刮取各种遥测数据格式（指标、日志和跟踪），如Prometheus 指标，将它们转化为通用的OTLP格式，并将它们导出到各种外部目标，如（但不限于）Datadog。收集器有一个模块化的设计，由几个核心组件组成。
- 接收器：它们提供了一种将数据输入收集器的方法；这些可以是基于推或拉的。支持一系列不同的接收器，而且这个列表还在不断增加。
- 处理者：这些定义了一旦收到遥测数据要做什么，如转换、路由、编辑等等。
- 导出器：这些定义了数据被接收和处理后的发送地点；这些也可以是基于推或拉的。也有各种各样的出口商，其中许多是由它们所输出的平台建立和支持的。
这些核心组件中的每一个都是通过管道连接起来的。同一个组件的多个实例可以存在于一个收集器进程中，它们可以通过YAML配置的管道以多种不同的方式串联在一起。
从CockroachDB收集遥测信息
采集器的模块化设计为我们提供了必要的灵活性，使我们能够为客户提供可互换的第三方集成。首先，CockroachDB集群的每个节点都会输出细化的时间序列指标。这些指标是以Prometheus格式提供的，而你知道吗？采集器有一个接收器。一旦配置好，Prometheus接收器就可以作为管道的一部分进行配置。
如果指标最初不是以适当的格式导出到Datadog，我们可以寻求众多采集器处理器之一的帮助来处理任何转换。例如，我们可以使用过滤处理器来消除指标集，只保留那些我们认为与云客户相关且可操作的指标。如果指标需要重新命名以适应第三方导出目标的特定风格，我们可以使用指标转换处理器。
到此为止，我们已经收到了我们的遥测有效载荷，并根据需要对其进行了格式化。现在，是时候把有效载荷发送到客户选择的观察平台了--例如，Datadog。幸运的是，我们也有一个导出器。Datadog导出器（现在，你可能已经明白了一个主题了！）。我们可以用必要的客户证书来配置Datadog导出器，将指标导出到他们的Datadog账户。
最后一步是用一个指标管道把所有的东西组合起来，看起来就像下面的YAML配置。
pipelines:
metrics/datadog:
receivers:
- prometheus
processors:
- filter
- metricstransform
exporters:
- datadog
这样一个灵活的平台很好地满足了我们的需求。遥测数据的每一步都有很多选择，而且有大量活跃的开源贡献者，OpenTelemetry Collector很适合支持CockroachCloud的发展。
现在我们已经看到收集器本身是如何工作的，让我们放大一点。这些OpenTelemetry Collector进程是如何融入更广泛的CockroachDB集群的？
OpenTelemetry Collector与CockroachDB的关系
官方OpenTelemetry文档指出，OpenTelemetry收集器包括两种主要的部署方式。
- 代理。与应用程序一起运行的收集器实例或与应用程序在同一主机上运行的收集器实例（例如二进制、sidecar或daemonset）。
- 网关。一个或多个收集器实例作为独立的服务（如容器或部署）运行，通常是每个集群、数据中心或区域。
建议将代理部署在环境中的每一台主机上。在CockroachDB的背景下，这意味着每个运行CockroachDB进程的虚拟机也应该运行一个收集器代理进程。代理进程负责接收初始遥测有效载荷，并在将有效载荷转发到网关之前应用任何必要的转换。
与代理不同，集群中只存在一个单一的网关进程（或在多区域集群中，在每个区域）。网关的主要职责是将遥测有效载荷 "最后一公里 "交付给客户出口目标，如Datadog。
在实践中，部署看起来是这样的。
这种在代理和网关采集器之间的责任划分有一些好处，主要是我们可以更好地限制向单个网关进程发送遥测有效载荷所需的出口点的数量，而不是多个代理进程。用于向客户目标传递遥测数据的API令牌秘密也是如此。
既然我们了解了主要的部署模式，让我们再具体说说。CockroachDB专用在Kubernetes中运行，因此所有OpenTelemetry Collector进程都在自己的Pod内运行。对于代理，我们需要每个主机有一个进程。因此，我们使用Kubernetes DaemonSet来部署代理进程，这可以确保所有节点都运行一个代理Pod的副本。对于网关，我们只需要每个区域一个，所以Kubernetes部署很适合我们的需求。该部署允许我们在每个CockroachDB区域内指定所需的副本数量，并使我们能够在必要时轻松地扩展副本的数量。
当这一切组合在一起时，一个CockroachDB专用集群看起来就像。
非常酷！"。但是你可能会想--如果采集器和CockroachDB节点运行在同一台主机上，这不会吞噬CockroachDB节点的资源吗？的确，资源是有限的。当然，我们对集群中的每个收集器豆荚进行了资源限制，以避免出现任何类型的 "失控列车 "情况。然而，采集器的效率给我们留下了相当深刻的印象。即使一个地区的12个CockroachDB节点的遥测数据流经一个网关进程，我们还没有看到一个采集器使用超过75MB的内存。此外，75MB本身也是一个异数。在写这篇文章的时候，采集器容器的平均RSS内存使用量只有47MB。在CPU方面，事情也是相当有效的，采集器平均使用0.003个vCPU核心。因此，对CockroachDB节点本身的影响是可以忽略不计的。
下一步是什么？
在最初的迭代中，CockroachCloud中的OpenTelemetry Collector栈只支持CockroachDB Dedicated，Datadog是一个 "试点 "集成。我们希望继续扩大我们的指标集成库，包括更多的第三方供应商，以继续满足我们的客户在他们感到最舒适的地方的监控需求。收集器也能够处理更多的指标，所以有很多机会将其用途扩大到痕迹和日志，以及可能将其用于我们自己的SRE的内部遥测。总而言之，收集器是一个非常强大和灵活的观察工具，为未来提供了许多可能性。我们在Cockroach实验室期待着与它一起发展。
