接下来说说监控的相关内容。监控还是非常重要的，特别是在生产环境。磁盘满了，队列积压严重，如果我们无法提前知道，这是个很严重的问题；关于解决这些问题网上有很多解决方案。例如：Management UI，rabbitmqctl 命令和 REST API 以及使用 prometheus + grafana，当然大厂的话都会自定开发基于 api监控系统。


一、rabbitmqctl 命令


与RabbitMQ前端页面对应的就是后端的命令行命令了，同样非常丰富。平时自己测试，或者临时查看一些状态时，也能用得上。这里整理了一些从官网找的一些常用的命令。


  


# 启动服务
 rabbitmq-server
# 停止服务 
rabbitmqctl stop
# vhost 增删查 
rabbitmqctl add_vhost
rabbitmqctl delete_vhost
rabbitmqctl list_vhosts
# 查询交换机 
rabbitmqctl list_exchanges
# 查询队列 
rabbitmqctl list_queues
# 查看消费者信息 
rabbitmqctl list_consumers
# user 增删查 
rabbitmqctl add_user
rabbitmqctl delete_user
rabbitmqctl list_users


二、REST API

官网链接：​​http://localhost:15672/api/index.html​​

官方文档写的挺清楚的，我就不过多说明了，下面是来自官方表格

GET

PUT

DELETE

POST

Path

Description

X

 

 

 

/api/overview

Various random bits of information that describe the whole system.

X

X

 

 

/api/cluster-name

Name identifying this RabbitMQ cluster.

X

 

 

 

/api/nodes

A list of nodes in the RabbitMQ cluster.

X

 

 

 

/api/nodes/name

An individual node in the RabbitMQ cluster. Add "?memory=true" to get memory statistics, and "?binary=true" to get a breakdown of binary memory use (may be expensive if there are many small binaries in the system).

X

 

 

 

/api/extensions

A list of extensions to the management plugin.

X

 

 

X

/api/definitions

/api/all-configuration (deprecated)

The server definitions - exchanges, queues, bindings, users, virtual hosts, permissions, topic permissions, and parameters. Everything apart from messages. POST to upload an existing set of definitions. Note that:

  • The definitions are merged. Anything already existing on the server but not in the uploaded definitions is untouched.
  • Conflicting definitions on immutable objects (exchanges, queues and bindings) will be ignored. The existing definition will be preserved.
  • Conflicting definitions on mutable objects will cause the object in the server to be overwritten with the object from the definitions.
  • In the event of an error you will be left with a part-applied set of definitions.

For convenience you may upload a file from a browser to this URI (i.e. you can use ​​multipart/form-data​​ as well as ​​application/json​​) in which case the definitions should be uploaded as a form field named "file".

X

 

 

X

/api/definitions/vhost

The server definitions for a given virtual host - exchanges, queues, bindings and policies. POST to upload an existing set of definitions. Note that:

  • The definitions are merged. Anything already existing on the server but not in the uploaded definitions is untouched.
  • Conflicting definitions on immutable objects (exchanges, queues and bindings) will be ignored. The existing definition will be preserved.
  • Conflicting definitions on mutable objects will cause the object in the server to be overwritten with the object from the definitions.
  • In the event of an error you will be left with a part-applied set of definitions.

For convenience you may upload a file from a browser to this URI (i.e. you can use ​​multipart/form-data​​ as well as ​​application/json​​) in which case the definitions should be uploaded as a form field named "file".

X

 

 

 

/api/connections

A list of all open connections. Use ​​pagination parameters​​ to filter connections.

X

 

 

 

/api/vhosts/vhost/connections

A list of all open connections in a specific virtual host. Use ​​pagination parameters​​ to filter connections.

X

 

X

 

/api/connections/name

An individual connection. DELETEing it will close the connection. Optionally set the "X-Reason" header when DELETEing to provide a reason.

X

 

 

 

/api/connections/name/channels

List of all channels for a given connection.

X

 

 

 

/api/channels

