Section 4 — Demonstrate and Understand of Platform Health and Monitoring

Objective 4.1 Perform and interpret a health check

4.1.1 Perform log collections

Collect logs from Prism Element (Health → Actions → Collect Logs), or with Logbay on a CVM. Pick a time window and components, then upload the bundle to the support case. Alert-triggered log collection can gather logs automatically when certain alerts fire.

logbay collect --duration=-4h

4.1.2 Perform NCC Checks

NCC (Nutanix Cluster Check) is the health-check framework. Run it from Prism Element (Health → Actions → Run NCC Checks) or from a CVM. You can schedule how often it runs and have results emailed to you, which needs SMTP.

ncc health_checks run_all

4.1.3 Determine the cluster status

Determine the cluster status from the Home dashboard's health widget (the heart turns red when something is critical) and the Health dashboard, which lists every failing check by entity. On a CVM, cluster status shows each service on each CVM.

MEMORISE

A red heart in Prism Element means open the Health dashboard to isolate the cause.

4.1.4 Demonstrate understanding of the difference in Metric and Entity Charts

In the Analysis dashboard:
- A Metric chart shows one metric across several entities, for example logical usage for three containers on one chart.
- An Entity chart shows several metrics for one entity, for example one VM's CPU, memory and IOPS.

TIP

To see whether memory load has historically been spread evenly across an application's VMs, chart their memory usage in Analysis. An alert policy or a filtered list only shows you the present.

Official docs for 4.1 (10)

Objective 4.2 Review and interpret alerts and events

4 cards practice questions

4.2.1 Verify Pulse Status

Pulse sends cluster health and configuration telemetry to Nutanix (Insights). Check its status in Prism Element or Prism Central settings, under Pulse.

4.2.2 Describe the benefits of Pulse

Pulse lets Nutanix spot known issues on your cluster proactively, feeds Insights / Discoveries, and speeds up support cases. Data obfuscation masks identifying names and IPs before they are sent.

TRAP

Disable Pulse only under the guidance of Nutanix Support.

4.2.3 Determine use cases for Custom Alert Policies

Custom alert policies in Prism Central set your own thresholds on metrics for an entity type, for example VM memory above 90% for 10 minutes, and notify you when they're crossed. Use them when the built-in alerts don't cover your service-level objective.

4.2.4 Distinguish Alert Severity

Alert severities are Critical, Warning and Info. Critical means act now (service or data at risk). Warning means degradation or a coming problem. Info is a notice.

4.2.5 Given an alert, determine impact and plan a resolution

To handle an alert: read its details (impact, cause, resolution steps, linked KB), check related alerts and events, then fix and resolve it. Forward alerts to a remote syslog server. Reports in Prism Central can be scheduled, for example a weekly VM performance report emailed to app owners.

Official docs for 4.2 (10)

Objective 4.3 Leverage support functions

2 cards practice questions

4.3.1 Describe how to create a support case

Open a case on the Nutanix Support Portal. Pick the priority by impact. P1 means production is down. P2, P3 and P4 are degraded through low impact. The priority sets the target response time.

4.3.2 Identify the required documentation for support cases

Have these ready: the cluster ID / block serial, AOS / hypervisor / NCC versions, NCC output, a log bundle covering the problem window, alert details, and the steps to reproduce.

4.3.3 Identify the various Documentation types

Documentation types: software documentation (admin guides), KB articles, release notes, solutions / best-practice guides and tech notes, the compatibility matrix, and hardware docs.

4.3.4 Leverage Insights for predictive health and support automation

Insights uses Pulse data to give predictive health. Discoveries flag clusters affected by known issues, and support can open cases proactively.

MEMORISE

Discoveries on the support portal identify clusters affected by known issues.

Official docs for 4.3 (7)

Objective 4.4 Review and interpret workload performance

3 cards practice questions

4.4.1 Based on Prism analytics/metrics, recognize potential oversubscription or contention issues, such as: CPU contention, CPU ready, Memory constraints, I/O latency

Use Prism's Analysis charts and the VM performance tabs to spot contention:
- CPU contention / CPU ready: high CPU ready time means a vCPU was ready to run but waited for a physical core. Sustained ready time points to oversubscription, too many vCPUs, or a busy host. Read the Interpreting CPU Ready values page for the thresholds.
- Memory: high usage, swapping, or overcommitted memory on AHV hosts.
- I/O latency: watch controller latency next to IOPS.

TRAP

Latency spikes when IOPS are low are often harmless. A handful of large I/Os skews the average. Look at latency together with IOPS.

TIP

ADS (Acropolis Dynamic Scheduling) watches AHV hosts for CPU and storage-controller hotspots over time and live-migrates VMs to balance them. The behavioural learning in Prism Central (anomaly detection, capacity runway) helps you spot trends before they become alerts.

Official docs for 4.4 (10)

Section 4 Demonstrate and Understand of Platform Health and Monitoring

Objective 4.1 Perform and interpret a health check

4.1.1 Perform log collections ○◐●

4.1.2 Perform NCC Checks ○◐●

4.1.3 Determine the cluster status ○◐●

4.1.4 Demonstrate understanding of the difference in Metric and Entity Charts ○◐●

Objective 4.2 Review and interpret alerts and events

4.2.1 Verify Pulse Status ○◐●

4.2.2 Describe the benefits of Pulse ○◐●

4.2.3 Determine use cases for Custom Alert Policies ○◐●

4.2.4 Distinguish Alert Severity ○◐●

4.2.5 Given an alert, determine impact and plan a resolution ○◐●