跳至主要内容
版本:3.13

监控

概述

本文档概述了与 RabbitMQ 监控相关的主题。监控 RabbitMQ 和使用它的应用程序至关重要。监控有助于在问题影响环境的其余部分并最终影响最终用户之前检测问题。

强烈建议将 Prometheus 和 Grafana 组合用于 RabbitMQ 监控。

监控是一个广泛的主题。本指南涵盖了几个

许多 流行工具,开源和商业工具,都可以用来监控 RabbitMQ。如上所述,RabbitMQ 团队建议大多数用户使用 Prometheus 和 Grafana 的组合。在 Kubernetes 上,Prometheus 插件由 Kubernetes RabbitMQ Operator 自动启用。

什么是监控?

在本指南中,我们将监控定义为一个过程,该过程通过健康检查和指标随着时间的推移捕获系统的行为。这有助于检测异常:当系统不可用、遇到异常负载、耗尽某些资源或以其他方式不按正常(预期)参数运行时。监控涉及长期收集和存储指标,这不仅对于异常检测很重要,而且对于根本原因分析、趋势检测和容量规划也很重要。

监控系统通常与警报系统集成。当监控系统检测到异常时,通常会将某种警报传递给警报系统,警报系统会通知相关方,例如技术运营团队。

拥有监控意味着更容易检测到系统行为的重要偏差,从某些区域的服务降级到完全不可用,并且查找根本原因所需的时间要少得多。在没有监控数据的情况下运行分布式系统就像试图走出森林而没有 GPS 导航设备或指南针一样。无论这个人多么聪明或经验丰富,拥有相关信息对于获得好的结果非常重要。

健康检查在监控中的作用

健康检查 是监控的另一个重要方面。健康检查涉及一个命令或一组命令,这些命令收集受监控系统的几个基本指标 随着时间的推移,并根据该指标断言系统的状态(健康状况)。

例如,RabbitMQ 的 Erlang VM 是否正在运行就是一个这样的检查。在这种情况下,指标是“是否正在运行操作系统进程?”。正常运行参数是“进程必须正在运行”。最后,还有一个评估步骤。

当然,还有更多类型的健康检查。哪些最合适取决于所使用的“健康节点”的定义。因此,这是一个系统和团队特定的决定。 RabbitMQ CLI 工具 提供可以作为有用健康检查的命令。这些命令将在 本指南的后面部分 中介绍。

虽然健康检查是一个有用的工具,但它们只能提供对系统状态的有限洞察力,因为它们的设计侧重于一个或少数几个指标,通常检查单个节点,并且只能推断特定时间点该节点的状态。为了进行更全面的评估,请收集更多指标 随着时间的推移。这可以检测到更多类型的异常,因为某些异常只能在较长的时间段内识别出来。这通常由称为监控工具的工具完成,这些工具种类繁多。本指南涵盖了一些用于 RabbitMQ 监控的工具。

系统和 RabbitMQ 指标

某些指标是 RabbitMQ 特定的:它们是由 RabbitMQ 节点收集和报告 的。在本指南中,我们将它们称为“RabbitMQ 指标”。例如,使用的套接字描述符数量、已排队的总消息数或节点间通信流量速率。其他指标是由 操作系统内核收集和报告 的。此类指标通常称为系统指标或基础设施指标。系统指标不是 RabbitMQ 特定的。例如,CPU 利用率、进程使用的内存量、网络数据包丢失率等。两种类型的指标都很重要。单个指标并不总是很有用,但当一起分析时,它们可以提供对系统状态的更全面的洞察力。然后,运营商可以对正在发生的事情以及需要解决的问题形成假设。

基础设施和内核指标

构建一个有用的监控系统的第一步是从基础设施和内核指标开始。指标很多,但有些比其他指标更重要。在运行 RabbitMQ 节点或应用程序的所有主机上收集以下指标

  • CPU 统计信息(用户、系统、iowait、空闲百分比)
  • 内存使用情况(使用、缓冲、缓存和空闲百分比)
  • 内核页面缓存,特别是在使用 的集群中
  • 虚拟内存 统计信息(脏页面刷新、回写量)
  • 磁盘 I/O(操作频率、每单位时间传输的数据量、长时间 I/O 操作完成所需时间的统计分布、I/O 操作失败率)
  • 用于 节点数据目录 的挂载上的可用磁盘空间
  • beam.smp 使用的文件描述符与 最大系统限制 相比
  • 按状态(ESTABLISHEDCLOSE_WAITTIME_WAIT)的 TCP 连接
  • 网络吞吐量(接收的字节、发送的字节)和最大网络吞吐量
  • 网络延迟(在集群中的所有 RabbitMQ 节点之间以及往返于客户端之间的延迟)

