View alerts
The Alerts table shows the most recently created alerts with no filtering.
See also Alerts API.
Alerts and alert details reference
The following table describes the alert attributes available in the alerts and the alert details tables.
Note
Unless otherwise noted, the term "events" refers to both ingested event notifications and metric anomalies.
Moogsoft stores all timestamps in UTC format. The dates and times displayed in the UI are based on your browser's local time.
Column | Description |
|---|---|
Active Incidents Count | The number of active incidents in which the alert is included. If you have multiple correlation definitions, one alert might fit multiple definitions and thus get included in multiple incidents. |
Alias | The alias for the alert source, as defined in the |
Assignee | The Moogsoft user currently assigned to investigate this alert. |
Class | The high-level category of the performance issue reported by the alert. Examples include If a metric anomaly does not have a |
Creation Time | The timestamp when Moogsoft ingested the first event, identified it as unique, and created the new alert. |
Description | Alert description, based on the |
Event Count | Number of events in the alert. |
First Event Time | The timestamp of the first event or anomaly added to the alert. |
ID | The alert ID. Moogsoft auto-generates the ID when it creates the alert. |
Incident Count | The number of incidents in which this alert is included. This number includes both open and resolved incidents. If you have multiple correlation definitions, one alert might match multiple definitions and be included in multiple incidents. |
Last Event Time | Timestamp of the most recent event included in the alert. |
Location | You can include generic geolocation information in the |
Manager | The generator or intermediary of the events in this alert. |
Manager ID | A machine-level reference to the manager. |
Service | The external application or service that generated the ingested event or metric. This is a required field for ingested events and is used to identify duplicate and similar events. |
Severity | Current severity of the alert, determined by the most recent event in the alert. |
Source | The node where the original events and/or anomalies occurred. This is typically an IP or fully-qualified domain name. |
Status | The alert status as specified by the Status pull-down menu in the Alert Details tab: Unassigned, Assigned, Acknowledged, etc. |
Tags | All optional tags included in this alert. You can specify tags during ingestion, or use event enrichment to add tags after ingestion. |
Searching and filtering alerts
You can do the following types of search:
Free-text search in the Global Search window in the top left.
"Smart look-ahead" filtering in the Incidents, Alerts, and Metrics tables. Place your cursor in the search field above the table. A pull-down menu shows the data fields or users that are valid for that position in the filter string.
After you validate a filter you can save, edit, reuse, and delete it as needed. You can also copy and paste a filter string into a relevant API request. You can define compound filters such as:
source in ("MCsource01", ["MCsource02") and severity in (Critical, Major, Minor)
Note the following:
It is good practice to use the smart-lookahead features to create your incident, alert, and metric filters.
Incident, alert, and metric filters support different sets of fields. This means that you cannot necessarily use filters across data types. The filter
service in (svc00, svc01)works for incidents and alerts but not for metrics, because incidents and alerts have aservicefield but metrics do not.