ServiceNow CIS-ITOM and CIS-Discovery - IT Operations Management Discovery Service Mapping Event Management

ServiceNow Cloud Discovery for AWS: (1) Cloud Account configuration — add AWS account credentials (IAM role or access key with read-only Discovery permissions) in ServiceNow Cloud Accounts; (2) Cloud Discovery schedules use AWS APIs directly from the ServiceNow instance (or via a MID Server with internet access) — no MID Server in the cloud required; (3) Discovers: EC2 instances (cmdb_ci_vm_instance), S3 buckets (cmdb_ci_s3_bucket), RDS instances, ELBs, VPCs, Security Groups; (4) Auto-scaling: new instances are discovered and added; terminated instances are marked "Absent" or retired in CMDB; (5) Runs frequently (hourly) to capture ephemeral cloud infrastructure changes. Installing MID Servers on each EC2 (option C) is impractical for auto-scaling environments. Weekly CSV imports (option D) are too infrequent for dynamic cloud environments.

Service Map-driven Change Impact Analysis: (1) Change Request "Affected CIs" includes the database server; (2) Change Impact Analysis: ServiceNow queries the CMDB service map relationships to find all Business Services that include this database as a dependency (directly or indirectly); (3) Impact Report: shows: Online Banking Service (depends on DB → App Server → DB), Customer Portal Service, Internal Reporting Service all will be affected; (4) This information is surfaced on the Change record for CAB review; (5) Scheduling: Change Manager selects a maintenance window outside peak usage for the most-affected business services; (6) Stakeholder notification: notified application owners are included in the approval chain. Manual spreadsheets (option D) become outdated immediately after any infrastructure change.

Service Mapping "Incomplete" status troubleshooting: (1) Service Mapping uses Patterns to trace connections from one CI to the next; (2) Pattern coverage gap: if no pattern exists for the connection type (e.g., custom middleware, uncommon database driver, encrypted proprietary protocol), tracing stops at that CI; (3) Fix: create or customize a Service Mapping pattern for the missing connection type; patterns use process-to-port mappings, connection table queries, or log file analysis to trace dependencies; (4) Credential gaps: if Service Mapping lacks credentials for a target CI (SSH/WMI), it can't trace within that CI; (5) Network blocking: if ports between CIs are blocked at the firewall, connection discovery fails; (6) Review "Service Mapping Results" for each incomplete entry to see the specific failure reason. Service Mapping has no hard CI count limit (option C). It traces many protocols beyond HTTP (option D).

CMDB duplicates during Discovery indicate IRE identification rule issues: (1) IRE Identification Rules define which attributes uniquely identify a CI class (e.g., cmdb_ci_linux_server identified by serial_number OR hostname + IP); (2) If the identification rule uses an attribute that Discovery doesn't populate correctly (e.g., serial number format mismatch), IRE can't match the incoming data to the existing CI and creates a duplicate; (3) Fix: navigate to CMDB Identification & Reconciliation, review the identification rules for the CI class, and ensure the identifying attributes are reliably populated by Discovery probes; (4) Run the CMDB Health Dashboard to identify all duplicate CIs; (5) Merge duplicates using the Duplicate CI remediation feature. Simply deleting one (option C) solves the symptom but not the root cause — Discovery will recreate the duplicate.

ITOM Event Management event processing pipeline: (1) Event Ingestion — events arrive via REST, SNMP, Syslog, or monitoring connectors (Dynatrace, Nagios, SolarWinds spokes); (2) Event Rules — filter, transform, and classify incoming events; (3) Deduplication — identical events (same CI, same condition) within a time window are deduplicated, counting occurrences rather than creating separate records; (4) CI Correlation — events are matched to CMDB CI records using IP, hostname, or source identifiers; (5) Alert Rules — correlated events for the same CI/service are grouped into a single Alert; (6) Alert Severity — maximum event severity sets the Alert severity; (7) 5,000 events might produce 50 meaningful Alerts. Only significant Alerts trigger incident creation. Direct incident creation (option A) creates alert storms that overwhelm the service desk.