"Turn" Ceilometer Project source code Analysis----Ceilometer Project source code structure analysis

Thank you for your friends to support this blog, welcome to discuss the exchange, due to limited capacity and time, mistakes are unavoidable, please correct me!

If reproduced, please retain the author's information.
Blog Address: Http://blog.csdn.net/gaoxingnengjisuan
Email address: [Email protected]

PS: Recently no login blog, many friends of the message did not see, apologize here! Also have is I less on QQ, can mail exchange.

ceilometer Key Concepts
Sample: sampled data is the corresponding value of meter at each acquisition time point;
Statistics : is generally the value of the meter corresponding to a certain period in a statistic (average, and so on);
Resource Span style= "font-family:kaiti_gb2312; font-size:18px; Color: #000000 "> : is a monitored resource object, which can be a virtual machine, a physical machine or a piece of cloud drive;
alarm : is the ceilometer alarm system, can be through the threshold or combination of conditions alarm, and set the alarm triggered when the Action,alarm implementation model, there are two That is, single alarm system and distributed alarm system;
Meter : The measured value of the tracked resource. An instance has a lot of metering values, such as the instance runtime, CPU usage, the number of disk requests, and so on. There are three metering values in Ceilometer:

    Cumulative: Cumulative, increasing over time ( such as disk read and write);
    Gauge: Units of measure, discrete items (such as floating IP, mirrored uploads) and fluctuating values (such as object storage values);
    Delta: Increment, A value that increases over time (such as a change in bandwidth);
Central agent : A service running on the central management node of the OpenStack schema to measure and send monitoring results to the collector;
COMPUTE Agent Span style= "font-family:kaiti_gb2312; font-size:18px; Color: #000000 "> : runs services on compute nodes in the OpenStack schema to measure and send monitoring results to the collector;
API Server : HTTP REST API service for Ceilometer;
Collector : A service running in the OpenStack architecture that monitors notifications sent from other OpenStack components and monitoring agents and stores them in the database;

ceilometer service Components
Need to explain this is for the Icehouse version of the Ceilometer module for source parsing. Depending on the configuration file setup.cfg and/ceilometer/cli.py, the service components running in Ceilometer are as follows:
Ceilometer-api: Ceilometer.cli:api
ceilometer-agent-central: ceilometer.cli:agent_central
Ceilometer-agent-compute: ceilometer.cli:agent_compute
ceilometer-agent-notification: ceilometer.cli:agent_notification
ceilometer-send-sample: ceilometer.cli:send_ Sample
ceilometer-dbsync: ceilometer.cli:storage_dbsync
ceilometer-expirer: ceilometer.cli:storage_expirer
ceilometer-collector: ceilometer.cli:collector_ Service
ceilometer-alarm-evaluator: ceilometer.cli:alarm_evaluator
Ceilometer-alarm-notifier: ceilometer.cli:alarm_notifier

Ceilometer Monitoring data acquisition mechanism
Here is an image from the Internet to illustrate the collection mechanism of ceilometer monitoring data (thanks to its authors):

