Multi-sending OTel

Many SOC teams want their AI-tool telemetry in their existing SIEM alongside their other security data. The OpenTelemetry Collector supports fan-out natively — a single pipeline can have multiple exporters — so customers can send the same events to both Arrakis and their SIEM without device-side duplication. This page covers the two architectural modes, when to choose each, and verified sample collector configs for the most common SIEMs.

Two architectural modes

Mode A — Arrakis primary, fan-out to your SIEM


[Devices / agents] --OTLP--> [Arrakis OTel gateway] --+--> [Arrakis ingest]
                                                      |
                                                      +--> [Customer SIEM]
                                                            (Splunk · Datadog ·
                                                             Sentinel · Elastic)

Every developer endpoint sends OTLP to a single Arrakis-hosted endpoint. Arrakis ingests for its own analysis and exports a copy to the customer’s SIEM via the relevant SIEM exporter. Arrakis owns the fan-out reliability — retries, persistent queues, batching.

Pros: single endpoint URL on every device (simplest day-1 onboarding); Arrakis owns fan-out reliability; central place for redaction processors. Cons: PII transits Arrakis before SIEM (compliance acceptance required); Arrakis is a single point of failure for SIEM ingestion; Arrakis stores customer SIEM credentials.

Mode B — Your collector primary, fan-out to Arrakis


[Devices / agents] --OTLP--> [Customer OTel collector] --+--> [Customer SIEM]
                                                         |
                                                         +--> [Arrakis ingest]

The customer’s existing OTel collector receives from devices and forwards a copy to Arrakis via an otlphttp exporter. Best fit for customers who already operate a perimeter collector for their SIEM.

Pros: data never crosses Arrakis until customer collector forwards; reuses existing infra; independent failure domains; SIEM credentials stay customer-side. Cons: customer operates and patches a collector deployment; latency bounded by their batching/queue config; Arrakis must publish and version a collector config snippet; harder to guarantee delivery.

Decision tree

Question	Lean Mode A	Lean Mode B
Customer already runs an OTel collector?	No	Yes
Compliance forbids third-party processors before SIEM?	No	Yes
Want Arrakis isolated from SIEM uptime?	No	Yes
Endpoint-config simplicity is the priority?	Yes	No
Need sub-second end-to-end latency for Arrakis correlations?	Yes	No

A pragmatic default is to offer both modes and let security architecture choose. Many large deployments converge on Mode B because it co-locates the fan-out with an existing customer-perimeter gateway.

Sample collector configurations

All four configurations use the same shared receiver block (one OTLP receiver on 4317/4318), one batch processor, and two exporters per pipeline (Arrakis + SIEM). Replace placeholders (<arrakis-tenant>, <arrakis-token>, <splunk-host>, <splunk-hec-token>, <datadog-site>, etc.) with values from your Arrakis tenant and your SIEM provider.

Splunk

Recommended exporter: splunk_hec (https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/splunkhecexporter ). For Splunk Observability Cloud customers, use the Splunk Distribution of the OpenTelemetry Collector instead (https://github.com/signalfx/splunk-otel-collector ).


receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
 
processors:
  batch: {}
 
exporters:
  otlphttp/arrakis:
    endpoint: https://ingest.arrakis.security/otlp/<arrakis-tenant>
    headers:
      Authorization: "Bearer ${env:ARRAKIS_TOKEN}"
  splunk_hec/customer:
    endpoint: https://<splunk-host>:8088/services/collector
    token: ${env:SPLUNK_HEC_TOKEN}
    source: arrakis
    sourcetype: otel
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, splunk_hec/customer]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, splunk_hec/customer]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, splunk_hec/customer]

Splunk Enterprise and Splunk Cloud customers want HEC. Splunk Observability Cloud uses a different ingest path and needs the SignalFx-flavored collector with realm-specific endpoints (https://ingest.<realm>.observability.splunkcloud.com) — a signalfx exporter for metrics and otlphttp for traces and logs.

Datadog

Recommended exporter: datadog (https://docs.datadoghq.com/opentelemetry/setup/collector_exporter/install/ ). Auth: API key + site (e.g., datadoghq.com, eu.datadoghq.com).


receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
 
processors:
  batch: {}
 
exporters:
  otlphttp/arrakis:
    endpoint: https://ingest.arrakis.security/otlp/<arrakis-tenant>
    headers:
      Authorization: "Bearer ${env:ARRAKIS_TOKEN}"
  datadog/customer:
    api:
      site: <datadog-site>
      key: ${env:DATADOG_API_KEY}
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, datadog/customer]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, datadog/customer]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, datadog/customer]

