Splunk excels at capturing, storing, and analysing high-volume machine data — logs, metrics, events — and generating alerts when patterns or thresholds are met. For teams that use Splunk heavily, it's often the most comprehensive source of application and security event data they have.
The limitation is that Splunk alerts live inside Splunk. Without a way to correlate them with infrastructure alerts from SolarWinds, Nagios, or cloud platforms, your team ends up with separate investigation workflows for application and infrastructure issues — even when they're related to the same root cause.
How Splunk alert forwarding works
Splunk provides a webhook mechanism that triggers an HTTP request each time an alert fires. By configuring a custom webhook action, you can forward Splunk alert data to an external system — including an event correlation engine — in real time.
The three standard endpoints for forwarding Splunk alerts to ECM are:
- The ECM Event REST API — recommended for most integrations
- The ECM Event SOAP API — for legacy environments
- ActiveMQ with the ECM ActiveMQ Connector — for high-volume or queued delivery scenarios
Setting up the webhook
The setup involves replicating Splunk's default webhook app action and creating a custom action that includes the ECM-required event fields. Splunk apps typically live in [SPLUNK_HOME]/etc/apps/. The custom action's script is modified to map Splunk alert fields to ECM event tokens, then configured via the Splunk UI with the target ECM API URL.
"Once Splunk alerts are flowing into ECM, they're treated exactly like any other event source — correlated against infrastructure and cloud alerts, not handled in isolation."
What changes once Splunk is connected
Once Splunk alerts are flowing into ECM, they're subject to the same deduplication and correlation rules as every other source. A Splunk application error alert and a related infrastructure alert from SolarWinds get grouped into a single incident. The correlation engine identifies which one is the root cause. One ticket gets created in ServiceNow or Jira — not two separate ones from two separate tools.
Where RightITnow ECM fits
RightITnow ECM accepts Splunk alerts via REST API, SOAP API, or ActiveMQ connector, and correlates them alongside events from SolarWinds, Nagios, Zabbix, Zenoss, Dynatrace, Datadog, and cloud platforms. Splunk-sourced events are treated as first-class inputs to the correlation engine.
The result: application-layer events from Splunk and infrastructure events from your monitoring tools are correlated together — so when a Splunk alert and an infrastructure alert are caused by the same root event, you see one incident, not two.