> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashcat.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitors Alert Engine

> A unified alert engine that integrates various metrics and log data sources for flexible alert rule configuration and threshold evaluation

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

<Tip>
  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.
</Tip>

## Core Capabilities

<CardGroup cols={2}>
  <Card title="Multi-datasource Support" icon="database">
    Support for Prometheus, VictoriaMetrics, Elasticsearch, ClickHouse, and other mainstream data sources
  </Card>

  <Card title="Flexible Alert Rules" icon="sliders">
    Support for threshold alerts, year-over-year alerts, period-over-period alerts, no-data alerts, and more
  </Card>

  <Card title="Distributed Architecture" icon="server">
    Support for multi-datacenter deployment with automatic sharding for high availability
  </Card>

  <Card title="Deep Integration" icon="link">
    Deep integration with On-call, delivering alerts directly to responders
  </Card>
</CardGroup>

## Architecture Design

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

<Steps>
  <Step title="SaaS Server">
    Responsible for managing alert rules, permission control, and alert event aggregation
  </Step>

  <Step title="monitedge Edge Node">
    Deployed within user private networks, syncs alert rules from SaaS, periodically queries data sources, and performs threshold evaluation
  </Step>

  <Step title="Alert Push">
    When edge nodes generate alert events, they push them to the SaaS server for subsequent processing
  </Step>
</Steps>

<Note>
  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.
</Note>

## High Availability Deployment

Monitors supports cluster deployment to ensure high availability of the alert engine:

<AccordionGroup>
  <Accordion title="Single Datacenter Cluster" icon="server">
    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.
  </Accordion>

  <Accordion title="Multi-datacenter Deployment" icon="globe">
    Deploy independent monitedge clusters in different datacenters, each cluster using a different cluster name to process their respective datacenter's data sources.
  </Accordion>

  <Accordion title="Failover" icon="shield">
    If an instance in the cluster fails, other instances will automatically take over its alert rules, ensuring high availability while avoiding duplicate alerts.
  </Accordion>
</AccordionGroup>

## Alert Rule Types

| Type                     | Description                                                          | Use Cases                                        |
| ------------------------ | -------------------------------------------------------------------- | ------------------------------------------------ |
| Threshold alert          | Trigger when metric exceeds/falls below threshold                    | CPU, memory, disk, and other resource monitoring |
| Year-over-year alert     | Trigger when deviation from historical same period exceeds threshold | Business volume, traffic anomaly detection       |
| Period-over-period alert | Trigger when deviation from previous period exceeds threshold        | Spike and drop detection                         |
| No-data alert            | Trigger when metric stops reporting                                  | Service liveness detection                       |
| Composite alert          | Combined condition evaluation                                        | Complex business scenarios                       |

## Supported Data Sources

<CardGroup cols={3}>
  <Card title="Prometheus" icon="fire">
    PromQL query support
  </Card>

  <Card title="VictoriaMetrics" icon="chart-area">
    Prometheus protocol compatible
  </Card>

  <Card title="Elasticsearch" icon="magnifying-glass">
    Log alerting support
  </Card>

  <Card title="ClickHouse" icon="database">
    SQL query support
  </Card>

  <Card title="MySQL" icon="database">
    SQL query support
  </Card>

  <Card title="More..." icon="ellipsis">
    Continuously expanding
  </Card>
</CardGroup>

## Quick Start

<CardGroup cols={2}>
  <Card title="Deployment Guide" icon="rocket" href="/en/monitors/quickstart/quickstart">
    Learn how to deploy monitedge and create your first alert rule
  </Card>

  <Card title="FAQ" icon="circle-question" href="/en/monitors/faq/faq">
    Answers to common questions during usage
  </Card>
</CardGroup>