Full table of mute rule config fields

Data model models/alert_mute.go:AlertMute.

Basic fields

severity alert level

Tag filtering (tags)

{ "key": "tag name", "func": "match operator", "value": "match value" }

• Multiple tags are AND'd: an event must match all conditions simultaneously to be muted (alert/common/key.go:MatchTags).
• The value for in/not in can be written either as a space-separated string or passed directly as an array (e.g. ["web01","web02"]); the tool automatically normalizes it to space-separated.
• key cannot be empty; func must be one of the six in the table above (the tool validates before persisting).

Common tags: ident (machine identifier/hostname), rulename (alert rule name), __name__ (metric name), custom business tags.

Mute time configuration

Mode 1: Fixed time range (mute_time_type: 0)

Mutes within the closed interval [btime, etime] (judged by the event trigger time). Prefer expressing the duration via the tool's duration parameter rather than computing timestamps yourself.

Only fill in btime/etime yourself when the user gives absolute start/end moments (rather than "how long to mute"). The system prompt's Now: line already provides the current precise time and Unix seconds.

Mode 2: Periodic mute (mute_time_type: 1)

Mutes periodically by day of week and time period.

periodic_mutes element structure:

{
  "enable_days_of_week": "1 2 3 4 5",
  "enable_stime": "02:00",
  "enable_etime": "06:00"
}

• Cross-midnight is natively supported: stime > etime (e.g. 22:00~06:00) is judged as ">= stime or < etime", no need to split into two segments.
• Time judgment uses the local timezone of the n9e process.

Complete examples

Example 1: Fixed-time mute of a specific machine (2 hours)

When calling, pass the tool parameter duration: "2h"; btime/etime are not needed in config.

{
  "note": "Maintenance window: mute web01 alerts",
  "cause": "web01 planned maintenance, expected 2 hours",
  "prod": "metric",
  "cate": "prometheus",
  "datasource_ids": [],
  "severities": [1, 2, 3],
  "tags": [
    {"key": "ident", "func": "==", "value": "web01"}
  ],
  "mute_time_type": 0,
  "periodic_mutes": [],
  "cluster": "0"
}

Example 2: Fixed-time mute of specific alerts on multiple machines (1 day)

When calling, pass the tool parameter duration: "1d".

{
  "note": "Batch maintenance: mute web cluster CPU alerts",
  "cause": "web cluster upgrade maintenance",
  "prod": "metric",
  "cate": "prometheus",
  "datasource_ids": [],
  "severities": [2, 3],
  "tags": [
    {"key": "ident", "func": "in", "value": "web01 web02 web03"},
    {"key": "rulename", "func": "=~", "value": ".*CPU.*"}
  ],
  "mute_time_type": 0,
  "periodic_mutes": [],
  "cluster": "0"
}

Example 3: Periodic mute (every day from 2-6 AM)

{
  "note": "Routine maintenance window: early-morning mute",
  "cause": "Mute alerts during the daily early-morning batch jobs",
  "prod": "metric",
  "cate": "prometheus",
  "datasource_ids": [],
  "severities": [2, 3],
  "tags": [
    {"key": "ident", "func": "=~", "value": "batch-.*"}
  ],
  "mute_time_type": 1,
  "periodic_mutes": [
    {
      "enable_days_of_week": "0 1 2 3 4 5 6",
      "enable_stime": "02:00",
      "enable_etime": "06:00"
    }
  ],
  "cluster": "0"
}

Example 4: Mute low-severity alerts during the weekday lunch break

{
  "note": "Weekday lunch-break mute",
  "cause": "Reduce non-urgent alert disturbance during the lunch break",
  "prod": "metric",
  "cate": "prometheus",
  "datasource_ids": [],
  "severities": [3],
  "tags": [],
  "mute_time_type": 1,
  "periodic_mutes": [
    {
      "enable_days_of_week": "weekday",
      "enable_stime": "12:00",
      "enable_etime": "13:30"
    }
  ],
  "cluster": "0"
}

Note: in Example 4, empty tags = mute all Info-level alerts within the business group; confirm the impact scope with the user before persisting.