Connect Guance Self-built Notification Targets
Added in version 2.5.2
1. Background
In some cases, the alarm notification methods provided by Guance cannot meet actual business needs. Using the "Custom Webhook" method requires users to modify their existing business systems or separately build a receiving system, which can be inconvenient.
At this point, you can use Guance's "Self-built Notification Targets" to send alert notifications directly to a specific function in local DataFlux Func, allowing for subsequent operations to be executed.
2. Preparation
To implement self-built notification targets, the following preparations need to be completed:
Preparation | Reference Documentation |
---|---|
Upgrade DataFlux Func to version 2.5.2 or higher | Deployment and Maintenance / Daily Maintenance / System Upgrade |
Create an API Key in Guance | Guance Documentation / Workspace Management / API Key Management |
3. Specific Steps
Below are the detailed steps:
3.1 Enable the Guance Connector
In "Management / Experimental Features," enable the "Guance Connector"
Go to "Development / Connectors / Add Connector," select the type as "Guance," and fill in the relevant configuration parameters.
3.2 Write the Self-built Notification Function
Go to "Development / Script Library" and create a script to store the self-built notification function.
The self-built notification function has fixed requirements:
- It must use
@DFF.API(...)
decoration and addcategory='guance.alertFunc'
- The function name is unrestricted, but there must be one and only one parameter
event
. For details on the parameter values, see the appendix.
Taking sending DingTalk notifications as an example, the complete code is as follows:
Sending DingTalk notifications can be configured directly in Guance without needing a self-built notification target; this code is merely an example and has no practical significance.
Refer to the appendix for documentation related to DingTalk bots.
Python | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
After completing the code writing, don't forget to publish it.
3.3 Confirm the Self-built Notification Target in Guance
In Guance's "Monitoring / Notification Targets Management," you should see the previously written and published notification target function in the list.
3.4 Select the Self-built Notification Target in Monitors
In Guance's "Monitoring / Monitors," configure the alert strategy for the monitor and select the newly created self-built notification target.
3.5 Receive the Self-built Notification
Based on the code written earlier, we extracted the event's title and content, and added an extra line: "This message was sent via a self-built notification target."
Assuming the "Event Content" in the monitor is simply configured with the following content:
Text Only | |
---|---|
1 2 |
|
Then, after processing through the self-built notification target, the final message received by the DingTalk bot will look like this:
X. Appendix
Below is the appendix.
X.1 DingTalk Bot Related Documentation
- Group Bots: https://open.dingtalk.com/document/robots/custom-robot-access
- Group Bot Signing Explanation: https://open.dingtalk.com/document/robots/customize-robot-security-settings
X.2 Self-built Notification Target Function event
Parameter
The event
parameter received by the self-built notification target is a dict, with the following internal fields:
Field Name | Type | Required | Description |
---|---|---|---|
timestamp |
Integer | Required | Generation time. Unix timestamp, unit seconds |
df_status |
Enum | Required | Status. Possible values: ok , info , warning , error , critical , nodata |
df_event_id |
String | Required | Event ID |
df_title |
String | Required | Title |
df_message |
String | Detailed description | |
df_dimension_tags |
String(JSON-format) | Required | Detection dimension tags, e.g., {"host":"web01"} |
df_monitor_id |
String | Monitor group ID | |
df_monitor_name |
String | Monitor group name | |
df_monitor_checker_id |
String | Monitor ID | |
df_monitor_checker_name |
String | Monitor name | |
df_monitor_checker_value |
String | Value when the detection triggers an event | |
df_monitor_checker_value_dumps |
str(JSON) | Value when the detection triggers an event (JSON serialized) Convenient for deserialization by the user to get the original value |
|
df_event_link |
String | Event jump link | |
df_workspace_uuid |
String | Belonging workspace UUID | |
df_workspace_name |
String | Belonging workspace name | |
Result |
Float | Detection value | |
{Other additional fields} |
Omitted |
Generally speaking, when connecting to third-party messaging platforms, only the df_title
and df_message
fields are needed.
Example:
JSON | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|