Splunk Integration

Aida integrates with Splunk Enterprise and Splunk Cloud so building OT and energy telemetry become visible alongside the rest of your IT/OT observability stack — and so facility workflows can eventually close the loop when Splunk detects issues.

This page describes why the integration exists, the primary data paths, and how that relates to where you run Aida Controller.

:::info Status Telemetry into Splunk (HEC export and Edge Hub lab paths) is available for evaluation and joint Cisco/Splunk demos. Controller HEC export and optional Platform proxy continue to roll out. Splunk → Aida automated actions is a later phase. :::

Purpose

Audience	What Splunk integration provides
IT / SOC / observability	Structured building events and metrics (cluster state, energy, device health) that traditional IT tools do not see
Facilities / OT	Correlation of lighting, shade, and energy behavior with environmental and site sensors when a Splunk Edge Hub is present
Joint Cisco + Splunk programs	A clear Visibility pillar: Aida produces trustable OT data; Splunk indexes, searches, and dashboards it

Aida Controller owns on-premises device control, local MQTT, and is the primary publisher of building event data to Splunk (direct HEC and/or Edge Hub MQTT).
Aida Platform owns multi-site tenancy, site configuration, and can act as a HEC proxy when the controller cannot reach a cloud or public Splunk instance.

Splunk does not replace the controller or the platform UI. It is a downstream system of record for analytics, alerting, and enterprise visibility.

Primary data paths

There are two supported families of path into Splunk. You can use either or both.

Who sends what

Path	Who can reach it	Typical sender
Direct HEC (local Splunk on LAN)	Controller only	Controller
Direct HEC (Splunk Cloud / public URL)	Controller and Platform	Controller primarily; Platform as proxy if the controller cannot reach Splunk
Edge Hub MQTT	On-site LAN clients only — Platform has no public route to the hub	Controller (or a thin LAN agent)

1. Direct HEC (recommended for Aida product data)

Controller → Splunk HTTP Event Collector (HEC)
(Platform only when acting as proxy to a reachable public/cloud HEC)

• The controller posts JSON events (batched) to your Splunk HEC endpoint with a token.
• Events use Aida sourcetypes such as aida:controller:event, aida:energy:metric, and aida:device:health, typically into an Aida-oriented index (for example aida_ot).
• Best for: curated product telemetry with site and controller identity, dashboards in the Aida Splunk app, and Cloud or Enterprise Splunk alike.

Sender	When to use
Controller	Default for event and metric export — works for on-LAN Splunk and for Splunk Cloud when the building can open outbound HEC
Platform (proxy)	Fallback when the controller cannot reach a cloud/public Splunk instance; Platform posts on the site’s behalf using stored HEC settings

2. Indirect — Edge Hub + Datastreamer

Controller → Splunk Edge Hub (MQTT) → Datastreamer → Splunk HEC

The Edge Hub MQTT broker is on the building LAN. The Aida Platform cloud cannot publish to it, so this path is controller-only (or another on-LAN agent).

• The controller (or a thin agent beside it) publishes JSON to the Edge Hub’s external MQTT broker.
• Splunk OT Intelligence Datastreamer on the hub ships selected topics to Splunk HEC.
• Data typically lands in Edge Hub indexes (for example edge_hub_logs / edge_hub_data) and can sit alongside native hub sensors (temperature, vibration, Modbus, OPC-UA, and so on).

Strength	Tradeoff
Uses the same OT fabric as other Edge Hub sensors	Extra hop; topic rules and Datastreamer must be configured
Hub can backlog when Splunk is briefly unreachable	Aida schema is carried in the payload; indexing is driven by hub/Datastreamer settings
Good for plant-floor / co-sell demos next to physical sensors	Not a substitute for clean direct-HEC product export

:::tip Lab note When validating low-rate MQTT samples through Datastreamer, use a small batch size (for example 1) so similar payloads are not held or deduplicated inside a large batch. :::

Where to run Aida Controller

Splunk Edge Hub hardware can run Docker containers (ARM64). That does not mean you should run the full Aida Controller stack on the hub.

Deployment	Suitability
Full Controller (API, Celery, Postgres, Redis, MQTT, UI, …)	Designed for a separate appliance or VM (for example Neeve Secure Edge, or your own server). Needs multi-GB RAM and durable storage.
On Splunk Edge Hub	Thin agent or slim worker only (for example MQTT/HEC bridge). Hub RAM (~8 GB on-device) is already shared with Edge Hub OS, sensors, Datastreamer, and optional AI containers.
Recommended production	Controllers on a dedicated deployment machine (or appliance). Edge Hub for OT sensors and optional controller publish into hub MQTT.

Recommended

  [Building LAN]
       │
       ├─ Aida Controller  (dedicated host / Neeve / VM)
       │       ├─ direct HEC ──────────────► Splunk (LAN or Cloud)
       │       └─ optional MQTT ──┐
       │                          ▼
       └─ Splunk Edge Hub  (sensors + Datastreamer)
                                  └─ Datastreamer HEC ─► Splunk

  [Cloud — only if controller cannot reach Splunk Cloud]
       Aida Platform ──proxy HEC──► Splunk Cloud

Do not plan to lift a full multi-container Controller image set onto the Edge Hub as a drop-in replacement for a normal controller deployment.

What you need on the Splunk side

• Splunk Cloud or Enterprise with HEC enabled and a token
• For Edge Hub path: registered hub, OT Intelligence, and a Datastreamer aimed at your HEC URL/token
• Optional: Aida OT Analytics Splunk app for Aida-oriented dashboards (install from your Aida Splunk package)

Related documentation

• Aida Controller overview — on-premises control plane
• Architecture overview — platform vs controller roles
• Engineering deep-dives (operators / implementers): Splunk integration planning in the platform repo and Edge Hub / data-channel docs in the aida_splunk package