[component] Component status reporting rfc #10413
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TylerHelmuth
added
the
Skip Changelog
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10413 +/- ##
=======================================
Coverage 91.89% 91.89%
=======================================
Files 411 411
Lines 19316 19316
=======================================
Hits 17750 17750
Misses 1217 1217
Partials 349 349 ☔ View full report in Codecov by Sentry. |
TylerHelmuth
force-pushed
the
component-status-reporting-rfc
branch
from
97a059a to
649dead
Compare
mwear
reviewed
Jun 17, 2024
Co-authored-by: Matthew Wear <[email protected]>
…ylerHelmuth/opentelemetry-collector into component-status-reporting-rfc
atoulme
reviewed
Jun 17, 2024
atoulme
reviewed
Jun 17, 2024
atoulme
reviewed
Jun 17, 2024
mx-psi
reviewed
Jun 18, 2024
Co-authored-by: Pablo Baeyens <[email protected]>
mx-psi
added a commit
that referenced
this pull request
Jun 20, 2024
This PR adds documentation for the collector status reporting system. It describes the current state of the system and has a section for best practices that we intend to evolve as we develop them. The intended audience is future users of the system and anyone interested in getting a deeper look into how the system works without having to read all of the code. This is intended to be complementary to the [in-progress RFC](#10413). [Here is a preview](https://github.com/open-telemetry/opentelemetry-collector/blob/61abf91b4faec42905b409c352e0e234e5b75ac9/docs/component-status.md) with the diagrams properly rendered. --------- Co-authored-by: Alex Boten <[email protected]> Co-authored-by: Pablo Baeyens <[email protected]>
djaglowski
reviewed
Jul 1, 2024
There was a problem hiding this comment.
When designing the existing component status system, we faced many challenges related to component instances. For example, a single processor configuration may be used in multiple pipelines, in which case multiple instances of the processor will be instantiated. Another example, a receiver or exporter which is used in pipelines of different data types will have one instance per data type. Should these instances share a single status or do they each have their own? If each instance has its own status, how do we uniquely identify these instances and communicate each one's status to users?
In my opinion this is a problem which needs to be addressed in any status system design. Alternatively, I think we should consider ways to remove these problems by making changes to the way components are instanced such that all instances correspond to exactly one configuration in the collector config.
mx-psi
reviewed
Jul 10, 2024
TylerHelmuth
commented
Jul 26, 2024
mx-psi
pushed a commit
that referenced
this pull request
Aug 13, 2024
#### Description Adds a `Reporter` interface that represents how a `component.Host` implementation could expose the ability to report a status. You can see how this interface will be used by looking at Related to #10777 <!-- Issue number if applicable --> #### Link to tracking issue Related to #10777 Related to #10413 <!--Describe what testing was performed and which tests were added.--> #### Testing Added unit test
mx-psi
pushed a commit
that referenced
this pull request
Aug 14, 2024
#### Description This is a prep PR to reduce the size of #10777. As part of the work to make our `component.Host` implementation implement `componentstatus.Reporter` (see #10852), the `host` struct and `graph` logic need to be closer together. This is because, as part of #10777 `StartAll` is changed to depend on our specific `Host` type instead of a `component.Host`. Our host already has a dependency on `graph`, so it can't be moved into its own module. <!-- Issue number if applicable --> #### Link to tracking issue Related to #10777 Related to #10413
mx-psi
added a commit
that referenced
this pull request
Aug 16, 2024
) #### Description This PR removes `ReportStatus` from `component.TelemetrySettings` and instead expects components to check if their `component.Host` implements a new `componentstatus.Reporter` interface. <!-- Issue number if applicable --> #### Link to tracking issue Related to #10725 Related to #10413 <!--Describe what testing was performed and which tests were added.--> #### Testing unit tests and a sharedinstance e2e test. The contrib tests will fail because this is a breaking change. If we merge this I and @mwear can commit to updating contrib before the next release. --------- Co-authored-by: Pablo Baeyens <[email protected]>
djaglowski
approved these changes
Aug 20, 2024
atoulme
approved these changes
Aug 22, 2024
|
I think we are good to merge this once @mwear takes another look :) |
mwear
approved these changes
Aug 22, 2024
Co-authored-by: Matthew Wear <[email protected]>
TylerHelmuth
added
the
ready-to-merge
|
Reviewed by @mwear, merging now |
github-actions
bot
modified the milestones:
go.opentelemetry.io/collector/component 1.0,
next release
This was referenced Aug 22, 2024
sfc-gh-sili
pushed a commit
to sfc-gh-sili/opentelemetry-collector
that referenced
this pull request
Aug 23, 2024
Adds an RFC for component status reporting. The main goal is to define what component status reporting is, our current, implementation, and how such a system interacts with a 1.0 component. When merged, the following issues will be unblocked: - open-telemetry#9823 - open-telemetry#10058 - open-telemetry#9957 - open-telemetry#9324 - open-telemetry#6506 --------- Co-authored-by: Matthew Wear <[email protected]> Co-authored-by: Pablo Baeyens <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds an RFC for component status reporting. The main goal is to define what component status reporting is, our current, implementation, and how such a system interacts with a 1.0 component. When merged, the following issues will be unblocked:
componentpublic API #6506