#### Description
Improve coverage of config validation, TracerProvider creation, and
trace context propagator configuration.
Simplify some other tests.
#### Link to tracking issue
N/A
#### Testing
N/A
#### Documentation
N/A
#### Description
Deprecate the feature gate now that metric views can be configured.
#### Link to tracking issue
Fixes#13537
#### Testing
Verified that the flag is deprecated with `otelcorecol featuregate` and
`otelcorecol --feature-gates telemetry.disableHighCardinalityMetrics`
(the latter leads to an error, as expected for deprecated feature
gates.)
#### Documentation
Added changelog
---------
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
Co-authored-by: Jade Guiton <jade.guiton@datadoghq.com>
#### Description
Move SDK construction into service/telemetry. This is a step towards
fully encapsulating the otelconf SDK in the service/telemetry package,
so we can have different telemetry provider implementations that can be
injected.
#### Link to tracking issue
Preparation work for
https://github.com/open-telemetry/opentelemetry-collector/issues/4970
#### Testing
N/A, non-functional change.
#### Documentation
N/A
cherry-pick of
d82267dd69
`go.opentelemetry.io/otel/exporters/prometheus v0.59.1` does not fully
fix the metric name issue so we have to revert to v0.58.0
Downgrades opentelemetry-go dependencies effectively reverting #13289
and others
- Due to a
[bug](https://github.com/open-telemetry/opentelemetry-go/issues/7039) in
the prometheus exporter, if you are configuring a prometheus exporter,
the collector's internal metrics will be emitted with an unexpected
suffix in its name. For example, the metric
`otelcol_exporter_sent_spans__spans__total` instead of
`otelcol_exporter_sent_spans_total`. The workaround is to manually
configure `without_units: true` in your prometheus exporter config
```yaml
service:
telemetry:
metrics:
readers:
- pull:
exporter:
prometheus:
host: 0.0.0.0
port: 8888
without_units: true
```
If you are using the collector's default Prometheus exporter for
exporting internal metrics you are unaffected.
Signed-off-by: alex boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
Co-authored-by: alex boten <223565+codeboten@users.noreply.github.com>
#### Description
This changes the config for the default Prometheus exporter to remove
`disable_scope_info: true`. This prevent errors in the exporter caused
by metrics only differentiated by their scope being considered aliasing,
which will become more common when the `telemetry.newPipelineTelemetry`
feature gate graduates (see tracking issue for details).
I marked this as a "breaking change", but I'm not sure if we make
guarantees about the format of the Prometheus metrics we emit?
#### Link to tracking issue
Fixes#12939
#### Testing
I updated some tests to reflect the additional labels added to
Prometheus metrics.
I performed manual testing and confirmed that the reproduction case in
the tracking issue no longer emits an error when the feature gate is
enabled.
#### Description
This PR adds a `service::telemetry::metrics::views` config key, which
explicitly sets the list of metric views used for internal telemetry,
mirroring `meter_provider::views` in the SDK config. This can be used to
disable specific internal metrics, among other uses.
This key will cause an error if used alongside other features which
would normally implicitly create views, such as:
- not setting `service::telemetry::metrics::level` to `detailed`;
- enabling the `telemetry.disableHighCardinalityMetrics` feature gate.
#### Further discussion needed
- A comment notes that the `telemetry.disableHighCardinalityMetrics`
alpha gate *"will be removed when the collector allows for view
configuration"*. I think setting the gate as deprecated first would be
the correct thing to do, but it means that users relying on it will see
their Collectors crash on update. Is that okay?
- In the context of being able to enable/disable specific metrics, this
key is only useful to disable metrics from an "all enabled" baseline. It
cannot easily be used to customize the set of metrics emitted at `level:
normal`, `level: basic`. Discussion is ongoing in #10769 on how to
handle that, but the solution will probably involve a new key, which
should hopefully be backward-compatible with the user-visible changes in
this PR.
#### Link to tracking issue
Updates #10769
#### Testing
None yet
#### Documentation
None yet, except the changelog
---------
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
#### Description
Upgrading the collector to use opentelemetry-go-contrib
v1.35.0/v0.60.0/v0.29.0/v0.15.0/v0.10.0/v0.8.0/v0.7.0
See changelog here:
https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v1.35.0
<!-- Issue number if applicable -->
#### Link to tracking issue
none available
<!--Describe what testing was performed and which tests were added.-->
#### Testing
I ran `make all` but happy to run other targets if needed
This PR does a couple of things that I couldn't quite split up so I put
together a PR w/ individual commits to help reviewers get through it.
This PR does the following:
1. update `go.opentelemetry.io/contrib/config` package to latest. this
brings in breaking changes. in order to prevent those breaking changes
from impacting end users, i've also added a layer of config unmarshaling
2. updates the collector to instantiate the meter provider (and
exporters) via the config package. this allows us to remove all the code
in `otelinit`. the reason for including this change was that
unmarshaling the config was causing circular dependencies i didn't want
to address by moving code that could be deleted around.
Replacement for
https://github.com/open-telemetry/opentelemetry-collector/pull/11458.
Fixes
https://github.com/open-telemetry/opentelemetry-collector/issues/12021
---------
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 -->
Drops metrics that depend on the metrics level:
- Batch processor metric
- otelarrow metrics (see open-telemetry/otel-arrow/issues/280 for
limitation).
- internal/otelarrow/netstats metrics. I did not implement
a25f058256/internal/otelarrow/netstats/netstats.go (L133-L136)
since `LevelNone` drops all metrics.
This attemps to unblock #11601 by hardcoding the metrics here since
there is a small number of them. Once we do #11754 we can move this back
to the individual components
#### Link to tracking issue
Updates #11061
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
attempts to fix flaky `service/telemetry/metrics` test
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#11654
<!--Describe what testing was performed and which tests were added.-->
#### Testing
update to test helper function
<!--Describe the documentation added.-->
#### Documentation
n/a
<!--Please delete paragraphs that you did not use before submitting.-->
#### Description
[whitespace](https://golangci-lint.run/usage/linters/#whitespace) is a
linter that checks for unnecessary newlines at the start and end of
functions.
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
This test wasn't testing any new behaviour since similar config was used
in both test cases. Removed the duplicate and updated
`getMetricsFromPrometheus` to not require a handler anymore. This will
be useful when updating the code with the new upstream config package.
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Andrew Wilkins
Matthieu MOREL
Yang Song
Jade Guiton
Alex Boten
Matthew Sainsbury
Pablo Baeyens
John L. Peterson (Jack)
Bogdan Drutu