update document
Change-Id: Ie40b2e04e59d4763f1eeef46feb5081ecefc24f2
This commit is contained in:
parent
b3a03e56c2
commit
073a15af50
@ -5,12 +5,6 @@
|
||||
=====================
|
||||
|
||||
.. index::
|
||||
single: agent; architecture
|
||||
double: compute agent; architecture
|
||||
double: collector; architecture
|
||||
double: data store; architecture
|
||||
double: database; architecture
|
||||
double: API; architecture
|
||||
|
||||
High-Level Architecture
|
||||
=======================
|
||||
@ -25,32 +19,27 @@ Evaluating the data
|
||||
Alarming Service
|
||||
----------------
|
||||
|
||||
The alarming component of Aodh, first delivered in the Havana
|
||||
version, allows you to set alarms based on threshold evaluation for a
|
||||
collection of samples. 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
|
||||
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
|
||||
:ref:`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 two have been implemented so far:
|
||||
There can be multiple form of actions, but only several actions have been
|
||||
implemented so far:
|
||||
|
||||
1. :term:`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.
|
||||
2. :term:`log`: mostly useful for debugging, stores alarms in a log file.
|
||||
|
||||
For more details on this, we recommend that you read the blog post by
|
||||
Mehdi Abaakouk `Autoscaling with Heat and Ceilometer`_. Particular attention
|
||||
should be given to the section "Some notes about deploying alarming" as the
|
||||
database setup (using a separate database from the one used for metering)
|
||||
will be critical in all cases of production deployment.
|
||||
|
||||
.. _Autoscaling with Heat and Ceilometer: http://techs.enovance.com/5991/autoscaling-with-heat-and-ceilometer
|
||||
3. :term:`zaqar`: Send notification to messaging service via Zaqar API.
|
||||
|
||||
Alarm Rules
|
||||
===========
|
||||
|
@ -41,6 +41,12 @@
|
||||
Logging is one of the alarm actions that is useful mostly for debugging,
|
||||
it stores the alarms in a log file.
|
||||
|
||||
zaqar
|
||||
According to `Zaqar Developer Documentation`_:
|
||||
|
||||
Zaqar is a multi-tenant cloud messaging and notification service for web
|
||||
and mobile developers.
|
||||
|
||||
project
|
||||
The OpenStack tenant or project.
|
||||
|
||||
@ -51,3 +57,4 @@
|
||||
An OpenStack user.
|
||||
|
||||
.. [#] http://en.wikipedia.org/wiki/Ceilometer
|
||||
.. _Zaqar Developer Documentation: http://docs.openstack.org/developer/zaqar/
|
||||
|
@ -35,11 +35,7 @@ run through tox_.
|
||||
$ sudo yum install mongodb
|
||||
$ sudo yum install mariadb-devel.x86_64
|
||||
|
||||
3. Install the test dependencies::
|
||||
|
||||
$ sudo pip install -e /opt/stack/aodh[test]
|
||||
|
||||
4. Run the unit and code-style tests::
|
||||
3. Run the unit and code-style tests::
|
||||
|
||||
$ cd /opt/stack/aodh
|
||||
$ tox -e py27,pep8
|
||||
@ -62,16 +58,16 @@ run through tox_.
|
||||
For reference, the ``debug`` tox environment implements the instructions
|
||||
here: https://wiki.openstack.org/wiki/Testr#Debugging_.28pdb.29_Tests
|
||||
|
||||
5. There is a growing suite of tests which use a tool called `gabbi`_ to
|
||||
4. There is a growing suite of tests which use a tool called `gabbi`_ to
|
||||
test and validate the behavior of the Aodh API. These tests are run
|
||||
when using the usual ``py27`` tox target but if desired they can be run by
|
||||
themselves::
|
||||
when using the usual ``functional`` tox target but if desired they can be
|
||||
run by themselves::
|
||||
|
||||
$ tox -e gabbi
|
||||
|
||||
The YAML files used to drive the gabbi tests can be found in
|
||||
``aodh/tests/gabbi/gabbits``. If you are adding to or adjusting the
|
||||
API you should consider adding tests here.
|
||||
``aodh/tests/functional/gabbi/gabbits``. If you are adding to or adjusting
|
||||
the API you should consider adding tests here.
|
||||
|
||||
.. _gabbi: https://gabbi.readthedocs.org/
|
||||
|
||||
|
@ -9,7 +9,7 @@
|
||||
|
||||
You can get API version list via request to endpoint root path. For example::
|
||||
|
||||
curl -H "X-AUTH-TOKEN: fa2ec18631f94039a5b9a8b4fe8f56ad" http://127.0.0.1:8777
|
||||
curl -H "X-AUTH-TOKEN: fa2ec18631f94039a5b9a8b4fe8f56ad" http://127.0.0.1:8042
|
||||
|
||||
Sample response::
|
||||
|
||||
@ -20,7 +20,7 @@ Sample response::
|
||||
"id": "v2",
|
||||
"links": [
|
||||
{
|
||||
"href": "http://127.0.0.1:8777/v2",
|
||||
"href": "http://127.0.0.1:8042/v2",
|
||||
"rel": "self"
|
||||
},
|
||||
{
|
||||
|
Loading…
Reference in New Issue
Block a user