<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Changes the underlying type of `component.Kind` to be closer to
[`pipeline.Signal`](https://pkg.go.dev/go.opentelemetry.io/collector/pipeline#Signal).
Right now the type is defined within `component`, but it could be moved
to an internal module so that we could have a different module exposing
other value on this enum.
This is already doable today, the only thing this PR gives us is
1. slightly more flexibility on things like making the concept of kind
more complex (e.g. adding an adjective to a kind).
2. restricting external consumers from implementing their own component
kinds without our explicit approval (with some kind of API we design)
I am not convinced this is _necessary_ to do, but we may as well do it.
This is technically a breaking change since `component.Kind(42)` was a
valid expression and it no longer is. I think this is extremely rare, so
I suggest if we go ahead we do so in one go.
#### Link to tracking issue
Fixes#11443
After reviewing the 6 month period, the period seems too long to get
feedback on whether an unmaintained component should be removed. I'm
proposing shortening it to 3 months.
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->
Forgot to do this on #11561
This PR also starts using the fact that StabilityLevel implements
UnmarshalText and cleans up the mdatagen stability structure.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
#### 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
https://github.com/open-telemetry/opentelemetry-collector/pull/10725
Related to
https://github.com/open-telemetry/opentelemetry-collector/pull/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 <pablo.baeyens@datadoghq.com>
<!--Describe the documentation added.-->
#### Documentation
Creates an internal architecture file. In it is a diagram of the startup
flow of the collector as well as links to key files / packages. I also
added package level comments to some key packages.
I wrote some other documentation in
https://github.com/open-telemetry/opentelemetry-collector/pull/10029 but
split the PRs up.
---------
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
This PR introduces component status reporting. There have been several
attempts to introduce this functionality previously, with the most
recent being: #6560.
This PR was orignally based off of #6560, but has evolved based on the
feedback received and some additional enhancements to improve the ease
of use of the `ReportComponentStatus` API.
In earlier discussions (see
https://github.com/open-telemetry/opentelemetry-collector/pull/8169#issuecomment-1668367246)
we decided to model status as a finite state machine with the following
statuses: `Starting`, `OK`, `RecoverableError`, `PermanentError`,
`FatalError`. `Stopping`, and `Stopped`. A benefit of this design is
that `StatusWatcher`s will be notified on changes in status rather than
on potentially repetitive reports of the same status.
With the additional statuses and modeling them using a finite state
machine, there are more statuses to report. Rather than having each
component be responsible for reporting all of the statuses, I automated
status reporting where possible. A component's status will automatically
be set to `Starting` at startup. If the components `Start` returns an
error, the status will automatically be set to `PermanentError`. A
component is expected to report `StatusOK` when it has successfully
started (if it has successfully started) and from there can report
changes in status as it runs. It will likely be a common scenario for
components to transition between `StatusOK` and `StatusRecoverableError`
during their lifetime. In extenuating circumstances they can transition
into terminal states of `PermanentError` and `FatalError` (where a fatal
error initiates collector shutdown). Additionally, during component
Shutdown statuses are automatically reported where possible. A
component's status is set to `Stopping` when Shutdown is initially
called, if Shutdown returns an error, the status will be set to
`PermanentError` if it does not return an error, the status is set to
`Stopped`.
In #6560 ReportComponentStatus was implemented on the `Host` interface.
I found that few components use the Host interface, and none of them
save a handle to it (to be used outside of the `start` method). I found
that many components keep a handle to the `TelemetrySettings` that they
are initialized with, and this seemed like a more natural, convenient
place for the `ReportComponentStatus` API. I'm ultimately flexible on
where this method resides, but feel that `TelemetrySettings` a more user
friendly place for it.
Regardless of where the `ReportComponentStatus` method resides (Host or
TelemetrySettings), there is a difference in the method signature for
the API based on whether it is used from the service or from a
component. As the service is not bound to a specific component, it needs
to take the `instanceID` of a component as a parameter, whereas the
component version of the method already knows the `instanceID`. In #6560
this led to having both `component.Host` and `servicehost.Host` versions
of the Host interface to be used at the component or service levels. In
this version, we have the same for TelemetrySettings. There is a
`component.TelemetrySettings` and a `servicetelemetry.Settings` with the
only difference being the method signature of `ReportComponentStatus`.
Lastly, this PR sets up the machinery for report component status, and
allows extensions to be `StatusWatcher`s, but it does not introduce any
`StatusWatcher`s. We expect the OpAMP extension to be a `StatusWatcher`
and use data from this system as part of its AgentHealth message (the
message is currently being extended to accommodate more component level
details). We also expect there to be a non-OpAMP `StatusWatcher`
implementation, likely via the HealthCheck extension (or something
similiar).
**Link to tracking Issue:** #7682
cc: @tigrannajaryan @djaglowski @evan-bradley
---------
Co-authored-by: Tigran Najaryan <tnajaryan@splunk.com>
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Alex Boten <aboten@lightstep.com>
* [chore] use license shortform
To remain consistent w/ contrib repo, see https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/22052
Signed-off-by: Alex Boten <aboten@lightstep.com>
* make goporto
Signed-off-by: Alex Boten <aboten@lightstep.com>
---------
Signed-off-by: Alex Boten <aboten@lightstep.com>
This change updates values returned by `StabilityLevel.String` to be consistent with other enum types:
- All returned strings are capitalized.
- "Undefined" is returned only for `StabilityLevelUndefined`.
- "" is returned for integers that are out of StabilityLevel enum range.
The main reason is to remove the circular dependency between the config (including sub-packages) and component. Here is the current state:
* component depends on config
* config/sub-package[grpc, http, etc.] depends on config & component
Because of this "circular" dependency, we cannot split for example "config" into its own module, only if all the other config sub-packages are also split.
Signed-off-by: Bogdan <bogdandrutu@gmail.com>
Adding the latest version of go to the tests run by CI. To pass the tests, the following changes were required:
- run make genpdata
- fix test certificates to address errors caused by the rejection of duplicate extensions in TLS handshakes
* add LogMessage and move LogStabilityLevel
This change will make the func available for extensions as well.
* add docstring
* fix typo
* fix impi
* apply review feedback
* Remove use of unnecessary internal interface in factory
This PR does not change the design (which is to not allow external implementation),
but simplifies the way how this is achieved, now that the helpers are in the same package.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Use baseFactory to implement Type() func
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
* chore: adds porto and fixes vanity imports.
* chore: fixes target overriding.
* chore: fixes install of porto.
* chore: includes porto as a tool.
* chore: upgrades porto to check internals.
* chore: rebase and update vanity import.
* chore: removes unnecessary space.
* chore: rollsback vanity import in generated files.
* Fix godoc wording and inconsistencies
1. Move the component lifecycle to interface godoc so the godoc can render it
2. Avoid using below/above, godoc already groups things correctly.
3. Avoid giving references to what functions/methods implement what. Instead, mention what they do.
4. Fix inconsistencies in new lines for long lines.
* Update component/receiver.go
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* Update component/receiver.go
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* Update component/receiver.go
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* Update component/receiver.go
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
* Make custom unmarshaling a config interface
If a component wants custom unmarshaling they need to add an
Unmarshal method to their Config struct instead of providing
it through the factory.
* Add interface assert for unmarshable configurations
* Document Unmarshal methods
* Mention that config.Unmarshable is an optional interface.
* Use config.Parser on config.Unmarshable interface
Move customUnmarshaler implementation to Unmarshal
* Deprecate factory unmarshaler interface
* Amend comment
* Empty commit to retrigger CI
* Add deprecation comment
* Revert previous commits
Revert "Add deprecation comment"
This reverts commit 4e10ec27f2.
Revert "Amend comment"
This reverts commit ab5ae0af76.
Revert "Deprecate factory unmarshaler interface"
This reverts commit e33c788d55.
* Add fallback to use deprecatedUnmarshaler
* Rename config.Unmarshable to config.CustomUnmarshable; update docs
* Empty commit to retrigger CI
Pablo Baeyens
Alex Boten
Bogdan Drutu
Tyler Helmuth
Antoine Toulme
Ankit Patel
Antoine Toulme
Matthew Wear
Alex Boten
Daniel Jaglowski
Dmitrii Anoshin
Sean Marciniak
José Carlos Chávez
Bryan Uribe
Jaana Dogan
Pablo Baeyens
Tigran Najaryan
James Bebbington
Jay Camp