There is no stable public “raw OTLP” endpoint at Datadog. Always use the datadog exporter or the Datadog Agent’s OTLP receiver — those are the two supported ingest paths.

Microsoft Sentinel / Azure Monitor

Recommended exporter: azuremonitor (https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/azuremonitorexporter ), which writes to Application Insights via a connection string.


receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
 
processors:
  batch: {}
 
exporters:
  otlphttp/arrakis:
    endpoint: https://ingest.arrakis.security/otlp/<arrakis-tenant>
    headers:
      Authorization: "Bearer ${env:ARRAKIS_TOKEN}"
  azuremonitor/customer:
    connection_string: ${env:APPLICATIONINSIGHTS_CONNECTION_STRING}
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, azuremonitor/customer]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, azuremonitor/customer]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, azuremonitor/customer]

The azuremonitor exporter targets Application Insights tables, NOT Sentinel-native security tables (SecurityEvent, CommonSecurityLog). For ingestion into custom Sentinel tables, customers need to pair an OTel collector with the Logs Ingestion API and a Data Collection Rule (DCR). That path is better treated as Mode B with a thin custom forwarder.

Elastic

Recommended path: APM Server’s native OTLP endpoint (https://www.elastic.co/guide/en/observability/current/apm-open-telemetry-direct.html ). Auth: Bearer secret token or ApiKey header.


receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
 
processors:
  batch: {}
 
exporters:
  otlphttp/arrakis:
    endpoint: https://ingest.arrakis.security/otlp/<arrakis-tenant>
    headers:
      Authorization: "Bearer ${env:ARRAKIS_TOKEN}"
  otlp/elastic:
    endpoint: https://<elastic-deployment>.apm.<elastic-region>.elastic-cloud.com:443
    headers:
      Authorization: "ApiKey ${env:ELASTIC_API_KEY}"
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, otlp/elastic]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, otlp/elastic]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/arrakis, otlp/elastic]

A direct-to-Elasticsearch alternative exists via the elasticsearch exporter for logs-heavy SIEM use cases — point it at https://<es-host>:9200 with Basic or api_key auth.

Cross-vendor summary

Vendor	Recommended exporter	Endpoint pattern	Auth
Splunk Enterprise / Cloud	`splunk_hec`	`https://<host>:8088/services/collector`	HEC token
Splunk Observability Cloud	`otlphttp` / `signalfx`	`https://ingest.<realm>.observability.splunkcloud.com`	SignalFx access token
Datadog	`datadog`	(handled by exporter; choose `site`)	API key + site
Azure Monitor / App Insights	`azuremonitor`	per-region connection string	InstrumentationKey + ingestion URL
Microsoft Sentinel (custom tables)	Logs Ingestion API + DCR	per-DCR ingestion URL	Entra app + DCR
Elastic APM	`otlp` (gRPC/HTTP)	`https://<deployment>.apm.<region>.elastic-cloud.com:443`	Bearer or `ApiKey`
Elasticsearch direct	`elasticsearch`	`https://<es-host>:9200`	Basic / `api_key`

Reliability defaults

For customer-perimeter collectors (Mode B), enable the file_storage extension with at least 5 GiB queue rather than rely on collector defaults — telemetry batches will be persisted across collector restarts. For Mode A, Arrakis runs the fan-out collector and applies its own reliability config; customer SIEM credentials are stored per-tenant in KMS with rotation.

Where Arrakis-specific values come from

Arrakis ingest hostname, bearer token, and recommended OTEL_RESOURCE_ATTRIBUTES for your tenant are provisioned in the Arrakis platform under Settings → Integrations → Deployment. SIEM exporter credentials (Splunk HEC token, Datadog API key, Azure connection string, Elastic API key) are customer-side secrets — paste them into the customer collector’s environment, never into Arrakis-side config.

Cross-references

OTel Collector & Arrakis Endpoint — endpoint, auth, and connectivity probes
MDM Sync & Change Management — pushing the collector config update via MDM
Offboarding — clean shutoff when disconnecting