To experience Monitors features, there are three core steps:
Install monitedge
Deploy the alert engine to your private network
Create Data Source
Configure the data sources to monitor
Create Alert Rules
Define alert conditions and notification methods
Install monitedge
monitedge needs to be deployed in your private network. It is responsible for syncing alert rules from SaaS, periodically querying data sources, performing threshold evaluation, generating alert events, and pushing them to the SaaS.
Menu Entry: Alert Engine → Engine Installation/Upgrade
Supports Linux, Docker, and Kubernetes installation methods.
Engine Cluster Name is very important: monitedge instances with the same name form a cluster, sharing the workload of processing alert rules to avoid single points of failure.
- Single cluster: Keep the default
default
- Multiple clusters (e.g., one in US-East datacenter, one in South China datacenter): Specify different names for each cluster
Alert Engine Status
After monitedge is installed, it automatically connects to the SaaS and periodically syncs alert rules. You can view current status information on the Alert Engine Status page.
Engine instances without heartbeat for a long time will display a delete button, which you can click to remove and avoid engine disconnection alerts.
Engine Disconnection Alert
monitedge downtime has significant impact, so engine disconnection alerts are provided.
For an engine cluster composed of multiple instances, as long as at least one instance in the cluster is alive, the engine disconnection alert will not trigger.
Create Data Source
Menu Entry: Data Sources → New
| Config Item | Description |
|---|
| Associated Alert Engine | Specify which alert engine cluster performs data queries and alert evaluation for this data source; typically select a cluster in the same datacenter |
| Data Source Connection URL | The address for monitedge to connect to; must be an internal address accessible by monitedge |
Create Alert Rules
Menu Entry: Alert Rules
There may be many alert rules. Monitors provides a tree-structured grouping for categorized management. Each alert rule must belong to a group. You can create groups first, then create alert rules under the groups.
Basic Configuration
| Config Item | Description |
|---|
| Rule Name | Name of the alert rule; does not support variable references (fixed names facilitate filtering and grouping operations) |
| Additional Labels | Similar to labels in Prometheus; attached to all alert events for filtering, routing, and inhibition |
Data Source Selection
Monitors supports a single rule applying to multiple data sources using wildcards, such as db-* to apply to all data sources starting with db-.
Data source configuration stores names rather than IDs (to support wildcards). If the data source name is changed, it will affect the alert rule’s effectiveness. Please modify with caution.
Query Detection Method
Configure how to query data sources and how to evaluate alert conditions. Please read the usage instructions on the right side of Query Detection Method on the page.
Detection Frequency and Effective Time
| Config Item | Description |
|---|
| Detection Frequency | Usually periodic detection; also supports cron expressions (down to seconds) |
| Effective Time | Time period when the alert rule is effective; alerts will not trigger outside the effective time period |
Event Configuration
| Config Item | Description |
|---|
| Custom Fields | Similar to annotations in Prometheus; can attach dashboard URLs, SOP URLs, etc. |
| Related Query | Not used for threshold evaluation, but can be included in notes as variable references (e.g., attach log samples) |
| Notes Description | Unstructured text field; supports variable references to help responders quickly locate issues |
| Channel | Specify a channel in Flashduty On-call; if not specified, delivery follows integration routing rules |
| Repeat Notification | Continues notifying when alert is not recovered; configurable interval and maximum count (default 10000) |
The maximum notification count does not represent the number of message reminders end users receive. Because alert events generated by Monitors are delivered to On-call, they may be grouped and noise-reduced; the final send count depends on On-call configuration.
View Results
After configuration is complete, if alert conditions trigger, the status before the alert rule will change to Triggered.
Click Triggered to see the alert events generated by this rule (also viewable in On-call):
Click the alert event title to view details, which are divided into three tabs: Alert Overview, Timeline, and Related Events.
Import Alert Rules
If you already have Prometheus alert rules, you can use the import feature to quickly migrate.
Menu Entry: Alert Rules → Import
Requires importing Prometheus alert rules in YAML format text, with groups as the root node in standard format. YAML indentation must be correct, otherwise import will fail.
