消息追踪与排查专题测试

以下关于 RabbitMQ 核心监控指标的描述，说法正确的是：

A. queue_messages_ready 表示队列中等待被消费的消息数，该值持续升高说明消费者处理能力不足 B. fd_used 表示已使用的文件描述符数量，当该值接近 fd_total 时说明连接数过多，应增加最大连接数限制 C. mem_used 表示 RabbitMQ 进程使用的内存总量，该值达到 mem_limit 时会触发 Flow Control 并拒绝新连接 D. disk_free 表示磁盘剩余空间，当该值低于 disk_free_limit 时 RabbitMQ 会停止所有队列的消费者

在 RabbitMQ 监控中，以下哪些指标可以用来判断消息积压问题？

A. queue_messages — 队列中消息总数（包括 ready 和 unacknowledged） B. queue_messages_ready — 等待被消费的消息数 C. queue_messages_unacknowledged — 已投递给消费者但尚未确认的消息数 D. queue_consumers — 当前订阅该队列的消费者数量 E. queue_message_stats.deliver_get — 消息投递/获取速率 F. connection_channels — 连接上的 Channel 数量

当 RabbitMQ 的内存使用量达到 vm_memory_high_watermark（默认物理内存的 40%）时，系统会自动进入 Flow Control 状态。此时，所有已建立的连接上的生产者会被阻塞（阻塞发布），但消费者可以继续正常消费消息，管理界面和 API 也可以正常访问。

为 RabbitMQ 设计合理的告警规则时，每个告警应包含以下关键要素：(1) ________ — 被监控的具体指标；(2) ________ — 触发告警的条件（如 > 10000 或持续 5 分钟超过水位线）；(3) ________ — 如 Warning、Critical、Emergency；(4) ________ — 告警触发后应采取的操作或排查步骤。

在 RabbitMQ 集群监控中，node_mem_used 和 node_disk_free 等指标是每个节点独立上报的。告警系统应该针对每个节点分别设置告警阈值，而不应该对集群所有节点的指标取平均值后进行告警，因为平均值可能掩盖单个节点的异常情况。

请为 RabbitMQ 生产集群设计一套完整的监控告警体系，涵盖以下三个级别，每个级别列出 2-3 个关键指标、告警阈值和响应动作：

1. Warning 级别（需要关注，暂未影响服务）
2. **Critical 级别（需要立即处理）
3. **Emergency 级别（服务已受影响）

关于 RabbitMQ Prometheus 集成方案，以下说法正确的是：

A. RabbitMQ 3.8+ 内置了 Prometheus Exporter 插件，启用后默认在端口 15692 暴露指标 B. Prometheus 通过 Pushgateway 模式从 RabbitMQ 拉取指标数据 C. rabbitmq_prometheus 插件返回的指标格式兼容 OpenMetrics 标准，可被 Prometheus 直接采集 D. Prometheus 采集的 RabbitMQ 指标默认包含每条消息的详细内容

关于 RabbitMQ rabbitmq_prometheus 插件的配置和指标特性，以下说法哪些是正确的？

A. 该插件可以通过 rabbitmq-plugins enable rabbitmq_prometheus 命令启用 B. 插件暴露的指标包括 Counter、Gauge、Histogram 三种 Prometheus 指标类型 C. 启用该插件后，需要在 Prometheus 的配置文件中手动添加每个节点的 scrape target D. 指标中包含 node 标签，可以区分集群中不同节点的指标数据 E. 该插件同时支持经典格式的指标（/metrics）和 per-object 格式（/metrics/per-object）

在搭建 RabbitMQ 监控大盘时，Prometheus 负责采集和存储指标数据，Grafana 负责可视化和告警。Grafana 内置了 RabbitMQ 的官方 Dashboard 模板，可以直接从 Grafana.com 导入使用，无需自行编写 PromQL 查询语句。

在 Grafana 中使用 PromQL 查询 RabbitMQ 集群指标时，以下查询语句的含义： (1) sum(rabbitmq_queue_messages{state="running"}) 表示 ________________________ ； (2) rate(rabbitmq_queue_messages_published_total[5m]) 表示 ________________________ ； (3) avg(rabbitmq_process_resident_memory_bytes) by (node) 表示 ________________________ 。

RabbitMQ Prometheus 插件提供了两个指标端点：/metrics（聚合指标）和 /metrics/per-object（按对象拆分的详细指标）。关于这两个端点的对比，以下说法正确的是：

