ExtremeCloud IQ Site Engine (XIQ-SE) study materials
ExtremeCloud IQ Site Engine (XIQ-SE) study resources

ExtremeCloud IQ Site Engine (XIQ-SE): Monitoring, Alarms, Events, and Reporting

ExtremeCloud IQ Site Engine (XIQ-SE) · Work through your exam, one topic at a time.

All guide sections

Monitoring, Alarms, Events, and Reporting

Domain 7 tests whether you can turn telemetry into actionable signal: the events-versus-alarms distinction, threshold and trap-based alarm definitions, health dashboards, and scheduled FlexReports.

Events, alarms and health

  • Syslog and SNMP traps arrive as events - a raw, high-volume stream. Alarms are defined conditions layered on top: threshold alarms poll counters (CPU, memory, interface utilisation, temperature, PoE), while event alarms match traps or syslog patterns.
  • Every alarm definition carries severity (critical, major, minor, warning, info), scope, thresholds and duration, plus actions: email, syslog, SNMP trap, run workflow.
  • Acknowledging silences notification but does not clear. Clearing comes from the condition resolving (a clear trap, threshold recovery, or manual clear), and alarm history persists for reporting.

Dashboards and reports

  • Dashboards and health views combine availability, active alarms and device state for NOC display and for proving improvement over time.
  • FlexReports select a data source (devices, alarms, events, Control endpoints), columns, filters and sort order. They run against the database on a schedule and export PDF, CSV or HTML to a distribution list.
  • Trap reception requires devices configured to send to the server on 162, and syslog forwarding on 514. XIQ-SE cannot alarm on data it never received.

Worked example

An interface-utilisation alarm set at 80% never fires during short microbursts. The counter is polled every five minutes and the threshold evaluates the polled sample or average, so a two-minute 95% burst between polls is invisible. Fix it by shortening the poll interval where supported, enabling flow data for burst analysis, or alarming on a metric that captures the condition.

Traps that cost marks

  • Acknowledging an alarm and assuming it is resolved.
  • Defining an event alarm for a trap the device never sends.
  • Thresholds evaluated against averaged data hiding bursts.
  • Schedules failing silently after SMTP or file-share credentials change - check report history, not just the schedule.
  • Forgetting report timestamps follow server time zone.
  • Duplicate alarms raised by both trap and threshold definitions for one condition.