4.4 监控与日志：让故障先开口

4.4 监控与日志：让故障先开口

本节摘要：监控回答"现在健康吗、趋势在恶化吗"，日志回答"刚才发生了什么"。本节给出必须进告警的指标清单与采集方式，示范管理 API 的脚本化巡检，并把六类高频日志报错翻译成人话——读完能回答那个运维终极问题：半夜谁先知道出事了。

生产化改造的收尾一步，也是大多数团队欠账最多的一步。消息队列的故障有个讨厌的特性：静默恶化。队列慢慢堆积、连接缓缓泄漏、磁盘悄悄变满——没有任何一种会"啪"地报个错。没有监控，你发现问题的时间就是用户投诉的时间。

必须进告警的指标清单

按"看什么、为什么、阈值怎么定"整理成一张硬清单：

清单里故意没有"消息速率"——速率高低本身不是健康信号，高吞吐不代表没事，零速率也不代表有事（可能业务本来就闲）。速率要看的是相对变化：发布速率正常而消费速率归零，才是"消费端出事了"的实锤。

采集方式：管理 API 一步到位

指标采集不必装额外代理，管理插件自带的 HTTP API 直接吐 JSON 指标，采集器抓它即可。先手动感受一下：

# 拉取队列指标（需要管理账号）
curl -s -u monitor_ro:RoPass2026! \
  http://mq-node1:15672/api/queues | \
  python -c "import json,sys; [print(q['name'], q.get('messages', 0)) for q in json.load(sys.stdin)]"
# 预期输出：
# trace.orders 0
# order.close.exec 128
# order.quorum 1
​

脚本化巡检的价值在于趋势判断。单点数值没有历史，主流做法是把 API 指标喂给时序数据库，告警规则写在监控层。给一个最小可用的巡检脚本骨架，团队没上监控系统前可以先用它顶着：

import json, urllib.request, base64

def fetch(path: str):
    req = urllib.request.Request(f"http://mq-node1:15672/api/{path}")
    token = base64.b64encode(b"monitor_ro:RoPass2026!").decode()
    req.add_header("Authorization", f"Basic {token}")
    return json.load(urllib.request.urlopen(req))

alerts = []
for q in fetch("queues"):
    name, ready = q["name"], q.get("messages_ready", 0)
    if name in ("order.close.exec", "order.quorum") and ready > 500:
        alerts.append(f"堆积告警 {name}: {ready}")
    if q.get("consumers", 0) == 0 and ready > 0:
        alerts.append(f"无消费者 {name}: {ready}")

for c in [len(fetch("connections"))]:
    print("当前连接数:", c)   # 记入时序，看趋势

print("\n".join(alerts) or "巡检通过")
# 预期输出（正常时）：
# 当前连接数: 34
# 巡检通过
​

结果与解读：脚本两分钟写完，却能覆盖清单前四项。它的局限同样要认清：单机执行、无历史、告警靠人看——它是临时拐杖，不是监控系统替代品。上了 Prometheus 生态的团队，直接启用 rabbitmq_prometheus 插件暴露指标端点，采集与告警全部托管。

日志排障：六类高频报错人话版

日志位置随安装途径而异，容器环境打标准输出。六类最常撞见的报错，先翻译再处理：

access refused：用户名或密码错误。多为配置分发错乱，检查环境变量与账户是否同步。vhost not found：连了不存在的虚拟主机。通常发生在新建环境时 vhost 还没建，客户端就先上线了——执行顺序问题。PRECONDITION_FAILED inequivalent arg：声明参数冲突。第 2 章的铁律显灵，两个服务对同一资源的声明参数漂移了，按 2.4 节的迁移流程处理。channel/connection is closed by server：通道被服务端关。查明原因帧（通常是上面的参数冲突或权限问题），修复后重建通道，不要盲目重连死循环。memory/disk alarm：资源水位告警。Broker 已阻塞发布方，按 4.1 节参数核查与堆积清理双管齐下。missed heartbeats from client：心跳超时。客户端长任务卡住心跳，回看 2.5 节的慢消费问题。

变式：把日志级别调到 debug 观察 3.2 节持久化消息的落盘行为，能直观看到"消息写入消息存储"与"确认回执"的时间差——对理解发送方确认的语义价值极有帮助，排障时也用它判断持久化是否真的在工作。

告警的落点纪律

指标进了监控不等于完事。三条落点纪律：每条告警必须绑定处置手册（收到"堆积告警"第一分钟做什么，写成 checklist）；告警分级（堆积预警进群、磁盘告警打电话）；定期演练告警链路本身（人为制造一次堆积，验证告警真的会响）——静默的监控比没有监控更危险，它给人虚假的安全感。

💡 关键直觉：监控的终极指标不是 Broker 的任何仪表，而是"业务消息的端到端延迟"。Broker 一切正常而业务延迟飙升，说明问题在你看不见的地方——这正是要把业务侧探针（发一条测试消息走全链路计时）纳入监控的原因。

本节要点回顾

• 告警清单：堆积、未签收、消费者数、内存磁盘水位、连接趋势、死信增长；
• 速率看相对：绝对速率无意义，发布与消费速率的剪刀差才是信号；
• 采集起点：管理 API 吐 JSON 指标，脚本巡检可顶急，正式方案接时序库；
• 日志六译：报错先翻译成人话再动手，多数报错对应第 2 章讲过的机制；
• 落点纪律：告警绑手册、分级通知、定期演练链路本身。

生产化四步走完：装好、配对、组队、上岗盯着。第 5 章回到代码视角，把高级模式、插件、安全与调优一次讲透。