List plugins:
rabbitmq-plugins
Start running the web administration site:
rabbitmq-plugins enable rabbitmq_management
Then restart RabbitMQ, and open the URL: http://localhost:15672/
The default credentials are guest and guest.
You can change the number of available file descriptors limit set by PAM.
Get the current settings for soft and hard limits:
su - rabbitmq -s /bin/sh -c "ulimit -Sn" su - rabbitmq -s /bin/sh -c "ulimit -Hn"
In this example, we'll quadruple the amount. Edit /etc/security/limits.conf and then restart RabbitMQ.
rabbitmq soft nofile 1048576 rabbitmq hard nofile 1048576
RabbitMQ's documentation recommends 4096 for development and at least 65536 for production environments.
RabbitMQ uses rabbitmqctl to do log rotation, so that logrotate is not needed. The third option is the suffix to be used.
rabbitmqctl rotate_logs .1
RabbitMQ will automatically append its data to the end of the existing log.
A simple cron job that rotates the logs at midnight, and splits it up into daily logs:
0 0 * * * /usr/sbin/rabbitmqctl rotate_logs -`date +%F`
A cluster can be created with more than one node. You will first create one instance which will act as the primary node, and then additional ones after that. Any time that a node is added to a running cluster, it will remove all the data currently in the primary node.
One thing that is interesting and may be different to the user, is that RabbitMQ does not contain the settings for the cluster a config file. The cluster itself keeps track of who the nodes are, so there are no special settings that need to be added in /etc/rabbitmq/rabbitmq.config.
In this example, there will be two nodes only. A primary node which will start as normal using the default configuration, and then a secondary node which will be added to the first, therefore creating a cluster.
The server hostnames used here are rabbitmq1 and rabbitmq2.
First of all, start rabbitmq as normal on both of the nodes.
/etc/init.d/rabbitmq start
When a node is first started, RabbitMQ will create unique cookie (or identifier) for that node at /var/lib/rabbitmq/.erlang.cookie. For the two nodes to join together, the cookie must be the same on all nodes.
RabbitMQ will generate one itself on first startup, or it can be set manually to another value if wanted.
One gotcha to be aware of is that the default cookie set will have no end-of-line for the string. Adding a new line will change the hash. In this case, it may be simpler to just create your own erlang cookie before starting the primary node.
The permissions are also set to read-only for the rabbitmq user.
In this example, I use pwgen to create a random password as well:
pwgen 8 1 | tee /var/lib/rabbitmq/.erlang.cookie chmod 0600 /var/lib/rabbitmq/.erlang.cookie chown rabbitmq: /var/lib/rabbitmq/.erlang.cookie
At this point, the primary node is up and running, the cookie exists, and it is ready to have a second node joined to it to create a cluster.
On the second node, the RabbitMQ service is already running as normal, from when we started it earlier. Now, we need to tell rabbitmq to stop the application – not the service – so that we can join it to the primary node.
Stop the app on the second node:
rabbitmqctl stop_app
Next, edit the /var/lib/rabbitmq/.erlang.cookie value on the secondary node as well.
Join the secondary node to the first, creating the cluster. This will flush the data on the primary node as well:
rabbitmqctl join_cluster rabbit@rabbitmq1
Clustering node 'rabbit@rabbitmq2' with 'rabbit@rabbitmq1' ... ...done.
Finally, start the app again using rabbitmqctl on the second node:
rabbitmqctl start_app
You can check the status of the cluster as well:
rabbitmqctl cluster_status
Cluster status of node 'rabbit@rabbitmq2' ...
[{nodes,[{disc,['rabbit@rabbitmq1','rabbit@rabbitmq2']}]},
{running_nodes,['rabbit@rabbitmq1','rabbit@rabbitmq2']},
{partitions,[]}]
...done.