The Thresholding Service maintains the state of the performance metrics and generates alarms from these when thresholds are triggered (armed) or cleared (unarmed). The service listens for and compares performance metrics after they are persisted to the time-series database. The state of the thresholds are held in memory and pushed to persistent storage only when they are changed.
Distributed thresholding with Sentinel
Thresholding for streaming telemetry with telemetryd is supported on Sentinel when using Newts. When running on Sentinel, the thresholding state can be stored in either Cassandra or PostgreSQL. Given that Newts already requires Cassandra, we recommend using Cassandra to minimize the load on PostgreSQL.
Thresholding on Sentinel uses the same configuration files as Meridian and operates similarly. When a thresholding changes to/from trigger or cleared, an event is published which is processed by Meridian and the alarm is created or updated.