實操筆記：爲 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 服務中查不到對應的日誌。我大體列舉了以下幾種狀況：

• 服務變動。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