Skip to main content

Pipeline Overview

Beacon turns runtime-specific signals into local endpoint telemetry. The pipeline receives OpenTelemetry and hook payloads, normalizes them into endpoint events, writes the runtime JSONL log, and supports local inspection or customer-controlled forwarding.

Local collection

Beacon writes an OpenTelemetry Collector configuration with localhost receivers:
ReceiverDefault endpoint
OTLP gRPC127.0.0.1:4317
OTLP HTTP127.0.0.1:4318
On macOS, the collector is managed with launchd in user mode or system mode. The generated collector pipeline receives logs, traces, and metrics, batches them, applies memory limits, and exports normalized Beacon events through the beaconjson exporter. Packaged deployments use the Beacon collector distribution. Local installs can point at another beacon-otelcol binary with --collector.

Normalization

Beacon converts runtime-specific payloads into one shared endpoint event model. Instead of preserving each runtime’s native shape, Beacon writes consistent entities:
  • Required context: event, endpoint, and harness
  • Optional actor and workflow context: user, session, tool, command, mcp, approval, and policy
  • Optional content and file context: prompt, file, content, destination, and health
See the Endpoint event schema for the schema overview and the schema fields reference for the complete entity list and common fields.

Local storage and inspection

Beacon writes one JSON object per line to the active runtime.jsonl path. That path stays stable for local inspection and forwarding, while Beacon rotates the active file at 10 MiB and keeps five numbered local archives. The local dashboard reads local runtime logs over a loopback-only service so teams can validate rollout and inspect recent agent activity without sending endpoint telemetry to a hosted backend.

Forwarding

The JSONL log is the default handoff point for Wazuh, Elastic/Filebeat, Datadog Agent custom log collection, Sumo Logic, Rapid7 InsightIDR, Microsoft Sentinel, AWS S3, Google Cloud Storage, and customer-managed forwarding. Wazuh localfile ingestion, Elastic/Filebeat deployments, Datadog Agent custom log collection, Sumo Logic shippers, Rapid7 forwarders, Azure Monitor Agent, and Vector storage forwarders tail the preserved JSONL file, so those SIEM and storage credentials stay outside Beacon endpoint configuration. When Splunk HEC or Falcon LogScale HEC is configured, the same collector pipeline can also send logs, traces, and metrics to the splunk_hec or falcon_hec exporter while preserving the local JSONL log.

Runtime metric and trace filtering

Beacon filters generic process and runtime OTLP metrics out of the JSONL log by default so timelines stay focused on agent prompts, tools, approvals, and file activity. Harness operational metrics from GitHub Copilot CLI and OpenClaw Gateway are also filtered by default. Use --include-runtime-metrics when low-level process, runtime, or harness metrics are required. Codex can emit low-level transport spans from libraries such as HTTP/2 framing and flow-control internals. Beacon filters those noisy internal Codex spans during trace ingestion while keeping meaningful Codex spans such as session, model client, dispatch, and turn activity.

Beacon architecture

Return to the architecture overview.

Runtime integrations

See how each runtime connects to the telemetry pipeline.

Log forwarding

Forward Beacon events to Wazuh, Splunk HEC, Falcon LogScale, Elastic, Datadog, Sumo Logic, Rapid7 InsightIDR, Microsoft Sentinel, AWS S3, Google Cloud Storage, or customer-managed SIEM pipelines.

Endpoint event schema

Review normalized Beacon JSONL event fields.