From c0190a0a5978e0df86b35fd4fabb3d4780e20d00 Mon Sep 17 00:00:00 2001 From: Lingxian Kong Date: Sat, 11 Jan 2020 13:48:48 +1300 Subject: [PATCH] Improve the description of aodh notifiers Change-Id: I322d22a8c3156e63d76e19d525aac2526bdde978 --- doc/source/admin/telemetry-alarms.rst | 57 +++++++++++++-------------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/doc/source/admin/telemetry-alarms.rst b/doc/source/admin/telemetry-alarms.rst index 26435f72a..0df2d0753 100644 --- a/doc/source/admin/telemetry-alarms.rst +++ b/doc/source/admin/telemetry-alarms.rst @@ -96,40 +96,39 @@ of datapoints involved and most recent of these. State transitions are detected by the ``alarm-evaluator``, whereas the ``alarm-notifier`` effects the actual notification action. -**Webhooks** +HTTP/HTTPS action + These are the *de facto* notification type used by Telemetry alarming and + simply involve an HTTP(S) POST request being sent to an endpoint, with a + request body containing a description of the state transition encoded as a + JSON fragment. -These are the *de facto* notification type used by Telemetry alarming -and simply involve an HTTP POST request being sent to an endpoint, -with a request body containing a description of the state transition -encoded as a JSON fragment. +OpenStack Services + The user is able to define an alarm that simply trigger some OpenStack + service by directly specifying the service URL, e.g. + ``trust+http://127.0.0.1:7070/v1/webhooks/ab91ef39-3e4a-4750-a8b8-0271518cd481/invoke``. + ``aodh-notifier`` will prepare ``X-Auth-Token`` header and send HTTP(S) POST + request to that URL, containing the alarm information in the request body. -**Log actions** +Heat Autoscaling + This notifier works together with ``loadbalancer_member_health`` evaluator. + Presumably, the end user defines a Heat template which contains an + autoscaling group and all the members in the group are joined in an Octavia + load balancer in order to expose highly available service to the outside, so + that when the stack scales up or scales down, Heat makes sure the new members + are joining the load balancer automatically and the old members are removed. + However, this notifier deals with the situation that when some member fails, + the Heat stack could be recovered automatically. More information + `here `_ -These are a lightweight alternative to webhooks, whereby the state -transition is simply logged by the ``alarm-notifier``, and are -intended primarily for testing purposes. +Log actions + These are a lightweight alternative to webhooks, whereby the state transition + is simply logged by the ``alarm-notifier``, and are intended primarily for + testing purposes by admin users. -**heat** +If none of the above actions satisfy your requirement, you can implement your +own alarm actions according to the current suppported actions in +``aodh/notifier`` folder. -This notifier works together with ``loadbalancer_member_health`` evaluator. -Presumably, the end user defines a Heat template which contains an autoscaling -group and all the members in the group are joined in an Octavia load balancer -in order to expose highly available service to the outside, so that when the -stack scales up or scales down, Heat makes sure the new members are joining the -load balancer automatically and the old members are removed. However, this -notifier deals with the situation that when some member fails, the Heat stack -could be recovered automatically. - - -Workload partitioning ---------------------- - -The alarm evaluation process can be scaled horizontally but requires -workload partitioning to function correctly. The -`Tooz `_ library provides the -coordination within the groups of service instances. For further -information about this approach, see the `high availability guide -`_. Using alarms ~~~~~~~~~~~~