实操笔记：为 NSQ 配置监控服务的心路历程

又拍云 UPYUN

墨衍会员 · AI 创作全网分发码龄10年

关注

原创 2021-05-27 10:13:36 1.1k 阅读 AI 写同款· GEO 优化 ›

在 Go 语言实现的实时消息队列中， NSQ 的热度可以排第一。

NSQ 这款消息中间件简单易用，其设计目标是为在分布式环境下运行，为去中心化服务提供一个强大的基础架构。它具有分布式、去中心化的拓扑结构，该结构具有无单点故障、故障容错、高可用性以及能够保证消息的可靠传递的特征。

NSQ 以分布式架构，能够处理数亿级别的消息能力俘获了众多 gopher 的心。我司也不例外，较多的业务都依赖 NSQ 做消息推送。今天我想和大家唠一唠关于 NSQ 监控的问题。

为什么要部署监控？

监控的重要性大家应该都清楚。没有监控的服务就是 “盲人骑瞎马，夜半临深池”。这样讲可能有些抽象，我来给大家分享一个亲历的真实案例吧。

还记得那天，我正吃着火锅唱着歌，心里甭提有多美了，突然手机响了，打开一看，发现有客户反馈 CDN 刷新成功后未生效的问题。

火锅是不可能继续愉快地吃了，我抱起电脑一顿操作猛如虎，可惜结果不靠谱：我查了系统调用链路上相关服务的日志，但是客户需要刷新的 URL 却没在日志中查到任务蛛丝马迹。那问题出在哪呢？

这块业务涉及到的服务调用示意图如上图所示。因为客户需求的紧急，我也把视线从沸腾的火锅收了回来，对着服务链路图沉思起来：

如图所示，用户成功提交了刷新请求说明请求流转到了 ohm 服务层，并且 ohm 成功处理了这个请求。
ohm 服务是刷新预热相关业务的 gateway，记录的是 ERROR 级的 log。没有在 ohm 的日志中查到该请求的相关的记录，表明 ohm 向下游的 NSQ 推送消息的动作是成功的。
NSQ 对应的消费者是 purge 和 preheat 组件。purge 负责执行刷新动作，它记录的日志是 INFO 级，每一条刷新的 URL 它都会记录到日志中。但是为什么在 purge 中却查不到相关日志？

刚才我就卡在了这里。问题的症结在于哪些情况下会在 purge 服务中查不到对应的日志。我大致列举了如下几种情况：

服务变更。purge 服务如果最近更新的代码如果有 Bug 可能导致了异常。但是我很快排除了这点，因为发布记录中，这个服务最近几个月都没人动过。
NSQ 坏了。这个更不靠谱，NSQ 是集群部署的，单点故障可以避免，全局故障的话恐怕公司群现在已经炸翻了天。
NSQ 没把消息发过来。但是 NSQ 是实时消息队列，消息投递应该很快，而且客户的刷新操作是在几个小时前了。

会不会因为 NSQ 消息堆积了，才没及时把消息投递过来呢？之前在测试环境没有发现此类问题，因为测试的量级与线上环境相比远远不够 … 想到这，有点茅塞顿开的感觉。登录 NSQ 的控制台看对应的 Topic，果然问题出现在这，NSQ 上未投递的消息已经堆积了几亿条！

问题定位了，后续先通过内部工具先替客户解决问题就属于常规操作了，这里就不展开了。

监控部署落地

工单处理完了，我松了一口气，但是事情并没有告一段落。这个故障算是敲响了警钟：不能觉得 NSQ 性能不错就认为消息不会堆积了，必要的监控报警还是得安排上。

因为我司已经存在的基础设施，所以我决定使用 Prometheus 来监控 NSQ 服务。（Prometheus 的相关背景知识就不在这里科普了，想看的请留言。）

Prometheus 通过 exporter 去采集第三方服务的数据，也就是说 NSQ 必须配置一个 exporter 才能接入 Prometheus。

Prometheus 的官方文档[https://prometheus.io/docs/instrumenting/exporters/]上对 exporter 有推荐，我顺着链接找到了官方推荐的 NSQ exporter[https://github.com/lovoo/nsq_exporter]。NSQ exporter 这个项目年久失修，最近的一次提交已经在 4 年前。