# 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 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:

1. 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. log: mostly useful for debugging, stores alarms in a log file.

3. zaqar: Send notification to messaging service via Zaqar API.

## Alarm Rules

### composite

Composite alarm rule.

A simple dict type to preset composite rule.

### event

Alarm Event Rule.

Describe when to trigger the alarm based on an event

### gnocchi_aggregation_by_metrics_threshold

Base class Alarm Rule extension and wsme.types.

### gnocchi_aggregation_by_resources_threshold

Base class Alarm Rule extension and wsme.types.

### gnocchi_resources_threshold

Base class Alarm Rule extension and wsme.types.

### loadbalancer_member_health

Base class Alarm Rule extension and wsme.types.

### prometheus

Base class Alarm Rule extension and wsme.types.

## Alarm Evaluators

### composite

Base class for alarm rule evaluator plugins.

### gnocchi_aggregation_by_metrics_threshold

Base class for alarm rule evaluator plugins.

### gnocchi_aggregation_by_resources_threshold

Base class for alarm rule evaluator plugins.

### gnocchi_resources_threshold

Base class for alarm rule evaluator plugins.

### loadbalancer_member_health

Base class for alarm rule evaluator plugins.

### prometheus

Base class for alarm rule evaluator plugins.

## Alarm Notifiers

### http

Rest alarm notifier.

### https

Rest alarm notifier.

### log

Log alarm notifier.

### test

Test alarm notifier.

### trust+heat

Heat autohealing notifier.

The auto-healing 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 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 stack could be recovered by marking the given autoscaling group member unhealthy, then update Heat stack in place. In order to do that, the notifier needs to know:

- Heat top/root stack ID.

- Heat autoscaling group ID.

- The failed Octavia pool members.

### trust+http

Notifier supporting keystone trust authentication.

This alarm notifier is intended to be used to call an endpoint using keystone authentication. It uses the aodh service user to authenticate using the trust ID provided.

The URL must be in the form `trust+http://host/action`.

### trust+https

Notifier supporting keystone trust authentication.

This alarm notifier is intended to be used to call an endpoint using keystone authentication. It uses the aodh service user to authenticate using the trust ID provided.

The URL must be in the form `trust+http://host/action`.

### trust+zaqar

Zaqar notifier using a Keystone trust to post to user-defined queues.

The URL must be in the form `trust+zaqar://?queue_name=example`.

### zaqar

Zaqar notifier.

This notifier posts alarm notifications either to a Zaqar subscription or to an existing Zaqar queue with a pre-signed URL.

To create a new subscription in the service project, use a notification URL of the form:

    zaqar://?topic=example&subscriber=mailto%3A//test%40example.com&ttl=3600

Multiple subscribers are allowed. `ttl` is the time to live of the subscription. The queue will be created automatically, in the service project, with a name based on the topic and the alarm ID.

To use a pre-signed URL for an existing queue, use a notification URL with the scheme `zaqar://` and the pre-signing data from Zaqar in the query string:

    zaqar://?queue_name=example&project_id=foo&
             paths=/messages&methods=POST&expires=1970-01-01T00:00Z&
             signature=abcdefg

## Alarm Storage

### log

Log the data.

### mysql

Put the data into a SQLAlchemy database.

### mysql+pymysql

Put the data into a SQLAlchemy database.

### postgresql

Put the data into a SQLAlchemy database.

### sqlite

Put the data into a SQLAlchemy database.

this page last updated: 2026-08-15 16:35:58

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug