This series is a summary note of the book "RabbitMQ in Action: Efficient Deployment of Distributed Message Queues".
The previous article summarizes the possible abnormal scenarios and analyzes the availability guarantee provided by RabbitMQ. After the server is down, it can still be serviced normally. In addition, it is necessary to restore the abnormal server as soon as possible, rejoin the cluster, and push unconsumed messages. Through monitoring, errors can be received and processed at the first time.
In addition, we want to actively understand the situation of message accumulation and consumption, as well as the pressure of server nodes. RabbitMQ provides several convenient and intuitive ways to understand, including Web management plug-ins, REST API, rabbitmqadmin scripts.
Through the introduction, you will learn:
- web management plugin
- REST API
- rabbitmqadmin script
- Nagios and monitoring RabbitMQ
web management plugin
The RabbitMQ plugin is written in Erlang and runs in the same Erlang VM as the server. Use the following command to enable the web management plugin:
sudo ./rabbitmq-plugins enable rabbitmq_management
After startup, visit port 15672 to see the main page of the web management page:
Add user
By default, a default user guest is provided, and the password is also guest. The online environment needs to create a new user and delete the guest user.
First switch to the Admin tab, you can view or add users, when adding users, you can specify Tags, which are equivalent to roles, and will have corresponding permissions:
Click the user name of the user list to assign permissions, edit or delete users. When assigning permissions, you can refine it to a topic under a virtual, and separate them according to read, write, and configuration categories:
Manage queues, exchanges, bindings
Switch to the "Exchanges" tab to view and manage exchanges, click the exchange name to view more detailed information, such as exchange bindings, and add new bindings:
Switch to the "Queues" tab, you can view queue information, click the queue name, you can view statistics such as the number and size of messages in all states of the queue:
You can also view consumers and bindings, publish and get messages:
REST API
Sometimes it is necessary to initialize a number of queues and exchanges. Every time a new environment is deployed, it is a bit troublesome to create it step by step. It is easy to implement automated scripts through the REST API.
When the web management plug-in is enabled, not only the WEB UI is obtained, but also a REST-based WEB management API, which can be invoked by any language or script as long as it has an HTTP library.
The interface will return a json string, such as getting all queues:
curl -i -u admin:admin http://localhost:15672/api/queues
Will return a json array, each element is a queue, containing various properties of the queue:
rabbitmqadmin script
In addition, a rabbitmqadmin script is provided to view metadata information and some statistical data. It wraps the REST API, uses a clean interface to interact with it, and the output content is formatted for our convenience.
For example, to view all queues, you can write:
./rabbitmqadmin list queues
will return the following results:
monitor
Monitoring RabbitMQ is not just about making sure port 5672 is open and able to receive TCP connections, but also being able to simulate an AMQP client to make sure the channel gets picked up after the connection, if you can use the REST API to find out if all the components that make up RabbitMQ are functioning properly, and if so. It would be better if they can communicate normally.
The book introduces the use of the Nagios monitoring framework for monitoring. I have not used it before. I have collected some information here and will give a brief introduction.
Nagios
Nagios is an open source monitoring tool that can effectively monitor the status of Windows, Linux and Unix hosts, network settings such as switches, routers, printers, etc. When the system or service status is abnormal, an email or SMS alarm will be sent to notify the website operation and maintenance personnel at the first time, and a normal email or SMS notification will be sent after the status is restored.
It does not include this part of the function itself. All monitoring and detection functions are completed through various plug-ins. After starting Nagios, it will automatically call the plug-in periodically to detect the server status. At the same time, Nagios will maintain a queue, and all plug-ins will return The returned status information enters the queue. Nagios reads the information from the head of the queue every time, and after processing, displays the status results through the web.
Nagios can recognize 4 kinds of status return information:
- 0 (OK) means the status is normal/green;
- 1(WARNING) means warning/yellow;
- 2(CRITICAL) means a very serious error/red;
- 3(UNKNOWN) means unknown error/dark yellow;
Nagios judges the status of the monitoring object according to the value returned by the plug-in, and displays it through the web, so that the administrator can find the fault in time.
How does it manage remote server objects, using the NRPE plug-in, the main process is as follows:
- Nagios executes the check_nrpe plugin installed in it and tells check_nrpe which services to detect;
- Through SSL, check_nrpe connects to the NRPE daemon on the remote machine;
- NRPE runs various local plugins to detect local services and status;
- NRPE sends the detection result to check_nrpe on the host side, and check_nrpe sends the result to the Nagios status queue;
- Nagios reads the information in the queue in turn, and then displays the results;
Monitoring RabbitMQ
The book mentions various aspects of monitoring RabbitMQ, such as: monitoring Rabbit's internal state, confirming that RabbitMQ is available and able to respond, observing queue status to detect consumer exceptions, and detecting undesired configuration changes in the message communication structure.
The basic idea is to write the detection script required by Nagios, use the AMQP client or REST API to obtain the monitoring information of interest, and return different status codes according to the situation.
The specific scripts will not be introduced one by one. Here is an example to monitor whether the persistent configuration of the queue is correct, obtain the queue information through api/queues/<vhost>/<queueName>, and determine whether its durable attribute is true. The script is as follows:
import sys, json, httplib, urllib, base64, socket
# 1.定义状态码
EXIT_OK = 0
EXIT_WARNING = 1
EXIT_CRITICAL = 2
EXIT_UNKNOWN = 3
# 2.解析参数
server, port = sys.argv[1].split(":")
vhost = sys.argv[2]
username = sys.argv[3]
password = sys.argv[4]
queue_name = sys.argv[5]
auto_delete = json.loads(sys.argv[6].lower())
durable = json.loads(sys.argv[7].lower())
# 3.连接服务器
conn = httplib.HTTPConnection(server, port)
# 4.构建api路径
path = "/api/queues/%s/%s" % (urllib.quote(vhost, safe=""),
urllib.quote(queue_name))
method = "GET"
# 5.执行http请求
credentials = base64.b64encode("%s:%s" % (username, password))
try:
conn.request(method, path, "",
{"Content-Type" : "application/json",
"Authorization" : "Basic " + credentials})
# 6.连接异常，退出
except socket.error:
print "UNKNOWN: Could not connect to %s:%s" % (server, port)
exit(EXIT_UNKNOWN)
response = conn.getresponse()
# 7.状态码为404，说明队列不存在，退出
if response.status == 404:
print "CRITICAL: Queue %s does not exist." % queue_name
exit(EXIT_CRITICAL)
# 8.durable属性是否正确
if response["durable"] != durable:
print "WARN: Queue '%s' - durable flag is NOT %s." % \
(queue_name, durable)
exit(EXIT_WARNING)
# 9.返回正常
print "OK: Queue %s configured correctly." % queue_name
exit(EXIT_OK)
The next article will cover RabbitMQ security and performance considerations.
<font color='green'>Welcome to scan the QR code below and follow my personal WeChat account</font> ~
