Is distributed tracing / APM realistically possible for legacy Perl applications?

[ShallTear]

Hello PerlMonks community,

We are trying to implement distributed tracing (APM-style request tracing) for a legacy Perl application running in a microservices environment.

Our goal is limited to application tracing only:

• Create traces and spans inside the Perl application
• Export them to a tracing backend such as Jaeger, Zipkin, Tempo, or an APM platform

We do not require infrastructure metrics or logs.

We attempted to use OpenTelemetry for Perl. While we were able to create traces and spans, we could not reliably export them due to limitations in the Perl ecosystem.

Our findings so far:

• OTLP over gRPC is not supported due to lack of a stable Perl gRPC client ecosystem and no gRPC exporter in the Perl OpenTelemetry SDK.
• OTLP over HTTP (JSON) is incomplete; the Perl OTLP JSON encoder is not fully compliant.
• OTLP over HTTP (Protobuf) requires runtime .proto compilation using Google::ProtocolBuffers::Dynamic, which is not feasible or reliable in production.
• OTLP wire-format compliance cannot be achieved from Perl.
• This appears to be a language ecosystem limitation rather than a configuration issue.

We also evaluated Jaeger and Zipkin. However, they are tracing backends only and cannot generate traces or spans themselves without a supported Perl instrumentation and export mechanism.

Given this situation, I would appreciate guidance from experienced Perl users on the following questions:

1. Is true distributed tracing / APM for Perl applications realistically possible today?
2. Are there any community-recommended Perl modules or approaches to export traces (for example using Jaeger Thrift, Zipkin HTTP, or other non-OTLP formats)?
3. Are there any platforms or vendors (open source or commercial) that successfully support Perl tracing in production?
4. If Perl-level instrumentation is not practical, are proxy-based or gateway-based tracing approaches (for example using Nginx or Envoy) the recommended solution for legacy Perl applications?
5. In your experience, what is the most practical and supported way to achieve observability for Perl services?

Any pointers to existing CPAN modules, real-world implementations, or alternative strategies would be greatly appreciated.

Thank you for your time and expertise.

Best regards,
ShallTear

[Corion]

Not having had to do any of this, Google::ProtocolBuffers::Dynamic claims to be able to do the generation ahead of time via protoc-gen-perl-gpd. I don't know how dynamic the .proto files actually are, but maybe it can either work with that tool or maybe you can generate the libraries from a dummy script and then package and deploy them for your real use?

[hippo]

Welcome to the Monastery, ShallTear.

OTLP over HTTP (JSON) is incomplete; the Perl OTLP JSON encoder is not fully compliant.

Are you referring to OpenTelemetry::Exporter::OTLP::Encoder::JSON? This has no open issues and claims compliance with the 1.2.0 version of the OTLP specification. Perhaps the simplest solution is either to raise an issue and await a fix or else contribute the fix yourself?

[perlink]

based on my experience, your conclusion is reasonable application-level tracing for Perl services is currently not a mature or well-supported capability, and most organizations rely instead on proxy-based tracing, external request correlation, or coarse-grained monitoring rather than full APM observability.

[Anonymous Monk]

Talking to yourself again?