update document

Change-Id: Ie40b2e04e59d4763f1eeef46feb5081ecefc24f2
This commit is contained in:
ZhiQiang Fan 2016-04-22 06:55:01 +08:00
parent b3a03e56c2
commit 073a15af50
4 changed files with 25 additions and 33 deletions

View File

@ -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
===========

View File

@ -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/

View File

@ -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/

View File

@ -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"
},
{