OpenStack Ceilometer Telemetry Service & Telemetry Data Collection Services

In continuation of our series of previous blogs on the components of the OpenStack, today we are going to look at the next component of OpenStack that is: “Telemetry (Ceilometer)”. We are also going to look at Telemetry Data Collection Services.

So let’s look at what Ceilometer is?

Telemetry (Ceilometer):

It is easy to guess from the name itself, in simple words we can say that Ceilometer is nothing but a telemetry service which helps in collecting, normalizing and transforming the data which is produced by the other OpenStack services.

Telemetry Alarming service which is also referred to as “Aodh” is used by Ceilometer for activating an alarm. Once you initiate Ceilometer, the telemetry alarming service also activates automatically.

Gnocchi time series database service is used by Ceilometer, therefore, it is suggested that the Gnocchi service should be activated and configured whenever you activate Ceilometer.

Enter the following command for activating the Ceilometer service:

$ kollacli property set enable_ceilometer yes

Once you execute the above command, then it’s time to set up passwords for the users of Ceilometer.

Warning:

This step of setting up passwords for the users of the Ceilometer is performed only for the earlier installation of a Ceilometer service. And once it is done, verify the /etc/kola/password.yml file, to confirm whether the passwords are defined already by the Ceilometer service.

$ kollacli password set ceilometer_database_password

$ kollacli password set ceilometer_keystone_password

Thus you are made to enter the password and then confirm the password. You will not see the password because the password value will not be displayed on the screen. Otherwise, you can use the following command for generating secure and random passwords:

Kollacli password init Command:

$ kollacli password init password_name

After that, you are required to set all the empty passwords as well as all the SSH keys.

Information about the Gnocchi Metric Service and how is it used for setting up the Gnocchi Service:

Gnocchi Metric Service:

As discussed earlier Gnocchi Metric service is used for setting up Gnocchi service and Gnocchi is nothing but a time series database service. Ceilometer uses Gnocchi as a chosen time series storage database.

As we already know that for enabling the Gnocchi service, enter the following command:

$ kollacli property set enable_gnocchi yes

And then set the passwords for all the users of Gnocchi.

Warning:

As discussed earlier, perform this step for setting up the passwords for all the users of Gnocchi only for an earlier installment of a Ceilometer service. Then verify whether the service has already defined the passwords, in the /etc/kolla /password.yml file.

$ kollacli password set gnocchi_database_password

$ kollacli password set gnocchi_keystone_password

As done before, enter and confirm all the passwords and the value of the password will not be displayed on the screen.

As above enter the following command for generating secure and random password:

$ kollacli password init password_name

Now up to here you can figure out that the steps were almost similar, nowhere onwards there are 3 new concepts or you can say three back ends are used by Gnocchi for storing data:

These three back ends are as follows:

1. The Incoming driver or the incoming measures
2. The storage drivers or the Time series aggregates
3. The indexer driver or the data indexing

Now, let’s see what each of these back ends is:

1. Incoming driver or the incoming measures:

With the help of gnocchi_incomig_storage property, by default, a similar value as the storage driver is set to the incoming driver or the incoming measures.

2. The Storage Driver or the time series aggregates:

Either a file system or Ceph which is recommended for the storage backend which is set up with the gnocchi_backend_storage property is used by Gnocchi.

For the Gnocchi storage driver, the file system present on the controller node is used by default. With the help of gnocchi_file_default_volume property and standard to / var /lib/gnocchi can be used for setting the name to the file system directory.

An NSF share may also be used for allowing shared storage, in case if you are using the file system for the storage driver or the time series aggregates. For setting up an NFS shared location use the gnocchi_nfs_share property for the storage driver or the time series aggregates.

With the help of a comma-separated list, the gnocchi_nfs_mount_options property supports you to set up the NFS mount options. For instance:

$ kollacli property set gnocchi_nfs_share 203.0.113.150:/nfs

$ kollacli property set gnocchi_nfs_mount_options nfsvers=4

The use of an NFS share for the storage drive or for the time series aggregates authorizes for much better scaling but at the same time it is unable to offer higher availability and for providing higher availability for the storage driver or the time series aggregates, it is recommended that you must use Ceph. When Ceph is activated, Gnocchi is set to use Ceph automatically as a storage driver backend.

