内容简介：Robinhood工程团队是如何实现度量的收集和监控的
Robinhood 服务器运营团队 发表 了 一系列 的 文章 ，详细阐述了公司所采用的度量采集、监控和报警的架构。根据文章介绍， OpenTSDB 、 Grafana 、 Kafka 和 Riemann 构成了其技术栈的核心。其中Kafka作为代理层，实现将度量流数据推送给Riemann处理，并推送到OpenTSDB存储。
Robinhood的技术栈主要由 Python 构成，还有部分Golang。生产服务器的调试和监控，很大程度上依赖于度量。度量汇集数据库OpenTSDB是实现度量收集的主要手段，它不仅针对各类软件栈分别提供了多种标准度量收集器（称为 tcollectors ），而且还支持自定义的收集器。自定义收集器可使用OpenTSDB的telnet或HTTP访问接口收集度量，并将收集到的数据推送到OpenTSDB中。对于Robinhood应用，度量数据首先被发送到Kafka代理。
对于各个服务器，可以使用标准的或自定义的tcolloctor发送度量数据给Kafka。对于应用的性能监测，使用了 statsd 库。应用度量发送到在各服务器本地运行的statsd进程。statsd服务器的实现采用了 C语言 编写的 statsite 。在转化statsd度量为本地tcollector度量时，采用了自定义的适配器。此后，本地tcollector度量由Kafka发送给OpenTSDB。tcollector进程将度量输出在标准输出上，并调用一个Python脚本将输出推送给Kafka。
作为度量采集系统的中枢，OpenTSDB需为高可用的。InfoQ咨询了Robinhood的运营工程师Aravind Gottipati，对此他做了深入的解释：
Robinhood运行多个独立的OpenTSDB实例，各个实例所消费的都是来自于Kafka的同一度量流。因为这些实例是相同的，我们可以请求任一OpenTSDB实例进行负载均衡，由此轻松实现了高可用。我们并不需要运行整个HBase集群，而是对每个实例运行一个单节点的本地HBase服务器（也是Master）。
鉴于Kafka以中介方式使用，各消费者（Consumer）可以采用不同的数据处理方式。一种方式是将度量转换后，推送到OpenTSDB。当需要处理不断增加的数据量时，还可以按需将数据分片到多个OpenTSDB服务器。以Kafka为代理，在需要维护时可以暂停并恢复消费者。连接Kafka和OpenTSDB间的桥梁，是一个基于控制台并输出到标准输出的消费者。输出使用netcat推送到OpenTSDB的telnet监听器。
Grafana是一个可视化的度量查看工具，它支持Graphite、InfluxDB和OpenTSDB后端。还可以在仪表盘中插入CloudWatch度量。
Robinhood监控和报警工作流的关键组成称为Riemann。Robinhood还使用了Sensu这样的传统报警系统，传统的报警系统依赖于指定时间点（point in time）查看度量，这并不适合于展示历史数据，原因包括难以编写查询，以及系统运行时存在高延迟。一些度量系统可能还不支持历史记录，因为对缺失数据必须支持插值操作。既然部分问题能被OpenTSDB较好地解决，那为什么Robinhood还要使用Riemann？对此问题，Gottipati给出了解释：“OpenTSDB依赖于HBase。HBase适用于对指定范围内全部数据的访问，并不擅长于获取某个具体时间点上的单个度量数据。如果在报警系统中使用HBase，需要HBase支持查看用户所选定某个具体时间点上的度量数据。在查询通常采用的是一种权宜之计，即为了获取单个数据点，依然必须扫描整个键值范围。”
在度量流的处理中，还需要定义一些规则和过滤器。数据流经时，一旦过滤器或规则得到匹配，就会触发报警。Riemann可以聚合来自多种数据源的度量流，并提交给一种流处理语言进行处理。整个度量收集系统是绑定到Riemann的，使用的是推送数据到Riemann的Kafka消费者。度量的命名转换受OpenTSDB的影响，即每个度量具有一个类型，键值对标记由关联到每个事件的主机和角色构成。其中所使用的netcat也会推送数据到Riemann，这时由起始tcollector对每个事件标记的角色（例如Web服务器、数据库）要被转化为Riemann标记。这使得Riemann内建的过滤器功能易于使用。Robinhood内部对Riemann原语开发了一个 包装DSL ，简化了开发人员的使用。这一系统对DevOps协作发挥了关键作用。那么在Robinhood企业中，什么是DevOps文化创立的关键里程碑？Gottipati是如此答复的：
我们构建了一些仪表盘样板，可以展示我们所采集的各种系统度量以及应用的度量仪表盘（来自于statsd度量）。作为对各用户疑问请求的响应，我们着手使用并共享这些仪表盘，让一些老用户开始使用它们。一段时间后，我们帮助这些用户添加更多的应用特定仪表盘，并继续这一过程。我们的后台/应用团队构建和维护了一系列的仪表盘，其中一些甚至不为运营人员所知。他们会培训新加入的工程师，如何去查阅并使用这些仪表盘。
在Riemann中查看事件时使用的是Elasticsearch（ELS）实例，而非默认的Riemann仪表盘。大约50%来自Kafka的事件被推送到ELS，峰值时可达每秒约20,000次事件。
查看英文原文： Metrics Collection and Monitoring at Robinhood Engineering
以上所述就是小编给大家介绍的《Robinhood工程团队是如何实现度量的收集和监控的》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- SOFALookout 1.4.2 发布，系统度量与监控中间件
- 3W字干货深入分析基于Micrometer和Prometheus实现度量和监控的方案
- 度量平台开发实践
- Metrics-服务指标度量
- 如何度量软件团队成员的技能？
- 用R语言实现信息度量
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
