写点什么

Honeycomb - 调试复杂系统的工具

  • 2016-11-07
  • 本文字数:1660 字

    阅读完需:约 5 分钟

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 的运营团队使用 Grap hite 的情况(但 Graphite 缺乏相应的背景信息)。

Honeycomb 收集了大量数据,那它是如何处理大规模查询的呢?Majors 说,由于接近 100% 用户发出的查询都是关于最近一两个星期的,他们现在正专注于近期的调试任务,以便于采用有效的抽样保留技巧。

为了处理大量的数据,Honeycomb 使用自己的列存储:

Majors 说,我们开始构建 Honeycomb 时研究了大量现有的解决方案,但没有一个能完美解决问题。我们最终发现,绝大多数的预构建解决方案都需要对功能性进行权衡,在那些我们不需要的功能(例如事务)和牺牲那些我们认为至关重要的功能(例如能够快速访问原始输入事件)之间取舍。

Honeycomb 目前还不支持与其他告警系统集成,如 Nagios、Zabbix、PagerDuty。目前只有受邀请者可以注册该服务。

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


感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-11-07 18:003327
用户头像

发布了 22 篇内容, 共 61861 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

生产环境全链路压测建设历程之七: 淘宝网2012年双十一库存超卖问题的本质

数列科技杨德华

《社会中的数据可视化》PDF免费下载

计算机与AI

数据可视化

银行业大数据应用及HiveQLjoin分析

garlic

极客大学架构师训练营

架构师训练营第三周”代码重构“作业

随秋

极客大学架构师训练营

架构师训练营 2 期 - 第 8 周命题作业

Geek_no_one

极客大学架构师训练营

架构师训练营第 1 期 - 第 12 周课后练习

Anyou Liu

极客大学架构师训练营

架构师训练营第 1 期 week12

张建亮

极客大学架构师训练营

第十二周作业

alpha

极客大学架构师训练营

玛雅公约软件系统开发|玛雅公约APP开发

系统开发

架构师训练营第 1 期第 12 周学习总结

好吃不贵

极客大学架构师训练营

02-week3-homework

J

极客大学架构师训练营

架构师训练营第八周作业1

韩儿

Prometheus backfilling 功速体验

Grafana 爱好者

Prometheus tsdb

第八周作业

孤星

许可区块链是许多金融应用未来的关键特性

CECBC

比特币区块链

性能优化总结二

Mars

第十二周作业(作业一)

Geek_83908e

架构师一期

Codurance不太一样

sherlockq

前端不得不懂的架构知识(中)

执鸢者

架构 大前端

架构师训练营 1 期第 12 周:数据应用(一)- 作业

piercebn

极客大学架构师训练营

架构之书:雄心与《C++语言的设计与演化》

lidaobing

c++ 架构

宝马区块链负责人:我们是如何让区块链技术与汽车产业结合的?

CECBC

大数据

第八周 作业

Jack

FFmpeg使用基础(音视频开发入门)

赖猫

【第十二周】课后作业

云龙

别再用智能合约时代的思维,去思考下一代区块链应用

CECBC

区块链 计算机

性能优化练习

Mars

第十二周作业(作业二)

Geek_83908e

架构师一期

第八周总结

孤星

架构师训练营 第八周作业

文江

架构师训练营 2 期 - 第八周总结

Geek_no_one

极客大学架构师训练营

Honeycomb - 调试复杂系统的工具_DevOps & 平台工程_Hrishikesh Barua_InfoQ精选文章