13.2 Custom Alert Policies and Behavioural Anomaly Detection

13.2 Custom Alert Policies and Behavioural Anomaly Detection

Section 8.1 covered the built-in alert and health engine — the several hundred checks Nutanix ships that watch the platform itself. Objective 4.2 asks for something different: "determine use cases for Custom Alert Policies."

Why Built-In Checks Are Not Enough

Built-in checks are about the platform: a drive failing, a service down, capacity approaching a limit, a node unreachable. They are excellent at that and they are the same on every Nutanix cluster in the world.

What they cannot know is your context:

• That this particular VM is a payments gateway where 20 ms of storage latency is a customer-visible problem, while the same latency on a build server is irrelevant.
• That your batch window runs 01:00 to 04:00 and CPU saturation during it is expected, not alarming.
• That a specific application must never exceed a memory ceiling agreed with its vendor.

A custom alert policy encodes that context.

Anatomy of a Custom Alert Policy

Created in Prism Central, a policy has four parts:

Scope by category is the important design decision

This is where categories (section 3.2) pay for themselves. A policy scoped to Environment: Production applies to every production VM automatically, including ones created next month. A policy scoped to Environment: Development can carry looser thresholds on the same cluster.

Building a policy against a hand-picked list of VMs instead means the policy silently stops covering new workloads — the classic way monitoring quietly decays.

Static Thresholds vs. Behavioural Anomaly Detection

Two ways to define "wrong," and choosing correctly is the substance of this objective.

Static thresholds

"Alert when this metric crosses this number."

Right when a specific value genuinely matters regardless of context:

• A contractual or vendor-mandated limit.
• A hard capacity ceiling.
• A known application breaking point.

Wrong when normal varies. A static CPU threshold on a workload that is idle at night and saturated during a batch window either fires every night or never fires at all — there is no single number that is correct at both times.

Behavioural anomaly detection

"Alert when this metric departs from what is normal for this entity, at this time."

The platform learns each entity's pattern over time — including time-of-day and day-of-week rhythms — and flags deviation from that learned band rather than from a fixed number.

Right when:

• Normal is genuinely cyclical (batch windows, business hours, month-end).
• You do not know what the correct threshold is, which is common for a new application.
• You want to catch a workload behaving unusually even while still inside acceptable absolute limits — the early signal a static threshold cannot give.

The blueprint references "Behavioral Learning Tools" under Objective 4.4 for exactly this. The richer behavioural and predictive capability, including capacity forecasting, belongs to NCM Intelligent Operations and its X-Fit engine (section 1.3).

[!TIP] Exam discriminator: if a scenario describes a workload whose normal load varies predictably by time, the answer is behavioural anomaly detection. If it describes a fixed limit that must not be crossed, the answer is a static threshold.

Choosing Severity Deliberately

Nutanix classifies alerts as Critical, Warning, or Info. Severity is not decoration — it determines what gets escalated and what gets ignored.

The failure mode to avoid is alert fatigue. A cluster that raises forty Critical alerts a day has effectively no Critical alerts, because nobody reads them. Marking a genuinely urgent condition as Warning is equally bad in the other direction.

Given an Alert, Determine Impact and Plan a Resolution

The last knowledge statement under Objective 4.2 asks you to reason from an alert to an action. A workable order:

1. Read the severity and the entity. What is affected, and how urgently?
2. Assess impact. Is a workload degraded now, is resiliency reduced, or is this a forward-looking warning?
3. Check whether it will auto-resolve. Many Nutanix alerts clear themselves when the underlying condition passes (section 8.1); a transient condition may need no action.
4. Correlate. Use an entity chart (section 13.1) to see what else was happening on that object at that time.
5. Run the relevant NCC check for a targeted diagnosis (section 8.2).
6. Act, or escalate — collect logs and open a support case (section 13.4) if the cause is not clear.

Note how the parts connect: alerts point to an entity, charts explain the entity, NCC diagnoses the platform, and support takes over what remains.