What the data for this category looks like
The typical maintainers for this category are operations engineers, SRE teams, and platform engineering teams. Data primarily comes from Prometheus, Zabbix, cloud monitoring, application logs, and CMDB systems. Daily maintained documents include monitoring metric lists, alert rules, on-call manuals, and alert change records. Monitoring metric lists include metric names, associated resource identifiers, and threshold ranges. Alert rules include trigger conditions, effective time windows, and notification recipients. Alert change records include change times, operators, and modification content. Basic metrics are synced daily, and data is updated immediately after each alert rule or resource configuration change.
What constraints these characteristics impose on the permission and data isolation link
Data for this category covers multiple types of monitoring resources and business operation details. Monitoring metrics and alert rules from different teams are exclusive business data, and must be strictly isolated. Data sources include resource attribution information from CMDB. Resources and permissions must be bound using team identifiers to prevent cross-team access to unauthorized data. The characteristics of high-frequency updates and immediate changes require permission configurations to support real-time effectiveness, ensuring permissions take effect immediately after changes. Alert notifications and change records include sensitive information such as operators and notification recipients. Permission verification must be tied to team identifiers to prevent unauthorized viewing or modification. Permissions for core operations such as alert threshold setting and noise cleaning must be bound to teams to prevent unauthorized adjustments from impacting business monitoring effectiveness.
How to set the configurations
These configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Team resource binding | Associate monitoring resources and teams using teamId, use the unique identifier of the corresponding team | Match resource attribution of monitoring data to achieve cross-team data isolation |
| Alert template isolation | Generate exclusive alert templates for each team, bind with tmbId | Ensure alert rules from different teams cannot be accessed across teams |
| Change operation permissions | Only allow team administrators to modify alert configurations for their own team, use the team administrator role | Prevent unauthorized personnel from tampering with alert rules |
| Alert notification interval | Set to 300 seconds | Avoid repeated disruption of on-call personnel from the same alert, while ensuring alerts are delivered promptly |
| Alert history retention | Set to 30 days | Meet compliance data retention requirements while controlling storage costs |
| Log access filtering | Filter queryable application logs by teamId, use the resource ID range associated with the corresponding team | Protect the privacy of team application operation data |
Three common configuration mistakes
- After adding a custom monitoring alert configuration plugin to a workflow, no input or output parameters are displayed, and no error logs are generated. The cause is failure to correctly bind the plugin's
teamIdand team permissions, resulting in insufficient permission for parameter rendering. - Cross-team viewing of alert configurations allows access to monitoring metric data from other teams. The cause is failure to configure resource isolation rules by
teamId, resulting in failed permission filtering. - Alert change records include operation logs from non-team members. The cause is failure to bind the operator's
tmbIdand team identifier, resulting in missing permission verification.
How to confirm configurations are correctly set
- Switch login accounts for different teams, verify that only monitoring metrics and alert rules associated with the current team can be viewed
- Submit an alert configuration modification request for another team, confirm that the operation is blocked by the permission system
- Trigger a test alert, confirm that notifications are only sent to the notification link bound to the current team
- View alert change records, confirm that only operation logs and change content from the current team are displayed
The values provided are common starting points, and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.