A list of all open channels. Use ​​pagination parameters​​ to filter channels.

X

 

 

 

/api/vhosts/vhost/channels

A list of all open channels in a specific virtual host. Use ​​pagination parameters​​ to filter channels.

X

 

 

 

/api/channels/channel

Details about an individual channel.

X

 

 

 

/api/consumers

A list of all consumers.

X

 

 

 

/api/consumers/vhost

A list of all consumers in a given virtual host.

X

 

 

 

/api/exchanges

A list of all exchanges. Use ​​pagination parameters​​ to filter exchanges.

X

 

 

 

/api/exchanges/vhost

A list of all exchanges in a given virtual host. Use ​​pagination parameters​​ to filter exchanges.

X

X

X

 

/api/exchanges/vhost/name

An individual exchange. To PUT an exchange, you will need a body looking something like this:

{"type":"direct","auto_delete":false,"durable":true,"internal":false,"arguments":{}}

The ​​type​​ key is mandatory; other keys are optional.

When DELETEing an exchange you can add the query string parameter ​​if-unused=true​​. This prevents the delete from succeeding if the exchange is bound to a queue or as a source to another exchange.


X

 

 

 

/api/exchanges/vhost/name/bindings/source

A list of all bindings in which a given exchange is the source.

X

 

 

 

/api/exchanges/vhost/name/bindings/destination

A list of all bindings in which a given exchange is the destination.

 

 

 

X

/api/exchanges/vhost/name/publish

Publish a message to a given exchange. You will need a body looking something like:

{"properties":{},"routing_key":"my key","payload":"my body","payload_encoding":"string"}

All keys are mandatory. The ​​payload_encoding​​ key should be either "string" (in which case the payload will be taken to be the UTF-8 encoding of the payload field) or "base64" (in which case the payload field is taken to be base64 encoded).

If the message is published successfully, the response will look like:

{"routed": true}

​​routed​​ will be true if the message was sent to at least one queue.

Please note that the HTTP API is not ideal for high performance publishing; the need to create a new TCP connection for each message published can limit message throughput compared to AMQP or other protocols using long-lived connections.


X

 

 

 

/api/queues

A list of all queues. Use ​​pagination parameters​​ to filter queues.

X

 

 

 

/api/queues/vhost

A list of all queues in a given virtual host. Use ​​pagination parameters​​ to filter queues.

X

X

X

 

/api/queues/vhost/name

An individual queue. To PUT a queue, you will need a body looking something like this:

{"auto_delete":false,"durable":true,"arguments":{},"node":"rabbit@smacmullen"}

All keys are optional.

When DELETEing a queue you can add the query string parameters ​​if-empty=true​​ and / or ​​if-unused=true​​. These prevent the delete from succeeding if the queue contains messages, or has consumers, respectively.


X

 

 

 

/api/queues/vhost/name/bindings

A list of all bindings on a given queue.

 

 

X

 

/api/queues/vhost/name/contents

Contents of a queue. DELETE to purge. Note you can't GET this.

 

 

 

X

/api/queues/vhost/name/actions

Actions that can be taken on a queue. POST a body like:

{"action":"sync"}

Currently the actions which are supported are ​​sync​​ and ​​cancel_sync​​.

 

 

 

X

/api/queues/vhost/name/get

Get messages from a queue. (This is not an HTTP GET as it will alter the state of the queue.) You should post a body looking like:

{"count":5,"ackmode":"ack_requeue_true","encoding":"auto","truncate":50000}


  • ​​count​​ controls the maximum number of messages to get. You may get fewer messages than this if the queue cannot immediately provide them.
  • ​​ackmode​​ determines whether the messages will be removed from the queue. If ackmode is ack_requeue_true or reject_requeue_true they will be requeued - if ackmode is ack_requeue_false or reject_requeue_false they will be removed.
  • ​​encoding​​ must be either "auto" (in which case the payload will be returned as a string if it is valid UTF-8, and base64 encoded otherwise), or "base64" (in which case the payload will always be base64 encoded).
  • If ​​truncate​​ is present it will truncate the message payload if it is larger than the size given (in bytes).

