**Related issue:** Resolves #25574 # Checklist for submitter - [x] Changes file added for user-visible changes in `changes/` - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually --- ## Summary - Adds a new `splunk` log plugin that sends osquery logs directly to Splunk's HTTP Event Collector (HEC) endpoint - Eliminates the need for middleware like AWS Firehose when using Splunk as a log destination - Follows the same pattern as existing log destinations (Firehose, Kafka REST, NATS, etc.) - Includes `insecure_skip_verify` option for environments with self-signed TLS certs ## UI changes Follows the same pattern as the NATS log destination PR (#36527) -- adding "Splunk" to the display name, tooltip, and TypeScript type union. No new components, pages, or styles. ### Manage automations modal -- "Log destination: Splunk" <img width="822" height="527" alt="image" src="https://github.com/user-attachments/assets/2533207f-fa95-4364-8ee0-3c39cd3e8e4d" /> ### Query details page -- "Log destination: Splunk" <img width="1905" height="662" alt="image" src="https://github.com/user-attachments/assets/069a5005-f95c-4562-a819-fd8bdcc349f7" /> ### Tooltip on hover <img width="639" height="348" alt="image" src="https://github.com/user-attachments/assets/809a47a6-b82a-4f45-b731-77b2d2c87947" /> ### Edit query form -- "sent to your log destination: Splunk" <img width="451" height="814" alt="image" src="https://github.com/user-attachments/assets/b78b9a57-1f0c-4413-8b7c-654de1fd40a2" /> ### Save new query modal -- "sent to your log destination: Splunk" <img width="536" height="698" alt="image" src="https://github.com/user-attachments/assets/d0a0ab01-66fe-4d63-9190-9c5e840e456d" /> --- ### How it works The Splunk writer (`server/logging/splunk.go`) implements the `fleet.JSONLogger` interface. On startup it performs a health check against the HEC `/services/collector/health` endpoint. On each `Write()` call, it wraps each log entry in Splunk's HEC event format (adding `time`, `index`, `source`, `sourcetype`), batches them up to 1 MB, and POSTs to `/services/collector/event` with the `Authorization: Splunk <token>` header. If a batch exceeds 1 MB it flushes and starts a new one. Events over 1 MB are dropped with a log warning. Transient errors (HTTP 503) are retried with exponential backoff (up to 8 retries). ### Configuration ```yaml osquery: status_log_plugin: splunk result_log_plugin: splunk splunk: url: https://splunk.example.com:8088 token: <HEC token> index: main source: fleet source_type: fleet:json insecure_skip_verify: false # set true for self-signed certs ``` Or via environment variables: ``` FLEET_OSQUERY_STATUS_LOG_PLUGIN=splunk FLEET_OSQUERY_RESULT_LOG_PLUGIN=splunk FLEET_SPLUNK_URL=https://splunk.example.com:8088 FLEET_SPLUNK_TOKEN=<HEC token> FLEET_SPLUNK_INDEX=main FLEET_SPLUNK_SOURCE=fleet FLEET_SPLUNK_SOURCE_TYPE=fleet:json ``` ### Files changed - `server/logging/splunk.go` -- Splunk HEC log writer with batching, retry, and health check - `server/logging/splunk_test.go` -- 9 unit tests - `server/logging/splunk_integration_test.go` -- 3 integration tests against real Splunk (gated by env var) - `server/logging/logging.go` -- Added `SplunkConfig` and `case "splunk"` to factory - `server/config/config.go` -- Added `SplunkConfig` struct and config flags - `cmd/fleet/logging.go` -- Wired Splunk config into logging builder - `server/fleet/app.go` -- Added `SplunkConfig` type for API responses (excludes token) - `server/service/service_appconfig.go` -- Added `case "splunk"` to logging plugin validation - `frontend/interfaces/config.ts` -- Added `"splunk"` to LogDestination type - `frontend/components/LogDestinationIndicator/LogDestinationIndicator.tsx` -- Added Splunk display name and tooltip - `docs/Configuration/fleet-server-configuration.md` -- Splunk config documentation - `docs/Get started/FAQ.md` -- Updated plugin list - `articles/log-destinations.md` -- Updated Splunk section with native HEC docs - `changes/25574-splunk-log-destination` -- Change file ## Test plan ### Unit tests (9 tests) - [x] `TestSplunkWrite` -- sends 3 events, verifies HEC format, auth header, index/source/sourcetype - [x] `TestSplunkWriteEmpty` -- empty logs don't trigger HTTP request - [x] `TestSplunkServerError` -- HEC 403 propagates as error - [x] `TestSplunkHealthCheckFailure` -- constructor fails on bad health - [x] `TestSplunkRecordTooBig` -- oversized events (>1MB) are dropped, normal events still sent - [x] `TestSplunkSplitBatchBySize` -- logs exceeding 1MB batch limit are split into multiple requests - [x] `TestSplunkRetryOnServiceUnavailable` -- 503 retried with backoff, succeeds on 3rd attempt - [x] `TestSplunkRetryExhausted` -- after 9 attempts (1 + 8 retries) returns error - [x] `TestSplunkMissingConfig` -- empty URL/token returns descriptive error ### Integration tests (3 tests, gated by `SPLUNK_INTEGRATION_TEST=1`) - [x] `TestSplunkIntegration` -- 3 events sent via writer, queried back from Splunk REST API - [x] `TestSplunkIntegrationBatch` -- 100 events in one Write(), all confirmed indexed - [x] `TestSplunkIntegrationBadToken` -- bad token Write() returns 403 ### End-to-end test (macOS ARM64, real osquery agent) 1. Started Splunk Enterprise, MySQL, Redis via Docker 2. Built Fleet server from this branch with `--osquery_status_log_plugin=splunk` 3. Set up Fleet, enrolled a real osquery 5.23.0 agent on this MacBook 4. **83 real osquery status log events indexed in Splunk** with correct source/sourcetype/index 5. Each event contained full osquery data (`hostIdentifier`, `host_uuid`, `calendarTime`, `severity`, `message`, `decorations`) ### Splunk showing real osquery events from Fleet <img width="1910" height="861" alt="image" src="https://github.com/user-attachments/assets/192490bf-d594-4424-a3e3-a18306892873" /> Generated with [Claude Code](https://claude.ai/code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added native Splunk HEC logging destination for status, result, and audit logs. * Updated the log destination UI to display **Splunk** with a dedicated tooltip. * Added Splunk HEC configuration (URL/token/index/source/source type) including TLS verification control. * **Bug Fixes** * Improved log delivery with batching, retries for temporary HTTP failures, and safeguards for oversized events. * **Tests** * Added unit tests and optional integration tests covering routing, batching, retries, and error scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fleet frontend
The Fleet frontend is a Single Page Application using React with Typescript and Hooks.
Table of contents
Running the Fleet web app
For details instruction on building and serving the Fleet web application consult the Contributing documentation.
Testing
Visit the overview of Fleet UI testing for more information on our testing strategy, philosophies, and tools.
To run unit or integration tests in ComponentName.tests.tsx, run yarn test -- ComponentName.tests.tsx. To test all Javascript components run yarn test.
QA Wolf manages our E2E test and will maintain the tests as well as raise any issues found from these tests. Engineers should not have to worry about working with E2E testing code or raising issues themselves.
For more information on how our front-end tests work, visit our frontend test directory.
Directory structure
Component directories in the Fleet front-end application encapsulate the entire component, including files for the component and its styles. The typical directory structure for a component is as follows:
└── ComponentName
├── _styles.scss
├── ComponentName.tsx
|-- ComponentName.tests.tsx
├── index.ts
_styles.scss: The component css stylesComponentName.tsx: The React componentComponentName.tests.tsx: The React component unit/integration testsindex.ts: Exports the React component- This file is helpful as it allows other components to import the component
by it's directory name. Without this file the component name would have to
be duplicated during imports (
components/ComponentNamevs.components/ComponentName/ComponentName).
- This file is helpful as it allows other components to import the component
by it's directory name. Without this file the component name would have to
be duplicated during imports (
components
The component directory contains global React components rendered by pages, receiving props from their parent components to render data and handle user interactions.
context
The context directory contains the React Context API pattern for various entities.
Only entities that are needed across the app has a global context. For example,
the logged in user (currentUser) has multiple pages and components
where its information is pulled.
interfaces
Files in the interfaces directory are used to specify the Typescript interface for a reusable Fleet entity. This is designed to DRY up the code and increase re-usability. These interfaces are imported in to component files and implemented when defining the component's props.
Additionally, local interfaces are used for props of local components.
layouts
The Fleet application has only 1 layout, the Core Layout. The Layout is rendered from the router and are used to set up the general app UI (header, sidebar) and render child components. The child components rendered by the layout are typically page components.
pages
Page components are React components typically rendered from the router.
React Router passed props to these pages in case they are needed. Examples include
the router, location, and params objects.
router
The router directory is where the react router lives. The router decides which
component will render at a given URL. Components rendered from the router are
typically located in the pages directory. The router directory also holds a paths
file which holds the application paths as string constants for reference
throughout the app. These paths are typically referenced from the App
Constants object.
services
CRUD functions for all Fleet entities (e.g. report) that link directly to the Fleet API.
styles
The styles directory contains the general app style setup and variables. It includes variables for the app color hex codes, fonts (families, weights and sizes), and padding.
templates
The templates directory contains the HTML file that renders the React application via including the bundle.js
and bundle.css files. The HTML page also includes the HTML element in which the React application is mounted.
test
The test directory includes test helpers, API request mocks, and stubbed data entities for use in test files. See the UI testing documentation for more on test helpers, stubs, and request mocks.
utilities
The utilities directory contains re-usable functions and constants for use throughout the application. The functions include helpers to convert an array of objects to CSV, debounce functions to prevent multiple form submissions, format API errors, etc.
Patterns
The list of patterns used in the Fleet UI codebase can be found in patterns.md.
Storybook
Storybook is a tool to document and visualize components, and we
use it to capture our global components used across Fleet. Storybook is key when developing new
features and testing components before release. It runs a separate server exposed on port 6006.
To run this server, do the following:
- Go to your root fleet project directory
- Run
make deps - Run
yarn storybook
The URL localhost:6006 should automatically show in your browser. If not, visit it manually.
Running Storybook before implementing new UI elements can clarify if new components need to be created or already exist. When creating a component, you can create a new file, component.stories.tsx, within its directory. Then, fill it with the appropriate Storybook code to create a new Storybook entry. You will be able to visualize the component within Storybook to determine if it looks and behaves as expected.