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

在 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 服务中查不到对应的日志。我大致列举了如下几种情况：

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

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

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

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

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

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

于是，我把这个项目拿到了本地，做了一些简单的改造，使它支持 go mod。（PR 在这里[https://github.com/lovoo/nsq_...

NSQ exporter 部署完成后，接下来的问题是哪些指标需要监控？

Prometheus 建议配置 Grafana 更加直观地查看指标的变动情况，我配置大体的效果如下：

超时消息对应着 Timed Out 指标

自从 NSQ 配置监控服务后，我们能迅速感知 NSQ 当前状况，在报警发出后及时人工处理跟进。相关业务的稳定性有明显提升，此类问题引起的工单变少了；此外监控收集到的相关数据，让我们在接下来的性能优化工作中的思路更加清晰，方向更加明显。