AI Smart Monitor¶
AI Smart Monitor lets you describe monitoring requirements in natural language, and the AI generates the monitor name, detection rules, and event content in one pass. After generation, you can review and adjust the configuration, then save it as a continuously running smart monitor.
The prompt is used only to generate the configuration. After the monitor is saved, the system executes detection based on the saved fixed rules and does not re-interpret the prompt on each detection run. Subsequent updates to algorithms or rule templates will not automatically replace the saved rules.
If you want to use the prompt directly as the detection rule and have the AI dynamically query and analyze observability data on each execution, use AI Monitor.
How It Works¶
The configuration and execution process of an AI Smart Monitor is as follows:
- Describe the monitoring target, data scope, and anomaly conditions in natural language.
- The AI generates the monitor name, one or more detection rules, and event content based on the prompt.
- Review the generated results, edit the name and event content, adjust rule thresholds, or manage rule states as needed.
- After saving, the system continuously executes detection based on the currently active fixed rules.
- When rules meet the trigger conditions, events are generated and handled according to the associated alert policy.
Differences from AI Monitor¶
| Comparison Item | AI Smart Monitor | AI Monitor |
|---|---|---|
| Role of the prompt | Used to generate concrete detection rules. | The prompt itself serves as the continuously effective detection rule. |
| Execution method | After saving, executes based on fixed query conditions, algorithms, and thresholds. | On each execution, the AI queries and analyzes observability data based on the prompt. |
| Detection results | Generates smart monitor events when rules meet the conditions; rules hit in the same detection run are merged into an analysis report. | Generates a structured event report when issues supported by data evidence are found. |
| Adjustment method | Modify rule thresholds, or modify the prompt and regenerate the configuration. | Modify the prompt directly to adjust subsequent analysis goals and judgment requirements. |
Create a Monitor¶
Go to Monitoring > Smart Monitoring, click Create Monitor, and select AI Smart Monitor.
1. Describe Monitoring Requirements¶
In Describe Monitoring Requirements, enter a prompt. It is recommended to include the following information:
| Content | Description | Example |
|---|---|---|
| Monitoring target | The environment, service, host, application, or cluster to monitor, with the corresponding names or tag values. | The order service (service:order-service) in the production environment (env:prod) |
| Data scope | The metrics, logs, or other observability data to focus on. | Request volume, error rate, and P95 response time |
| Anomaly conditions | The abnormal behavior and change direction to identify. | Rising error rate, slower response time |
| Judgment requirements | Known thresholds, duration, or comparison methods. | Error rate exceeds 5% for 10 minutes |
The service names, environment, cluster names, and thresholds in the following examples are for illustration only; replace them with actual values in the current workspace.
For example, to monitor a specific service:
Monitor the order service (
service:order-service) in the production environment (env:prod). When the request error rate exceeds 5% within the last 10 minutes, or the P95 response time exceeds 1 second, determine it as abnormal. The event content must specify the hit metric, current value, and threshold.
To monitor a specific Kubernetes cluster:
Monitor the Kubernetes cluster (
cluster_name:prod-cluster) in the production environment, limited to the business namespace (namespace:order-prod). Focus on node CPU, memory, and disk usage. When any metric exceeds 85% for 10 consecutive minutes, determine it as abnormal, and specify the abnormal node, metric value, and duration in the event content.
The prompt should specify the monitoring target, scope, and abnormal behavior as clearly as possible to reduce deviation between the generated result and the actual requirements.
2. Generate Configuration¶
Click Generate Configuration. You can view the progress during generation, or click Stop Generation at any time.
After successful generation, the system fills in the following content at the same time:
| Generated Content | Description | Adjustable Scope |
|---|---|---|
| Monitor name | A monitor name distilled from the prompt, up to 256 characters. | Editable and required when saving. |
| Detection rules | One or more upper-threshold, lower-threshold, or sudden-change rules generated based on the monitoring target. | Thresholds can be modified, and rules can be deleted or restored; other rule fields are read-only. |
| Event content | Content written to events and used for alert notifications after rules are triggered. | Editable or clearable, with existing event variable capabilities retained. |
During generation, the prompt, name, rules, event content, and save operation are temporarily unavailable for modification. If generation fails, times out, or is stopped manually, existing generated results and user modifications are retained, and you can adjust the prompt and regenerate.
3. Review Detection Rules¶
Detection rules display the monitoring target, data scope, detection metric, calculation method, detection window, judgment method, threshold, unit, and event level. Sudden-change rules also display the comparison window, change direction, and difference method.
To ensure consistent structure and semantics across generated rules, all rule fields are read-only except the threshold. You can:
- Adjust thresholds: Modify the anomaly trigger boundary of a rule; input values must meet the range and precision requirements shown on the page.
- Delete rules: Move rules you no longer need to Deleted Rules; deleted rules do not participate in detection.
- Restore rules: Restore rules from Deleted Rules; restored rules retain their original structure, thresholds, and order.
A monitor must retain at least one active rule. When only one active rule remains, you cannot delete it.
4. Configure Events and Alerts¶
Review or edit the AI-generated event content, then configure as needed:
Save the monitor after configuration. The system saves the current prompt, name, event content, all rules, and rule states, and executes the currently active rules.
Modify and Regenerate¶
Open a saved AI Smart Monitor, and you can directly modify and save the following:
- Monitor name;
- Event content;
- Rule thresholds;
- Deleted or restored status of rules;
- Common configuration such as alert policy and operation permissions.
If you modify the prompt, click Regenerate for the AI to regenerate the name, all detection rules, and event content. Simply modifying the prompt will not automatically change existing rules, nor can it be saved directly.
When regenerating, note the following:
- If the name, event content, thresholds, or rule states have been manually modified, the system will prompt that this regeneration will replace these contents;
- After successful regeneration, the name, active rules, deleted rules, and event content are replaced as a whole with the newly generated result;
- If regeneration fails, times out, or is stopped, the current valid configuration and user modifications are retained.
Management and Traceability¶
| Function | Description |
|---|---|
| Monitor list | Use Monitor Type to distinguish AI Smart Monitors from other smart monitors, and retain the existing search, filtering, enable/disable, and action menus. |
| Configuration versions | Saved monitors use the rule snapshot from the time of saving and do not change automatically due to updates to AI generation policies or built-in rules. |
| History | View changes to the name, prompt, event content, rule structure, thresholds, and rule states. History is for viewing and traceability only and does not change the current configuration. |
| Import and export | Exported content includes the prompt, complete rules, rule states, version, and common configuration; after reimporting, monitors are created based on the rules in the file without automatically invoking AI regeneration. |
Billing¶
Each detection run of an AI Smart Monitor generates both Triggers and AI Credits usage:
| Metered Item | Metering Rules |
|---|---|
| Triggers | Each detection run counts as 100 Triggers. |
| AI Credits | Deducted based on the actual Credits consumed by this AI analysis. |
Triggers and Credits are counted separately.
View Events¶
When rules meet the trigger conditions, smart monitor events are generated. In the smart monitor list, you can click View Related Events to enter the event details and view the event content, analysis report, associated views, and other information.
A single detection run may trigger multiple rules at the same time. The system aggregates the rules hit in that run and merges them into one analysis report, rather than generating a separate report for each rule. The report presents an anomaly summary by detection dimension and provides hit rules, monitor signals, current values, judgment basis, anomaly causes, and trends, making it easier to assess the anomaly in one place.
Other Smart Monitors¶
Smart monitors for Host, Log, Application, RUM, Kubernetes, and Cloud Billing use fixed built-in rules and do not require a prompt. After creation, you can adjust rule thresholds and delete or restore rules; other rule fields are read-only.
Existing smart monitors created before the algorithm refactoring retain their original content and execution method, and their configuration page is read-only. Even with management permissions, you cannot modify their rules or common configuration. If you need to adjust the detection logic, create a new monitor.