Skip to main content
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.
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

1

Select deployment method

Choose Linux, Docker, or Kubernetes.
2

Set engine cluster name

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

Select API Key

Choose an existing API Key from the dropdown, or click Manage API Key to create a new one.
4

Copy and execute commands

The page automatically generates install and upgrade commands based on your selections. Copy and execute them on the target machine.

​
Deployment method comparison

​
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

The management panel also displays the current status of each API Key:
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

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.