Integration with Guance and TrueWatch Self-built Notification Targets
Added in version 2.5.2
1. Background
In some cases, the alert notification methods provided by Guance and TrueWatch may not meet actual business needs. Using a "Custom Webhook" requires users to modify their existing business systems or set up a separate receiving system, which can be inconvenient.
At this point, you can use Guance and TrueWatch's "Self-built Notification Targets" to send alert notifications directly to a specific function in your local DataFlux Func, allowing subsequent operations to be executed from there.
2. Preparations
To implement self-built notification targets, the following preparations need to be made:
Preparation | Reference Documentation |
---|---|
Upgrade DataFlux Func to version 2.5.2 or above | Deployment and Maintenance / Daily Maintenance / System Upgrade |
Create an API Key in Guance and TrueWatch | Guance Documentation / Workspace Management / API Key Management TrueWatch Documentation / Workspace Management / API Key Management |
3. Specific Steps
The following are the detailed steps:
3.1 Enable the Guance and TrueWatch Connector
In "Management / Experimental Features," enable the "Guance and TrueWatch Connector."
Go to "Development / Connectors / Add Connector," select the type as "Guance and TrueWatch," 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.
For functions used for self-built notifications, there are fixed requirements:
- The function must use
@DFF.API(...)
decoration and addcategory='guance.alertFunc'
. - There is no restriction on the function name, but it must have exactly one parameter
event
. For details about the parameter value, see the appendix.
As an example, here is the complete code for sending DingTalk notifications:
Sending DingTalk notifications can be configured directly in Guance and TrueWatch without needing a self-built notification target; the code below is only for demonstration purposes and has no practical significance.
Documentation related to DingTalk robots can be found in the appendix.
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 writing the code, don't forget to publish it.
3.3 Confirm the Self-built Notification Target in Guance and TrueWatch
In Guance and TrueWatch's "Monitoring / Notification Target Management," you can see the previously written and published notification target functions in the list.
3.4 Select the Self-built Notification Target in Monitors
In Guance and TrueWatch's "Monitoring / Monitors," configure the alert strategy for the monitors and select the newly created self-built notification target.
3.5 Receive Self-built Notifications
Based on the previously written code, we extract the title and content of the event and add an additional line: "This message was sent via a self-built notification target."
Assume that the "Event Content" in the monitor is simply configured as follows:
Text Only | |
---|---|
1 2 |
|
Then, after processing by the self-built notification target, the final message received by the DingTalk robot will look like this:
X. Appendix
The following is the appendix.
X.1 DingTalk Robot Related Documentation
- Group Robots: https://open.dingtalk.com/document/robots/custom-robot-access
- Group Robot Signature Instructions: https://open.dingtalk.com/document/robots/customize-robot-security-settings
X.2 Parameters of the Event Argument for Self-built Notification Functions
The event
argument received by self-built notification functions is a dict with the following fields:
Field Name | Type | Required | Description |
---|---|---|---|
timestamp |
Integer | Required | Time of generation. Unix timestamp, in 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, such as {"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 at the time of detection trigger | |
df_monitor_checker_value_dumps |
str(JSON) | Value at the time of detection trigger (JSON serialized) Convenient for deserialization |
|
df_event_link |
String | Event jump link | |
df_workspace_uuid |
String | UUID of the workspace | |
df_workspace_name |
String | Name of the workspace | |
Result |
Float | Detection value | |
{Other Additional Fields} |
Omitted |
Generally speaking, when integrating with 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 |
|