byted-volcengine-alert-inspection-analyzer

Solidify "pulling Feishu group alarm messages + filtering + deduplication + event aggregation + risk analysis + report output" into a standard skill.

Applicable Scenarios

Use this skill when the user raises the following types of requests:

Query cloud alarm notifications within a certain Feishu group on a certain day/in a certain time period
Pull alarm messages sent by a specified robot, Bot, or application
Perform inspection analysis, daily reports, retrospectives, or stability assessments on alarm messages
Need to export structured JSON, Markdown reports, or compressed packages
Need to determine whether an alarm has recovered, whether there are unclosed events, or whether it is a noise alarm

Input Requirements

At least the following three types of information are required:

chat_id: Feishu group ID, for example oc_xxx
time: time range
- Relative time:today、yesterday、last_24_hours、this_week
- or absolute time:start_time + end_time, ISO 8601 format, for example 2026-06-05T00:00:00+08:00
bot: robot identifier
- Prefer to use bot_sender_id / app id, for example cli_xxx
- If there is only the robot name, first pull messages by time range and then identify it from the sender information; at the same time, explain the accuracy risk

Optional information:

output_dir: output directory, default output/alert_inspection_<日期>_<chat_id>/
report_format：json、markdown, by default generate at the same time
keyword: content keyword filtering, for example "Volcano Engine Cloud Monitoring Alarm Notification"

Workflow

1. Validate input

When chat_id、time or bot is missing, first ask the user to provide it.
Time must be one of two choices: relative time, or start_time + end_time。
For Chinese dates (such as "June 5"), use the current year and Beijing time by default, unless the user specifies otherwise.

2. Pull Feishu messages

Prefer to use the feishu_im_user_get_messages tool:

{
  "chat_id": "oc_xxx",
  "start_time": "2026-06-05T00:00:00+08:00",
  "end_time": "2026-06-05T23:59:59+08:00",
  "page_size": 50,
  "sort_rule": "create_time_asc"
}

Pagination rules:

Each page has at most 50 items.
If it returns has_more=true, continue to use page_token to pull the next page.
After merging all paginated results, deduplicate by message_id .

3. Robot filtering

Filtering priority:

If the user provides bot_sender_id: filter exactly by sender.id .
If there is only the robot name:
- First identify candidate sender ids for sender.sender_type == app from the returned messages.
- Perform conservative filtering based on message card titles, content keywords, and alarm semantics.
- Once the sender id is confirmed, record it in subsequent analysis as filter_mode=identified_sender_id。
If the sender id cannot be confirmed:
- Filter by content keywords.
- Clearly mark filter_mode=keyword_onlyin the report, explaining that it may be incomplete or imprecise.

4. Standardize messages

Use scripts/alert_inspection.py to standardize the raw message JSON. Standard fields:

message_id
create_time
status：警告 / 已恢复 / 严重 / 未知
policy
resource
metric
current_value
content
sender

Extract as much as possible from the Feishu card content:

Alarm policy
Alarm level
Project
Region
Alarm time
Cloud product
Resource ID
Current value
Alarm details link

5. Analyze alarms

Analysis dimensions:

Total messages, warning count, recovery count, unknown count
Statistics by policy
Statistics by metric
Statistics by resource
Statistics by hour
Alert event closure: from continuous warning to recovery as one event cycle
Unrecovered event identification
Duration, longest event, repeated events
Risk level: low / medium / high
Possible causes and handling suggestions

Risk assessment suggestions:

Low risk: A small number of alerts, all quickly recovered, no repeated concentrated pattern.
Medium risk: The same resource/metric alerts repeatedly, all recovered but with high frequency.
High risk: There are unrecovered alerts, severe-level alerts, long duration, core metric anomalies, or high-frequency concentrated outbreaks.

6. Output files

Default output to:

output/alert_inspection_<YYYY-MM-DD>_<chat_id>/

Should generate:

raw_messages.json: Raw messages
normalized_messages.json: Normalized messages
analysis.json: Structured statistics and analysis data
report.md: User-facing Chinese analysis report
run_meta.json: Runtime metadata

If the user requests sending a compressed package, package the output directory as .zip and then use message tool to send it.

Recommended execution method

A. When raw messages have already been obtained through a tool

Save the tool return result as raw JSON:

python scripts/alert_inspection.py \
  --input raw_messages.json \
  --chat-id oc_xxx \
  --bot-name 云告警通知 \
  --start-time 2026-06-05T00:00:00+08:00 \
  --end-time 2026-06-05T23:59:59+08:00 \
  --output-dir output/alert_inspection_2026-06-05_oc_xxx

B. When real-time pulling from Feishu is needed

Use feishu_im_user_get_messages to pull by group and time with pagination.
Save as raw_messages.json。
Call scripts/alert_inspection.py to generate the analysis file.
Reply to the user with a summary; if there are files/compressed packages, use message tool to send them, do not only return MEDIA: tags.

Reply to user template

已完成告警巡检分析。

结果摘要：
- 时间范围：...
- 命中消息：... 条
- 警告：... 条，恢复：... 条，未闭环：... 条
- 主要资源：...
- 风险等级：...
- 输出目录：...

核心判断：...
建议：...

Notes

Do not fabricate alert data; if raw messages have not been obtained, do not claim that analysis has been performed.
The bot name is not a stable filter condition; prioritize using sender id.
The report must clearly state the data source, filtering method, and accuracy risks.
Do not output sensitive data such as tokens, cookies, or authorization information.
When sending files externally, follow the current platform's file sending rules, use message tool to send the local absolute path.