Telemetry Service in openstack
Telemetry Service in openstack
Telemetry service is used in openstack for metering rate of resources used by each service and generating bills for corresponding usage. We can interact openstack via API or from command line. In the initial stage openstack development gave less importance to telemetry service. After development of heat service the telemetry service transforms into a Giant CPU Eater and also difficulty in time series data storage which leads to evolution. Now, many developers are working on telemetry project and the project was divided into three, Aodh,Ceilometer and Gnocchi. Currently telemetry service also supports Kafka driver for better performance.
Purpose of Telemetry service on openstack
There are three types purpose mostly mentioned
- Metering:Is the process that collects information about the usage that has been converted into bills.
- Rating: To convert a billed value into equivalent currency value.
- Billing:Generate Bills to each customer and start the payment procedure.
Components of Ceilometer
- Polling Agent:To poll openstack services and build meters.
- Notification Agent:Listen the notification message and convert to events and samples.
- Collector: Collect the events and samples created by Polling and Notification Agents.
- Data Store: Store the events and samples(mysql, mongodb, Gnocchi dispatcher storage in swift or ceph)
- API Server: Service to view records stored by collector service.
Types of Data
Two types of data stored in the database:
- Event: This data, including the start of an instance, volume attach to an instance, stop an instance etc.
- Metric: This data, including including CPU usage, memory usage, data transfer etc.
There are three types of database backend used for storage:
- SQL: Early release mysql database used for storage.
- Mongo DB: Currently we use no-sql Mongo DB used for storage, because of heavy load on mysql.
- Ceph or Swift: These types of storage used for backend, when gnocchi dispatcher used instead of Rest API.
Telemetry project Includes three projects
Due to the complexity of telemetry service, there are project evolve from it.
Aodh project is for alarm code handling. Now, It is a standalone project independent from ceilometer and gnocchi project. Aodh project forked original alarm feature of ceilometer. Alarm feature of Ceilometer is deprecated after liberty release and completely removed in Mitaka release. Aodh uses Ceilometer or gnocchi as a backend storage. Each aodh service can scale horizontally based on the load. We can trigger alarm based on our custom rules. This useful with autoscaling service such as heat.
The above diagram shows how Aodh service work, it has used to trigger some predefined jobs. The external system can access Aodh service through API’s.
Ceilometer project is for monitoring and collecting data regarding to resource usage in the cloud infrastructure. Previously, ceilometer used mysql as for backend storage. Now, mongodb and gnocchi backend done this job.
Ceilometer has three parts, a polling agent, a notification agent and a collector. Polling agent polls each service in the openstack infra and Notification agent was listening on the message queue for collecting the notification generated by different service or external systems and convert these notifications into samples and metric and published via multiple pipeline. Collector agent collects the samples and metric generated by polling, notification agents and record on backend storage.
We can access ceilometer data through appropriate API calls. Currently, two API (REST and Gnocchi) calls supported. But we can use any one of them.Normally we have used RabbitMQ deployed as AMQP publisher. Currently ceilometer support kafka driver for external purpose.
After the introduction of heat service(OpenStack Orchestration program). We can create a server cluster using heat templates. At the same time telemetry service collects samples and metric from each server. This will cause huge CPU consumption and difficult to gather time series data, because of large alarm create during each heat template, execute, so we cannot record in a timely manner.
The Second problem is scalability, on previous ceilometer infra we cannot store data on a scalable file system such as ceph, sheepdog etc. In large infra database is largely consumed by metric data(CPU usage, network usage etc.). Scalability of current available database up to certain limit only. This leads to the introduction of another project in telemetry service known as Gnocchi (Metric data as a service)
Above shows how access data from gnocchi backend. We have used the gnocchi API to access metric data. When gnocchi API calls first get the index from DB then search metric data on gnocchi backend. Gnocchi fulfills the need of a time series database in cloud computing. It provides ability to store large amount of metric data in a scalable manner. Another feature it doesn’t calculate anything, the only thing done by gnocchi is writing the metric date in a time series manner. This avoids the CPU overhead and calculation done by applications that accessing Gnocchi database.
Posted January 18, 2016 by Jossy Watson