Monitoring and alerting overview

ITVA watches your devices, interfaces, routing neighbors, probes, and services. When a check fails, ITVA opens an incident and sends a notification. This page lists every check you can alert on and where the data for each check comes from.

How alerting works

Alerting has four parts:

• Conditions set which checks are on for a device or probe, and the limits for each check.
• Incidents open when a check fails and resolve when the check passes again. An incident is Open, Acknowledged, or Resolved.
• Rules match incidents by tag and priority, and send them through one or more escalation levels.
• Channels deliver the notification by email, SMS, Microsoft Teams, or webhook.

You manage conditions, rules, channels, and alerting monitors on the Settings > Alerting page.

What you can alert on

Device unreachable

ITVA checks that it can reach each device. For most vendors, the check reads the device hostname over the same connection that a sync uses. For devices with the vendor Other, the device's probe pings the management IP instead.

Device CPU and memory

ITVA alerts when CPU or memory utilization on a device is above the limit you set. The values come from the device metrics that each sync collects. CPU and memory are separate checks, so you can turn on one without the other.

Device PSU

ITVA alerts when one or more power supplies on a device report as unhealthy. The power supply status comes from the device sync.

Device ping monitors

A ping monitor runs a ping on the device itself, from an interface you select, to a destination IP. Use it to test a path from the device's point of view, for example from a branch router to a data center.

ITVA alerts when the latest ping gets no replies, or when its average latency is above the latency threshold. The default latency threshold is 300 ms. You add ping monitors on the device details page.

Interface down

ITVA alerts when the link or the line protocol on an interface is down. The interface status comes from the interface metrics that each sync collects.

Interface alerting is off for every interface by default. To alert on an interface, turn on alerting on its interface details page. The condition only sets the threshold and interval for this check.

Interface bandwidth

ITVA alerts when inbound or outbound utilization on an interface is above a percentage limit. The bit rates come from the interface metrics that each sync collects.

By default, ITVA measures utilization against the lowest CIR of the circuits on the interface. You enter circuits and their CIR in ITVA. If the interface has no circuit with a CIR, or the condition does not use CIR, ITVA uses the interface speed from the device. If neither is known, ITVA skips the check.

Like interface down, this check only runs on interfaces that have alerting turned on.

BGP, OSPF, and IS-IS neighbors

ITVA alerts when a BGP, OSPF, or IS-IS neighbor is unhealthy. The neighbor state comes from the device sync:

• BGP: the session is unhealthy when its state is not Established, or when it is no longer in the sync.
• OSPF: the neighbor is unhealthy when its state is not Full, or when it is no longer in the sync.
• IS-IS: the adjacency is unhealthy when it is no longer in the sync.

Alerting is off for each neighbor by default. To alert on a neighbor, open its details page, turn on the alerting switch, and select a priority.

Alerting monitors

An alerting monitor checks a host or URL that is not tied to one device, such as a website or a cloud service. There are two kinds:

• Ping pings the host. The check fails if any packet is lost or the average latency is above the latency threshold (300 ms by default).
• Curl sends a request to the URL. The check fails if the request fails.

If you select a probe for the monitor, the probe runs the check from your network. If you do not select a probe, the ITVA platform runs the check from its own servers. Each monitor has its own threshold, interval, tags, and priority, and ITVA shows its uptime for the last 1, 7, and 30 days.

Probe unreachable

The ITVA platform polls each probe for diagnostics. If the probe does not respond, or sends a response that ITVA cannot read, the health check fails. ITVA alerts when enough health checks fail.

Vulnerability detected

ITVA alerts when a device has one or more open vulnerabilities. The incident lists a summary of each vulnerability, and resolves when no open vulnerabilities remain on the device.

To find vulnerabilities, the platform builds two CPE names for each device from the device sync: one for the OS version and one for the hardware model. The platform looks up CVEs for the OS in the NIST National Vulnerability Database (NVD). It keeps only the CVEs that also apply to the hardware. If ITVA cannot build both CPE names for a device, it does not check that device.

Thresholds and intervals

Most checks use two numbers. The interval is how many recent checks ITVA looks at. The threshold is how many of those checks must fail to open an incident.

For example, with a threshold of 2 and an interval of 3, ITVA opens an incident when 2 of the last 3 checks fail. The incident resolves when fewer than 2 of the last 3 checks fail. This stops one dropped check from opening an incident.

A new condition uses these defaults:

A check runs each time new data for it arrives, so the time an interval covers depends on your schedules. For example, CPU and memory checks run after each device sync. With an interval of 5 and a sync every 5 minutes, the check looks at the last 25 minutes.

Where the data comes from

Each check gets its data from one or more of three sources:

• Device: data that the device reports about itself during a sync. The probe connects to the device for the sync, but the data comes from the device.
• Probe: tests that the probe runs from your network, such as a ping or an HTTP request.
• Platform: tests that the ITVA platform runs itself, and data that you enter in ITVA.

Ping is the one test that can come from all three sources. A device ping monitor pings from the device. An alerting monitor of kind Ping pings from a probe if you select one, or from the platform if you do not. Use the source that matches the path you want to test.