fleio-collector is an Openstack notifications forwarder based on oslo.messaging. The role of the fleio-collector service is to collect notifications from Openstack services and to centralize them for the Fleio updated service. While updated can connect to multiple brokers and listen to multiple sources of notifications it may be a good idea not to expose the Openstack messaging broker and instead install the fleio-collector and allow it to forward the notifications from each internal network (from each Openstack region).
fleio-collector should be installed in each Openstack region on a server with access to the messaging broker’s network. In this example we will use the RabbitMQ messaging broker.
- A user and password are required, with access to the exchanges and topics used by the Openstack services to send notifications,
which can be created using the rabbitmqctl command line tool.
rabbitmqctl add_user fleio TYPEPASSWORD
After creating the user, install the fleio-collector service.
apt-get install curl software-properties-common apt-transport-https curl https://repos.fleio.com/public.key | apt-key add - add-apt-repository "deb [arch=amd64] https://repos.fleio.com/ubuntu xenial main" apt-get install fleio-collector
apt-get install curl software-properties-common apt-transport-https curl https://repos.fleio.com/public.key | apt-key add - add-apt-repository "deb [arch=amd64] https://repos.fleio.com/ubuntu bionic main" apt-get install fleio-collector
yum install https://repos.fleio.com/rhel/7/fleio-release-1-2.el7.noarch.rpm yum install fleio-collector
The fleio-collector default configuration file is located at: /etc/fleio/fleio_collector.conf This file is parsed using the oslo.config package. The default options are available and commented. If you wish to change a setting, simply uncomment the line (remove the ‘#’ from the beginning of the line).
The [DEFAULT] section
In the [DEFAULT] section, the important configuration is the region. The region should equal the name of the region this collector is installed in (gathering messages from). The region setting is very important because it allows Fleio to know exactly what region each resource is located in when receiving notifications.
The name of the exchange the collector will use/create when listening for notifications. The default name is fleio
The [listener] section
The listener section contains configuration options for the collector’s notifications listener.
The messaging_urls are URLs used by the collector to connect and listen for notifications on the Openstack messaging broker. We can add as many messaging_urls as we need. For example, if we have multiple virtual hosts, for each Openstack service, we would use:
messaging_urls = rabbit://username:password@rabbitmqHost//nova messaging_urls = rabbit://username:password@rabbitmqHost//neutron messaging_urls = rabbit://username:password@rabbitmqHost//glance messaging_urls = rabbit://username:password@rabbitmqHost//cinder
assuming /nova, /neutron, /glance and /cinder are virtual hosts on the messaging broker.
topic = and exchanges =
The exchange and the topic to listen to. In a standard Openstack setup the topic is notifications and the exchanges equals nova, glance, neutron, openstack
The pool settings should be set to a valid name (for example ‘fleio’) if Ceilometer is installed or another service is listening on the same topic as the collector. Setting the pool prevents multiple listeners from loosing notifications.
The [oslo_messaging_notifications] section
In this section we set the notifications dispatcher options. The dispatcher forwards any notifications received, to a central broker where updated can connect to. We will set the topics where notifications are forwarded, the driver (usually ‘messaging’) and the transport_url. The transport_url is a complete URL also containing the username and password. For example:
transport_url = rabbit://user:password@central_rabbit_host:5672/
Additional notifications filters can be setup using python regular expressions to match notifications metadata and content. The filters may help reducing the number of notifications that need to be forwarded and improve performance. We do however recommend to start without filters and add them later, if required.
An alternative to using the fleio-collector service is to use the broker’s specific forwarding implementation. For example RabbitMQ has the Shovel plugin that can be manually setup to forward messages from each broker to a single RabbitMQ server where updated can connect. Advantages here are the possibility of using SSL encryption for messages sent over the wire using plugin maintained and tested by the RabbitMQ team.