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

Setup collector receiver #160

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

dmathieu
Copy link
Member

This is an extraction from #87, with the intent to clean up and setup only the collector receiver, without an attached collector distribution.

@dmathieu dmathieu force-pushed the collector-receiver branch 5 times, most recently from cd467ae to a639d0a Compare September 19, 2024 09:24
@dmathieu dmathieu force-pushed the collector-receiver branch 2 times, most recently from ccdac1c to 00c1c6b Compare October 1, 2024 10:15
Co-authored-by: Tim Rühsen <[email protected]>
@@ -0,0 +1,236 @@
// Copyright The OpenTelemetry Authors
Copy link
Member

Choose a reason for hiding this comment

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

Can't we move opentelemetry-ebpf-profiler/helpers.go into its own package that we can import here to avoid duplicating all this code?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in #197

)

// Config represents the receiver config settings within the collector's config.yaml
type Config struct {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe for another PR, but it'd be nice if we used a single configuration structure to cover both CLI and collector, that way the validation logic would also be shared.


// Start starts the receiver.
func (c *Controller) Start(ctx context.Context, host component.Host) error {
cfg := c.config
Copy link
Member

@christos68k christos68k Oct 18, 2024

Choose a reason for hiding this comment

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

Since there's a lot of duplication with startup logic in main here, maybe we should factor out commonalities into a separate package (e.g. agent or controller) that we can reuse here and in main.

Copy link
Member Author

Choose a reason for hiding this comment

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

While your point definitely makes sense, this is far from being a trivial change in main.go, as it mixes a lot of things together. So making that refactoring looks like it's going to take several PRs.
While I'm happy to look into that, I wonder if we shouldn't start without this refactoring, so we can move forward with the collector support.

@dmathieu
Copy link
Member Author

Moving this back to draft. I realized this uses the OTLPReporter, which doesn't use the collector's nextConsumer behavior.

@dmathieu dmathieu marked this pull request as draft October 25, 2024 09:31
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