Crisp 是如何实现可扩展微服务监控的

  • Hrishikesh Barua
  • 张卫滨

2018 年 3 月 29 日

话题:DevOps

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

Crisp 的工程团队分享了他们在监控微服务技术栈方面的经验。他们开源了使用 Rust 编写的 Vigil 监控项目,该项目是一组拉取 / 推送的探针,用于为多种语言收集健康数据,它包含了一个状态仪表盘并且能够与其他外部告警工具集成。

Crisp 为 Web 站点提供了实时的方案。Crisp 的监控工具,名为 Vigil,包含了探针和一个仪表盘,该仪表盘能够展现探针所收集的各种微服务的状态。Vigil 的探针分为两类:轮询(poll)和推送(push)。轮询探针会阶段性地通过 TCP 或 HTTP 轮询服务,并基于给定的预期值检查响应内容和响应时间。推送探针通过集成微服务的源码来实现,它会在服务进程内阶段性地发送状态信息给 Vigil。这种模式在监控系统中是很常见的,大多数系统这两种方式都支持,只是会加关注其中的某一种。Vigil 是使用Rust编写的,在开源之前已经作为内部项目运行好几年了。

Crisp 每月会提供超多 10 亿次的请求。它们的后端有 40 多个不同的微服务,大多数都不是 HTTP 的。服务间的通信通过RabbitMQ来实现。有一些基于 HTTP 的微服务,如 REST API,会位于负载均衡器之后。另外,还有大约 20 个守护进程,如 Postfix 和 MongoDB。

每个微服务都会在多个节点上运行,每个节点会通过 replica 标识符来进行标识。节点的状态可以通过仪表盘来获取,可以查看该节点的状态是健康、病态(sick)还是已经死亡(dead)。在判断服务节点处于“病态”时,在两种模型中,分别按照不同的方式来确定,在推送模型中,是因为所报告的系统负载(CPU 或 RAM)超过了一个阈值,而在轮询模型中,则是因为服务的响应消耗了太多的时间。服务的死亡状态表明它可能已经宕机了。

InfoQ 采访了 Crisp 的 CTO Valerian Saliou,以了解 Vigil 如何进行内部和外部监控的更多信息:

当 Web 节点中的某一个节点宕机时,如果微服务节点是按照推送模式监控的话,我们马上就会知道,因为这意味着节点停机后,它就不会发送报告了,Vigil 将会自动触发一个“Down”提醒到 Slack,然后会显示到公开的状态页中,并且会精确定位宕机的节点。

Saliou 说到,对于终端用户外部端点的监控,Vigil 在https://api.crisp.chat上会检查 API,通过一个轮询探针检查公开访问的状态是否为 OK。另外,相同 API 的微服务还会通过推送方式进行报告,这就是在 Crisp 的状态页的“Web”分组和“Relay”分组会看到两个对该 API 引用的原因。

Vigil 的推送集成支持多种语言:Rust, nodeGo。它还与第三方的工具进行了集成,如 Slack 和 Email,但是还没有对其他常见告警工具的支持,如 Nagios 和 PagerDuty。在 Crisp,Vigil 目前以单节点方式运行。冗余功能目前还没有日程表,Saliou 说因为它的目标是“拥有一个简单的状态页面,足以完成任务,并让 SaaS 开发人员 / 系统管理员能够轻松访问一个不需任何成本的状态页面”。

查看英文原文Monitoring Microservices at Scale at Crisp

DevOps