收集基础设施和内核指标、存储和可视化这些指标的工具(例如 Prometheus 或 Datadog)并不缺乏。

使用 Prometheus 兼容工具监控

RabbitMQ 带有一个内置插件,该插件以 Prometheus 格式公开指标:rabbitmq_prometheus。该插件公开了一些 RabbitMQ 指标,用于节点、连接、队列、消息速率等。此插件开销低,强烈建议用于生产环境。

Prometheus 与 GrafanaELK 堆栈 相比其他监控选项具有许多优势

  • 将监控系统与被监控的系统分离
  • 开销更低
  • 长期指标存储
  • 访问其他相关指标,例如 运行时 的指标
  • 更强大且可定制的用户界面
  • 指标数据共享变得容易:指标状态和仪表板
  • 指标访问权限不是 RabbitMQ 特定的
  • 节点特定指标的收集和聚合,这对于单个节点故障更有弹性

如何启用它

要启用 Prometheus 插件,请使用

rabbitmq-plugins enable rabbitmq_prometheus

预配置 插件。

HTTP API 端点

该插件默认情况下在端口 15692 上为 Prometheus 兼容的抓取器提供指标

curl {hostname}:15692/metrics

请咨询 Prometheus 插件指南 以了解更多信息。

使用管理插件监控

内置的 管理插件 也可以收集指标并在 UI 中显示它们。对于开发环境来说,这是一个方便的选择。

该插件也可以为监控工具提供指标。但是,与 使用 Prometheus 监控 相比,它有一些重要的局限性

  • 监控系统与被监控的系统交织在一起
  • 使用管理插件监控往往会产生更大的开销,特别是对于节点 RAM 占用空间
  • 它只存储最近的数据(想想小时,而不是天或月)
  • 它只有基本的用户界面
  • 它的设计 强调易用性而不是最佳可用性
  • 管理 UI 访问通过 RabbitMQ 权限标签系统 (或 JWT 令牌范围的约定)控制

如何启用它

要启用管理插件,请使用

rabbitmq-plugins enable rabbitmq_management

预配置 插件。

HTTP API 端点

该插件默认情况下在端口 15672 上通过 HTTP API 提供指标,并使用基本 HTTP 身份验证

curl -u {username}:{password} {hostname}:15672/api/overview

请咨询 管理插件指南 以了解更多信息。

监控 Kubernetes 运营商部署的集群

使用 RabbitMQ Kubernetes 运营商 部署到 Kubernetes 的 RabbitMQ 集群可以使用 Prometheus 或兼容工具进行监控。

这在关于 在 Kubernetes 中监控 RabbitMQ 的专用指南中有所介绍。

基于交互式命令行的观察工具

rabbitmq-diagnostics observer 是一个类似于 tophtopvmstat 的命令行工具。它是 Erlang 的 Observer 应用程序 的命令行替代品。它提供了对许多指标的访问,包括单个 运行时 进程的详细状态

  • 运行时版本信息
  • CPU 和调度统计信息
  • 内存分配和使用统计信息
  • 按 CPU(减少量)和内存使用量排序的顶级进程
  • 网络链路统计信息
  • 详细的进程信息,例如基本的 TCP 套接字统计信息

等等,在一个具有周期性更新的交互式 ncurses 类似的命令行界面中。

以下是一些屏幕截图,展示了该工具提供的信息类型。

包含关键运行时指标的概述页面

rabbitmq-diagnostics observer overview

内存分配器统计信息

rabbitmq-diagnostics memory breakdown

客户端连接进程指标

rabbitmq-diagnostics connection process

监控的资源使用和开销

监控可能是侵入性的,并会增加被监控系统的负载。这取决于被监控集群中实体(连接、队列等)的数量,但也取决于其他因素:监控频率、监控工具请求的数据量等等。

许多监控系统会定期轮询其监控的服务。轮询的频率因工具而异,但通常可以由操作员配置。

