Event Management
About 10% of the CIS-SM exam — see all 6 domains.
Service Mapping and Event Management are complementary ITOM capabilities; the exam tests the seam between them.
Why they pair
Event Management ingests events from monitoring tools, turns them into alerts (repeated events with the same message key update one alert), correlates related alerts, and then uses the dependency relationships built by Service Mapping to calculate service impact. Without a map, an alert is just a host problem; with a map, the platform can say which application service is degraded and how the fault propagates upward.
Impact and service health
- Alerts are bound to CIs; impact flows up the dependency tree that Service Mapping created, so a database alert can show as impacting the application service that depends on it.
- You can view active alerts directly on the application service map, seeing which CIs are affected and how relationships carry the impact.
- Event Management can show cross-service impact: how a degraded application service affects another application service that depends on it. Impact is calculated for application services (service instances), not for the Business Service class; to track several application services together, use a service group.
- Service health dashboards summarize the operational state of services using this combined data.
Self-health
Event Management includes a self-health application service map so operators can confirm Event Management's own components are healthy.
Fast-recall: Domain 4
- Event Management turns events into alerts (deduplicated by message key) and correlates related alerts; Service Mapping's relationships turn alerts into service impact.
- Impact propagates up the dependency tree; view active alerts on the application service map.
- Supports cross-service impact between dependent application services (not the Business Service class) and service health views.
- A self-health application service map monitors Event Management itself.
Sample questions from this domain
Three of the 30 in this domain, with the reasoning. The full set is in the question bank.
What is the primary input that Event Management processes?
- A. Alerts from Discovery, which are bound to CIs and correlated into incidents
- B. Discovery messages from the MID Server, which become alerts on the bound CI
- C. Incidents from the service desk, which are grouped into alerts by message key
- D. Events from monitoring tools, which are normalized and may become alerts ✓
Why: Event Management ingests events sent by monitoring tools and connectors, processes them through event rules and field mapping, and creates or updates alerts from them. Discovery does not send alerts into Event Management; it populates the CMDB that alerts bind to. Discovery messages are logged against a Discovery run and are not event input. Incidents are the output an operator or a rule can create from an alert, not the raw input, and the message key groups repeated events, not incidents.
What is the difference between an event and an alert in Event Management?
- A. An alert is a raw notification; an event is a deduplicated, actionable record created from one or more alerts
- B. An event is a notification bound to a CI; an alert is an incident created automatically for each new event received
- C. An event is a raw notification; an alert is a deduplicated, actionable record created from one or more events ✓
- D. An event is a group of correlated alerts; an alert is the single raw message that a monitoring tool sends
Why: An event is the raw notification a monitoring tool sends. Event Management processes events and creates an alert, an actionable record that repeated events with the same message key update instead of creating new ones. Reversing the two gets the flow backward. An alert is not an incident; an incident can be created from an alert by a rule or an operator, and repeated events do not each create one. Correlation groups alerts, not events, and the single raw message is the event.
How does Service Mapping enhance Event Management?
- A. By sending service map changes as events so that the resulting alerts show which tier was rediscovered
- B. By providing service context so alerts can be tied to the business/application services they impact ✓
- C. By setting each alert's message key from the service map so repeated events update one alert
- D. By creating the event rules that bind each incoming event to a CI found in the service map
Why: Service Mapping supplies the application service context: the CIs and relationships that make up each service. Event Management uses it to tie alerts on those CIs to the services they impact. Map changes are not sent as events. The message key comes from event fields (source, node, type, resource, metric) set by the monitoring tool or event rules, not from the map. Event rules are configured in Event Management by an administrator; Service Mapping does not create them.