What problem does it solve?
When a monitoring system marks a machine as unreachable, it is often unclear whether the host is truly down, the agent is hung, the network is flapping, or the machine is simply under maintenance. Concluding "down" from a single heartbeat signal is a common source of false-positive alerts and wasted on-call effort.
Core Features & Use Cases
- Three-Layer Evidence Collection: Gathers real-time heartbeat status from Redis, a 10-minute metric window from the Prometheus datasource, and the health of neighbor hosts in the same business group.
- Three-State Decision Table: Classifies the situation into truly down, agent hung, network flapping, under maintenance, cluster event, or insufficient data, each with a confidence level.
- False-Positive Guardrails: Checks alert mutes, companion alerts, and clock skew before recommending any action, and always includes a self-verification step such as checking
systemctl status categraf.
- Use Case: A user asks "why is machine web-07 unreachable?" The skill pulls heartbeat lag, recent CPU/network metrics, and neighbor status, then concludes whether it is a single-host outage or a cluster-level event with concrete recommended actions.
Quick Start
Ask the assistant why a specific host shows as unreachable in Nightingale and whether the alert is a false positive.
