OpenStack Measurements with a Ceilometer
The author: Ruslan Kiyanchuk
The goal of the OpenStack project is to create an open source cloud computing platform that will meet the requirements of public and private clouds with simple deployment and scalability. Since OpenStack provides infrastructure as a service (IaaS) to end customers, it is important to be able to measure its performance and use for billing, performance evaluation, scalability, and statistics.
Several projects are available for measuring the OpenStack infrastructure :
')
• Zabbix is an open source enterprise distributed solution for network monitoring and applications that can be configured for use with OpenStack.
• Synaps is a cloud monitoring system that is compatible with AWS CloudWatch, designed to collect metrics, provide statistics, track and notify alarm events in the system.
• HP's Healthmon is committed to providing “Cloud Resource Monitor” - an extensible monitoring service for the OpenStack infrastructure.
• StackTach is a debugging and monitoring utility in OpenStack that can work with multiple data centers, including with multi-cell deployments.
• The Ceilometer project is an infrastructure for collecting metrics in the OpenStack cloud, designed to avoid developing multiple solutions with the same functions. The main goal of the project is to monitor and measure, but the capabilities of the framework can be expanded for other needs.
Among these projects, the most promising and rapidly developing is the Ceilometer , which is well suited for measuring the OpenStack infrastructure. The project went out of the incubation stage and became part of OpenStack. In meteorology, a ceilometer (in English - ceilometer) is a device that uses a laser or other light source to determine the height of the lower boundary of the clouds. Thus, the Ceilometer project is the basis for monitoring and measuring the OpenStack cloud. Also, the project can be expanded for other needs.
The main targets of the Ceilometer project are as follows [1] :
• Efficient collection of metrics with optimal use of processor and network resources.
• Collect data by tracking notifications from services or by polling the infrastructure.
• Configure the type of data collected to meet various operational requirements.
• Accessing measurement data and adding it using the REST API.
• Expansion of infrastructure for collecting custom metrics with additional plug-ins.
• Receive signed and irrefutable messages with measurement results.
To fulfill these requirements, the following architecture was implemented in the Grizzly release:
The API server provides access to metrics in the database through the REST API.
The central agent (central agent) polls data on the utilization of resources that are not associated with virtual machines or compute nodes. Only one instance of the central agent can be started in the infrastructure.
The compute agent polls the measurement data and statistics from the compute nodes (mainly the hypervisor). Computing agents must be running on every compute node that needs to be monitored.
The collector keeps track of message queues (for notifications sent by the infrastructure, and for measurement results from agents). Notifications are processed, converted into measurement data, then signed and returned to the message bus in the appropriate topic. The collector can work on one or several management servers.
A data store is a database that can handle simultaneous writing (from one or more collectors) and reading data (from an API server). The collector, the central agent and the API can work on any node.
These services are communicated using the standard OpenStack messaging bus. Only the collector and the API server have access to the data store. SQL databases compatible with SQLAlchemy are supported, as well as MongoDB and HBase; however, Ceilometer developers recommend MongoDB due to the efficient handling of simultaneous read / write operations. In addition, only the Ceilometer configuration with MongoDB has been thoroughly tested and deployed in commercial environments. For the Ceilometer database, it is recommended to use a dedicated node, since the infrastructure can create a large number of records in the database [2] . According to developers, infrastructure measurement at the commercial level involves up to 386 records per second and 33,360,480 events per day, which will require up to 239 GB to store statistics per month.
With the development of the OpenStack project to the commercial level, there is a need for new functionality for its successful use as a cloud provider: a billing system, usage statistics, automatic scaling, benchmarking, tools for diagnosing and correcting errors. After running several projects to satisfy data requirements it became apparent that most of their implementations have the overall functionality of monitoring and measuring infrastructure.
To eliminate fragmentation and duplication of functionality, it is planned to integrate related projects in order to provide other services with a single monitoring and measurement interface.
The Healthmon project was decided to integrate into the Ceilometer because of the same purpose (infrastructure dimension), although the data model and measurement mechanisms differed. [4] . For the release of OpenStack Havana, the Healthmon and Ceilometer integration project was created and approved. Also, the Synaps and StackTach projects have unique functionality that integrates into the Ceilometer as additional features. The main reason for the preservation of the Ceilometer project and the integration of other solutions into it is not so much in the large list of opportunities, as in the modularity and clear definition of the functional task. Most other similar projects have implemented limited measurement functionality and some additional focused features. In turn, Ceilometer provides a full-featured measurement service and an API for accessing the data obtained, on the basis of which you can build any other functionality, be it billing, autoscaling, or performance monitoring.
The cloud application management project, OpenStack Heat , also plans to modify its server-side (back-end) processing of measurements and notifications to work with the API Ceilometer, which will allow autoscaling [3] . The integration process includes the development of an API for notifications and the ability to send sample measurements via REST requests to the Ceilometer, as well as processing Heat to enable modular measurement logic.
The integration will expand the Ceilometer interface with additional functions and plug-ins, which will lead to the following changes in the architecture [5] :
Most of the work on the integration and implementation of additional features are planned for the release of OpenStack Havana . The main implementation plan includes covering most of the measurement and monitoring functionalities, as well as providing the possibility of building other services (command line interface, graphical interface, visualization, alarm function execution, etc.) around the API Ceilometer.
Three types of measurements are implemented in the Ceilometer project:
• Cumulative (cumulative): increase over time (for example, the lifetime of a virtual machine)
• Gauge (indicator): discrete events (for example, floating IP addresses or loading images) and changing values ​​(such as disk I / O)
• Delta : change over time (for example, network bandwidth)
Each meter collects data from one or more samples (collected from a message queue or agents), which are represented by counters. Each counter has the following fields:
- counter_name
Counter ID string. By convention, the delimiter is '.' used to move from the least specific word to the most specific (for example, disk.ephemeral.size).
- counter_type
One of the types of counters described above (cumulative, indicator, delta).
- counter_volume
The amount of measured data (CPU cycles, the number of bytes transmitted over the network, the deployment time of the virtual machine, etc.). This field is not relevant for indicator type meters; in this case, it should be assigned a default value (usually: 1).
- counter_unit
Description of the unit of measure of the counter. For designation, SI units of measure and their approved abbreviations are used. The amount of information must be expressed in bits ('b') or bytes ('B'). When a measurement is not a quantity of data, the description must always contain exact information about what is being measured (virtual machines, images, floating IP addresses, etc.).
- resource_id
The identifier of the measured resource (virtual machine UUID, network, image, etc.).
- project_id
ID of the project that owns the resource.
- user_id
The ID of the user who owns the resource.
- resource_metadata
Some additional metadata from the content of the measurement message.
A complete list of currently available measurements can be found in the OpenStack Ceilometer documentation [6] .
Due to the active development of Ceilometer and its integration with other projects, many additional features are planned for the release of OpenStack Havana. The Ceilometer functionality (implemented or planned for the next release) is described below [7] .
The implementation of this function allows you to send measurement data using the Ceilometer REST API v2 interface. The list of sent counters should be defined in JSON format and sent as a POST request to the URL address http: // <metering_host>: 8777 / v2 / meters / <meter_id> (the name of the counter corresponds to the meter ID). For example:
[
{
"Counter_name": "instance",
"Counter_type": "gauge",
"Counter_unit": "instance",
"Counter_volume": "1",
"Resource_id": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36",
"Project_id": "35b17138-b364-4e6a-a131-8f3099c5be68",
"User_id": "efd87807-12d2-4b38-9c70-5f5c2ac427ff",
"Resource_metadata": {
"Name1": "value1",
"Name2": "value2"
}
}
]
This allows third-party programs to easily send measurement data to a Ceilometer.
Notifications allow you to track the status of the counter and report after it reaches the threshold value. This functionality will allow you to build many features based on the Ceilometer, such as autoscaling, diagnostics and error correction, and many other actions in the infrastructure. A corresponding notification interface implementation plan has been approved with high priority and is scheduled for Havana release.
The Ceilometer API will be extended to provide additional functionality that is required for billing engines, for example:
• Maximum use of the resource lasting more than 1 hour;
• Resource usage statistics over time;
• Providing additional statistics (standard deviation, median, variance, distribution, etc.).
The corresponding plan is approved and scheduled for release Havana-2.
The Ceilometer project will be supplemented with a network bandwidth calculation using Quantum. The Quantum bandwidth measurement plan is approved with a medium priority for the release of Havana-3.
Ceilometer will track physical devices in the OpenStack infrastructure, including physical servers running Glance, Cinder, Quantum, Swift, computing nodes and Nova controllers, as well as network devices used in the OpenStack environment (switches, firewalls). The physical device monitoring plan has been approved for the release of Havana-2 and its implementation is already at the code verification stage.
The Ceilometer project involves simple expansion and customization with an individual fit for each installation. The system of plug-ins based on entry points to the configuration tools provides the ability to add new monitors to the collector or subagents for polling. A plugin system based on setuptools entry points provides the ability to add new monitors to the collector or polling agents.
There are two types of plug-ins: pollsters and listeners. Listeners process notifications created and queued by OpenStack components to create corresponding counter objects. Questionnaires are used for selective polling of infrastructure by metrics, notifications for which are not placed in the message queue by OpenStack components. All plugins are configured in the setup.cfg file in the [entry_points] section. For example, to enable custom plugins located in the ceilometer / plugins directory and defined as the classes MyCustomListener and MyCustomPollster, you need to configure the setup.cfg file as follows:
[entry_points]
ceilometer.collector =
custom_listener = ceilometer.plugins: MyCustomListener
...
ceilometer.poll.central =
custom_pollster = ceilometer.plugins: MyCustomPollster
...
The purpose of plug-in questionnaires is to obtain the necessary measurement results from the cloud infrastructure and create from them objects-counters. The central agent plugins are defined in the ceilometer.poll.central entry points of setup.cfg, and for computing agents in the ceilometer.poll.compute namespace. Listener plugins are loaded from the ceilometer.collector section.
The heart of the system is the collector, which tracks the message bus for data provided by questionnaires, as well as notifications from other OpenStack components, such as Nova, Glance, Quantum and Swift.
A typical listener plug-in class should have several methods for receiving specific notifications from the message queue and creating counters from them. The get_event_types () method should return a list of strings containing event types in which the plugin is interested. These events are transmitted to the plugin each time a notification is received. The notification_to_metadata () method is responsible for handling notifications and creating metadata that will be included in measurement messages, access to which will be provided through the Ceilometer API. The process_notification () method determines the logic for creating a counter based on data from received notifications. This method can also return an empty list if no suitable measurement data was found in the current notification. Counters are created by the ceilometer.counter.Counter () constructor, which takes the values ​​of the required counter fields (see Dimensions in the Ceilometer). Meters provided by Ceilometer by default are also implemented as plugins and can be used as auxiliary information for creating additional plugins.
Ceilometer is a promising project designed to provide extensive measurement and monitoring capabilities for cloud infrastructure, implementing the functionality that is necessary for commercial use of OpenStack. Although there are already cases of commercial application of the Ceilometer (CloudWatch, AT & T, Dreamhost [5] ), by October 2013 many changes and additional functions will be added to the project. Thus, the Ceilometer project should be much more adapted to commercial use with the release of Havana, which is planned for the implementation of major changes and new functionality.
Original article in English
The goal of the OpenStack project is to create an open source cloud computing platform that will meet the requirements of public and private clouds with simple deployment and scalability. Since OpenStack provides infrastructure as a service (IaaS) to end customers, it is important to be able to measure its performance and use for billing, performance evaluation, scalability, and statistics.
Several projects are available for measuring the OpenStack infrastructure :
')
• Zabbix is an open source enterprise distributed solution for network monitoring and applications that can be configured for use with OpenStack.
• Synaps is a cloud monitoring system that is compatible with AWS CloudWatch, designed to collect metrics, provide statistics, track and notify alarm events in the system.
• HP's Healthmon is committed to providing “Cloud Resource Monitor” - an extensible monitoring service for the OpenStack infrastructure.
• StackTach is a debugging and monitoring utility in OpenStack that can work with multiple data centers, including with multi-cell deployments.
• The Ceilometer project is an infrastructure for collecting metrics in the OpenStack cloud, designed to avoid developing multiple solutions with the same functions. The main goal of the project is to monitor and measure, but the capabilities of the framework can be expanded for other needs.
Among these projects, the most promising and rapidly developing is the Ceilometer , which is well suited for measuring the OpenStack infrastructure. The project went out of the incubation stage and became part of OpenStack. In meteorology, a ceilometer (in English - ceilometer) is a device that uses a laser or other light source to determine the height of the lower boundary of the clouds. Thus, the Ceilometer project is the basis for monitoring and measuring the OpenStack cloud. Also, the project can be expanded for other needs.
Architecture of the project OpenStack Ceilometer
The main targets of the Ceilometer project are as follows [1] :
• Efficient collection of metrics with optimal use of processor and network resources.
• Collect data by tracking notifications from services or by polling the infrastructure.
• Configure the type of data collected to meet various operational requirements.
• Accessing measurement data and adding it using the REST API.
• Expansion of infrastructure for collecting custom metrics with additional plug-ins.
• Receive signed and irrefutable messages with measurement results.
To fulfill these requirements, the following architecture was implemented in the Grizzly release:
The API server provides access to metrics in the database through the REST API.
The central agent (central agent) polls data on the utilization of resources that are not associated with virtual machines or compute nodes. Only one instance of the central agent can be started in the infrastructure.
The compute agent polls the measurement data and statistics from the compute nodes (mainly the hypervisor). Computing agents must be running on every compute node that needs to be monitored.
The collector keeps track of message queues (for notifications sent by the infrastructure, and for measurement results from agents). Notifications are processed, converted into measurement data, then signed and returned to the message bus in the appropriate topic. The collector can work on one or several management servers.
A data store is a database that can handle simultaneous writing (from one or more collectors) and reading data (from an API server). The collector, the central agent and the API can work on any node.
These services are communicated using the standard OpenStack messaging bus. Only the collector and the API server have access to the data store. SQL databases compatible with SQLAlchemy are supported, as well as MongoDB and HBase; however, Ceilometer developers recommend MongoDB due to the efficient handling of simultaneous read / write operations. In addition, only the Ceilometer configuration with MongoDB has been thoroughly tested and deployed in commercial environments. For the Ceilometer database, it is recommended to use a dedicated node, since the infrastructure can create a large number of records in the database [2] . According to developers, infrastructure measurement at the commercial level involves up to 386 records per second and 33,360,480 events per day, which will require up to 239 GB to store statistics per month.
Integration of related projects in Ceilometer
With the development of the OpenStack project to the commercial level, there is a need for new functionality for its successful use as a cloud provider: a billing system, usage statistics, automatic scaling, benchmarking, tools for diagnosing and correcting errors. After running several projects to satisfy data requirements it became apparent that most of their implementations have the overall functionality of monitoring and measuring infrastructure.
To eliminate fragmentation and duplication of functionality, it is planned to integrate related projects in order to provide other services with a single monitoring and measurement interface.
The Healthmon project was decided to integrate into the Ceilometer because of the same purpose (infrastructure dimension), although the data model and measurement mechanisms differed. [4] . For the release of OpenStack Havana, the Healthmon and Ceilometer integration project was created and approved. Also, the Synaps and StackTach projects have unique functionality that integrates into the Ceilometer as additional features. The main reason for the preservation of the Ceilometer project and the integration of other solutions into it is not so much in the large list of opportunities, as in the modularity and clear definition of the functional task. Most other similar projects have implemented limited measurement functionality and some additional focused features. In turn, Ceilometer provides a full-featured measurement service and an API for accessing the data obtained, on the basis of which you can build any other functionality, be it billing, autoscaling, or performance monitoring.
The cloud application management project, OpenStack Heat , also plans to modify its server-side (back-end) processing of measurements and notifications to work with the API Ceilometer, which will allow autoscaling [3] . The integration process includes the development of an API for notifications and the ability to send sample measurements via REST requests to the Ceilometer, as well as processing Heat to enable modular measurement logic.
The integration will expand the Ceilometer interface with additional functions and plug-ins, which will lead to the following changes in the architecture [5] :
Most of the work on the integration and implementation of additional features are planned for the release of OpenStack Havana . The main implementation plan includes covering most of the measurement and monitoring functionalities, as well as providing the possibility of building other services (command line interface, graphical interface, visualization, alarm function execution, etc.) around the API Ceilometer.
Measurements in Ceilometer
Three types of measurements are implemented in the Ceilometer project:
• Cumulative (cumulative): increase over time (for example, the lifetime of a virtual machine)
• Gauge (indicator): discrete events (for example, floating IP addresses or loading images) and changing values ​​(such as disk I / O)
• Delta : change over time (for example, network bandwidth)
Each meter collects data from one or more samples (collected from a message queue or agents), which are represented by counters. Each counter has the following fields:
- counter_name
Counter ID string. By convention, the delimiter is '.' used to move from the least specific word to the most specific (for example, disk.ephemeral.size).
- counter_type
One of the types of counters described above (cumulative, indicator, delta).
- counter_volume
The amount of measured data (CPU cycles, the number of bytes transmitted over the network, the deployment time of the virtual machine, etc.). This field is not relevant for indicator type meters; in this case, it should be assigned a default value (usually: 1).
- counter_unit
Description of the unit of measure of the counter. For designation, SI units of measure and their approved abbreviations are used. The amount of information must be expressed in bits ('b') or bytes ('B'). When a measurement is not a quantity of data, the description must always contain exact information about what is being measured (virtual machines, images, floating IP addresses, etc.).
- resource_id
The identifier of the measured resource (virtual machine UUID, network, image, etc.).
- project_id
ID of the project that owns the resource.
- user_id
The ID of the user who owns the resource.
- resource_metadata
Some additional metadata from the content of the measurement message.
A complete list of currently available measurements can be found in the OpenStack Ceilometer documentation [6] .
Ceilometer functionality
Due to the active development of Ceilometer and its integration with other projects, many additional features are planned for the release of OpenStack Havana. The Ceilometer functionality (implemented or planned for the next release) is described below [7] .
Sending measurement samples using the REST API
The implementation of this function allows you to send measurement data using the Ceilometer REST API v2 interface. The list of sent counters should be defined in JSON format and sent as a POST request to the URL address http: // <metering_host>: 8777 / v2 / meters / <meter_id> (the name of the counter corresponds to the meter ID). For example:
[
{
"Counter_name": "instance",
"Counter_type": "gauge",
"Counter_unit": "instance",
"Counter_volume": "1",
"Resource_id": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36",
"Project_id": "35b17138-b364-4e6a-a131-8f3099c5be68",
"User_id": "efd87807-12d2-4b38-9c70-5f5c2ac427ff",
"Resource_metadata": {
"Name1": "value1",
"Name2": "value2"
}
}
]
This allows third-party programs to easily send measurement data to a Ceilometer.
Ceilometer notification interface
Notifications allow you to track the status of the counter and report after it reaches the threshold value. This functionality will allow you to build many features based on the Ceilometer, such as autoscaling, diagnostics and error correction, and many other actions in the infrastructure. A corresponding notification interface implementation plan has been approved with high priority and is scheduled for Havana release.
Ceilometer interface extension
The Ceilometer API will be extended to provide additional functionality that is required for billing engines, for example:
• Maximum use of the resource lasting more than 1 hour;
• Resource usage statistics over time;
• Providing additional statistics (standard deviation, median, variance, distribution, etc.).
The corresponding plan is approved and scheduled for release Havana-2.
Bandwidth Measurement in Quantum
The Ceilometer project will be supplemented with a network bandwidth calculation using Quantum. The Quantum bandwidth measurement plan is approved with a medium priority for the release of Havana-3.
Physical device monitoring
Ceilometer will track physical devices in the OpenStack infrastructure, including physical servers running Glance, Cinder, Quantum, Swift, computing nodes and Nova controllers, as well as network devices used in the OpenStack environment (switches, firewalls). The physical device monitoring plan has been approved for the release of Havana-2 and its implementation is already at the code verification stage.
Extending Ceilometer features
The Ceilometer project involves simple expansion and customization with an individual fit for each installation. The system of plug-ins based on entry points to the configuration tools provides the ability to add new monitors to the collector or subagents for polling. A plugin system based on setuptools entry points provides the ability to add new monitors to the collector or polling agents.
There are two types of plug-ins: pollsters and listeners. Listeners process notifications created and queued by OpenStack components to create corresponding counter objects. Questionnaires are used for selective polling of infrastructure by metrics, notifications for which are not placed in the message queue by OpenStack components. All plugins are configured in the setup.cfg file in the [entry_points] section. For example, to enable custom plugins located in the ceilometer / plugins directory and defined as the classes MyCustomListener and MyCustomPollster, you need to configure the setup.cfg file as follows:
[entry_points]
ceilometer.collector =
custom_listener = ceilometer.plugins: MyCustomListener
...
ceilometer.poll.central =
custom_pollster = ceilometer.plugins: MyCustomPollster
...
The purpose of plug-in questionnaires is to obtain the necessary measurement results from the cloud infrastructure and create from them objects-counters. The central agent plugins are defined in the ceilometer.poll.central entry points of setup.cfg, and for computing agents in the ceilometer.poll.compute namespace. Listener plugins are loaded from the ceilometer.collector section.
The heart of the system is the collector, which tracks the message bus for data provided by questionnaires, as well as notifications from other OpenStack components, such as Nova, Glance, Quantum and Swift.
A typical listener plug-in class should have several methods for receiving specific notifications from the message queue and creating counters from them. The get_event_types () method should return a list of strings containing event types in which the plugin is interested. These events are transmitted to the plugin each time a notification is received. The notification_to_metadata () method is responsible for handling notifications and creating metadata that will be included in measurement messages, access to which will be provided through the Ceilometer API. The process_notification () method determines the logic for creating a counter based on data from received notifications. This method can also return an empty list if no suitable measurement data was found in the current notification. Counters are created by the ceilometer.counter.Counter () constructor, which takes the values ​​of the required counter fields (see Dimensions in the Ceilometer). Meters provided by Ceilometer by default are also implemented as plugins and can be used as auxiliary information for creating additional plugins.
Conclusion
Ceilometer is a promising project designed to provide extensive measurement and monitoring capabilities for cloud infrastructure, implementing the functionality that is necessary for commercial use of OpenStack. Although there are already cases of commercial application of the Ceilometer (CloudWatch, AT & T, Dreamhost [5] ), by October 2013 many changes and additional functions will be added to the project. Thus, the Ceilometer project should be much more adapted to commercial use with the release of Havana, which is planned for the implementation of major changes and new functionality.
Original article in English
Source: https://habr.com/ru/post/189012/
All Articles