过于频繁的轮询会对被监控系统造成负面影响。例如,过度负载均衡器检查(打开到节点的测试 TCP 连接)会导致 高连接抖动。对 RabbitMQ 中的通道和队列进行过度检查会增加其 CPU 消耗。当节点上有许多(比如,10,000 个)这样的通道和队列时,差异可能会很大。

监控工具的另一个常见问题是它们从 RabbitMQ 节点请求的数据量。一些监控工具查询整个页面或所有队列,只是为了获得一个队列的单个指标值。这会显著增加监控的 CPU 负载。

可以使用 rabbitmq_top 插件或 rabbitmq-diagnostics observer 识别这些情况。按减少量(运行时调度器时间的单位)排序的顶级进程通常是以下进程之一

  • rabbit_mgmt_db_cache_connections
  • rabbit_mgmt_external_stats
  • queue_metrics_metrics_collector
  • 以及其他以 _metrics_collector 结尾的进程

为了减少监控占用,请降低监控频率,并确保监控工具仅查询其所需的数据。

监控频率

生产环境中推荐的指标收集间隔为 **30 秒**,或 30 到 60 秒范围内的其他合适值。 Prometheus 导出器 API 旨在每 15 到 30 秒抓取一次,包括生产系统。

在开发环境中,为了收集更接近实时的间隔,请使用 5 秒——但不要低于 5 秒!

对于速率指标,请使用跨越四个或更多指标收集间隔的时间范围,以便它能够容忍竞争条件并对抓取失败具有弹性。

RabbitMQ 指标

本节将介绍监控的多个 RabbitMQ 特定方面。本节中提到的大多数指标都由 Prometheus 插件 和管理 UI 公开。

集群范围的指标

集群范围的指标提供了集群状态的高级视图。其中一些指标描述了节点之间的交互。此类指标的示例包括集群链路流量和检测到的网络分区。其他指标将所有集群成员的指标组合在一起。所有节点的完整连接列表就是一个例子。两种类型都与基础设施和节点指标相辅相成。

GET /api/overviewHTTP API 端点,它返回集群范围的指标。

指标JSON 字段名称
集群名称cluster_name
集群范围的消息速率message_stats
连接总数object_totals.connections
通道总数object_totals.channels
队列总数object_totals.queues
消费者总数object_totals.consumers
消息总数(已准备就绪的消息加上未确认的消息)queue_totals.messages
已准备就绪的待传递消息数queue_totals.messages_ready
未确认 的消息数queue_totals.messages_unacknowledged
最近发布的消息message_stats.publish
消息发布速率message_stats.publish_details.rate
最近传递给消费者的消息message_stats.deliver_get
消息传递速率message_stats.deliver_get_details.rate
其他消息统计信息