3. Indexer driver or the data indexing:

The indexer driver or the indexing the data saves the archive policies, metrics, and also the index of all the resources inside the MySQL database which is automatically installed in the cluster.

Up to here, we have seen what Ceilometer is and setting up Gnocchi service with the help of Gnocchi Metric Service.

Now let’s move on to next topic,

• Which are Telemetry Data Collection Service and its functions:

Functions provided by the Telemetry Data Collection service are as follows:

• Metering data associated with the OpenStack services is effectively counted.
• Notifications sent from services are monitored for collecting actions and recording data.
• This collected data is published to different targets containing data stores and the message queues.

Following components are present in the Telemetry service:

• A central agent (seilometer_agent_central):

A central agent runs on a central management server to collect resource utilization statistics for resources which are not bound to compute nodes. For starting to scale the service flatly, more than one agent can be used.

• A compute agent (ceilometer-agent-compute):

A compute agent runs on every compute node and collects resource utilization statistics. Currently, our focus is on creating compute agent even though in future there can be different types of agents.

• A collector (ceilometer-collector):

A collector works on central management server/s and transmits the telemetry data which is collected to a data store or an outside consumer without any modification.

• A notification agent (ceilometer-agent-notification):

A notification agent works on central management server/s and uses messages from the queue of messages for building event and metering data.

• An API server (ceilometer-api):

An API server works on multiple central management servers for allowing data access from the data store.

• What Telemetry Alarming service is and its components:

Telemetry Alarming Services:

As discussed earlier, the telemetry alarming services are used for activating or triggering the alarms when the event data tries to break the precise rules.

Following components are present in the Telemetry service:

• An API server (aodh-api):

An API server works on multiple central management servers for providing access to the information about alarm which is saved in a data store.

• An alarm evaluator (aodh-evaluator):

An alarm evaluator works on multiple central management servers for determining when the alarms fire because of the associated statistic trend intercrossing inception over a crawling time window.

• A notification listener (aodh-listner):

A notification listener works on a central management server and decides when to fire alarms. These alarms are created on the basis of precise rules opposite events that are collected by the Telemetry data collection services notification agents.

• An alarm notifier (aodh-notifier):

An alarm notifier works on multiple central management servers for allowing alarms to set up on the basis of borderline evaluation for the samples that are collected.

With the help of OpenStack messaging bus, alarm notifier services communicate. Access to the data store is only to collect data and the API server.

Information about OpenStack Telemetry (Ceilometer):

As discussed earlier, the OpenStack Telemetry (Ceilometer) supplies statistics and the metering because telemetry is efficient in gathering the metering data, with regard to the costs of CPU and network. Ceilometer can set up metering throughout all the latest core components of the OpenStack.

1.            Meter:

It is a type of measurements, which can be thought of as a measure for KPI.

How to List all the available Meters:

For revoking list of all the known meters considers the following example:

List<? extends Meter> meters = os.telemetry ().meters ().list ();

2.            Sample:

A unique numeric data point is represented by a sample; it also handles a meter which showcases the changes in those values along the time. After that, the Samples are used for compute statistics that supply an abstract of the average, min, max and counts.

How to List Samples for Meters:

For obtaining the list of all the recent sample data you should supply the name of the meter which you want to question for. Consider the following example:

List<? extends Sample> samples = os.telemetry ().meters ().samples (“cpu_util”);

3.            Statistics:

On the basis of the samples, the statistics are calculated. The statistics can be calculated versus all the recent samples for that specific meter, time range and also grouping.

How to list all computed Statistics for a Meter:

For instance, the following example will show the query for all the samples and can calculate the statistics opposite them for the particular meter:

List<? extends Statistics> stats = os.telemetry ().meters ().statistics (“cpu_util”);

How to get computed Statistics for a Meter based on a Time Period:

For getting a computation on the basis of a query that you can transfer in a specific period i.e. in seconds. Consider the following example:

List<? extends Statistics> stats = os.telemetry ().meters ().statistics (“cpu_util”, 320);

Summary:

Today we saw information about OpenStack Telemetry Ceilometer component and also about the Telemetry data collection and its components. I hope you find this information helpful. Please do not forget to leave a comment in the comment section below. Thank you for reading the blog! See you soon with another interesting blog!

Also read:-