​​truncate​​ is optional; all other keys are mandatory.

Please note that the get path in the HTTP API is intended for diagnostics etc - it does not implement reliable delivery and so should be treated as a sysadmin's tool rather than a general API for messaging.


X

 

 

 

/api/bindings

A list of all bindings.

X

 

 

 

/api/bindings/vhost

A list of all bindings in a given virtual host.

X

 

 

X

/api/bindings/vhost/e/exchange/q/queue


A list of all bindings between an exchange and a queue. Remember, an exchange and a queue can be bound together many times!

To create a new binding, POST to this URI. Request body should be a JSON object optionally containing two fields, ​​routing_key​​ (a string) and ​​arguments​​ (a map of optional arguments):

{"routing_key":"my_routing_key", "arguments":{"x-arg": "value"}}

All keys are optional. The response will contain a ​​Location​​ header telling you the URI of your new binding.

 


X

 

X

 

/api/bindings/vhost/e/exchange/q/queue/props

An individual binding between an exchange and a queue. The props part of the URI is a "name" for the binding composed of its routing key and a hash of its arguments. props is the field named "properties_key" from a bindings listing response.

X

 

 

X

/api/bindings/vhost/e/source/e/destination


A list of all bindings between two exchanges, similar to the list of all bindings between an exchange and a queue, above.

 

To create a new binding, POST to this URI. Request body should be a JSON object optionally containing two fields, ​​routing_key​​ (a string) and ​​arguments​​ (a map of optional arguments):

{"routing_key":"my_routing_key", "arguments":{"x-arg": "value"}}

All keys are optional. The response will contain a ​​Location​​ header telling you the URI of your new binding.

 

 


X

 

X

 

/api/bindings/vhost/e/source/e/destination/props

An individual binding between two exchanges. Similar to the individual binding between an exchange and a queue, above.

X

 

 

 

/api/vhosts

A list of all vhosts.

X

X

X

 

/api/vhosts/name

An individual virtual host. As a virtual host usually only has a name, you do not need an HTTP body when PUTing one of these. To set metadata on creation, provide a body like the following:

{"description":"virtual host description", "tags":"accounts,production"}

​​tags​​ is a comma-separated list of tags. These metadata fields are optional. To enable / disable tracing, provide a body looking like:

{"tracing":true}


X

 

 

 

/api/vhosts/name/permissions

A list of all permissions for a given virtual host.

X

 

 

 

/api/vhosts/name/topic-permissions

A list of all topic permissions for a given virtual host.

 

 

 

X

/api/vhosts/name/start/node

Starts virtual host name on node node.

X

 

 

 

/api/users/

A list of all users.

X

 

 

 

/api/users/without-permissions

A list of users that do not have access to any virtual host.

 

 

 

X

/api/users/bulk-delete

Bulk deletes a list of users. Request body must contain the list:

{"users" : ["user1", "user2", "user3"]}


X

X

X

 

/api/users/name

An individual user. To PUT a user, you will need a body looking something like this:

{"password":"secret","tags":"administrator"}

or:

{"password_hash":"2lmoth8l4H0DViLaK9Fxi6l9ds8=", "tags":"administrator"}

The ​​tags​​ key is mandatory. Either ​​password​​ or ​​password_hash​​ can be set. If neither are set the user will not be able to log in with a password, but other mechanisms like client certificates may be used. Setting ​​password_hash​​ to ​​""​​ will ensure the user cannot use a password to log in. ​​tags​​ is a comma-separated list of tags for the user. Currently recognised tags are ​​administrator​​, ​​monitoring​​ and ​​management​​. ​​password_hash​​ must be generated using the algorithm described ​​here​​. You may also specify the hash function being used by adding the ​​hashing_algorithm​​ key to the body. Currently recognised algorithms are ​​rabbit_password_hashing_sha256​​, ​​rabbit_password_hashing_sha512​​, and ​​rabbit_password_hashing_md5​​.

