GitHub user Zhuoxi2000 added a comment to the discussion: [Discuss][Observability] OpenTelemetry GenAI export for Agent Traces (follow-up to #900)
Thanks for the thorough review — these are exactly the questions worth settling before implementation. **Rejected alternative.** Agreed. I’ll document why `OpenTelemetryTraceReporterFactory` isn’t a good fit: no caller-defined IDs or status, related spans need to be exported together, and support differs across Flink distributions. **1. Source and scope.** Phase 1 is a batch converter over already-collected Event Log files, not a continuous tailer. Durability, checkpoints, retention, and failover therefore belong to a separate durable Event Log sink design, which a future continuous OTel consumer could build on. Since the converter is standalone, its settings will be regular arguments such as endpoint, protocol, and `service.name`, rather than `event-log.*` config. **2. Recording metadata.** Strong +1 on recording the resolved model, provider, and per-call usage in `entityMetadata`. That keeps the exporter a pure converter without inference or metric joins. The run/root/parent relationships should also be explicit in the contract rather than synthesized by the exporter. I’m happy to help with the LLM metadata follow-up once #924 settles. **3. Language neutrality.** Agreed. Both runtimes produce the same serialized Event Log records, so one converter serves both. “Java first” only refers to the converter implementation language. **4. Dependency boundary.** The converter will remain an optional standalone module and won’t be bundled into the distribution, keeping its OTel SDK/exporter dependencies off the main classpath. **5. Delivery semantics.** The batch converter is at-least-once. Deterministic IDs make duplicates identifiable, but idempotency is ultimately backend-dependent. Checkpointing and replay guarantees belong to the future continuous-consumer track. So the revised plan is: 1. Clarify metadata and run/root/parent semantics in #924. 2. Track the durable, replayable Event Log sink separately. 3. Keep #970 focused on the optional batch converter, with a continuous consumer as follow-up work. I’ll update #970 accordingly. GitHub link: https://github.com/apache/flink-agents/discussions/929#discussioncomment-17924359 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
