Remove Unused erchef Queue from Chef Server Analytics Vhost

Sean Horn -

The presence of the erchef queue on the Chef Server means that there was a pretty ancient version of Analytics working against this Chef Server at one time. No big deal. What happens is that that erchef queue eats many/all the messages that should be landing in the alaska queue, which is the new location where the Chef Server produces all actions. The Analytics alaska processes come in later on and consume any messages found on the same queue.

Here are instructions for cleanup. If you are on a 12.3.0 or higher Chef Server system, you already have the rabbit management interface installed and running

Here are steps for the complete cleanup of the /analytics/erchef queue

Commands used

sudo PATH=/opt/opscode/embedded/bin:$PATH /opt/opscode/embedded/bin/rabbitmqctl list_queues -p /analytics
sudo PATH=/opt/opscode/embedded/bin:$PATH /opt/opscode/embedded/bin/rabbitmqctl list_consumers -p /analytics
sudo PATH=/opt/opscode/embedded/bin:$PATH /opt/opscode/embedded/service/rabbitmq/sbin/rabbitmq-plugins enable rabbitmq_management

* Login to chef server and install the rabbitmq_management plugin if running on less than Chef Server 12.3.0

sudo PATH=/opt/opscode/embedded/bin:$PATH /opt/opscode/embedded/service/rabbitmq/sbin/rabbitmq-plugins enable rabbitmq_management

* If installed rabbitmqmgt, restart rabbitmq

chef-server-ctl restart rabbitmq

* Connect to the newly installed rabbitmq web interface

The credentials for the webui are rabbitmgmt  <the password found in /etc/opscode/private-chef-secrets.json under the rabbitmq key. It will look like this `    "management_password": "c3b72565962cff3848b0a41fa091b4035799c5dc11cafacc176ab7d3d176f29729a1560a18ae67bd8df38aaa21d233bde9bb"`>

For Chef Server 11.3.x


For Chef Server 12.x


* Configure the interface to allow guest user access to the
/analytics vhost. By default the guest user is an administrator,
but doesn't have explicit access to the /analytics vhost, so we
need to set it.

The steps are the same for EC11x and Chef Server 12x, but on Chef Server 12x Rabbitmq interface, there is an Admin link at the top. The user list is inside that link. On EC11x, there is a Users link at the top with the same user list inside the link.

Users -> guest bold link -> Select /analytics Virtual Host dropdown, click Set Permission button.

Click Queues link at top and select Virtual Host: /analytics dropdown item.
You should see alaska and erchef queues in a system that has been in-place upgraded from EC 11x and previously had an Analytics 1.0.x system running against it.

Select the erchef queue's bolded link, scroll to the bottom of the page and delete the erchef queue using the Delete button.

If on a Chef Server 12 system, cap the Chef Server queues with this as root

rabbitmqctl set_policy -p /analytics max_length '(erchef|alaska|notifier.notifications|notifier_config)' '{"max-length":10000}' --apply-to queues

Cannot cap queues until rabbitmq 3.1.0
Chef Server 12.0.8 ships with Rabbitmq 3.3.x

* Restart analytics server with

opscode-analytics-ctl restart

* Check on the status of the queues/exchange back on the chef server.

List_consumers should show the analytics alaska service consuming the
/analytics/alaska queue after it has restarted and come back up.

rabbitmqctl list_exchanges -p /analytics
rabbitmqctl list_queues -p /analytics
rabbitmqctl list_consumers -p /analytics

If the Analytics system has restarted and been able to process a message, you should see a consumer like

[root@centos-6 ca]# rabbitmqctl list_consumers -p /analytics
Listing consumers ...
alaska <rabbit@localhost.2.2320.0> amq.ctag-JPowOFrfiwELKlnokBwMzg true 1 []

You may need to go all out and do both of these, on the Chef Server
and Analytics server respectively. You are trying to ensure that the
consumer of the alaska queue shows up, as shown above with the
rabbitmq list_consumers ... command.

chef-server-ctl restart rabbitmq
opscode-analytics-ctl restart
Have more questions? Submit a request


Powered by Zendesk