Skip to content

Conversation

anuraaga
Copy link
Contributor

@anuraaga anuraaga commented Jul 17, 2025

Which problem is this PR solving?

  • openai SDK usage should have gen ai conventions but there is no instrumentation yet

Short description of the changes

  • Adds instrumentation targeting openai SDK 4 for chat and embeddings

Future PRs will add support for responses API and SDK 5

/cc @trentm if you can help review
/cc @lmolkova because I heard you are also interested in this instrumentation. Notably, I'd like this instrumentation to exist upstream so people can use it but need potential component owners I believe

This instrumentation is adapted from the one in https://github.com/elastic/elastic-otel-node/tree/main/packages/instrumentation-openai

@anuraaga anuraaga requested a review from a team as a code owner July 17, 2025 09:23
@anuraaga anuraaga marked this pull request as draft July 17, 2025 09:23
})
).rejects.toThrow(OpenAI.APIConnectionError);

// TODO: Figure out why it takes so long to get this span. trace.getTracerProvider()._delegate.forceFlush() didn't help.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could use some help debugging this

Copy link

codecov bot commented Jul 18, 2025

Codecov Report

❌ Patch coverage is 87.96296% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.81%. Comparing base (cde6d4d) to head (6d77251).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...ages/instrumentation-openai/src/instrumentation.ts 90.90% 25 Missing ⚠️
packages/instrumentation-openai/src/utils.ts 53.33% 14 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2941      +/-   ##
==========================================
- Coverage   89.86%   89.81%   -0.06%     
==========================================
  Files         189      192       +3     
  Lines        9314     9638     +324     
  Branches     1911     1988      +77     
==========================================
+ Hits         8370     8656     +286     
- Misses        944      982      +38     
Files with missing lines Coverage Δ
packages/instrumentation-openai/src/semconv.ts 100.00% <100.00%> (ø)
packages/instrumentation-openai/src/utils.ts 53.33% <53.33%> (ø)
...ages/instrumentation-openai/src/instrumentation.ts 90.90% <90.90%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Contributor

@trentm trentm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for starting this, Anuraag. This is just a quick start at looking. I haven't looked at src/ or test/ yet.

body.content = msg.content;
}
}
this.logger.emit({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If one has set up a global logging provider, is it possible to opt out of the logs emitted from this instrumentation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seemk I think one could do so by setting a NoopLoggerProvider on the instrumentation via instr.setLoggerProvider(noopLoggerProvider).

But are you asking for something different than that?

I haven't been following the GenAI semconv discussions of late. I vaguely recall that there was discussion of making it user-optional whether GenAI instrumentations used log-events or span attributes. Is that what you are referring to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - from what I understand, the conventions imply that when logs are enabled, logs are always emitted - this is how it currently works in the bedrock instrumentation of this repo, as well as genai in python and java. If it seems like there should be more knobs, we'd need to raise changes to the semconv but for now this implements the current practice.

Copy link
Contributor

@trentm trentm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another round of review, looking at the implementation this time. Looks good! Thanks for all the type improvements.

I haven't yet looked at the tests.

Copy link
Contributor

@trentm trentm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests look good to me (with some comments below). I didn't comb through all 3000 lines; about half of them.

Copy link
Contributor

@trentm trentm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple more things: test-all-versions, and openai@5 support.

@trentm
Copy link
Contributor

trentm commented Aug 1, 2025

This LGTM.

Not sure if you were going to wait for feedback from the MS folks that might help and possibly be component owners.

Before or when being taken out of draft, this PR will need to add one or more component owners to ".github/component_owners.yml". I could be one if needed, at least for starters.

const EVENT_GEN_AI_USER_MESSAGE = 'gen_ai.user.message';
const EVENT_GEN_AI_ASSISTANT_MESSAGE = 'gen_ai.assistant.message';
const EVENT_GEN_AI_TOOL_MESSAGE = 'gen_ai.tool.message';
const EVENT_GEN_AI_CHOICE = 'gen_ai.choice';
Copy link
Contributor

@trentm trentm Aug 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I've started a PR to eventually add EVENT_* exports from the semantic-conventions package.
open-telemetry/opentelemetry-js#5832

@anuraaga anuraaga marked this pull request as ready for review August 7, 2025 03:09
@anuraaga
Copy link
Contributor Author

anuraaga commented Aug 7, 2025

Thanks @trentm - I have gone ahead and updated owners as if possible, it would be nice to avoid drift by merging an initial version. Will continue discussion to hopefully add more /cc @paulshealy1

@trentm
Copy link
Contributor

trentm commented Aug 19, 2025

I asked for possible additional component owners for this instrumentation on the GenAI SIG today: https://docs.google.com/document/d/1EKIeDgBGXQPGehUigIRLwAUpRGa7-1kXB736EaYuJ2M/edit?tab=t.0#heading=h.tath31lg83xm

Being a "component owner" means that you are listed for the particular instrumentation here: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/.github/component_owners.yml
and that you will be tagged for feedback/review for issues and PRs related to this instrumentation.
The idea is that you are able to provide informed review and opinions on telemetry design for the target module (in this case for openai). I can handle any instrumentation details related to opentelemetry-js internals or general instrumentation issues.

No pressure, but there was possible interest expressed by @zhirafovod. (@seemk would you be interested in being a component owner for this instrumentation?)

As well, @singankit was possibly going to poke @paulshealy1 again internally.

Thanks.

@seemk
Copy link
Contributor

seemk commented Aug 19, 2025

I asked for possible additional component owners for this instrumentation on the GenAI SIG today: https://docs.google.com/document/d/1EKIeDgBGXQPGehUigIRLwAUpRGa7-1kXB736EaYuJ2M/edit?tab=t.0#heading=h.tath31lg83xm

Being a "component owner" means that you are listed for the particular instrumentation here: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/.github/component_owners.yml and that you will be tagged for feedback/review for issues and PRs related to this instrumentation. The idea is that you are able to provide informed review and opinions on telemetry design for the target module (in this case for openai). I can handle any instrumentation details related to opentelemetry-js internals or general instrumentation issues.

No pressure, but there was possible interest expressed by @zhirafovod. (@seemk would you be interested in being a component owner for this instrumentation?)

As well, @singankit was possibly going to poke @paulshealy1 again internally.

Thanks.

I can help out, yeah

Copy link
Contributor

@trentm trentm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anuraaga One suggested change (adding seemk as a component owner), then LGTM. Thanks!

@anuraaga
Copy link
Contributor Author

Thanks a lot @seemk and @trentm!

@pichlermarc pichlermarc enabled auto-merge (squash) August 21, 2025 13:00
@pichlermarc pichlermarc merged commit 3e575ba into open-telemetry:main Aug 21, 2025
21 checks passed
@dyladan dyladan mentioned this pull request Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants