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

by

• Hrishikesh Barua

摘要：

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

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

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