message_stats.*(请参阅 HTTP API 参考

节点指标

有两个 HTTP API 端点提供对特定于节点的指标的访问

  • GET /api/nodes/{node} 返回单个节点的统计信息
  • GET /api/nodes 返回所有集群成员的统计信息

后一个端点返回一个对象数组。支持(或可以支持)该端点的监控工具应该首选该端点,因为它减少了请求数量。当这种情况不存在时,请使用前一个端点依次检索每个集群成员的统计信息。这意味着监控系统知道集群成员列表。

大多数指标代表某一时刻的绝对值。有些指标代表最近一段时间内的活动(例如,GC 运行和回收的字节数)。后一种指标在与以前的指标值和历史平均值/百分位数进行比较时最有意义。

指标JSON 字段名称
使用的 内存 总量mem_used
内存使用量高水位线mem_limit
是否处于 内存警报 状态?mem_alarm
剩余磁盘空间低水位线disk_free_limit
是否处于 磁盘警报 状态?disk_free_alarm
可用的文件描述符fd_total
已使用的文件描述符fd_used
文件描述符打开尝试次数io_file_handle_open_attempt_count
可用的套接字sockets_total
已使用的套接字sockets_used
节点间通信链路cluster_links
GC 运行次数gc_num
GC 回收的字节数gc_bytes_reclaimed
Erlang 进程限制proc_total
已使用的 Erlang 进程proc_used
运行时运行队列run_queue

单个队列指标

单个队列指标通过 HTTP API 通过 GET /api/queues/{vhost}/{qname} 端点提供。

下表列出了一些可用于监控队列状态的关键指标。其他一些指标(例如队列状态和“空闲时间”)应被视为 RabbitMQ 贡献者使用的 **内部指标**。

指标JSON 字段名称
内存memory
消息总数(已准备就绪的消息加上未确认的消息)messages
已准备就绪的待传递消息数messages_ready
未确认 的消息数messages_unacknowledged
最近发布的消息message_stats.publish
消息发布速率message_stats.publish_details.rate
最近传递的消息message_stats.deliver_get
消息传递速率message_stats.deliver_get_details.rate
其他消息统计信息

message_stats.*(请参阅 HTTP API 参考

应用程序级指标

使用消息传递的系统几乎总是分布式的。在这些系统中,通常无法立即清楚哪个组件行为异常。系统中的每个部分,包括应用程序,都应该被监控和调查。

一些基础设施级指标和 RabbitMQ 指标可以显示异常系统行为或问题的存在,但无法确定根本原因。例如,很容易判断出节点是否内存不足,但并不总是容易判断原因。这就是应用程序指标发挥作用的地方:它们可以帮助识别失控的发布者、反复失败的消费者、无法跟上速率的消费者,甚至遇到减速的后续服务(例如,消费者使用的数据库中缺少索引)。

一些客户端库和框架提供了注册指标收集器或开箱即用地收集指标的方法。 RabbitMQ Java 客户端Spring AMQPNServiceBus 就是一些示例。对于其他库,开发人员必须在他们的应用程序代码中跟踪指标。

应用程序跟踪的指标可以是特定于系统的,但有些指标与大多数系统相关

  • 连接打开速率
  • 通道打开速率
  • 连接失败(恢复)速率
  • 发布速率
  • 传递速率
  • 正向传递确认速率
  • 负向传递确认速率
  • 平均值/第 95 百分位传递处理延迟

健康检查

健康检查是测试 RabbitMQ 服务的某个方面是否按预期运行的命令。健康检查是 由机器定期执行 或由操作员交互执行的。

健康检查可用于评估节点的状态和存活性,也可作为部署自动化和编排工具(包括在升级期间)的 就绪探测

可以执行一系列健康检查,从最基本且很少产生 误报 的检查开始,到越来越全面、侵入性和有意见的检查,这些检查产生误报的可能性更高。换句话说,健康检查越全面,结果就越不确定。

健康检查可以验证单个节点(节点健康检查)或整个集群(集群健康检查)的状态。

单个节点检查

本节介绍了节点健康检查的几个示例。它们按阶段组织。更高阶段执行更全面和有意见的检查。此类检查产生误报的可能性更高。某些阶段有专用的 RabbitMQ CLI 工具命令,而其他阶段可能涉及其他工具。

虽然健康检查是有序的,但更高的数字并不意味着检查“更好”。

可以有选择地使用健康检查,并将其组合起来。除非另有说明,否则检查应遵循与指标收集相同的 监控频率 建议。

早期版本的 RabbitMQ 使用了 侵入性健康检查,该检查现已弃用,应避免使用。请使用本节中介绍的检查(或其组合)之一。

阶段 1

最基本的检查确保 运行时 正在运行,并且(间接地)CLI 工具可以 通过身份验证

除了 CLI 工具身份验证部分外,除了升级和维护窗口外,误报的可能性可以认为接近 0

rabbitmq-diagnostics ping 执行此检查

rabbitmq-diagnostics -q ping
# => Ping succeeded if exit code is 0

阶段 2

一个稍微更全面的检查是执行 rabbitmq-diagnostics status 状态

这包括阶段 1 检查,以及检索一些必要的系统信息,这些信息对于其他检查很有用,并且如果 RabbitMQ 在节点上运行,则应该始终可用(见下文)。

rabbitmq-diagnostics -q status
# => [output elided for brevity]

这是检查节点可靠性的常用方法。除了升级和维护窗口外,误报的可能性可以认为接近 0

阶段 3

包括之前的检查,并验证 RabbitMQ 应用程序是否正在运行(没有使用 rabbitmqctl stop_app暂停少数派分区处理策略 停止),并且没有资源警报。

# lists alarms in effect across the cluster, if any
rabbitmq-diagnostics -q alarms

rabbitmq-diagnostics check_running 是一个检查,确保运行时正在运行,并且其上的 RabbitMQ 应用程序没有停止或暂停。

rabbitmq-diagnostics check_local_alarms 检查节点上是否启用了任何本地警报。如果有,它将以非零状态退出。

这两个命令组合起来提供阶段 3 检查

rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms
# if both checks succeed, the exit code will be 0

误报的可能性很低。徘徊在其 高运行时内存水位线 周围的系统将有很高的误报可能性。在升级和维护窗口期间,误报可能性会显著增加。

特别是对于内存警报,GET /api/nodes/{node}/memory HTTP API 端点可用于执行其他检查。在以下示例中,其输出被传递到 jq

curl --silent -u guest:guest -X GET http://127.0.0.1:15672/api/nodes/rabbit@hostname/memory | jq
# => {
# => "memory": {
# => "connection_readers": 24100480,
# => "connection_writers": 1452000,
# => "connection_channels": 3924000,
# => "connection_other": 79830276,
# => "queue_procs": 17642024,
# => "queue_slave_procs": 0,
# => "plugins": 63119396,
# => "other_proc": 18043684,
# => "metrics": 7272108,
# => "mgmt_db": 21422904,
# => "mnesia": 1650072,
# => "other_ets": 5368160,
# => "binary": 4933624,
# => "msg_index": 31632,
# => "code": 24006696,
# => "atom": 1172689,
# => "other_system": 26788975,
# => "allocated_unused": 82315584,
# => "reserved_unallocated": 0,
# => "strategy": "rss",
# => "total": {
# => "erlang": 300758720,
# => "rss": 342409216,
# => "allocated": 383074304
# => }
# => }
# => }

它生成的 细分信息 可以使用 jq 或类似工具简化为一个值

curl --silent -u guest:guest -X GET http://127.0.0.1:15672/api/nodes/rabbit@hostname/memory | jq ".memory.total.allocated"
# => 397365248

rabbitmq-diagnostics -q memory_breakdown 提供对同一类别数据的访问,并支持各种单位

rabbitmq-diagnostics -q memory_breakdown --unit "MB"
# => connection_other: 50.18 mb (22.1%)
# => allocated_unused: 43.7058 mb (19.25%)
# => other_proc: 26.1082 mb (11.5%)
# => other_system: 26.0714 mb (11.48%)
# => connection_readers: 22.34 mb (9.84%)
# => code: 20.4311 mb (9.0%)
# => queue_procs: 17.687 mb (7.79%)
# => other_ets: 4.3429 mb (1.91%)
# => connection_writers: 4.068 mb (1.79%)
# => connection_channels: 4.012 mb (1.77%)
# => metrics: 3.3802 mb (1.49%)
# => binary: 1.992 mb (0.88%)
# => mnesia: 1.6292 mb (0.72%)
# => atom: 1.0826 mb (0.48%)
# => msg_index: 0.0317 mb (0.01%)
# => plugins: 0.0119 mb (0.01%)
# => queue_slave_procs: 0.0 mb (0.0%)
# => mgmt_db: 0.0 mb (0.0%)
# => reserved_unallocated: 0.0 mb (0.0%)

阶段 4

包括阶段 3 中的所有检查,以及对所有启用的侦听器(使用临时 TCP 连接)的检查。

要检查在节点上启用的所有侦听器,请使用 rabbitmq-diagnostics listeners

rabbitmq-diagnostics -q listeners --node rabbit@target-hostname
# => Interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
# => Interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
# => Interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
# => Interface: [::], port: 15672, protocol: http, purpose: HTTP API
# => Interface: [::], port: 15671, protocol: https, purpose: HTTP API over TLS (HTTPS)

rabbitmq-diagnostics check_port_connectivity [--address <address>] 是一个命令,执行上述基本 TCP 连接检查

# This check will try to open a TCP connection to the discovered listener ports.
# Since nodes can be configured to listen to specific interfaces, an --address should
# be provided, or CLI tools will have to rely on the configured hostname resolver to know where to connect.
rabbitmq-diagnostics -q check_port_connectivity --node rabbit@target-hostname --address <ip-address-to-connect-to>
# If the check succeeds, the exit code will be 0

误报的可能性通常很低,但在升级和维护窗口期间会显著增加。

阶段 5

包括阶段 4 中的所有检查,以及检查是否存在任何失败的 虚拟主机

rabbitmq-diagnostics check_virtual_hosts 是一个命令,检查是否任何虚拟主机依赖项可能已失败。这将对所有虚拟主机执行。

rabbitmq-diagnostics -q check_virtual_hosts --node rabbit@target-hostname
# if the check succeeded, exit code will be 0

误报的可能性通常很低,除非系统处于高 CPU 负载状态。

健康检查作为就绪探测

在某些环境中,节点重启由指定的 健康检查 控制。检查验证一个节点已启动,并且部署过程可以继续进行到下一个节点。如果检查未通过,则节点的部署被视为不完整,并且部署过程通常会等待并重试一段时间。此类环境的一个流行示例是 Kubernetes,其中运营商定义的 就绪探测 可以阻止部署继续进行,当使用 OrderedReady pod 管理策略 时(不建议在 RabbitMQ 中使用!),或者当执行滚动重启时。

鉴于 节点重启期间的同行同步行为,这样的健康检查可以阻止集群范围的重启及时完成。明确或隐含地假设已完全启动的节点已重新加入其集群同行的检查将失败并阻止进一步的节点部署。

此外,大多数 CLI 命令(如 rabbitmq-diagnostics)都具有性能影响,因为 CLI 会加入 Erlang 分布(用于集群 RabbitMQ 节点的相同机制)。在每次探测执行时加入和离开此集群会导致不必要的开销。

RabbitMQ Kubernetes 运营商 在 AMQP 端口上配置 TCP 端口检查作为 readinessProbe,并且根本不定义 livenessProbe。这应该被视为最佳实践。

集群监控

监控单个节点很容易且直截了当。

监控集群时,重要的是要了解所使用 API 端点提供的保证。在集群环境中,每个节点都可以处理指标端点请求。此外,一些指标是特定于节点的,而另一些则是针对集群范围的。

每个节点都提供了对 特定于节点的指标 的访问权限。与 基础设施和操作系统指标 一样,必须为每个集群节点收集特定于节点的指标。

Prometheus 和管理插件 API 端点在它们提供哪些指标以及如何聚合集群范围的指标方面存在重要区别。

Prometheus

使用 Prometheus 插件,每个节点都提供了对 特定于节点的指标 的访问权限。Prometheus 查询指标端点 {hostname}:15692/metrics 并存储结果。然后从这些特定于节点的数据中计算出集群范围的指标。

管理插件

使用管理插件,每个节点都提供了对自身以及其他集群节点的 特定于节点的指标 的访问权限。

可以从任何可以 与其同行联系 的节点获取集群范围的指标。该节点将根据需要收集并组合来自其同行的 数据,然后生成响应。

使用管理插件,节点间连接问题会 影响 HTTP API 行为。为监控请求选择一个随机的在线节点。例如,使用负载均衡器或 循环 DNS

已弃用的健康检查和监控功能

旧版侵入式健康检查

早期版本的 RabbitMQ 提供了一个单一的观点式和侵入式健康检查命令(及其相应的 HTTP API 端点)

# DO NOT USE: this health check is very intrusive, resource-intensive, prone to false positives
# and as such, deprecated
rabbitmq-diagnostics node_health_check

上述命令已弃用,将在 RabbitMQ 的未来版本中删除,应避免使用。使用它的系统应采用 细粒度现代健康检查 之一。

上述检查强制系统中的每个连接、队列领导者副本和通道发出某些指标。对于大量的并发连接和队列,这可能非常资源密集,并且很可能产生误报。

上述检查也不适合用作 就绪探测,因为它隐含地假设了一个完全启动的节点。

监控工具

以下是通常用于收集 RabbitMQ 指标的第三方工具的按字母顺序排列的列表。这些工具的功能各不相同,但通常可以收集 基础设施级别RabbitMQ 指标

请注意,此列表绝不完整。

监控工具在线资源
AppDynamics

AppDynamicsGitHub

AWS CloudWatchGitHub
collectdGitHub
DataDog

DataDog RabbitMQ 集成GitHub

DynatraceDynatrace RabbitMQ 监控
GangliaGitHub
Graphite与 Graphite 配合使用的工具
Munin

Munin 文档GitHub

NagiosGitHub
Nastel AutoPilotNastel RabbitMQ 解决方案
New RelicNew Relic RabbitMQ 监控
Prometheus

Prometheus 指南GitHub

Sematext

Sematext RabbitMQ 监控集成Sematext RabbitMQ 日志集成

ZabbixZabbix 通过 HTTPZabbix 通过代理博客文章
Zenoss

RabbitMQ ZenPack教学视频

日志聚合

日志 在对分布式系统进行故障排除中也很重要。与指标一样,日志可以提供重要的线索,帮助识别根本原因。收集来自所有 RabbitMQ 节点以及所有应用程序(如果可能)的日志。