View "Message Sending" Function Logs
2024-09-05
This document primarily introduces the function logs generated by message sending tasks in Guance.
Message result logs source:message_send_result have been temporarily removed
According to the iteration requirements of 2025-05-14, the writing of message sending results into user space has been paused.
Original source:MD_send_result logs have been removed
After the 2025-04 version, the result logs of message sending will be recorded in the respective workspace logs.
Users can directly search and view the message sending records in the log Explorers of their respective workspaces using source:message_send_result message_type:xxxxx
.
Logs for 'Message Sending Task source:DFF_task_record_func' are different from 'Message Result Log source:message_send_result'
Do not confuse 'Message Result Logs' with 'Message Sending Task Logs'.
'Message Sending Task Logs' are essentially 'Function Task Logs', which are written to specified reporting addresses according to Func 'Management / System Configuration'.
'Message Result Logs' are written to individual spaces, containing only sending parameters and results, and are used in conjunction with Guance for users to view.
1. Introduction
Like other functions executed in DataFlux Func, after configuring function logs to be reported to Guance, the logs of message sending tasks can also be conveniently queried on the Guance platform.
For information on how to configure function logs to be reported to Guance and explanations of the reported fields, please refer to Manual / Deployment and Maintenance / Reporting Self-Observation Data
2. Basic Queries
Key fields:
Field | Type | Description |
---|---|---|
source |
str | Message sending task logs: DFF_task_record_func Message result logs: message_send_result |
workspace_uuid |
str | Associated Guance workspace UUID Format: wksp_xxxxx |
monitor_checker_ids |
str(JSON) | List of involved monitor IDs Only applicable for monitoring alert messages Format: [ "rul_xxxxx", "rul_yyyyy" ] |
event_ids |
str(JSON) | List of involved event IDs Only applicable for monitoring alert messages Format: [ "event-xxxxx", "event-yyyyy" ] |
message_type |
enum | Message task type, see below X. Message Types |
exception_type |
str | Error type Example: WeChat message sending failure "WechatSendingFailure" |
exception |
str | Specific error Example: WechatSendingFailure('Status Code: 200. Response: {"errcode":40058, ... <略> } |
In the Guance 'Log Explorer', filling in the following filtering conditions will filter out all execution logs of message sending tasks:
Text Only | |
---|---|
1 |
|
If you need to view logs of a specific type of message, add the message_type
filtering condition, such as:
Text Only | |
---|---|
1 |
|
If you only want to view error logs, add the status
filtering condition, such as:
Text Only | |
---|---|
1 |
|
3. Common Query Conditions
Below are common query conditions; copy the query conditions into the filter bar of the Guance 'Log Explorer' for searching.
All message sending task logs:
Text Only | |
---|---|
1 |
|
Failed message sending task logs:
Text Only | |
---|---|
1 |
|
All message sending task logs for a specific workspace:
Text Only | |
---|---|
1 |
|
Failed message sending task logs for a specific workspace:
Text Only | |
---|---|
1 |
|
Message sending task logs for a specific message type:
Text Only | |
---|---|
1 |
|
Failed message sending task logs for a specific message type:
Text Only | |
---|---|
1 |
|
4. Querying Non-'Monitor Alert' Messages
Non-'Monitor Alert' messages may invoke different Func functions depending on the actual situation; please consult the caller for the method used.
Here we describe typical invocation methods.
4.1 Direct Message Sending
For sending general notification emails, etc., the MessageDesk script set's functions might be called directly.
The query method for corresponding logs is as follows:
Directly send email | |
---|---|
1 |
|
All message sending tasks | |
---|---|
1 |
|
4.2 Delayed Message Sending
For some messages that require delayed sending (such as pre-mute notification emails), the message task function under 'Guance support' might be called, with the sending time specified.
Log time for delayed message sending
Note that delayed message sending occurs in three phases:
-
Task setup phase: For example, at 00:00, the user performs an operation in the UI, creating a task to send a message at 05:00 (Note: The log time for this task is 00:00, not 05:00).
-
Delayed message dequeuing phase: When it reaches 05:00, the system internally retrieves the task from phase 1 and starts an asynchronous sending task.
-
Actual sending phase: The message is actually sent.
User UI operation during 'Task Setup Phase'
Generally, delayed trigger tasks originate from user UI operations.
Specifically, if a user adds a mute rule starting at 00:30:00 at 00:00:00, and specifies sending a notification 5 minutes before it takes effect,
then the user's action of 'Adding Mute Rule' is considered the 'UI Operation', occurring at time 00:00:00.
The delayed task sending time would then be '00:30:00 - 5 minutes', i.e., 00:25:00.
Additionally, since Func only provides basic functionality, specific business logic (e.g., when certain functions are called) should be consulted with Studio-side development.
The query method for corresponding logs is as follows:
Check the logs to confirm whether the delayed task was correctly configured.
The query time corresponds to the UI operation time.
Add / Replace Message Task | |
---|---|
1 |
|
Check the logs to confirm whether the delayed task was correctly dequeued.
The query time corresponds to the 'Scheduled Send Time' from the above 1., with an appropriately expanded range.
Delayed Task Dequeue Logs | |
---|---|
1 |
|
Based on the actual function ID called in 'the above 2.', query the corresponding logs to check the sending result.
The query time corresponds to the same time as 'the above 2.' with an appropriately expanded range.
Actual Message Sending Logs | |
---|---|
1 |
|
If it involves canceling already-set delayed sending tasks, you can search using the following filtering conditions:
Delete Message Task | |
---|---|
1 |
|
X. Message Types
The correspondence between the values of the message_type
field and the message types is shown in the table below:
message_type |
Message Type |
---|---|
"mail" |
|
"dingTalkRobot" |
DingTalk Robot |
"feishuRobot" |
Lark Robot |
"wechatRobot" |
WeCom Robot |
"HTTPRequest" |
HTTP Request |
"jiguang" |
Jiguang Push |
"sms" |
SMS |
"slackIncomingWebhook" |
Slack Incoming Webhook |
"teamsWorkflowWebhook" |
Teams Workflow Webhook |