automateyournetwork/zabbix-problem-review

Zabbix Problem Review

Server

zabbix-mcp — vendored third-party, read-only, three tools. See zabbix-metrics-history for the shared cautions.

Current problems vs history — use the right one

| Question | Method | Note | |---|---|---| | What is wrong now? | problem.get | Reads a dedicated problem table. This is the right one | | What happened then? | event.get | Historical, heavier, needs a time window | | What rule fired it? | trigger.get | The definition behind a problem |

zabbix_api("problem.get", {
  "output": "extend", "selectAcknowledges": "extend", "selectTags": "extend",
  "recent": false, "sortfield": ["eventid"], "sortorder": "DESC"
})

Every problem you report carries: severity · host · when it started · how long it has been active · acknowledgement state. "How long" is the question NetClaw could not answer at all before this integration existed — do not drop it.

The distinction that matters most here

"No active problems" and "the NMS could not be reached" are not the same answer.

An empty problem list is a legitimate, positive finding — the monitoring system looked and found nothing wrong. An unreachable NMS is a failure to look.

They are both an empty result over the wire, and reporting the second as the first is the most misleading thing this skill can do: it tells an engineer everything is fine at exactly the moment monitoring is blind.

Three outcomes, three different sentences:

| | Say | |---|---| | NMS reachable, nothing wrong | "Zabbix reports no active problems as of <time>." | | NMS unreachable | "Zabbix could not be reached — this is not a statement about the network." | | Credentials rejected | "Zabbix rejected the credentials — the monitoring state is unknown." |

Acknowledgement is a workflow fact, never a resolution

An acknowledged problem is still happening. Someone has said "I've seen this", which is a fact about the team, not about the network.

Report it as "active, acknowledged by <who> at <when>". Never let acknowledgement soften the description of the underlying condition, and never let a filtered-out acknowledged problem disappear from a count.

Filtering

Filter before you answer — by severity, host or group — rather than returning everything and asking the reader to ignore rows. Use severities, hostids or groupids on the call.

Severities: 0 not classified · 1 information · 2 warning · 3 average · 4 high · 5 disaster.

When you filter, say what you filtered out, so "two problems" is never mistaken for "two problems exist".

Resolved problems

event.get with value: 0 gives resolutions. Report both onset and resolution times — a problem that lasted four minutes and one that lasted four hours are different incidents, and the duration is usually the point of the question.

Boundaries

| Want to… | Use | |---|---| | Metric values over time | zabbix-metrics-history | | Availability and inventory | zabbix-availability | | Unsolicited traps | snmptrap-mcp — push, not poll | | Flows | ipfix-mcp | | Instrumented metrics / dashboards | prometheus, grafana | | SaaS monitoring | auvik, thousandeyes, datadog | | Current device state | pyats, multivendor-cli, fortinet — this is the poller's view over time | | Acknowledge, close or suppress anything | nothing here. This integration is strictly read-only |

Rules

1. Never report an unreachable NMS as "no problems".
2. Always give duration, not just onset.
3. Acknowledged ≠ resolved. Say "acknowledged", never imply "handled".
4. Say what you filtered out.
5. Read-only. Acknowledging an alert is a real action a human owns; there is no write path here.