A. /metrics 端点的指标数量更多，因为包含每个队列的详细信息 B. /metrics/per-object 端点的指标数量随队列和连接数量线性增长，在大规模集群中可能导致 Prometheus 采集开销显著增加 C. 生产环境应该只使用 /metrics 端点，/metrics/per-object 端点仅适用于开发调试 D. Prometheus 只能从其中一个端点采集数据，无法同时配置两个端点

请描述 RabbitMQ 集群接入 Prometheus + Grafana 监控的完整实施步骤，包括：

1. RabbitMQ 端启用 Prometheus 插件并验证
2. Prometheus 配置 scrape 目标
3. Grafana 导入 Dashboard 并设置告警规则

在 RabbitMQ 中，一条消息从生产者发布到消费者确认消费的完整链路涉及多个环节。以下哪个环节最不可能导致消息丢失？

A. 生产者发送消息后未启用 Publisher Confirm 机制，消息在到达交换机之前因网络中断而丢失 B. 交换机未绑定任何队列，消息路由失败后被丢弃 C. 队列未设置持久化，RabbitMQ 节点重启后队列中的消息全部丢失 D. 消费者收到消息后正确处理业务并发送了 basic.ack，但业务数据在后续数据库写入时失败

排查 RabbitMQ 消息丢失问题时，以下哪些方法可以帮助快速定位消息在哪个环节丢失？

A. 启用 Publisher Confirm 和 Return Listener，确认消息是否到达交换机和路由到队列 B. 在消费者端记录每条消息的 ID，与生产者发送的消息 ID 做对比 C. 使用 Firehose Tracer 或 Tracing 插件记录消息在 RabbitMQ 内部的完整流转路径 D. 检查 RabbitMQ 日志中是否有 delivery acknowledgement timeout 相关记录 E. 使用 rabbitmqctl list_queues name messages messages_ready messages_unacknowledged 查看队列中消息状态

要确保 RabbitMQ 中的消息在节点重启后不丢失，必须同时满足以下三个条件：(1) 队列声明时设置 durable=true；(2) 发布消息时设置 delivery_mode=2（持久化消息）；(3) 发布消息时设置 mandatory=true。如果其中任何一个条件不满足，消息在重启后都可能丢失。

RabbitMQ 消息丢失的常见根因可以分为以下四类： (1) ________ 问题：未启用 Publisher Confirm，消息未到达 Broker 即丢失； (2) ______ 问题：交换机未绑定队列或路由键不匹配，消息被丢弃； (3) ______ 问题：队列或消息未持久化，节点重启后数据丢失； (4) ________ 问题：自动 ACK 模式下消息被消费但业务处理失败，或手动 ACK 时未正确处理异常导致消息被确认但业务未成功。

在 RabbitMQ 中，如果消费者使用自动 ACK 模式（autoAck=true），当消息从队列投递给消费者后，RabbitMQ 会立即将该消息标记为已确认并从队列中删除。如果消费者在处理消息时发生异常（如抛出未捕获异常或进程崩溃），该消息不会被重新投递，从而导致消息丢失。

某电商系统的订单服务报告"部分订单消息丢失"。请给出一个系统化的排查方案，按照消息从生产者到消费者的完整链路，列出每个排查步骤、使用的工具和命令、以及判断标准。

关于 RabbitMQ 的 Firehose 消息追踪功能，以下说法正确的是：

A. Firehose 通过复制所有发布到交换机和从队列投递的消息到一个特殊的 amq.rabbitmq.trace 交换机来实现全局追踪 B. 启用 Firehose 后，被追踪的消息会携带额外的路由键：发布消息的路由键格式为 publish.<exchange_name>，投递消息的路由键格式为 deliver.<queue_name> C. Firehose 可以按 VHost 或队列进行过滤，只追踪特定资源的消息 D. Firehose 对生产环境的性能影响可以忽略不计，因为它使用的是异步复制机制

关于 RabbitMQ Firehose 消息追踪的使用场景和操作，以下说法哪些是正确的？

A. 可以通过 rabbitmqctl trace_on 命令启用 Firehose，通过 rabbitmqctl trace_off 命令关闭 B. Firehose 追踪的消息可以通过订阅 amq.rabbitmq.trace 交换机的消费者来实时接收和查看 C. Firehose 适合在生产环境长期启用，作为日常监控的常规手段 D. Firehose 记录的消息包含消息体内容、消息头、路由键和发布时间等完整信息 E. 可以配合使用 rabbitmqadmin 工具来管理 Firehose 的追踪日志队列