openstack
/
openstack-manuals
Code Issues Proposed changes

Limit alarm actions 

Cloud administrator can limit each alarm's maximum actions
for three states, and disables normal user to create
log:// and test:// to avoid bad things happen.

Change-Id: I8a6a49d66c0c51555cec705e4d43c819ede3dc35
Closes-Bug: 1442580
This commit is contained in:
thorking 2015-07-28 15:55:26 +08:00 committed by Christian Berendt
parent 4339790d4f
commit 5f11a18c4f
2 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/admin-guide-cloud-rst/source/telemetry-alarms.rst
View File

@ -145,6 +145,11 @@ though it could alternatively be a webhook URL.
.. note::
Alarm names must be unique for the alarms associated with an
individual project.
The cloud administrator can limit the maximum resulting actions
for three different states, and the ability for a normal user to
create ``log://`` and ``test://`` notifiers is disabled. This prevents
unintentional consumption of disk and memory resources by the
Telemetry service.
The sliding time window over which the alarm is evaluated is 30
minutes in this example. This window is not clamped to wall-clock

5
doc/admin-guide-cloud/telemetry/section_telemetry-alarms.xml
View File

@ -109,6 +109,11 @@
<para>This creates an alarm that will fire when the average CPU utilization for an individual instance exceeds 70% for three consecutive 10 minute periods. The notification in this case is simply a log message, though it could alternatively be a webhook URL.</para>
<note>
<para>Alarm names must be unique for the alarms associated with an individual project.</para>
<para>The cloud administrator can limit the maximum resulting actions
for three different states, and the ability for a normal user to
create <literal>log://</literal> and <literal>test://</literal>
notifiers is disabled. This prevents unintentional consumption of
disk and memory resources by the Telemetry service.</para>
</note>
<para>The sliding time window over which the alarm is evaluated is 30 minutes in this example. This window is not clamped to wall-clock time boundaries, rather it's anchored on the current time for each evaluation cycle, and continually creeps forward as each evaluation cycle rolls around (by default, this occurs every minute).</para>
<para>The period length is set to 600s in this case to reflect the out-of-the-box default cadence for collection of the associated meter. This period matching illustrates an important general principal to keep in mind for alarms:</para>