Events and Alerts

Use Events and Alerts for operational visibility:

• Events show what actions happened in the platform timeline.

• Alerts show conditions that need operator attention.

Objective

• Monitor platform activity quickly.

• Detect failures early.

• Capture enough context for escalation and troubleshooting.

Expected Operational Outcome

A new user can open both pages, identify risky rows, and extract the right context (resource, time, and state) for follow-up.

Completion Criteria

• You can review Events and Alerts dashboards confidently.

• You can open one event details page and read key fields.

• You can classify which rows need immediate action versus monitoring.

Events

When to Use Events

Use Events when you need a comprehensive audit log of platform actions, user activity, and operation outcomes.

Step: Review Events

When to Use:

Use this first when starting incident triage from the Events timeline.

Purpose:

Identify high-risk operation failures quickly and establish timeline context.

Steps:

1. Open Control Center -> Observability -> Events.

2. Confirm the events table is loaded with the latest rows.

3. Start triage with Level=ERROR and State=Failed to isolate high-risk operations first.

4. Expand to additional filters after initial triage.

Events dashboard.

Tip

Start with Level=ERROR + State=Failed first, then widen scope to include related WARNING and INFO rows.

Warning

Event history is policy-based and often time-limited. Capture required incident evidence in the same session.

Expected Outcome:

• You can identify high-risk rows quickly from state and level.

• You can explain what happened, who triggered it, and when.

If this fails:

1. Refresh the page.

2. Re-apply Level=ERROR and State=Failed filters.

Step: Open Events Help

When to Use:

Use this when column, state, or level meanings are unclear during triage.

Purpose:

Confirm page-specific field definitions before acting on results.

Steps:

1. On the Events page, click the help icon.

2. Review definitions for columns, state, and level meanings.

3. Return to the table and continue triage with the same filters.

Events help panel.

Expected Outcome:

• You can interpret Events fields consistently before filtering or escalation.

If this fails:

1. Refresh the page and reopen help.

2. Continue with field definitions from this guide if panel access is unavailable.

What the Events Table Shows

Column	Description
Type	Event/operation type (for example VM.CREATE, VM.DESTROY, FIREWALL.CLOSE, ISO.CREATE, VOLUME.CREATE). Click to filter by type.
State	Current operation status (Completed, Started, Scheduled, Created, Failed).
Level	Severity level (INFO, WARNING, ERROR).
Resource Type	Resource impacted by the event (for example VirtualMachine, Volume, Boot Image, Network).
Username	User who initiated the operation.
Account	Account associated with the event.
Domain	Domain/organizational scope for the event.
Created At	Event timestamp in DD/MM/YYYY HH:MM:SS format.

Event Type Reference

Category	Common types	What it tracks
VM operations	VM.CREATE, VM.START, VM.STOP, VM.DESTROY, VM.REBOOT, VM.MIGRATE, VM.SNAPSHOT	VM lifecycle and mobility operations.
Volume operations	VOLUME.CREATE, VOLUME.DELETE, VOLUME.ATTACH, VOLUME.DETACH, VOLUME.RESIZE	Volume provisioning and attachment lifecycle.
Network operations	FIREWALL.CREATE, FIREWALL.DELETE, FIREWALL.CLOSE, NETWORK.CREATE, NETWORK.DELETE	Network and firewall changes.
Storage operations	ISO.CREATE, ISO.DELETE, SNAPSHOT.CREATE, SNAPSHOT.DELETE (ISO.* events correspond to Boot Images actions in the UI)	Boot image and snapshot actions.
User/security operations	USER.CREATE, USER.DELETE, USER.UPDATE, LOGIN, LOGOUT	Identity and access-related events.
Infrastructure operations	CLUSTER.CREATE, CLUSTER.DELETE, HOST.ADD, HOST.REMOVE	Cluster/host lifecycle changes.
System operations	BACKUP, CONFIG.UPDATE, ALERT, ERROR	Platform-level maintenance and failure signals.

