> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Alert engine management
> Manage alert engine installation, status monitoring, and API Keys to ensure continuous alert detection
The alert engine (`monitedge`) is a core component deployed in your private network. It syncs alert rules from the Flashduty SaaS, reads data from local data sources for anomaly detection, and pushes alert events to the SaaS for further processing.
**Menu Entry**: Alert Engine
The alert engine page contains three tabs: **Alert Engine Status**, **Engine Installation/Upgrade**, and **Engine Disconnection Alert**.
## Alert engine status
Displays information about all registered alert engine instances. The list auto-refreshes every 5 seconds.
| Column | Description |
| ----------------------- | ----------------------------------------------------------------------------------------- |
| **Engine Cluster Name** | Instances with the same name form a cluster that shares alert rule processing |
| **Instance IP** | The IP address where the instance is running |
| **Instance Port** | The port the instance listens on |
| **Last Heartbeat** | The most recent heartbeat time reported to the SaaS, with online/offline status indicator |
| **Instance Version** | The running `monitedge` version |
Engine instances that have not reported a heartbeat for more than 30 seconds are marked as offline (red). Offline instances display a **Delete** button that you can click to clean up stale instance records.
### Cluster data source MD5 check
Multiple engine instances within the same cluster should use the same data source configuration. If the system detects mismatched data source MD5 values across instances in a cluster, a red warning indicator appears before the cluster name, prompting you to check your engine configuration.
## Engine installation/upgrade
Provides one-click generation of install and upgrade commands, supporting three deployment methods.
### Installation configuration
Choose **Linux**, **Docker**, or **Kubernetes**.
When deploying multiple instances in the same datacenter, use the same cluster name to form a high-availability cluster. Use different cluster names for different datacenters.
Typically, each datacenter has its own alert engine cluster. The cluster name is usually set to the datacenter name.
Choose an existing API Key from the dropdown, or click **Manage API Key** to create a new one.
The page automatically generates install and upgrade commands based on your selections. Copy and execute them on the target machine.
### Deployment method comparison
| Deployment Method | Use Case |
| ----------------- | ------------------------------------------------------------------------ |
| **Linux** | Direct installation on physical or virtual machines, managed via systemd |
| **Docker** | Containerized deployment for environments with Docker already set up |
| **Kubernetes** | Cloud-native environments, deployed as a Deployment |
## API Key management
API Keys are used for authentication between the alert engine and the SaaS. You can click **Manage API Key** on the engine installation/upgrade page to open the management panel.
### Features
| Operation | Description |
| ---------- | -------------------------------------------------------------------------------- |
| **Create** | Create a new API Key by entering a name. Each tenant can create up to 5 API Keys |
| **Rename** | Click the Key name to edit and rename it |
| **Delete** | Delete unused API Keys; requires the API Key delete permission |
The management panel also displays the current status of each API Key:
| Status | Description |
| -------------------------- | ---------------------------------------------------------------------------------------------------- |
| **Enabled** (green icon) | The API Key is active; engine instances can use it to communicate with the SaaS |
| **Disabled** (yellow icon) | The API Key has been disabled; engine instances using it will be unable to communicate with the SaaS |
After deleting an API Key, all engine instances using that Key will be unable to communicate with the SaaS. Ensure you have switched related engines to another valid API Key before deletion.
### Permission requirements
* Creating an API Key requires `ApiKeyCreate` permission
* Deleting an API Key requires `ApiKeyDelete` permission
If you lack the required permissions, contact your administrator to grant access on the Access Control page.
## Engine CLI flag reference
The `monitedge` binary is configured via command-line flags. The following flags control how alert events are pushed to the SaaS endpoint.
### Alert push flags
| Flag | Default | Description |
| ---------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `alerter.serverURL` | `https://api.flashcat.cloud` | FlashDuty SaaS endpoint address |
| `alerter.serverAPIKey` | — (required) | API Key used to authenticate with the SaaS |
| `alerter.serverTimeout` | `30s` | Per-request timeout for a single push attempt |
| `alerter.alertRuleDeliveryWorkers` | `64` | Number of delivery workers for ordinary alert rule events. Events are partitioned to per-worker queues by alert key, so events of the same alert are always delivered serially by the same worker |
| `alerter.alertRuleEventQueueSize` | `2048` | Event queue capacity of each delivery worker |
| `alerter.alertRuleEventBatchSize` | `200` | Maximum number of events per delivery batch, at most 200. Queued events are batched and sent once a batch fills up or when no new event arrives |
| `alerter.alertRuleDeliveryResponseBytes` | `8MB` | Maximum response size of the delivery endpoint; a larger response fails the request |
| `alerter.serverSleep` | `3s` | Initial backoff interval after a failed batch delivery; it doubles after each failure, up to 30 seconds |
Firing / repeat / recovery events of ordinary alert rules are sent by the batched delivery service (alertruledelivery) to `POST /monit/api/edge/alert-rule/v1/events` on the SaaS side: events first enter each worker's queue, then are merged into batches of at most 200 events and 4 MB per batch.
**Retry strategy**: Batch delivery uses exponential backoff — the first failure waits `alerter.serverSleep` (default 3 s), then the wait doubles after every failure up to a maximum of 30 s, with no limit on the number of retries, until delivery succeeds or the engine instance shuts down. Compared with the old fixed-interval retry, exponential backoff avoids high-frequency futile retries during brief network congestion.
Earlier versions used `alerter.serverConcurrency` and `alerter.serverRetry` to control concurrent consumption of an in-memory queue (fixed-interval, limited retries). That consumer is no longer started; ordinary alert rule delivery has switched to the batched service above, so these two flags no longer take effect and do not need to be configured.
**Tuning guidance**:
* **High-throughput deployments** (many alert rules, high alert frequency): increase `alerter.alertRuleDeliveryWorkers` (e.g. 128) to reduce event queue backlog; raise `alerter.alertRuleEventQueueSize` as well if needed.
* **Constrained network or CPU**: lower `alerter.alertRuleDeliveryWorkers` (e.g. 16–32) to limit outbound connections and avoid competing with other traffic.
* **High packet-loss or unreliable networks**: consider a larger `alerter.serverSleep` (e.g. 10s) so backoff starts from a longer initial interval, reducing futile requests during congestion.