Skip to main content
All Buildkite integration capabilities

​
About

From v3.135.0, the Buildkite agent can export job output as OpenTelemetry log records. Turn that on with the agent’s job-logs-otlp setting and point its OTLP/HTTP log exporter at your Sazabi intake URL. Each line of job output then reaches Sazabi as one record, with the same [REDACTED] masking as the Buildkite job log. The job log in the Buildkite dashboard is unchanged, and no collector, Buildkite API token, or pipeline change is needed. Records carry buildkite.organization.slug, buildkite.pipeline.slug, buildkite.branch, buildkite.build.number, buildkite.build.id, buildkite.job.id, buildkite.job.label, buildkite.job.key, buildkite.queue, and the agent name and ID. The resource service.name is buildkite-agent.
Job log export is an agent operator setting: a pipeline can’t turn it on, and only self-hosted agents are covered. Buildkite documents OTLP export from hosted agents for traces only, not job logs.

​
Prerequisites

  • Self-hosted Buildkite agents on v3.135.0 or later (every v4 release qualifies), installed from the Linux packages, the Elastic CI Stack for AWS, the Agent Stack for Kubernetes, the buildkite/agent Docker image, or any other way you start buildkite-agent
  • Outbound HTTPS from the agents to your Sazabi intake host
  • Your Sazabi intake URL, shown above — open the log source and copy the Intake URL from its setup screen (the public key is embedded in the URL)

​
Set up in the dashboard

1

​
Turn on job log export

Every agent needs the same three settings. Replace <your intake host> with the intake URL shown above, without https://. No Authorization header is needed because the public key is in the hostname.The logs-specific endpoint is used as-is, so it must end in /v1/logs. Using the OTEL_EXPORTER_OTLP_LOGS_* variables leaves any tracing setup that uses OTEL_EXPORTER_OTLP_ENDPOINT untouched. The exporter variables can’t go in buildkite-agent.cfg; they must be in the agent process’s environment.Linux packages. Add job-logs-otlp=true to the agent config file and the exporter variables to a systemd drop-in, then restart the agent.
Linux
Elastic CI Stack for AWS. Save this environment file in a private S3 bucket and set the stack’s AgentEnvFileUrl parameter to its s3:// URI. Grant the instances s3:GetObject on it through ManagedPolicyARNs, then update the stack.
agent.env
Agent Stack for Kubernetes. The controller adds an agent container to every job pod and applies pod-spec-patch to it. Merge this into your Helm values and run helm upgrade. If you already have a pod-spec-patch, add the agent container entry to it.
values.yaml
Docker. Add the three -e flags to your existing docker run command (or the environment of your Compose service) and recreate the container.
Docker
Anything else. Export the three variables in the environment of the process that runs buildkite-agent start.
2

​
Restart the agents

The agent reads these settings when it starts. Restart every agent, or roll the stack or Helm release. Jobs that start afterwards export their logs; jobs already running don’t.
3

​
Hand off the change

If your agent configuration is version-controlled, commit it on a new branch, push it, and open a pull request. Otherwise apply it directly. Keep the intake URL in a secret store where your tooling supports it, such as an S3 object with restricted access or a Kubernetes Secret.

​
Set up with the CLI

You can also register the Buildkite log source with the Sazabi CLI (installed and authenticated — see CLI reference). Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):
The command prints the intake URL for the new source — copy the whole URL and use its host in the configuration shown above. Run sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.

​
Verify

Run any build on a queue served by an updated agent. Open the Intake page in the Sazabi dashboard and confirm records from the Buildkite source appear within a minute or two, then search for the pipeline’s buildkite.pipeline.slug or a buildkite.job.id.

​
Troubleshooting

No records after restarting — Confirm the agent is v3.135.0 or later and was restarted after the change. If the exporter can’t start, the job log shows Failed to initialize OTLP job log exporter. Still nothing — Check that OTEL_EXPORTER_OTLP_LOGS_PROTOCOL is http/protobuf; without it the agent uses gRPC, which the intake doesn’t accept. Check that the logs endpoint ends in /v1/logs. Kubernetes jobs don’t export — The patch must target the container named agent. Inspect a job pod with kubectl get pod <job-pod> -o yaml and confirm the three variables are on that container. Sensitive output — Redaction only masks values the agent recognizes as secrets (redacted environment variables and secrets registered through the Job API). Anything else a build prints is sent as-is.

​
Further reading

Intake

See per-source ingestion volume and health.

Log sources

Browse the full log source catalog.