State and Level Reference

State badges:

State	Meaning	Operator guidance
Completed (green)	Operation finished successfully.	No immediate action unless additional validation is required.
Started (green)	Operation in progress.	Monitor to completion for long-running tasks.
Scheduled (yellow)	Operation queued; not started yet.	Verify prerequisites and resource availability if it remains queued.
Created (yellow)	Operation/resource created but not fully processed.	Check for required follow-up steps if it does not advance.
Failed (red)	Operation did not complete.	Investigate and remediate before rerun.

Level badges:

Level	Meaning	Operator guidance
INFO (green)	Normal informational signal.	Use for timeline/audit context.
WARNING (yellow)	Potential issue; recoverable condition.	Monitor and investigate if repeated.
ERROR (red)	Failed operation or critical issue.	Prioritize investigation and escalate when required.

Tooltip and UI Cues

Use these in-screen cues during triage:

• Type values are clickable for quick type filtering.

• State and Level badge colors provide immediate status/severity context.

• Created At gives precise sequencing for correlation with alerts and diagnostics.

• Pagination controls (page size, page navigation, result count) help navigate larger result sets.

Step: Filter and Search Events

When to Use:

Use this when raw event volume is too large for direct triage.

Purpose:

Narrow results to one action path or one incident window.

Steps:

1. Filter by Type to isolate one operation path (for example VM.CREATE).

2. Filter by Level to prioritize ERROR and WARNING rows.

3. Filter by State to focus on Failed or long-running states.

4. Filter by Resource Type to isolate VM, volume, network, or image operations.

5. Filter/search by Username for user-level activity tracking.

6. Apply date/time window filters for incident-window analysis.

7. Use keyword search for resource names, IDs, or specific strings.

8. Use pagination controls (page size + navigation) for larger datasets.

Expected Outcome:

• Results are narrowed to actionable rows without losing incident context.

If this fails:

1. Re-apply Level=ERROR and State=Failed.

2. Narrow the incident time window.

3. Filter by Resource Type or Username to isolate one action path.

4. Re-check with one additional correlated filter only (avoid over-filtering).

Step: Open Single Event Details

When to Use:

Use this after identifying a high-risk row that needs escalation context.

Purpose:

Capture event and resource metadata in one place for accurate handoff.

Steps:

1. From Events, open a target row (by clicking the event entry).

2. In Event Information, confirm:

• Type

• State

• Level

• Description

• Created At

3. In Resource Information, capture:

• Resource Type and Resource Name

• Resource ID

• Account / Username / Domain

4. Use these fields in incident tickets or escalation notes.

Warning

Failed operations can leave resources in partial state. Verify current resource state before retrying any operation.

Single event details view.

Expected Outcome:

• Type, State, Level, and Created At are captured.

• Resource ID and ownership context (account/user/domain) are captured.

• One escalation note can be written without returning to the table.

If this fails:

1. Reopen the event row from the filtered table.

2. Capture available metadata and continue with correlated alerts if detail data is partial.

Expected Outcome

• You can quickly isolate failed operations.

• You can produce an auditable timeline of who changed what and when.

• You can escalate with complete evidence (event + resource + ownership context).

Alerts

When to Use Alerts

Use Alerts when you need system-generated notifications for infrastructure events, thresholds, and operational issues.

Step: Review Alerts

When to Use:

Use this first when triaging active platform risk conditions.

Purpose:

Identify the highest-impact alerts and establish a response order.

Steps:

1. Open Control Center -> Observability -> Alerts.

2. Sort by Sent to start with most recent alerts.

3. Prioritize critical alert categories first (for example Host Down and VM Error).

4. Use filters and search to isolate related alerts before deep triage.

Alerts dashboard.

Tip

Sort by Sent first to assess current incident impact before reviewing older alerts.

Expected Outcome:

• High-risk alerts are identified and ranked.

• A clear action path exists for the highest-priority alert categories.

If this fails:

1. Clear filters and retry from newest rows.

