首先需要注意的是，本文即將提到的 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。