Fleio collector

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).

Installing

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. Make sure to enable our repository before trying to install the package, described in our Installing section.

Ubuntu

apt-get install fleio-collector

Centos

yum install fleio-collector

Configuring

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

region =

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 importand because it allows Fleio to know exactly what region each resource is located in when receiving notifications.

control_exchange =

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.

messaging_urls =

The messaging_urls are URLs used by the collector to connect and listend 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

pool =

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.

Alternatives

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 encription for messages sent over the wire using plugin maintained and tested by the RabbitMQ team.