Skip to main content

​
Forwarding overview

Beacon writes normalized endpoint events as JSONL and can also send OTLP logs, traces, and metrics to Splunk HTTP Event Collector (HEC) through the bundled collector. The active runtime log remains the stable local handoff path and rotates locally. Use the built-in HEC destination when you want Beacon to forward directly, or configure a customer-managed forwarder to read the runtime log and send each JSON object to HEC. When the built-in HEC destination is enabled, Beacon’s collector needs network access to your Splunk HEC endpoint and stores the HEC token in the collector config. When you use an external forwarder, that forwarder is responsible for reading the local file, authenticating to HEC, and retrying delivery.

​
Runtime log paths

Use system mode for MDM deployments so every managed endpoint writes to /var/log/beacon-agent/runtime.jsonl.

​
Beacon-managed forwarding

For Beacon-managed forwarding, pass HEC settings during endpoint install or repair:
Install Beacon with Splunk HEC forwarding
Keep the HEC token in your endpoint-management secret store before passing it to Beacon. Beacon writes the token into the collector config so the local collector can authenticate to Splunk HEC.

​
Customer-managed forwarding

Create or reuse a Splunk HEC token for Beacon endpoint telemetry, then install Beacon with the HEC destination:
Install Beacon with Splunk HEC forwarding
To add or update Splunk HEC on an existing endpoint, run repair with the same destination flags:
Update Splunk HEC on an existing endpoint

​
Settings

If you use a customer-managed forwarder instead of Beacon’s collector destination, store the token in that forwarder’s secret store rather than Beacon configuration.

​
Example HEC payload

Your forwarder should wrap each Beacon JSON object in a Splunk HEC envelope:
Keep the HEC token in your endpoint-management secret store and pass it to Beacon at install or repair time.

​
Collector behavior

When Splunk HEC is configured, Beacon writes a collector pipeline with both exporters enabled:
The beaconjson exporter preserves the local runtime log. The splunk_hec exporter sends OTLP logs, traces, and metrics to Splunk HEC. Before they reach it, the beacon_privacy processor redacts secrets with the same rules as the local runtime log, leaving identifiers and usage numbers unchanged. Redaction is pattern-based, so treat forwarded content as sensitive. Before log records reach either exporter, the logs pipeline runs Beacon’s claude_api_body processor, followed by beacon_privacy (processors: [memory_limiter, claude_api_body, beacon_privacy, batch]). The body processor drops Claude Code API request and response bodies, which can contain the system prompt, conversation history, and tool results. When Beacon was installed with --claude-capture-model-context, two kinds of request are forwarded with their body replaced by what Beacon keeps, the same copy the runtime log stores. The WebFetch summarizer request carries the fetched page text in beacon.web_fetch.input, with secrets redacted and capped at 2048 characters. A request that advertises MCP tools carries beacon.mcp.tools, the name and redacted description of each tool the session has not been sent before. See Claude Code: model context from API bodies.

​
Validate forwarding

Confirm Beacon has the destination configured:
Confirm Beacon has the destination configured
In the JSON output, check that destinations.splunk_hec.configured is true and that the endpoint, index, source, and sourcetype match your deployment. The token is not printed. Then write a validation event:
Write a validation event
Then search Splunk for the validation event:
If the event does not appear, verify that the collector service is running, the HEC endpoint accepts the configured token, and TLS settings match your Splunk deployment.
Check endpoint status as JSON

Log forwarding

Review forwarding patterns and validation steps.

Endpoint event schema

Review normalized Beacon JSONL fields and example events.