Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: otel support #7

Merged
merged 3 commits into from
Nov 16, 2024
Merged

feat: otel support #7

merged 3 commits into from
Nov 16, 2024

Conversation

nirga
Copy link
Member

@nirga nirga commented Nov 13, 2024

Screenshot 2024-11-14 at 10 13 19

Copy link
Contributor

@galkleinman galkleinman left a comment

Choose a reason for hiding this comment

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

I would model it differently. It makes no sense IMO that the request/response and any other nested DTO implements a trait with record_span. There should be a utility object for each request imo, which implements call (which is the actual request handling logic), record_span, end_span, and inside of these functions you do the span attrs assignments. In current impl it looks really weird (at least to me), lines like this:
self.usage.record_span(span); which makes me wonder why should a usage dto "spawn" a new span.

Approving in case you wanna go forward with it, but i would restructure.

src/pipelines/otel.rs Outdated Show resolved Hide resolved
@nirga nirga merged commit 42c8169 into main Nov 16, 2024
1 check passed
@nirga nirga deleted the otel branch November 16, 2024 10:28
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.

2 participants