首先需要注意的是，本文即将提到的 Druid，并非阿里巴巴的 Druid 数据库连接池，而是另一个大数据场景下的解决方案：Apache Druid。

Apache Druid 是一个用于大数据实时查询和分析的高容错、高性能开源分布式时序数据库系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid 仍能够保持 100% 正常运行。创建 Druid 的最初意图主要是为了解决查询延迟问题，当时试图使用 Hadoop 来实现交互式查询分析，但是很难满足实时分析的需要。而 Druid 提供了以交互方式访问数据的能力，并权衡了查询的灵活性和性能而采取了特殊的存储格式。

目前 Druid 广泛应用在国内外各个公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。

本文 作者 Mohan Garadi 披露了 eBay 如何使用 Druid 进行监控的技术细节。

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

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

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

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

应用程序开发人员和网站可靠性管理（Site reliability engineering，SRE）团队都会对这些事件感兴趣，因为他们可以实时监控应用程序的性能。它们能够将系统中发生的错误数量以可视化的形式呈现，通过命令执行对这些错误进行切片和切块，并构建导致这些错误的程序，然后根据可能影响应用程序性能的错误阈值设置警报。

当应用程序开发团队必须在生产中部署应用程序的新项目时，这些信息提供了关键的洞见。他们将能够在一小部分主机上进行代码的抽样部署（sampled rollout），并可视化实时仪表盘，以确定新代码在生成错误方面的行为，然后将实时数据与历史数据进行比较，从而提供一定程度的可信度。

传统架构

传统架构是多年前设计的，当时整个站点每天生成的事件数量大约为 1000 万次。这在当时是可扩展的，并且在未来几年内也可以进行扩展。

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

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

随着数据量的增加，自定义多维数据生成的可扩展性随时间的推移效果变得较差。

在维度基数非常高（几十万到几百万种组合）的情况下，生成速度缓慢或无法创建多维数据集。

新架构

在新的架构中，已删除 Tibco 依赖项，并将 Kafka 用做临时保存信息以供使用的层。Tranquilty 用于使用来自 Kafka 的数据并输入 Druid。