Detection Rules¶

Currently, Guance supports over a dozen monitoring detection rules, each covering different data ranges.

Rule Types¶

Rule Name	Data Scope	Basic Description
Threshold Detection	All	Detect anomalies in metrics data based on set thresholds.
Mutation Detection	Metrics (M)	Detect sudden abnormal behavior in metrics based on historical data, suitable for business data and short time windows.
Interval Detection	Metrics (M)	Detect anomaly data points in metrics based on dynamic threshold ranges, suitable for stable trend time series.
Interval Detection V2	Metrics (M)	Detect anomaly data points in metrics based on dynamic threshold ranges, suitable for stable trend time series.
Outlier Detection	Metrics (M)	Detect whether the metrics/statistics of specific groups deviate from the norm.
Log Detection	Logs (L)	Detect anomalies in business applications based on log data.
Process Anomaly Detection	Process Objects (O::`host_processes`)	Periodically detect process data to understand process anomalies.
Infrastructure Liveness Detection V2	Objects (O)	Set liveness conditions based on infrastructure object data to monitor the stability of infrastructure.
Application Performance Detection	Traces (T)	Set threshold rules based on APM data to detect anomalies.
User Access Detection	User Access Data (R)	Set threshold rules based on RUM data to detect anomalies.
Composite Detection	All	Combine multiple monitors' results into one monitor using expressions and alert based on the combined result.
Security Check Anomaly Detection	Security Check (S)	Detect anomalies based on data generated by security checks, effectively sensing host health status.
Synthetic Testing Anomaly Detection	Synthetic Testing Data (L::`type`)	Set threshold rules based on synthetic testing data to detect anomalies.
Network Detection	Network (N)	Set threshold rules based on network data to detect network performance stability.
Third-Party Event Detection	Other	Send anomaly events or records from third-party systems to an HTTP server via POST requests to generate Guance event data.

Start Configuration¶

Detection Configuration¶

Set corresponding detection frequencies, detection intervals, and detection metrics for different detection rules.

Event Notifications¶

Event Title¶

Define the event name that triggers the alert; you can use predefined template variables.

Note: In the latest version, the monitor name will be automatically generated after entering the event title. In older monitors, there may be inconsistencies between the monitor name and the event title. For better user experience, please synchronize to the latest version as soon as possible.

Event Content¶

Write the notification content for the event, which will be sent externally when the trigger conditions are met. You can input Markdown formatted text and preview the effect; you can also use related links and template variables.

Custom Notification Content¶

By default, Guance uses the event content as the alert notification content. If you need to customize the actual notification content sent externally, you can enable this switch and fill in the notification information here.

Note: Different notification targets support different Markdown syntax, for example, WeCom does not support unordered lists.

The monitor will automatically generate jump links based on the detection metrics configured in Detection Configuration. You can adjust the filter conditions and time range after inserting the link. Generally, it is a fixed link address prefix containing the current domain and workspace ID; you can also choose to customize the jump link.

If you need to insert a link to a dashboard, based on the above logic, you must also provide the dashboard ID and name, and adjust the view variables and time range as needed.

Custom Advanced Settings¶

You can add related logs or error stacks in the event content through advanced settings to view contextual data when anomalies occur:

Add Related Logs:

Query:

For example, get a log message with index default:

{% set dql_data = DQL("L::RE(`.*`):(`message`) { `index` = 'default' } LIMIT 1") %}

Related Log:

{{ dql_data.message | limit_lines(10) }}

Add Related Error Stack

Query:

{% set dql_data = DQL("T::re(`.*`):(`error_message`,`error_stack`){ (`source` NOT IN ['service_map', 'tracing_stat', 'service_list_1m', 'service_list_1d', 'service_list_1h', 'profile']) AND (`error_stack` = exists()) } LIMIT 1") %}

Related Error Stack:

{{ dql_data.error_message | limit_lines(10) }}

{{ dql_data.error_stack | limit_lines(10) }}

Data Gap Events¶

Customize the notification content for data gaps. You can configure the title and content of the notification sent externally for this type of event.

If not configured here, the official default notification template will be used when sending notifications.

Associated Incident¶

When enabled, if an anomaly event occurs under this monitor, an Issue will be created synchronously. You can choose to create Issues for different event levels.

Select the event level;
Define the final Issue level;
Choose the assignee for this type of Issue;
Select the delivery channel;
Optionally choose to close the Issue when the event is resolved.

Issues created here can be viewed at Incident > Your selected Channel.

Alert Configuration¶

Once the monitoring conditions are met, immediately send alerts to specified notification targets. The alert strategy includes the event levels to notify, notification targets, and alert silence period.

Alert strategies support single or multiple selections. Clicking the strategy name expands the details page. To modify the strategy, click Edit Alert Strategy.

Association¶

Associated Dashboard: Each monitor supports associating with a dashboard for quick access.

Permissions¶

After setting monitor operation permissions, roles, team members, and space users in your current workspace will perform corresponding operations according to the assigned permissions. This ensures that different users operate according to their roles and permission levels.

Not enabling this configuration: Follows the default permissions for "Monitor Configuration Management";
Enabling this configuration and selecting custom permission objects: Only the creator and those granted permissions can enable/disable, edit, or delete the monitor's rules;
Enabling this configuration but not selecting custom permission objects: Only the creator has the permissions to enable/disable, edit, or delete the monitor.

Note: The Owner role in the current workspace is not affected by this permission configuration.

Recover Monitor¶

Guance supports viewing existing monitor states, last update time, creation time, and creator. It allows you to recover monitor configurations to facilitate communication and collaboration with team members to update monitors.

Operation Example:

In Monitoring > Monitors, select an existing monitor for editing. On the monitor configuration page, click the button in the top-right corner to view the monitor's state, last update time, creation time, and creator.

Click the button next to the Update Time to open a new browser window to view the previous version of the monitor configuration;

Click Revert to This Version in the top-right corner of the previous version monitor and confirm the revert in the pop-up dialog to restore the previous version of the monitor configuration for editing and saving.