X

 

 

 

/api/users/user/permissions

A list of all permissions for a given user.

X

 

 

 

/api/users/user/topic-permissions

A list of all topic permissions for a given user.

X

 

 

 

/api/user-limits

Lists per-user limits for all users.

X

 

 

 

/api/user-limits/user

Lists per-user limits for a specific user.

 

X

X

 

/api/user-limits/user/name

Set or delete per-user limit for ​​user​​. The ​​name​​ URL path element refers to the name of the limit (​​max-connections​​, ​​max-channels​​). Limits are set using a JSON document in the body:

{"value": 100}

. Example request:

curl -4u 'guest:guest' -H 'content-type:application/json' -X PUT localhost:15672/api/user-limits/guest/max-connections -d '{"value": 50}'


X

 

 

 

/api/whoami

Details of the currently authenticated user.

X

 

 

 

/api/permissions

A list of all permissions for all users.

X

X

X

 

/api/permissions/vhost/user

An individual permission of a user and virtual host. To PUT a permission, you will need a body looking something like this:

{"configure":".*","write":".*","read":".*"}

All keys are mandatory.

X

 

 

 

/api/topic-permissions

A list of all topic permissions for all users.

X

X

X

 

/api/topic-permissions/vhost/user

Topic permissions for a user and virtual host. To PUT a topic permission, you will need a body looking something like this:

{"exchange":"amq.topic","write":"^a","read":".*"}

All keys are mandatory.

X

 

 

 

/api/parameters

A list of all vhost-scoped parameters.

X

 

 

 

/api/parameters/component

A list of all vhost-scoped parameters for a given component.

X

 

 

 

/api/parameters/component/vhost

A list of all vhost-scoped parameters for a given component and virtual host.

X

X

X

 

/api/parameters/component/vhost/name

An individual vhost-scoped parameter. To PUT a parameter, you will need a body looking something like this:

{"vhost": "/","component":"federation","name":"local_username","value":"guest"}


X

 

 

 

/api/global-parameters

A list of all global parameters.

X

X

X

 

/api/global-parameters/name

An individual global parameter. To PUT a parameter, you will need a body looking something like this:

{"name":"user_vhost_mapping","value":{"guest":"/","rabbit":"warren"}}


X

 

 

 

/api/policies

A list of all policies.

X

 

 

 

/api/policies/vhost

A list of all policies in a given virtual host.

X

X

X

 

/api/policies/vhost/name

An individual policy. To PUT a policy, you will need a body looking something like this:

{"pattern":"^amq.", "definition": {"federation-upstream-set":"all"}, "priority":0, "apply-to": "all"}

​​pattern​​ and ​​definition​​ are mandatory, ​​priority​​ and ​​apply-to​​ are optional.

X

 

 

 

/api/operator-policies

A list of all operator policy overrides.

X

 

 

 

/api/operator-policies/vhost

A list of all operator policy overrides in a given virtual host.

X

X

X

 

/api/operator-policies/vhost/name

An individual operator policy. To PUT a policy, you will need a body looking something like this:

{"pattern":"^amq.", "definition": {"expires":100}, "priority":0, "apply-to": "queues"}

​​pattern​​ and ​​definition​​ are mandatory, ​​priority​​ and ​​apply-to​​ are optional.

X

 

 

 

/api/aliveness-test/vhost

Declares a test queue on the target node, then publishes and consumes a message. Intended to be used as a very basic health check. Responds a 200 OK if the check succeeded, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/alarms

Responds a 200 OK if there are no alarms in effect in the cluster, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/local-alarms

Responds a 200 OK if there are no local alarms in effect on the target node, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/certificate-expiration/within/unit


Checks the expiration date on the certificates for every listener configured to use TLS. Responds a 200 OK if all certificates are valid (have not expired), otherwise responds with a 503 Service Unavailable.

Valid units: days, weeks, months, years. The value of the within argument is the number of units. So, when within is 2 and unit is "months", the expiration period used by the check will be the next two months.


