This is replaced by a LeveledMeterProvider method on the struct instead.
This
reduces the complexity from the view of component authors, in that
there's no need
to check the level before invoking the meter to record a metric.
Closes
https://github.com/open-telemetry/opentelemetry-collector/issues/9510
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.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>
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>
Bump go.opentelemetry.io/contrib/zpages from 0.29.0 to 0.30.0
Bump google.golang.org/protobuf from 1.27.1 to 1.28.0 in /model
Bump go.opentelemetry.io/otel/metric from 0.27.0 to 0.28.0
Bump go.opentelemetry.io/otel/sdk from 1.5.0 to 1.6.1
Bump go.opentelemetry.io/otel/sdk/metric from 0.27.0 to 0.28.0
Bump go.opentelemetry.io/otel/exporters/prometheus from 0.27.0 to 0.28.0
Bump github.com/ory/go-acc from 0.2.7 to 0.2.8 in /internal/tools
* consolidate flags for configuring telemetry
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Enable configuring metrics via service config
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Make components take MetricsLevel from TelemetrySettings
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Fix lint errors
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Remove configuration for metrics prefix and adding instance ID
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Make entire Collector available to telemetry initialization, use it to set metrics prefix to buildInfo.Command
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* fix metrics prefix tests
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Fix lint errors
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* config/telemetry: parseLevel() no longer needs to be exported
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* config/telemetry: remove intanceID and prefix flags
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Apply PR feedback
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* address PR feedback
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Avoid linter complaining about use of deprecated functions
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Update CHANGELOG
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.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.
Bogdan Drutu
Alex Boten
Tyler Helmuth
Antoine Toulme
Alex Boten
Matthew Wear
Jacob Aronoff
Anthony Mirabella
José Carlos Chávez