Skip to content

[CLN] Use GRPC for chroma-load OTEL #4427

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

Merged
merged 1 commit into from
May 2, 2025

Conversation

jasonvigil
Copy link
Contributor

Description of changes

Remove sampling. Will leverage refinery for this instead.

Test plan

These changes are untested. However, it is now using (mostly) the same setup code as the other chroma services (which are working). So, we can test in staging after this is merged.

Also, remove sampling. Will leverage refinery for this instead.
@jasonvigil jasonvigil requested a review from rescrv May 2, 2025 22:01
Copy link

github-actions bot commented May 2, 2025

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

  • Can you think of any use case in which the code does not behave as intended? Have they been tested?
  • Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
  • If appropriate, are there adequate property based tests?
  • If appropriate, are there adequate unit tests?
  • Should any logging, debugging, tracing information be added or removed?
  • Are error messages user-friendly?
  • Have all documentation changes needed been made?
  • Have all non-obvious changes been commented?

System Compatibility

  • Are there any potential impacts on other parts of the system or backward compatibility?
  • Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

  • Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

.with_config(trace_config)
.build();
let tracer = tracer_provider.tracer(service_name.clone());
// TODO(MrCroxx): Should we the tracer provider as global?
// global::set_tracer_provider(tracer_provider);

// Prepare meter.
Copy link
Contributor

Choose a reason for hiding this comment

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

Refinery doesn't support metrics and Honeycomb doesn't support tonic. This was setup the way it is to get metrics into honeycomb. Metrics, not traces.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can use otel-collector as the same endpoint for both metrics and traces. This simplifies our config and setup complexity (from chroma service standpoint, at least)

Copy link
Contributor

@rescrv rescrv left a comment

Choose a reason for hiding this comment

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

Talked offline. Will send to otel-collector, not refinery. This might work.

@jasonvigil jasonvigil enabled auto-merge (squash) May 2, 2025 22:26
@jasonvigil jasonvigil merged commit 8fa5a73 into main May 2, 2025
71 checks passed
warpbuild-benchmark-bot bot added a commit to WarpBuilds/chroma that referenced this pull request May 2, 2025
@jasonvigil jasonvigil deleted the jason/use-grpc-for-chroma-load-otel branch May 2, 2025 22:59
tjkrusinskichroma pushed a commit that referenced this pull request May 3, 2025
## Description of changes

Remove sampling. Will leverage refinery for this instead.

## Test plan

These changes are untested. However, it is now using (mostly) the same
setup code as the other chroma services (which are working). So, we can
test in staging after this is merged.
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