-
Notifications
You must be signed in to change notification settings - Fork 278
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
Add live graph backend (merge to feature branch) #2645
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! some comments, but nothing big
internal/component/otelcol/internal/lazyconsumer/lazyconsumer.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/lazyconsumer/lazyconsumer_test.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/livedebuggingconsumer/livedebuggingconsumer.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/livedebuggingconsumer/livedebuggingconsumer.go
Outdated
Show resolved
Hide resolved
a79c730
to
0dd571d
Compare
internal/component/otelcol/internal/livedebuggingconsumer/livedebuggingconsumer.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/livedebuggingconsumer/livedebuggingconsumer.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much, much cleaner without the callbacks to LiveDebugging(...)
function from the service. Few more comments, but we're almost there!
internal/component/otelcol/internal/interceptorconsumer/logs.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/interceptorconsumer/logs.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/interceptorconsumer/logs.go
Outdated
Show resolved
Hide resolved
internal/component/otelcol/internal/livedebuggingpublisher/livedebuggingpublisher.go
Outdated
Show resolved
Hide resolved
return ids | ||
} | ||
|
||
func PublishLogsIfActive(debugDataPublisher livedebugging.DebugDataPublisher, componentID string, ld plog.Logs, nextLogs []otelcol.Consumer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think nextLogs
needs to be otelcol.Consumer
, you only ever use them to extract component ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True but it's quite handy for the components because it's easy to provide.
Would you prefer that I change it to:
PublishLogsIfActive(debugDataPublisher livedebugging.DebugDataPublisher, componentID string, ld plog.Logs, componentIDs []string)
and that I export the extractIDs function?
Or do you have a different idea in mind? I'd like to keep the code as little intrusive as possible in the components
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking to use a smaller interface, like
type NamedComponent interface {
ComponentID() string
}
cause that's all you need
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does that work for you: 7392390 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small comment, but otherwise LGTM
return ids | ||
} | ||
|
||
func PublishLogsIfActive(debugDataPublisher livedebugging.DebugDataPublisher, componentID string, ld plog.Logs, nextLogs []otelcol.Consumer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking to use a smaller interface, like
type NamedComponent interface {
ComponentID() string
}
cause that's all you need
* add live graph backend * update discovery process * review feedback1 * review feedback 2 * change back to splitting functions in livedebugging service * fix race condition in otel receiver * add comment about memory leak * rework live debugging for otel components * add comment about window unit * review feedback * fix tests * use interface in publish live debugging data
PR Description
This is the backend part of the new live graph.
The approach is similar to live debugging, except that it adds the callback to all components in the given module.
The live debugging feed is now a struct that contains data needed to build the new graph. Because the data string is not needed for the graph, it's passed around as a function. This way we can use the same struct for the live debugging and the live graph with limited performance overhead.
Which issue(s) this PR fixes
Fixes #2608
Notes to the Reviewer
This was tested manually via curl:
curl -N http://localhost:12345/api/v0/web/graph
to get the data from all components at the rootcurl -N http://localhost:12345/api/v0/web/graph/{moduleID}
to get data from a particular modulePR Checklist