易贝基于Apache Druid构建大数据实时监控系统

时间：2021-08-22 来源：互联网编辑：宝哥软件园浏览：次

首先需要注意的是，本文提到的德鲁伊并不是阿里巴巴的德鲁伊数据库连接池，而是大数据场景下的另一种解决方案：Apache德鲁伊。

Apache Druid是一个面向大数据实时查询和分析的高容错、高性能的开源分布式时间序列数据库系统，旨在快速处理大规模数据，实现快速查询和分析。尤其是在代码部署、机器故障等产品系统遇到宕机时，Druid依然可以保持100%正常运行。创建Druid的初衷主要是为了解决查询延迟问题。当时尝试用Hadoop实现交互式查询分析，但难以满足实时分析的需求。Druid提供了以交互方式访问数据的能力，并且考虑到查询的灵活性和性能，采用了一种特殊的存储格式。

目前，德鲁伊广泛应用于国内外各种公司，如阿里、滴滴、知乎、360、易贝、葫芦等。

本文作者莫汉加拉迪披露了易贝如何使用德鲁伊进行监控的技术细节。

在易贝，我们将监控技术栈从传统的本地架构转变为基于Druid的实时监控系统。在本文中，我们将讨论如何过渡到新的技术堆栈，以及它给我们带来的好处。

EBay每天支持数百万用户进行电子商务交易。随着支持不同产品的各种应用产生的数据爆炸式增长，用户数量也在大幅增加。日志是应用程序的核心，用于决定应用程序执行哪些操作。随着应用程序规模的增长，可视化日志变得越来越困难。我们还有一个集中式日志存储来处理所有日志。直接从日志中获取有用信息是非常困难的，实时从日志中获取有用信息的想法是不可行的。在易贝，监测小组以不同的方式看待问题。解决这个问题的更好方法是从日志中提取有用的事件，并通过数据管理进行处理。

事件数量与根据当前系统流量生成的日志数量直接相关。一些应用程序可能会生成数百到数千个事件，而其他应用程序可能会生成数百万个事件。我们感兴趣的是基于从日志中提取的事件来监控每个应用程序的执行，以及当系统中有太多错误或异常行为时提醒用户的能力。

应用程序事件包括错误状态代码、url事务、命令执行以及不同主机上应用程序项目的构建标识。这些事件有不同的目的。

应用程序开发人员和站点可靠性工程(SRE)团队都对这些事件感兴趣，因为他们可以实时监控应用程序的性能。他们可以可视化系统中的错误数量，通过命令执行对这些错误进行切片和剪切，构建导致这些错误的程序，然后根据可能影响应用程序性能的错误阈值设置警报。

当应用程序开发团队必须在生产中部署新的应用程序项目时，这些信息提供了重要的见解。他们将能够在少量主机上对代码进行采样，并可视化实时仪表板，以确定新代码在生成错误时的行为，然后将实时数据与历史数据进行比较，以提供一定程度的可信度。

传统建筑

传统建筑是很多年前设计的，当时整个网站每天产生大约1000万个事件。这在当时是可扩展的，未来几年还可以扩展。

随着时间的推移，传统架构暴露出一些缺点：

多维数据集生成是为每个时间间隔定制的代码。生成当前时间数据通常需要几分钟，这对于实时监控来说是不可接受的。并且这种延迟随着数据量的增加而增加。

随着数据量的增加，用户自定义多维数据生成的可扩展性随着时间的推移而变差。

当维度基数很高(几十万到几百万的组合)时，生成速度很慢或者无法创建多维数据集。

新建筑

在新的架构中，Tibco依赖关系已经被移除，Kafka被用作临时保存信息以供使用的层。Tranquilty用于使用来自卡夫卡的数据并输入德鲁伊。

新架构的要点如下：

从时间生成到退出实现的最小端到端延迟(对于非常大的应用，最大延迟不超过10秒)。

使用Druid处理各种粒度的数据，如1分钟、1刻钟、1小时等。每隔1天重新索引数据。

Kubernetes部署使我们能够在升级或维护时，在几分钟内删除集群并重新创建集群。用100个节点执行滚动更新很容易。

Druid可以有效地处理高基数数据。只要为索引任务提供足够的可扩展性，即使几百万个latitude值也可以由Druid处理，没有任何额外的延迟，索引任务可以在零停机时间内实现。

(Tibco是用于数据传输的企业消息总线。Tranquilty是Druid-io的一部分，它带来了一个向Druid发送数据流的API。)

事件处理

事件包括系统中发生的事情，本质上是零星的。有些应用程序每天都会生成一些事件，而有些应用程序在一分钟内会生成数百万个事件。根据事件的用途，可以生成不同类型的事件。我们在这种背景下讨论监控事件。

在我们的用例中，数据有一个固定的维度键(11个维度)、一个时间戳和两个要计算的度量：计数和延迟。计数是在特定时间戳收集数据时主机上发生的事件数。延迟代表所有交易的延迟总和。跨应用程序的数千台主机可以生成数百万个事件，每个事件可以包含不同的纬度值集。每个应用程序的每个维度的纬度值可以从十到几千。

开发团队和SRE团队对上述事件非常感兴趣，以便了解特定应用程序或多个应用程序的网站上的错误数量，这可能会产生很大的影响。将每分钟数以百万计的事件实时收集到集中存储中并进行处理，将带来一系列与准确性、速度、可靠性和灵活性相关的挑战。

扩展

监控事件在整个集群中以每秒800万个事件的速度生成，在流量高峰期间平均每秒1000万个事件，这些事件来自5，000多个应用程序。监控事件需要跨多个维度进行切片，如应用名称、应用类型、操作名称、错误状态、运行应用的构建、主机等。所有数据都应在近乎实时的服务级别协议中进行汇总和提供。有11个固定维度，所有维度的纬度基数都在140万到200万个唯一组合之间。

我们的德鲁伊集群部署在多个可用区域，以实现高可用性，并在每个数据中心保留每个实例的2个副本。这使我们能够在两个数据中心提供4份拷贝。每个数据中心有数百个中间管理器、2个主导协调器节点、15个代理节点和80个历史节点。

峰值数据流如下图所示。

出口设计

数据导出的设计目标是保持数据的高可用性。Droid代理前面的层是为了查询Droid数据来确定每个数据中心的健康状态而设计的。我们希望这两个数据中心处于最佳状态，并且始终保持高可用性。如果任何数据中心的任何数据丢失，出口将切换到数据质量更好的集群。

我们每分钟从每个集群获取事件计数，以确定两个集群是否有相似的数据(偏差小于集群之间事件计数差异的0.5%)。如果偏差太大，我们会选择事件数较好的集群。计算每分钟执行一次，我们会继续更新集群的运行状况，以确定能够在一段时间内为数据提供服务的最佳集群。如果检测到任何数据丢失，我们还会标记该集群，这样就不会有查询进入有问题的集群的代理节点进行查询。