a597136e8a
Turn on the flag in setup.cfg. Fix some formatting issues with a couple of docstrings. Fix some mistakes in the rst files. Suppress warnings from Sphinx extensions that used to be suppressed by pbr with older versions of Sphinx. Change-Id: I549292b5e22cf8ae0f54f878793a36f2cd3b8e6c Signed-off-by: Doug Hellmann <doug@doughellmann.com>
1.9 KiB
System Architecture
High-Level Architecture
Each of Aodh's services are designed to scale horizontally. Additional workers and nodes can be added depending on the expected load. It provides daemons to evaluate and notify based on defined alarming rules.
Evaluating the data
Alarming Service
The alarming component of Aodh, first delivered in Ceilometer service
during Havana development cycle then split out to this independent
project in Liberty development cycle, allows you to set alarms based on
threshold evaluation for a collection of samples or a dedicate event. An
alarm can be set on a single meter, or on a combination. For example,
you may want to trigger an alarm when the memory consumption reaches 70%
on a given instance if the instance has been up for more than 10 min. To
setup an alarm, you will call Aodh's API server <alarms-api> specifying the
alarm conditions and an action to take.
Of course, if you are not administrator of the cloud itself, you can only set alarms on meters for your own components.
There can be multiple form of actions, but only several actions have been implemented so far:
HTTP callback: you provide a URL to be called whenever the alarm has been set off. The payload of the request contains all the details of why the alarm was triggered.log: mostly useful for debugging, stores alarms in a log file.zaqar: Send notification to messaging service via Zaqar API.
Alarm Rules
aodh.alarm.rule
Alarm Evaluators
aodh.evaluator
Alarm Notifiers
aodh.notifier
Alarm Storage
aodh.storage