RabbitMQ的使用中常常会出现队列积压等问题，这时就需要监控connection、channel、queue等状态。
RabbitMQ包含了监控插件，通过命令rabbitmq-plugins enable rabbitmq_management可以启用，通过15672端口可以访问。
在浏览器中可以直接使用界面交互，很容易看到各种属性的状况，一般使用guest/guest登录即可：
如果我们想在程序中集成mq监控，则可以使用Rabbitmq的API获取各个属性的数据。
在参考链接中有java的实现代码。
附Rabbitmq的说明：
RabbitMQ Management HTTP API
Introduction
Apart from this help page, all URIs will serve only resources of type
application/json
, and will require HTTP basic authentication (using the standard RabbitMQ user database). The default user is guest/guest.
Many URIs require the name of a virtual host as part of the path, since names only uniquely identify objects within a virtual host. As the default virtual host is called "
/
", this will need to be encoded as "
%2f
".
PUTing a resource creates it. The JSON object you upload must have certain mandatory keys (documented below) and may have optional keys. Other keys are ignored. Missing mandatory keys constitute an error.
Since bindings do not have names or IDs in AMQP we synthesise one based on all its properties. Since predicting this name is hard in the general case, you can also create bindings by POSTing to a factory URI. See the example below.
Many URIs return lists. Such URIs can have the query string parameters
sort
and
sort_reverse
added.
sort
allows you to select a primary field to sort by, and
sort_reverse
will reverse the sort order if set to
true
. The
sort
parameter can contain subfields separated by dots. This allows you to sort by a nested component of the listed items; it does not allow you to sort by more than one field. See the example below.
You can also restrict what information is returned per item with the
columns
parameter. This is a comma-separated list of subfields separated by dots. See the example below.
Examples
A few quick examples for Windows and Unix, using the command line tool
curl
:
- Get a list of vhosts:
:: Windows
C:\> curl -i -u guest:guest http://localhost:15672/api/vhosts
# Unix
$ curl -i -u guest:guest http://localhost:15672/api/vhosts
HTTP/1.1 200 OK
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Mon, 16 Sep 2013 12:00:02 GMT
Content-Type: application/json
Content-Length: 30
[{"name":"/","tracing":false}] - Get a list of channels, fast publishers first, restricting the info items we get back:
:: Windows
C:\> curl -i -u guest:guest "http://localhost:15672/api/channels?sort=message_stats.publish_details.rate&sort_reverse=true&columns=name,message_stats.publish_details.rate,message_stats.deliver_get_details.rate"
# Unix
$ curl -i -u guest:guest 'http://localhost:15672/api/channels?sort=message_stats.publish_details.rate&sort_reverse=true&columns=name,message_stats.publish_details.rate,message_stats.deliver_get_details.rate'
HTTP/1.1 200 OK
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Mon, 16 Sep 2013 12:01:17 GMT
Content-Type: application/json
Content-Length: 219
Cache-Control: no-cache
[{"message_stats":{"publish_details":{"rate" ... (remainder elided) - Create a new vhost:
:: Windows
C:\> curl -i -u guest:guest -H "content-type:application/json" ^
-XPUT http://localhost:15672/api/vhosts/foo
# Unix
$ curl -i -u guest:guest -H "content-type:application/json" \
-XPUT http://localhost:15672/api/vhosts/foo
HTTP/1.1 204 No Content
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Mon, 16 Sep 2013 12:03:00 GMT
Content-Type: application/json
Content-Length: 0
Note: you must specify application/json as the mime type.
Note: the name of the object is not needed in the JSON object uploaded, since it is in the URI. As a virtual host has no properties apart from its name, this means you do not need to specify a body at all! - Create a new exchange in the default virtual host:
:: Windows
C:\> curl -i -u guest:guest -H "content-type:application/json" ^
-XPUT -d"{""type"":""direct"",""durable"":true}" ^
http://localhost:15672/api/exchanges/%2f/my-new-exchange
# Unix
$ curl -i -u guest:guest -H "content-type:application/json" \
-XPUT -d'{"type":"direct","durable":true}' \
http://localhost:15672/api/exchanges/%2f/my-new-exchange
HTTP/1.1 204 No Content
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Mon, 16 Sep 2013 12:04:00 GMT
Content-Type: application/json
Content-Length: 0
Note: we never return a body in response to a PUT or DELETE, unless it fails. - And delete it again:
:: Windows
C:\> curl -i -u guest:guest -H "content-type:application/json" ^
-XDELETE http://localhost:15672/api/exchanges/%2f/my-new-exchange
# Unix
$ curl -i -u guest:guest -H "content-type:application/json" \
-XDELETE http://localhost:15672/api/exchanges/%2f/my-new-exchange
HTTP/1.1 204 No Content
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Mon, 16 Sep 2013 12:05:30 GMT
Content-Type: application/json
Content-Length: 0
Reference
|
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 and parameters. Everything apart from messages. POST to upload an existing set of definitions. Note that:
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:
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.
| |||
|
X
|
/api/vhosts/
vhost
/connections
|
A list of all open connections in a specific vhost.
| |||
|
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.
| |||
|
X
|
/api/vhosts/
vhost
/channels
|
A list of all open channels in a specific vhost.
| |||
|
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.
| |||
|
X
|
/api/exchanges/
vhost
|
A list of all exchanges in a given virtual host.
| |||
|
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.
| |||
|
X
|
/api/queues/
vhost
|
A list of all queues in a given virtual host.
| |||
|
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,"requeue":true,"encoding":"auto","truncate":50000}
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 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/users
|
A list of all users.
| |||
|
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
must be set. 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
.
| |
|
X
|
/api/users/
user
/permissions
|
A list of all permissions for a given user.
| |||
|
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/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/aliveness-test/
vhost
|
Declares a test queue, then publishes and consumes a message. Intended for use by monitoring tools. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
Note: the test queue will not be deleted (to to prevent queue churn if this is repeatedly pinged).
| |||
|
X
|
/api/healthchecks/node
|
Runs basic healthchecks in the current node. Checks that the rabbit application is running, channels and queues can be listed successfully, and that no alarms are in effect. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
If something fails, will return HTTP status 200 with the body of
{"status":"failed","reason":"string"}
| |||
|
X
|
/api/healthchecks/node/
node
|
Runs basic healthchecks in the given node. Checks that the rabbit application is running, list_channels and list_queues return, and that no alarms are raised. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
If something fails, will return HTTP status 200 with the body of
{"status":"failed","reason":"string"}
|
参考链接：
https://my.oschina.net/lzhaoqiang/blog/549921
http://www.cnblogs.com/yespon/p/5579389.html
https://www.rabbitmq.com/management.html
https://blog.csdn.net/cloudmq/article/details/54633769
1953
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