X

 

 

 

/api/health/checks/port-listener/port

Responds a 200 OK if there is an active listener on the give port, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/protocol-listener/protocol

Responds a 200 OK if there is an active listener for the given protocol, otherwise responds with a 503 Service Unavailable. Valid protocol names are: amqp091, amqp10, mqtt, stomp, web-mqtt, web-stomp.

X

 

 

 

/api/health/checks/virtual-hosts

Responds a 200 OK if all virtual hosts and running on the target node, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/node-is-mirror-sync-critical

Checks if there are classic mirrored queues without synchronised mirrors online (queues that would potentially lose data if the target node is shut down). Responds a 200 OK if there are no such classic mirrored queues, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/health/checks/node-is-quorum-critical

Checks if there are quorum queues with minimum online quorum (queues that would lose their quorum and availability if the target node is shut down). Responds a 200 OK if there are no such quorum queues, otherwise responds with a 503 Service Unavailable.

X

 

 

 

/api/vhost-limits

Lists per-vhost limits for all vhosts.

X

 

 

 

/api/vhost-limits/vhost

Lists per-vhost limits for specific vhost.

 

X

X

 

/api/vhost-limits/vhost/name

Set or delete per-vhost limit for ​​vhost​​. The ​​name​​ URL path element refers to the name of the limit (​​max-connections​​, ​​max-queues​​). Limits are set using a JSON document in the body:

{"value": 100}

. Example request:

curl -4u 'guest:guest' -H 'content-type:application/json' -X PUT localhost:15672/api/vhost-limits/my-vhost/max-connections -d '{"value": 50}'


X

 

 

 

/api/auth

Details about the OAuth2 configuration. It will return HTTP status 200 with body:

{"enable_uaa":"boolean", "uaa_client_id":"string", "uaa_location":"string"}


 

 

 

X

/api/rebalance/queues

Rebalances all queues in all vhosts. This operation is asynchronous therefore please check the RabbitMQ log file for messages regarding the success or failure of the operation.

curl -4u 'guest:guest' -XPOST localhost:15672/api/rebalance/queues/


X

 

 

 

/api/federation-links

/api/federation-links/vhost

Provides status for all federation links. Requires the ​​rabbitmq_federation_management​​ plugin to be enabled.

X

 

X

 

/api/auth/attempts/node

A list of authentication attempts.

X

 

X

 

/api/auth/attempts/node/source

A list of authentication attempts by remote address and username.


三、prometheus + grafana 监控rabbitmq 

3.1、 安装并启动grafana

创建数据文件挂载目录：



mkdir -p /data/grafana


最新版的grafana出现启动失败的问题，需要授予一下权限给数据挂载目录。这是因为Grafana启动使用的用户和用户组都是472，造成对外挂存储没有权限。



chown -R 472:472 /data/grafana


启动grafana



docker run -it -d --name=gra -p 3000:3000 -v /data/grafana/:/var/lib/grafana grafana/grafana


3.2、 安装并启动node export



docker run -d --restart=always --name node --net="host" --pid="host" -v "/:/host:ro,rslave"   prom/node-exporter --path.rootfs=/host


3.3、安装并启动prometheus

创建prometheus.yml配置文件，注意当前路径：



vim prometheus.yml



scrape_configs:
  - job_name: monitor
    static_configs:
      - targets: ['192.x.x.x:9100']


注意：

  • job_name：可以理解为当前任务的任务名
  • 192.x.x.x是内网IP地址，需要注意
  • targets是列表，意味着可以在里面监听多个IP和端口：
  • targets: ['192.x.x.x:9100','192.x.x.x:3306','192.x.x.y:6379']

启动容器，注意prometheus.yml的绝对路径：



docker run -it -d -p 9090:9090 --name pro -v /root/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus


3.4、 配置grafana图形界面

 我配置的数据源是普罗米修斯RabbitMQ 监控（六）_docker

 


这短短的一生我们最终都会失去，不妨大胆一点，爱一个人，攀一座山，追一个梦