2. Re-apply one filter at a time.

Step: Open Alerts Help

When to Use:

Use this when alert category meaning or operator action is unclear.

Purpose:

Confirm alert semantics and triage guidance before remediation decisions.

Steps:

1. On the Alerts page, click the help icon.

2. Review alert category guidance and triage context.

3. Return to the table and continue with type/search filters.

Alerts help panel.

Expected Outcome:

• You can map alert categories to appropriate response actions.

If this fails:

1. Refresh and reopen help.

2. Continue with alert type definitions from this guide.

What the Alerts Table Shows

Column	Description
Name	Short identifier/name of the alert.
Type	Alert category (for example Capacity, Memory, CPU, Storage, Host Down).
Description	Detailed trigger/context message for the alert.
Subject	Alert message summary.
Sent	Timestamp when the alert was generated/sent.

Alert Type Reference

Type	Description
Capacity	Overall resource capacity thresholds reached.
Memory	Physical/virtual memory usage exceeded limits.
CPU	Processor utilization is critically high.
Storage	Storage pool usage exceeded thresholds.
Storage Allocated	Allocated storage space is nearing limits.
Public IP	Public IP pool is nearing exhaustion.
Private IP	Private IP range is running low.
Host	Host node reported an issue.
VM Error	Virtual machine encountered an error.
Domain Router	Domain virtual router has an issue.
Console Proxy	Console proxy service is not responding.
Routing	Network routing issue detected.
Storage Misc	Miscellaneous storage subsystem issue.
Usage Server	Usage data collection server issue.
Management Node	Management server reported a problem.
Host Down	Host node is unresponsive/offline.
VM Migration	VM live migration encountered an error.
Secondary Storage	Image Storage reported an issue. This alert type still uses the legacy backend name Secondary Storage.
Usage Server Result	Usage server returned unexpected results.
Storage Delete	Storage deletion operation error.
Update Resource Count	Resource count update failed.
Usage Sanity Result	Usage sanity check found inconsistencies.
Direct Attached Public IP	Direct attached public IP issue detected.
Local Storage	Local (non-shared) storage issue.
Resource Limit	Account/domain resource limits are being approached.
Sync	Synchronization between components failed.
Upload Failed	Boot image/template upload operation failed.
VM Snapshot	VM snapshot operation failed.

Step: Filter and Search Alerts

When to Use:

Use this when alert volume is high and triage requires focused filtering.

Purpose:

Reduce alert noise to the affected service/resource and incident window.

Steps:

1. Use All Types to isolate a specific alert category.

2. Use search to filter by alert name/content (host, VM, storage pool, or other keywords).

3. Use Sent ordering to focus on the newest alerts first.

4. Narrow to a time window when investigating an incident.

Expected Outcome:

• Filtered results contain only actionable alerts for the current incident path.

If this fails:

1. Keep only one Type filter active.

2. Add one keyword for the affected resource.

3. Reduce to the exact incident window.

Step: Prioritize and Recheck Alerts

When to Use:

Use this after filtering alerts to decide response order and verify recurrence.

Purpose:

Apply a consistent triage sequence and confirm remediation effectiveness.

Steps:

1. Prioritize Host Down and VM Error first (highest service-impact risk).

2. Prioritize Capacity and Storage next (resource planning and risk mitigation).

3. Prioritize Memory and CPU for workload balancing and scaling actions.

4. Track Resource Limit for proactive quota expansion before operations are blocked.

Warning

Alerts do not resolve by themselves in workflow terms; address root cause and verify recurrence has stopped.

Expected Outcome:

• Alert triage order is clear and active-risk items are worked first.

If this fails:

1. Confirm new Sent timestamps are still appearing.

2. Re-check dependencies and recent changes.

3. Escalate with alert IDs and timestamps.

Expected Outcome

• You can identify which alert categories are highest risk.

• You can filter quickly to the affected resources and time window.

• You can apply a consistent triage process and verify recurrence is resolved.