OTLP metrics exporter emits only target_info while OTLP logs succeed

Open 💬 1 comment Opened Aug 14, 2026 by evoNick-A

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.810.41047 (observed app-server version: 0.148.0-alpha.9)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS)

What issue are you seeing?

With managed OTLP HTTP/protobuf exporters configured separately for logs and metrics, the log exporter successfully delivers structured Codex events to Grafana Loki. The metrics exporter directed to the OTLP /v1/metrics endpoint does not yield Codex application metrics in Prometheus/Mimir.

After a fresh Codex start and activity, the only Codex-associated series is target_info. It has service_name=codex-app-server and resource/SDK labels with value 1. No request, token, tool, error, or latency metric series appear.

Loki receives codex.api_request, codex.sse_event, codex.user_prompt, and codex.websocket_request events, so connectivity and authentication for the log path are working.

What steps can reproduce the bug?

  1. In an Enterprise managed Codex configuration, configure separate OTLP HTTP/protobuf log and metrics exporters, using the respective /v1/logs and /v1/metrics endpoints.
  2. Refresh the signed managed configuration cache and start Codex after the refresh.
  3. Generate Codex activity.
  4. Confirm recent Codex events in Loki.
  5. Query Prometheus/Mimir after the same start time for service_name=codex-app-server, excluding a synthetic codex_otel_pipeline_probe.
  6. Observe target_info but no Codex application metric series.

What is the expected behavior?

The metrics exporter should emit documented Codex application metrics to /v1/metrics, such as request/token counters or latency metrics, after Codex activity. At minimum, the telemetry documentation should clarify if target_info is the only metric currently emitted by the Codex App.

Additional information

target_info is resource metadata, not evidence of request activity or a metrics heartbeat. Collector endpoint URLs and authorization headers have been redacted.

View original on GitHub ↗

1 Comment

stefqc · 8 days ago

Yeah, had the same issue. But Codex do emit a shitload of metrics. I had AI build an otel receiver, pointed codex to it, and dumped content. Problem is metrics are emitted with Temporality delta, which apparently, Grafana/prometheus/mimir doesn't support. I tried transmitting such a metric to grafana endpoint and it got rejected with

HTTP error: 400 Bad Request
otlp parse error: invalid temporality and type combination for metric "http.requests.delta"

Here are a few links

Code where it happens

Issues about grafana and prometheus with temporality delta

https://github.com/prometheus/prometheus/issues/17649
https://github.com/grafana/mimir/issues/10439

Also, codex otel support doesn't seem to follow Otel semantic convention for Genai which as everything in AI is a Work in Progress.

So no sure if it is a codex or grafana bug. But my advice is turn off codex otel support, try again in a few months. This repository has thousands of issues, so don't expect everything to be fixed promptly. Even In this age of AGI...