As can be seen, the implementation of monitoring data collection service components are three, respectively, Ceilometer-agent-central, Ceilometer-agent-compute and Ceilometer-agent-notification. According to my understanding, the monitoring data collection mainly divides into two kinds of situations realization, one is the service component through the correlation module's client or the compute node's hypervisor realization active obtains the correlation module the related monitoring data, One is to obtain useful monitoring data by collecting the notification (notification) information that each module pushes to the oslo-messaging, so that the relevant monitoring data can be collected passively.
The service component of Ceilometer-agent-compute is mainly used to collect the monitoring data of the virtual machine instance on the compute node, and the service component is run on each compute node, and the agent manages a set of pollster plug-ins through stevedore. This information is used to obtain the Cpu,disk io,network io,instance of the virtual machines on the compute nodes, most of which are obtained by invoking the Hypervisor API and require regular poll polling to gather information.
The Ceilometer-agent-central service component runs on the control node by invoking the rest API of the relevant module, by accessing the client of the relevant module, thereby enabling the active collection of the relevant modules (Image,volume,objects, Network) requires periodic poll polling to gather information.
While the Ceilometer-agent-notification service component implements access to the Oslo-messaging,openstack in each module, it pushes notification (notification) information to the Oslo-messaging message framework, Ceilometer-agent-notification Access this Message Queuing service framework to obtain relevant notification information and further convert to the format of sampled data. Obtaining notification information from the Message Queuing service framework and further obtaining sampled data information can be understood as passive access to monitoring data operations and the need to listen to oslo-messaging Message Queuing.
As can be seen, when the monitoring acquisition is completed, the information publishing operation will be performed, there are three implementation options to choose from, namely Rpc/udp/file. Wherein, RPC will publish the relevant message to the message queue, the subsequent collector component service will listen to the corresponding message queue to obtain this data information, UDP will establish a socket to establish an information channel, to send related message data, The subsequent Collector component service will receive the relevant message data through this information channel, and file will save the relevant message data directly to the specified log file.
As can be seen, when the information publishing operation is completed, the Collector Component Service will obtain the relevant message data separately, and implement saving the obtained message data to the data storage system. But the data storage System scheme also supports several implementations, namely LOG/MONGODB/MYSQL/POSTGRESQL/SQLITE/HBASE/DB2 and so on;

Introduction to other service components
Ceilometer-alarm-notifier load and start the Alarmnotifierservice service to implement the notification service triggered by the alarm;
Ceilometer-alarm-evaluator implementation of the load and start the alarm service, Ceilometer implemented in the System alarm service has two kinds, That is, the single alarm system singletonalarmservice and distributed alarm system Partitionedalarmservice, and Ceilometer default application is Singletonalarmservice; for alarm system related content , I will conduct a detailed analysis in another blog post;

I version ceilometer project source code structure
The realization of/ceilometer/alarm alarm system;
/CEILOMETER/API provides rest API services;
The concrete realization of/ceilometer/central ceilometer-agent-central
The concrete realization of/ceilometer/compute Ceilometer-agent-compute
/ceilometer/dispatcher is used to implement saving data to data storage system;
/ceilometer/energy through the KWAPI architecture, the energy consumption related data of the physical machine is obtained.
/ceilometer/event Ceilometer Events
/ceilometer/hardware obtain the relevant monitoring data information of the physical machine hardware;
/ceilometer/image realizes the Glance module through the client access, obtains the related monitoring data information;
/ceilometer/network realizes the neutron module through the client access, obtains the related monitoring data information;
/ceilometer/objectstore implementation of the Swift module through the client access to the relevant monitoring data information;
/ceilometer/openstack universal application Code tool;
/ceilometer/orchestration through the Heat notification information to obtain the relevant monitoring items sampled data information;
/ceilometer/publisher the collection of monitoring data to the implementation of the release;
/ceilometer/storage storage monitoring data to the data storage system implementation;
/ceilometer/transformer Data Conversion
/ceilometer/volume realizes the Cinder module through the client access, obtains the related monitoring data information;
/ceilometer/agent.py Ceilometer through the agent module to polling the virtual machine or the information needed in OpenStack;
/ceilometer/cli.py to realize the start of several service components;
/ceilometer/collector.py to achieve the collection of published monitoring data;
/ceilometer/middleware.py HTTP related plug-in implementation;
/ceilometer/notification.py through the oslo-messaging framework, monitoring the queue of Compute/image/network/heat/cinder and other services to obtain relevant notification information;
/ceilometer/notifier.py according to different plug-ins to implement the specific methods in Instance/image/network/volume/httprequest process_notification, The sampling data information used to obtain the monitoring item from the notification;
/ceilometer/nova_client.py Nova Client;
/ceilometer/pipeline.py Pipeline realization;
/ceilometer/plugin.py plug-in implements the base class;
/ceilometer/sample.py forms the sample format according to the known sampled data;
/ceilometer/service.py service implementation related;
/ceilometer/utils.py some common tools;

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

"Turn" Ceilometer Project source code Analysis----Ceilometer Project source code structure analysis