你怎么能观察到不可观察的事物？在Databricks，我们非常依赖内部服务的详细指标来保持高可用性和可靠性。然而，Databricks平台管理apachespark™ 客户集群，部署到他们自己的Azure帐户和私有虚拟网络中，我们的监控基础设施无法轻松观察到这些。本博客描述了我们构建的解决方案，该解决方案是为了从这些"不可观察"的环境中将实时指标引入到我们的中央监控基础设施中。我们提出的体系结构并不是只监视apachespark所独有的™ 集群，但可以用于从部署在Azure云或私有VPN中的任何分布式架构中获取度量和日志。安装程序Databricks提供具有全局架构的云服务，在各种云、区域和部署模型中操作服务。这种独特的复杂性带来了一些挑战，这些挑战强调了对我们的服务进行适当可见性的重要性。Databricks的可观测性团队负责提供一个跨三个支柱处理数据的平台：度量、日志和跟踪。这篇文章重点介绍我们如何为3个数据源中的2个提供改进的体验：度量（记录服务状态或运行状况的度量）和日志（服务发出的不同事件）。我们的度量监控基础设施由Prometheus的部署组成，Prometheus是一个开源的监控系统，运行在区域性的Kubernetes集群中。每一组复制的服务负责收集来自所有并置服务的遥测数据，以固定的采样间隔摄取和存储度量。我们利用Grafana和Alertmanager构建仪表板和实时警报，以便我们的工程师能够随时了解Databricks服务的运行状况。图1。数据库监控体系结构的每个区域视图。这种架构适用于运行在同一个Kubernetes集群中的服务，但是如上所述，客户部署不能用这种方式进行。这些服务无法被我们的普罗米修斯部署访问，这意味着我们无法收集他们的度量数据，并失去宝贵的服务洞察力。但是，我们确实有一个内部日志导出代理在这些环境中运行，我们决定利用它来收集度量并将它们代理回我们的中心集群。要求在与其他接口工程师交谈后，我们收集了本系统的以下要求：每分钟处理量高达10千兆字节，可根据预测的未来负荷灵活调整达到亚分钟延迟确保高可用性和容错性虽然我们可以利用日志导出器，但是我们不能使用现有的日志ETL管道，因为它们是针对对象存储操作的，并且具有显著的延迟。度量管道的一个主要用例是实时警报，而延迟的数据阻碍了我们最小化事件响应时间的能力。另外，我们希望这个系统能够扩展到一些用例中，比如改善我们现有的日志管道的延迟。日志记录管道对延迟（分钟）的要求稍微宽松一些，但吞吐量要高得多。运输我们决定使用apachekafka进行数据传输。Kafka是构建实时事件日志管道的常见解决方案，它使用各种方法来实现吞吐量、延迟和容错级别，这使得它对这个用例很有吸引力。此外，我们还利用了azureeventhubs，一个云托管的数据摄取服务，可以公开Kafka表面。这意味着我们可以快速启动，而无需在部署和管理基础设施方面投入太多，同时在将来以最小的代码更改就可以迁移到自我管理的Kafka。构建实时管道一旦我们确定了传输层并部署了事件集线器，我们就开始实现实际的收集管道。收集指标我们的日志导出器（毫不奇怪）是面向文件的。因此，我们修改了主服务循环，每30秒将所有服务的指标转储到一个文件中。Prometheus客户机库使得这一点变得非常简单，因为我们可以简单地迭代默认注册表并写出在那里找到的所有度量。如果这项服务通过普罗米修斯直接取消，那么将返回相同的数据。我们选择了30秒，因为这模拟了我们在直接刮取服务时使用的刮取间隔。我们的日志导出器已经支持"流式"模式，在这种模式下，文件可以"跟踪"并写入流端点。我们只需将日志导出器配置为将度量转储文件视为应该流式传输的日志。生成消息下一步是修改我们的日志导出器以支持Kafka协议。使用OSS Kafka producer可以很容易地实现这一点，我们确实需要做出一些选择，即在保证交付时要有多积极。我们决定通过降低记录确认的门槛来换取提高吞吐量的保证。失去一轮度量并不太糟糕，因为我们只需在30秒后发送更新的度量值。正在使用邮件消费者方面的情况有些复杂。将日志从Kafka移动到ETL管道是很自然的，但是度量的过程并不那么清晰。如前所述，普罗米修斯的运营模式是拉式的，在这种模式下，普罗米修斯会对周围的服务进行清理。对于不能被刮取的服务（即短时间运行的作业），它们提供Pushgateway。服务可以将它们的度量发送到Pushgateway缓存，一个位于同一位置的普罗米修斯将从那里获取它们。我们采用这个模型通过一个名为Kafka2Prom（K2P）的服务向Prometheus公开代理度量。所有的K2P吊舱都属于一个卡夫卡消费群体。每个pod被分配一些分区的子集，并使用各自的度量，然后将它们发送到一个与Prometheus兼容的度量端点进行收集。我们提供交付保证，只在指标暴露后将补偿提交给Kafka。此时，我们的度量收集管道如下图所示：图2。数据块监控体系结构的每个区域视图（使用Kafka和Kafka2prom服务）。一个警告是，普罗米修斯摄取度量并使用设置为刮取时间（而不是上载时间或事件时间）的时间戳存储它们。对于本地服务来说，这是一个很好的假设，但是它对K2P有一些影响。K2P需要保证一旦某个度量被任何pod暴露给Prometheus，就不会暴露该度量的旧值，因为Prometheus会给它一个更晚的时间戳。一个度量的所有值都发布到同一个Kafka主题中，因此在一个pod中保证这一点很简单。在分区重新平衡的过程中，更难保证：如果新的度量值出现在新的pod上，而旧的pod仍然拥有以前的值，那么Prometheus可能会把它们刮得乱七八糟。为了避免这种情况，我们在允许新pod从重新平衡的主题接收任何度量之前同步地清除旧pod的缓存。另一个要考虑的是如何称呼"吵闹的邻居"。因为我们需要在一个pod中进行排序，所以跨分区的记录分布不一定是一致的。虽然我们可以选择将K2P pod的数量扩展到分区的数量，但是我们也可能希望将多个分区分配给一个pod并使用多个cpu。我们将一个分区的所有处理都放在一个线程内，因为否则很难保持排序保证。在这个设置中，我们不希望一个分区上的备份阻止其他线程进行处理。对于多线程处理，我们需要将记录从使用者异步传递到处理器。为此，我们在每个分区上使用一个小的backlog队列。这允许分区之间的隔离：如果一个线程落后而其队列填满，我们可以暂停这个分区，而其他线程不受影响。这也给了我们一些处理背压的灵活性。例如，在紧急情况下，我们可以停止暂停分区，而是从队列的前面退出。我们将拥有较少的粒度指标数据，但我们可以赶上当前的指标，而不会直接跳转到最新的记录，也不会对其间发生的事情失去所有洞察力。结论这个项目可以实时查看Azure中"不可观察"Spark工人的状态。这提高了监控（仪表盘和警报）以及工程师做出数据驱动决策的能力，从而提高了产品的性能和稳定性。该系统的各个组件可以水平和独立地缩放，使数据块能够继续适应遥测用例不断增长的数据规模。此外，我们希望继续扩展用例，以生成更多的见解并利用这种以日志为中心的体系结构。 免费试用Databricks。今天就开始吧