Honeycomb 是用于觀察和關聯分布式系統中各事件的工具。它的方法與現有工具（例如Zipkin）不同。Honeycomb由原有的單一請求跟蹤模型轉變為更自由形式的模型，能夠跨層(layers)、跨維度(dimensions)地收集和查詢數據。

Honeycomb與Zipkin這樣的軟件有什么區別？Zipkin是基于Google Dapper paper的分布式跟蹤系統，由Twitter編寫和開放源代碼。InfoQ近日與Honeycomb聯合創始人Charity Majors聯系，了解到該產品的更多信息。Majors指出，與使用全球唯一的UUID進行請求跟蹤不同，“對大家來說通常更有用的是某種用戶ID或應用程序ID，以及其他類型的ID。這些請求ID便于將具有您可能想要計算或聚合的共同特征進行分組。”

這在實踐中意味著什么？基于如Zipkin之類的跟蹤工具的請求，假設每個請求都附有唯一的ID。從請求進入系統的時間起，ID通過各種子系統調用（可用于微服務）來傳遞，而子系統調用是由初始調用的結果觸發的。如果在每個步驟都記錄下此ID，并且設定中心區域來聚合和索引這些日志，那么在請求ID已知的前提下，在系統中搜索和跟蹤特定請求將變得很容易。這種日志聚合器的一個典型例子是ELK（Elasticsearch/Logstash/Kibana）。

Honeycomb打破了這種模式，盡量在每個級別分別獲取數據（如負載均衡器、微服務和數據庫），標記數據，便于用戶今后對這些數據進行混合匹配（mix-an-match）和即時查詢(ad-hoc queries)。Majors解釋說，Honeycomb采用這種方法是因為跟蹤本身給你留下一個亟待解決的問題。這個問題就是“哪些是有代表性，值得首先研究的請求”。一旦用Honeycomb展示數據，用戶可以跨系統、跨時間，將不同層的數據聯系整合，進行運算，從而理解它的性能。例如，跨越多個系統的請求響應時間的增加可能是由于來自多個因素（包括時間）的集體效應。這不利于請求跟蹤，因為請求一般代表的是給定時間段內相關事件的單個線程。

數據一般可以通過API調用發送到Honeycomb。以下示例表示如何用API調用來記錄Web請求數據：

curl https://api.honeycomb.io/1/events/Quickstart -X POST -H "X-Honeycomb-Team: YOUR_WRITE_KEY" -d '{"status":200,"path":"/docs/","latency_ms":13.1,"cached":false}'

在這個例子里， “-d”參數可用于獲取JSON對象。這個JSON對象具有便于以后查詢的任何應用程序特定信息。數據收集為一系列事件，對于其中每個事件都應該進行跟蹤。這些事件可以捆綁成名為“數據集”的單個實體。Honeycomb可以通過所謂的“連接器”與應用程序集成。連接器是從特定軟件中提取數據并將其發送到Honeycomb的適配器。用戶還可以使用SDK以及名為honeytail的工具將數據從現有日志集成到Honeycomb。

為了：給正在收集的數據添加上下文，Honeycomb還標記各事件是由誰觸發的：是操作員還是像計劃任務cron之類的什么（部署、腳本或一次性動作）。這些操作垂直排列，上面附加了一些信息，例如誰運行腳本以及指向部署代碼的鏈接。這有點類似于Etsy的運營團隊使用Graphite的情況（但Graphite缺乏相應的背景信息）。

Honeycomb收集了大量數據，那它是如何處理大規模查詢的呢？Majors說，由于接近100%用戶發出的查詢都是關于最近一兩個星期的，他們現在正專注于近期的調試任務，以便于采用有效的抽樣保留技巧。

為了處理大量的數據，Honeycomb使用自己的列存儲：

Majors說，我們開始構建Honeycomb時研究了大量現有的解決方案，但沒有一個能完美解決問題。我們最終發現，絕大多數的預構建解決方案都需要對功能性進行權衡，在那些我們不需要的功能（例如事務）和犧牲那些我們認為至關重要的功能（例如能夠快速訪問原始輸入事件）之間取舍。

Honeycomb目前還不支持與其他告警系統集成，如Nagios、Zabbix、PagerDuty。目前只有受邀請者可以注冊該服務。

查看英文原文：Honeycomb - A Tool for Debugging Complex Systems