Skip to main content
Set up telemetry delivery before connecting a production project to Keyring. Keyring uses this path to record credential use and give your team the evidence needed to investigate a request.
Production deployments should use AUDIT_DURABILITY=required. A protected response is released only after the configured OTLP logs endpoint acknowledges its audit event.

​
Choose a delivery path

OpenTelemetry Collector

Recommended. Keep the acknowledgment path close to Keyring, then let the collector handle vendor authentication, queuing, retries, and routing.

Direct OTLP endpoint

Fewer components, but vendor latency and availability become part of the protected request path.

​
What Keyring expects

OTEL_COLLECTOR_URL is a base URL. Keyring sends OTLP/HTTP Protobuf to:
  • <base>/v1/logs for logs and acknowledged audit events;
  • <base>/v1/traces for traces; and
  • <base>/v1/metrics for metrics.
In required mode, the logs endpoint must return a synchronous 2xx response. Redirects do not count as acknowledgment. Keyring retries retryable failures up to three times, with a two-second limit on each attempt, before withholding the protected response. Run the collector beside Keyring whenever your platform supports a sidecar or nearby service. For ECS, Cloud Run multi-container services, and Kubernetes pods, both containers can communicate over 127.0.0.1 without exposing the collector receiver publicly. Configure Keyring with the local collector base URL:
Keyring environment
Use this as a starting collector configuration. Replace the exporter endpoint and header with values from your observability provider:
otel-collector.yaml
Mount /var/lib/otelcol on storage that matches your recovery requirements. Keep provider credentials on the collector, not in the Keyring container. This configuration uses file_storage from the Collector Contrib distribution. Pin a reviewed OpenTelemetry Collector distribution and version instead of tracking a floating image tag. The logs pipeline intentionally sends directly to the exporter’s persistent queue. Do not add an in-memory batch processor in front of that queue without reviewing how it changes acknowledgment and recovery behavior.
The receiver address above is for a sidecar that shares Keyring’s network namespace. A standalone collector should use a private listener protected by network policy and TLS.

​
Direct vendor endpoint

Use a direct endpoint only when it accepts OTLP/HTTP Protobuf on all three standard paths. The logs endpoint must return a final 2xx response quickly enough to sit on the protected request path. Keyring treats that 2xx response as the acknowledgment. Confirm the provider’s intake and retention semantics meet your audit requirements. Store OTEL_COLLECTOR_HEADERS as a secret. It uses comma-separated Name=value pairs, with spaces and other reserved characters percent-encoded.
Datadog recommends an Agent or OpenTelemetry Collector for production. Its direct OTLP intake is a fallback when a collector is not feasible and may require signal-specific settings.
The example is for Datadog US1. Select the endpoint for your Datadog site and review its current direct OTLP intake requirements.

​
Verify before enabling a project

  1. Start Keyring and confirm there are no collector configuration errors.
  2. Run one read-only tool call through a test Composio project.
  3. Find service.name=keyring and an audit.operation record in your telemetry backend.
  4. Join the audit event to its logs and trace using the Keyring request ID.
  5. In a test environment, interrupt telemetry delivery and confirm Keyring does not release a protected success response.
best_effort keeps requests moving without acknowledged audit delivery. Use it only for local evaluation or when your organization has explicitly accepted that production risk. For the event fields and security guarantees, see Audit and observability.