Ship Kestra logs to Splunk

Stream Kestra execution logs into Splunk on a daily schedule using the Enterprise Edition LogShipper task with the Splunk LogExporter. This system flow consolidates orchestration telemetry into your existing Splunk Cloud or Splunk Enterprise instance so SREs, platform teams, and security analysts can query, alert, and build dashboards on workflow activity alongside the rest of their infrastructure logs. Instead of polling Kestra's API or scraping logs by hand, the flow tracks an offset, picks up only new entries, and pushes them to Splunk's HTTP Event Collector (HEC).

How it works

1. The daily trigger (io.kestra.plugin.core.trigger.Schedule with cron @daily) fires the flow once every 24 hours.
2. The log_export task (io.kestra.plugin.ee.core.log.LogShipper) queries Kestra logs for the past day. It uses logLevelFilter: INFO to capture INFO and higher severities, lookbackPeriod: P1D to bound the initial window, and offsetKey: logShipperOffset to persist a cursor between runs so events are never duplicated or skipped.
3. delete: false keeps the original logs inside Kestra after shipping, preserving the in-product execution view.
4. The configured SplunkLogExporter (io.kestra.plugin.ee.splunk.LogExporter) posts each log event to your Splunk HEC endpoint (host) authenticated with an HEC token sourced from {{ secret('SPLUNK_API_KEY') }}.

What you get

• Daily, incremental shipment of Kestra logs into Splunk with offset tracking.
• Centralized observability across orchestration, applications, and infrastructure.
• Source data for SPL searches, dashboards, alerts, and SOC investigations.
• An auditable trail of workflow activity stored in your existing SIEM.

Who it's for

• Platform and SRE teams running Kestra Enterprise alongside Splunk.
• Security and compliance teams that need orchestration logs in their SIEM.
• Data and observability engineers building unified dashboards.

Why orchestrate this with Kestra

Splunk's own ingestion pipelines do not know when a Kestra execution started, retried, or failed, and they cannot reach inside Kestra to pull internal log streams. Running the shipper as a Kestra flow gives you declarative YAML, schedule and event triggers, automatic retries on transient HEC errors, full execution lineage, and the ability to chain follow-up tasks (for example, raising a PagerDuty alert) if log delivery fails. The offset key handled by LogShipper removes the need for an external bookmark store.

Prerequisites

• Kestra Enterprise Edition (this flow uses EE-only plugins).
• A Splunk Cloud or Splunk Enterprise instance with the HTTP Event Collector enabled.
• An HEC token with permission to write to your target index.

Secrets

• SPLUNK_API_KEY: Splunk HEC token used to authenticate against the HEC endpoint.

Quick start

1. Enable and configure HEC in Splunk, then create a token scoped to the index that should receive Kestra logs.
2. Add SPLUNK_API_KEY as a Kestra secret in the target tenant or namespace.
3. Replace the host value (https://example.splunkcloud.com:8088) with your real HEC endpoint.
4. Deploy the flow to the system namespace and let the @daily schedule run, or trigger it manually for the first execution.
5. Search index=<your_index> in Splunk to confirm Kestra events are arriving.

How to extend

• Tighten or relax logLevelFilter (for example, WARN for noisy environments, DEBUG for deep troubleshooting).
• Shorten the cron to */15 * * * * or @hourly for near real time shipping.
• Add more entries under logExporters to fan out the same logs to additional destinations such as Elasticsearch, Datadog, or cloud object storage.
• Set delete: true once you are confident in Splunk retention to reduce Kestra storage.
• Wrap the task with errors: handlers that notify Slack or PagerDuty when shipping fails.

Links

• Plugin docs: https://kestra.io/plugins/plugin-ee-splunk
• Log shipper plugin: https://kestra.io/plugins/plugin-ee