共计 2051 个字符，预计需要花费 6 分钟才能阅读完成。
在 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/in… exporter 有举荐，我顺着链接找到了官网举荐的 NSQ exporter[https://github.com/lovoo/nsq_… exporter 这个我的项目年久失修，最近的一次提交曾经在 4 年前。
于是，我把这个我的项目拿到了本地，做了一些简略的革新，使它反对 go mod。（PR 在这里 [https://github.com/lovoo/nsq_…
NSQ exporter 部署实现后，接下来的问题是哪些指标须要监控？
参考官网 [https://nsq.io/components/nsq…
- Depth：以后 NSQ 沉积的音讯。NSQ 在内存中默认只保留 8000 音讯，超过的音讯会长久化到磁盘中。
- Requeued：音讯 requeue 的次数。
- Timed Out：解决超时的音讯。
Prometheus 倡议配置 Grafana 更加直观地查看指标的变动状况，我配置大体的成果如下：
超时音讯对应着 Timed Out 指标
- 沉积音讯对应着 Depth 指标
- 负载是依据公式 sum(irate(NSQ_topic_message_count{}[5m])) 生成的。
- 探测服务是探测 NSQ exporter 服务是否失常。因为该服务常常会因为 NSQ 压力过去导致 exporter 本身服务不可用。
自从 NSQ 配置监控服务后，咱们能迅速感知 NSQ 当前状况，在报警收回后及时人工解决跟进。相干业务的稳定性有显著晋升，此类问题引起的工单变少了；此外监控收集到的相干数据，让咱们在接下来的性能优化工作中的思路更加清晰，方向更加显著。
举荐浏览
服务器标配 SSH 协定，你理解多少？
聊聊风口上的 eBPF
