Architecture
============
.. _target: http://graphite.readthedocs.io/en/latest/render_api.html#target
.. raw:: html
Terminology
-----------
Pattern
^^^^^^^
A Graphite pattern is a single dot-separated metric name,
possibly containing one or more wildcards.
Examples:
.. code-block:: text
server.web*.load
server.web{1,2,3}.load
server.web1.load
Target
^^^^^^
A Graphite target_ is one or more patterns,
possibly combined using Graphite functions.
Examples:
.. code-block:: text
averageSeries(server.web*.load)
Metric
^^^^^^
A metric is a single time-series that is a result
of parsing some Graphite target.
Some targets produce a single metric, for example:
.. code-block:: text
server.web1.load
highestCurrent(server.web*.load)
Some targets produce several metrics, for example:
.. code-block:: text
movingAverage(server.web*.load, 10)
State
^^^^^
Moira stores separate state for every metric. Each metric
can be in only one state at any moment:
.. raw:: html
OK
WARN
ERROR
NODATA
EXCEPTION
Trigger
^^^^^^^
Trigger is a configuration that tells Moira which metrics to watch for.
Triggers consist of:
- Name. This is just for convenience, user can enter anything here.
- Description. Longer text that gets included in notification
to delivery channels that support long texts.
- One or more targets.
- WARN and ERROR value limits, or a Python expression to calculate state.
- One or more tags.
- TTL value. When new data doesn't arrive for TTL seconds, the metric will switch to the `State`_ set by the user.
- Check schedule. For example, a trigger can be set
to check only during business hours.
Last Check
^^^^^^^^^^
When Moira checks a trigger, it stores the following
information on each metric:
- Current value.
- Current timestamp.
- Current state.
Trigger Event
^^^^^^^^^^^^^
When Moira checks a trigger, if any of the metric
states change, Moira generates an event. Events consist of:
- Trigger ID.
- Metric name (as given by parsed target).
- New state.
- Previous state.
- Current timestamp.
Tags
^^^^
Tags are simple string markers for grouping of triggers
and configuring subscriptions.
Subscription
^^^^^^^^^^^^
Moira generates notifications for an event only if trigger tags match any
of the user-created subscriptions. Each subscription consists of:
- One or more tags.
- Contact information.
- Quiet time schedule.
Dataflow
--------
Filter and Check Incoming Metrics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: ../_static/dfd-filter.svg
:alt: filter and checker
:width: 70%
:align: center
When user adds a new trigger, Moira parses patterns from targets and saves them
to ``moira-pattern-list`` key in Redis. Filter rereads this list every second.
When a metric value arrives, Filter checks metric name against the list
of patterns. Matching metrics are saved to ``moira-metric:`` keys
in Redis. Redis pub/sub mechanism is used to inform Checker of incoming metric
value that should be checked as soon as possible.
Checker metrics handler reads triggers by pattern from
``moira-pattern-triggers:`` and add ``trigger_id`` to Redis set
``moira-triggers-to-check``. NODATA Checker adds all triggers to Redis set
``moira-triggers-to-check`` once per ``nodata_check_interval`` setting.
:ref:`remote-triggers-checker` gets all remote trigger ID and adds it to
Redis set ``moira-remote-triggers-to-check`` once per ``remote\check_interval``
setting.
Checker pops ``trigger_id`` from ``moira-triggers-to-check`` and starts
checking procedure. :ref:`remote-triggers-checker` does the same, but pops
``trigger_id`` from ``moira-remote-triggers-to-check`` and starts remote check,
which involve remote Graphite HTTP API.
Trigger target can contain one or multiple metrics, so results are written
per metric. ``moira-metric-last-check:`` Redis key contains last
check JSON with metric states.
When a metric changes its state, a new event is written to
``moira-trigger-events`` Redis key. This happens only if value timestamp
falls inside time period allowed by trigger schedule.
If a metric has been in NODATA or ERROR state for a long period, every 24 hours
Moira will issue an additional reminder event.
Trigger switches to EXCEPTION state, if any exception occurs during
trigger checking.
Process Trigger Events
^^^^^^^^^^^^^^^^^^^^^^
.. image:: ../_static/dfd-notifier-events.svg
:alt: notifier events
:width: 70%
:align: center
Notifier constantly pulls new events from ``moira-trigger-events``
Redis key and schedules notifications according to subscription schedule
and throttling rules. If a trigger contains *all* of the tags in
a subscription, and only in this case, a notification is created for
this subscription.
Subscription schedule delays notifications of occurred event to the
beginning of next allowed time interval. Note that this differs from
trigger schedule, which suppresses event generation entirely.
Throttling rules will delay notifications:
- If there are more than 10 events per hour, a notification will be sent
at most once per 30 minutes.
- If there are more than 20 events per 3 hours, a notification will be sent
at most once per hour.
Scheduled notifications are written to ``moira-notifier-notifications``
Redis key.
Process Notifications
^^^^^^^^^^^^^^^^^^^^^
.. image:: ../_static/dfd-notifier-notifications.svg
:alt: notifier notifications
Notifier constantly pulls scheduled notifications from
``moira-notifier-notifications`` Redis key. It calls sender for certain contact
type and writes notification back to Redis in case of sender error.