quartzmo
commented
10 months ago Hi @nirga,
Thanks for opening this issue! This repo, google-cloud-go, is home to a heterogeneous collection of clients. Most are automatically generated, such as the Vertex AI client aiplatform. Adding a dependency on go-openllmetry to these hundreds of generated libraries is very unlikely to be approved. Adding a few OpenTelemetry spans for basic observability is certainly on the roadmap, but we follow a playbook in which we work out the kinks first in another category of clients in the repo, which are the handwritten clients. For example, our best-of-breed vertexai client, which is carefully handwritten by a team of dedicated maintainers for an optimal user experience with Vertex AI. If you would like me to reassign this issue to that team, please change ai: in the title above to vertexai:. (These scopes, which we use in conventional commits, are derived from the module and top-level directory names.)
nirga
Describe the solution you'd like I'm the maintainer of OpenLLMetry where we built a set of extensions of OpenTelemetry for GenAI applications. We currently support Python and Typescript (where we can easily monkey-patch the libraries within our instrumentations) and want to extend this to Go. Because there isn't a way to easily monkey-patch code in Go, we currently force our users to do it manually and I'd love to add this natively to your SDK so it will happen automagically. This will give an ability for a user to turn on go opentelemetry instrumentation which uses our semantic convention. Then, the user can connect it to any observability tools they want - Datadog, Honeycomb, Traceloop, etc.
Describe alternatives you've considered Manually reporting of LLM spans which is cumbersome and annoying :(
Additional context Willing to do the PR and the work, just wanted a buy-in from the team before starting to work.