Skip to content

feat(integrations): Splunk data source + anomaly forwarding (#99) - #145

Draft
Jovonni wants to merge 1 commit into
masterfrom
feat/splunk-integration
Draft

feat(integrations): Splunk data source + anomaly forwarding (#99)#145
Jovonni wants to merge 1 commit into
masterfrom
feat/splunk-integration

Conversation

@Jovonni

@Jovonni Jovonni commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

What

Integrates Splunk in both directions (requested in #99):

  • Input — run a Splunk search and feed the results to a model as a data source.
  • Output — forward detected anomalies back to Splunk via HEC.

How it reuses existing infrastructure

  • SplunkConnector (core/integrations/splunk.py) sits alongside ElasticsearchConnector / SparkConnector — REST export search for input, HTTP Event Collector for output, bearer or basic auth. Config via integration_settings (from_config) or SPLUNK_* env.
  • Model runner gains a splunk branch in _load_data_for_model, mirroring the elasticsearch branch (self-contained requests, returns a DataFrame with numeric coercion).
  • train/execute endpoints get splunk_search / splunk_index params + a dispatch branch, exactly like the existing spark / elasticsearch / source_group sources.
  • Orchestrator forwards each inference run's anomalies to Splunk HEC when forward_anomalies is enabled — best-effort, so a Splunk outage never affects detection or persistence.
  • Settings: splunk registered in the whitelist, secrets (token/hec_token/password) masked, /test connectivity probe, and a Splunk card in the Data Engines settings panel.
  • Docs: docs/SPLUNK.md.

Tests (dedicated subsuite, CI-wired)

core/tests/test_services/test_splunk_connector.py + test_splunk_wiring.py26 unit tests, all mocked (no live Splunk): SPL normalization, search parsing + bearer/basic auth, error handling, HEC output + auth header, batch send counts, connectivity probe, settings whitelist/masking/_test_splunk, and orchestrator forwarding gating (enabled/disabled/flag-off/error-safe). Placed under test_services/ so they run in the CI unit job (the -k filter excludes anything under test_integrations/).

Local: 26/26 green, runner compiles, tsc/next lint/next build all clean.

Follow-up (not in this PR)

Splunk-as-a-physical-source inside source_groups (so a source group can mix Splunk with other sources) is a natural next step.

Closes #99

Adds a bidirectional Splunk integration, reusing the existing connector /
data-source / integration-settings patterns:

- SplunkConnector (core/integrations): REST export search (input) + HTTP Event
  Collector (output), bearer or basic auth, env + integration_settings config
- model runner: 'splunk' data_source branch runs an SPL search and returns a
  DataFrame (self-contained, mirrors the elasticsearch branch)
- models train/execute: splunk_search / splunk_index params + dispatch
- orchestrator: best-effort forward of each run's anomalies to Splunk HEC when
  enabled (forward_anomalies), never blocking detection
- settings: register 'splunk', mask token/hec_token/password, /test probe
- settings UI: Splunk card under Data Engines
- docs/SPLUNK.md
- dedicated test subsuite (26 unit tests, fully mocked, runs in the CI unit job)

Closes #99
@Jovonni Jovonni mentioned this pull request Aug 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

integrate with splunk

1 participant