使用 Apache Kafka 和 OpenTelemetry 最大化可扩展性


OpenTelemetry Collector 和 Apache Kafka 之间的选择不是零和游戏。每个都有其独特的优势,甚至可以在某些架构中相互补充。OpenTelemetry Collector 擅长数据收集、压缩和过滤,使其成为减少系统内延迟并在数据到达后端之前提高数据质量的有力候选者。

OpenTelemetry Collector
OpenTelemetry Collector 是 OpenTelemetry 可观测性部署的可选但强烈推荐的部分。在数据发送到可观测性后端之前,收集器可以收集、压缩、管理和过滤 OpenTelemetry 仪器发送的数据。

然而,在更高级的情况下,这可能还不够。想象一个处理高频请求的边缘服务,将定期请求发送到同一网络上相当远的收集器。当应用程序无法到达每个请求的收集器时,结果将是应用程序上引发错误。

同样,收集器的全部好处是它应该能够缓存、批处理和压缩数据以进行发送,无论其数据摄取的频率有多高。

多收集器有很多优点:

  • 可扩展性:在大型分布式系统中,单个 OpenTelemetry 收集器可能不足以处理所有服务和应用程序生成的遥测数据量。
  • 减少网络流量:对于网络中发生的每一个额外的过滤步骤,您都可以减少用于可观察性的网络带宽总量。
  • 过滤和采样:通过多层方法,您可以在将数据转发到中央收集器之前在中间收集器执行数据过滤、转换或采样。这可以由了解仪器下的微服务以及需要突出显示哪些数据的团队来完成。或者,如果您遇到多个服务中出现 PII 等问题,您可以在中央收集器上设置过滤,以确保所有地方都遵循规则。

内部队列和多收集器架构都是提高可观测性数据可靠性的方法。

Apache Kafka
Apache Kafka 在高可靠性和数据缓冲至关重要的场景中表现出色,例如在数据库中断或流量高峰期间。Kafka 强大的排队机制可以充当有价值的中介,确保不会丢失数据并且不会过度配置数据库。

Kafka 队列对数据最有意义的两种场景是:

  1. 确保数据库中断期间的数据收集 - 即使可靠的数据库发生故障,Kafka 也可以在中断期间摄取和存储数据。当数据库再次启动时,消费者可以再次开始接收数据。
  2. 处理流量突发 - 可观测性数据可能会在使用高峰期间出现峰值,如果您正在进行深度跟踪,峰值的规模可能会比流量的增长还要大。如果您扩展数据库以在不进行任何排队的情况下处理此峰值,则数据库将过度配置正常流量。队列将缓冲数据峰值,以便数据库在准备就绪时可以对其进行处理。

本文讨论的多收集器架构提供了一种可扩展且高效的方法来处理大量遥测数据。通过将收集器放置在更靠近受监控的服务的位置,您可以减少网络流量并实现更有效的数据过滤。该架构可以通过集成 Kafka 队列进一步增强,从而增加另一层可靠性和可扩展性。