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。目前只有受邀请者可以注册该服务。
本文转自d1net（转载）
