![Akihiro Motoki](/assets/img/avatar_default.png)
Part of "consistency-file-rename" spec [1] This commit also changes the following: * Update corresponding references to common in various guides * Rename excluded_patterns in conf.py of various guide * Rename existing entries in www/static/.htaccess * Add entries to .htaccess to redirect renamed files [1] http://specs.openstack.org/openstack/docs-specs/specs/newton/consistency-file-rename.html Change-Id: I39a9d5b95535cad1918ee64e95dee5ef18ab2cbe
2.6 KiB
Telemetry service overview
Telemetry Data Collection service
The Telemetry Data Collection services provide the following functions:
- Efficiently polls metering data related to OpenStack services.
- Collects event and metering data by monitoring notifications sent from services.
- Publishes collected data to various targets including data stores and message queues.
The Telemetry service consists of the following components:
- A compute agent (
ceilometer-agent-compute
) -
Runs on each compute node and polls for resource utilization statistics. There may be other types of agents in the future, but for now our focus is creating the compute agent.
- A central agent (
ceilometer-agent-central
) -
Runs on a central management server to poll for resource utilization statistics for resources not tied to instances or compute nodes. Multiple agents can be started to scale service horizontally.
- A notification agent
(
ceilometer-agent-notification
) -
Runs on a central management server(s) and consumes messages from the message queue(s) to build event and metering data.
- A collector (
ceilometer-collector
) -
Runs on central management server(s) and dispatches collected telemetry data to a data store or external consumer without modification.
- An API server (
ceilometer-api
) -
Runs on one or more central management servers to provide data access from the data store.
Telemetry Alarming service
The Telemetry Alarming services trigger alarms when the collected metering or event data break the defined rules.
The Telemetry Alarming service consists of the following components:
- An API server (
aodh-api
) -
Runs on one or more central management servers to provide access to the alarm information stored in the data store.
- An alarm evaluator (
aodh-evaluator
) -
Runs on one or more central management servers to determine when alarms fire due to the associated statistic trend crossing a threshold over a sliding time window.
- A notification listener (
aodh-listener
) -
Runs on a central management server and determines when to fire alarms. The alarms are generated based on defined rules against events, which are captured by the Telemetry Data Collection service's notification agents.
- An alarm notifier (
aodh-notifier
) -
Runs on one or more central management servers to allow alarms to be set based on the threshold evaluation for a collection of samples.
These services communicate by using the OpenStack messaging bus. Only the collector and API server have access to the data store.