Add support for opentelemetry to the SDK

[ankit8697]

Thanks for stopping by to let us know something could be better!

PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

Is your feature request related to a problem? Please describe.
The previous SDK that Google provided for GenAI had built-in OpenTelemetry support. When we migrated to this SDK, that OpenTelemetry support disappeared. It would be great if this SDK had built-in OpenTelemetry support as well.

Describe the solution you'd like
I'd like the SDK to have built-in OpenTelemetry support, where it would automatically pick up on the OpenTelemetry setup in the project and push traces, logs, and metrics to the collector that has been configured for the project.

Describe alternatives you've considered
The alternatives are to add instrumentation manually which is time consuming and doesn't have everything I need, including errors from the Gemini API and details on why specific errors were receieved.

[qiaodev]

Hi @ankit8697 Thanks for reaching out.

I investigated the previous SDK opentelemetry support. The opentelementry is enabled by default and you can disable it via WithTelemetryDisabled. The opentelemetry is added to transportation layer here.

Could you give us more detailed examples about how you are using the opentelemetry with the previous SDK? This would help us develop the new integration and use them to assist with our end-to-end testing.

Thanks

[qiaodev]

@ankit8697 Since you are using Vertex, do you have support package or not? If so, you can create ticket covered by the support package. This can help us prioritize the opentelemetry feature request.

cc: @chrisheecho

Thanks

[ankit8697]

I don't have a support package, but I can probably get one.

Could you give us more detailed examples about how you are using the opentelemetry with the previous SDK? This would help us develop the new integration and use them to assist with our end-to-end testing.

In the older SDK, the main benefit was to see errors more detailed errors in our tracing backend. Right now we just get back an INTERNAL error when something goes wrong, but in the older SDK we used to get a more comprehensive explanation of the error. Also, it had a lot of other useful metadata for our logging backend when debugging issues. So that's the main things we used it for.