Skip to main content

What is Monitors?

Flashduty Monitors is a unified alert engine that integrates various metrics and log data sources. Based on your configured alert rules, it periodically queries data, performs threshold evaluation, and pushes generated alert events to Flashduty On-Call for aggregation and delivery.
Monitors can replace the alerting capabilities of products like Nightingale, vmalert, and elastalert, deeply integrated with the On-Call product to meet various complex alerting needs.

Core Capabilities

Multi-datasource Support

Support for Prometheus, VictoriaMetrics, Elasticsearch, ClickHouse, and other mainstream data sources

Flexible Alert Rules

Support for threshold alerts, year-over-year alerts, period-over-period alerts, no-data alerts, and more

Distributed Architecture

Support for multi-datacenter deployment with automatic sharding for high availability

Deep Integration

Deep integration with On-Call, delivering alerts directly to responders

Architecture Design

Flashduty is a SaaS service that cannot directly access data sources within user private networks, so Monitors adopts an edge computing architecture:
1

SaaS Server

Responsible for managing alert rules, permission control, and alert event aggregation
2

monitedge Edge Node

Deployed within user private networks, syncs alert rules from SaaS, periodically queries data sources, and performs threshold evaluation
3

Alert Push

When edge nodes generate alert events, they push them to the SaaS server for subsequent processing
If you have multiple datacenters, you can deploy independent monitedge instances in each datacenter, each responsible for alerting on data sources within their respective datacenter.

High Availability Deployment

Monitors supports cluster deployment to ensure high availability of the alert engine:
Deploy multiple monitedge instances in the same datacenter, use the --alerter.clusterName parameter to set the same cluster name, and the system will automatically shard alert rule processing.
Deploy independent monitedge clusters in different datacenters, each cluster using a different cluster name to process their respective datacenter’s data sources.
If an instance in the cluster fails, other instances will automatically take over its alert rules, ensuring high availability while avoiding duplicate alerts.

Alert Rule Types

TypeDescriptionUse Cases
Threshold alertTrigger when metric exceeds/falls below thresholdCPU, memory, disk, and other resource monitoring
Year-over-year alertTrigger when deviation from historical same period exceeds thresholdBusiness volume, traffic anomaly detection
Period-over-period alertTrigger when deviation from previous period exceeds thresholdSpike and drop detection
No-data alertTrigger when metric stops reportingService liveness detection
Composite alertCombined condition evaluationComplex business scenarios

Supported Data Sources

Prometheus

PromQL query support

VictoriaMetrics

Prometheus protocol compatible

Elasticsearch

Log alerting support

ClickHouse

SQL query support

MySQL

SQL query support

More...

Continuously expanding

Quick Start