feat: Add telemetry support.

[ehsavoie]

Adding support for OpenTelemetry

Fixes #388 🦕

[gemini-code-assist]

Summary of Changes

Hello @ehsavoie, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request integrates OpenTelemetry into the A2A Java SDK, providing robust distributed tracing capabilities. The changes enable automatic span creation for both client-initiated and server-processed A2A requests, offering deeper visibility into the flow of operations. This enhancement is crucial for monitoring, troubleshooting, and understanding the performance characteristics of applications built with the SDK.

Highlights

• OpenTelemetry Module: Introduced a new Maven module, extras/opentelemetry, to encapsulate all OpenTelemetry integration logic for the A2A Java SDK.
• Client-Side Tracing: Implemented dynamic wrapping of ClientTransport instances with OpenTelemetryClientTransport within the ClientBuilder. This allows for automatic tracing of client-side A2A interactions when an OpenTelemetry Tracer is provided in the ClientTransportConfig.
• Server-Side Tracing Interceptors: Added a new @Trace annotation and SpanInterceptor mechanism to enable automatic distributed tracing for server-side request handler methods across gRPC, JSON-RPC, and REST protocols. Custom AttributeExtractor implementations are used to enrich spans with relevant request details.
• Enhanced ClientTransportConfig: The ClientTransportConfig now includes a generic parameters map, facilitating the injection of arbitrary configuration, such as the OpenTelemetry Tracer instance, into transport implementations.
• Example Application Updates: The helloworld example client and server applications have been updated to demonstrate the setup and usage of OpenTelemetry, including dependency additions and configuration for tracing.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for OpenTelemetry, which is a great addition for observability. The implementation introduces a new opentelemetry extras module and integrates tracing on both the client and server sides. On the client side, it uses reflection for optional wrapping, and on the server side, it uses CDI interceptors with a new @Trace annotation. My review focuses on improving the robustness and maintainability of this new feature. I've found a few critical issues, such as a ClassCastException in an attribute extractor and silent exception swallowing that could make debugging difficult. I've also identified several opportunities for code cleanup, such as fixing typos, removing duplicated code, and improving the design of the CDI interceptor to better support dependency injection. Addressing these points will make the OpenTelemetry integration more solid and easier to maintain.

[brunobat]

I think you need to decide if you are creating your own instrumentation annotations and API or if you just reuse the ones provided by OTel.

Also, the attribute names, should follow these semantic conventions, as much as possible: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/

[kabir]

A few things which may or may not be needed :-)

[kabir]

Actually, @ehsavoie it looks like you are adding Otel tracing to the example. But I don't know how to enable this etc.
Can you update the README with instructions?

Maybe we could also make this example testable in the CI, like we do for the cloud-deployment one?

Also, it would be good to have some tests in the extras module

[kabir]

@ehsavoie 2 small things.

If the JBang validator is tricky, open an issue and link it here

[ehsavoie]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces OpenTelemetry distributed tracing support across the A2A Java SDK client and server, along with multi-protocol support (JSONRPC, GRPC, HTTP+JSON) for the helloworld example. Key changes include adding a new a2a-java-sdk-opentelemetry module, which provides ClientTransportWrapper and CDI SpanInterceptor implementations to automatically instrument client and server operations. The ClientBuilder was enhanced to support transport wrapping, and ClientTransportConfig now includes a parameters map for passing tracing context. The helloworld example client and server were updated to demonstrate dynamic protocol selection and OpenTelemetry integration, with corresponding pom.xml and README.md changes. Review comments highlighted the need to return an unmodifiable map for ClientTransportConfig.getParameters() to ensure immutability, to use public constants for OpenTelemetry parameter keys for better maintainability, and to simplify the application.properties file by consolidating quarkus.agentcard.protocol definitions.

Out of date

[kabir]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces comprehensive OpenTelemetry support across the client and server components, including gRPC, JSON-RPC, and REST transports. The implementation leverages a flexible wrapper pattern for clients and CDI interceptors for servers, allowing for extensible tracing. Attribute extraction is thoughtfully tailored to each transport and method, providing rich and detailed tracing information. The accompanying documentation and tests have been updated to reflect these new capabilities, ensuring clarity and correctness. Overall, the changes are well-implemented and significantly enhance the observability of the A2A SDK.

[ehsavoie]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces comprehensive OpenTelemetry support for both client and server components. The implementation is well-designed, using a ServiceLoader-based ClientTransportWrapper for the client and CDI interceptors for the server, which allows for clean, decoupled observability. The example applications have been updated to demonstrate how to enable and use this new telemetry feature. The changes are extensive and well-executed. I've found a couple of minor issues: a potential resource leak in the client example due to an incorrectly placed finally block, and a small typo in the README documentation. Overall, this is a great addition to the SDK.

[gemini-code-assist]

The finally block that closes the OpenTelemetrySdk is placed within an inner try block. If an exception occurs after initOpenTelemetry() is called but before this inner try block is entered (for example, during clientBuilder.build()), the SDK will not be closed. This could lead to un-flushed telemetry data.

To ensure the SDK is always closed properly, the finally block should be associated with the main try block that encompasses the entire client logic, including the SDK initialization and client build process.

            } catch (Exception e) {
                System.err.println("Failed to get response: " + e.getMessage());
            }
        } catch (Exception e) {
            System.err.println("An error occurred: " + e.getMessage());
            e.printStackTrace();
        } finally {
            // Ensure OpenTelemetry SDK is properly shut down to export all pending spans
            if (openTelemetrySdk != null) {
                System.out.println("Shutting down OpenTelemetry SDK...");
                openTelemetrySdk.close();
                System.out.println("OpenTelemetry SDK shutdown complete.");
            }
        }

[gemini-code-assist]

There appears to be a typo in the JBang command. jbangHelloWorldRunner.java should likely be jbang HelloWorldRunner.java with a space.

Suggested change

	jbangHelloWorldRunner.java -Dopentelemetry=true
	jbang HelloWorldRunner.java -Dopentelemetry=true