OpenTelemetry to pull request

Can existing OpenTelemetry data help generate a fix?

Yes. Prilog accepts OpenTelemetry logs and traces and uses production evidence with a connected repository to investigate errors and prepare code changes. You can keep your existing telemetry destination and configure an additional OTLP HTTP export to Prilog. Your exporter or Collector must support that routing.

OpenTelemetry supplies evidence. Prilog supplies the repository-aware investigation and fix workflow. An OTLP request by itself neither requests a fix nor publishes code; project automation controls what happens after ingestion.

1. Connect code and provision monitoring

Connect the application's GitHub repository in Prilog and select its branch. In service setup, choose Add free Prilog monitoring and copy the connection DSN. Use a distinct service name for each deployable component.

The DSN contains a scoped ingest token. It does not grant read access to source code, projects, or errors. See monitoring permissions.

2. Configure an OTLP HTTP exporter

Derive the base URL and token from the DSN as described in the OTLP transport contract. Replace the placeholders below:

$
$
$
$
$
$export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT="https://HOST/api/otel/orgs/WORKSPACE/projects/PROJECT/connections/CONNECTION"
export OTEL_EXPORTER_OTLP_HEADERS="X-Prilog-OTLP-Token=YOUR_INGEST_TOKEN"
export OTEL_SERVICE_NAME="checkout-api"
export OTEL_RESOURCE_ATTRIBUTES="service.version=YOUR_RELEASE,deployment.environment.name=production"
export OTEL_METRICS_EXPORTER=none

These environment variables configure compatible exporters; they do not install or initialize an SDK. Preserve your existing exporter configuration when adding a second destination. Per-signal URLs end in /v1/logs and /v1/traces. Prilog accepts HTTP/protobuf and HTTP/JSON, including gzip; this endpoint does not accept OTLP gRPC or metrics.

3. Preserve useful failure context

• Give every service a stable service.name and each release a service.version.
• Include exception stack traces and the relevant error message.
• Preserve W3C trace and span context across service boundaries.
• Emit logs with the active request context to correlate them with spans.

For a browser calling a separate API origin, configure trace propagation and CORS using the browser tracing guide.

4. Inspect the investigation and proposed change

Review incoming errors in Prilog or run prilog list in the intended project. Use prilog fix ERROR_ID for an explicit request, then inspect state and prilog diff ERROR_ID when ready. Review actual test results and publish with prilog pr ERROR_ID when appropriate.

Automation settings can handle eligible work without assigning every error manually. Confirm those settings before sending production data. Incomplete evidence can lead to an unsuccessful investigation or no patch.

Choose the shortest setup

Use Node.js, browser and React, Go, or the Python archive if you need instrumentation. Use the OTLP reference for an existing SDK or Collector, and troubleshooting if signals do not arrive.