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.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Adds a `confmap.Marshaler` implementation for `configoptional.Optional`
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@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 -->
A second attempt at #11882.
Note that I added some tests in #12871 to prevent something like #12661
from happening again.
#### Link to tracking issue
Fixes#11749
<!--Describe what testing was performed and which tests were added.-->
#### Testing
<!--Describe the documentation added.-->
See tests from #12871 as well as the new tests added here.
#### 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
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Update config structs in the service module to include `omitempty` tags.
<!-- Issue number if applicable -->
#### Link to tracking issue
Works toward
https://github.com/open-telemetry/opentelemetry-collector/issues/12191
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Builds on
https://github.com/open-telemetry/opentelemetry-collector/pull/12224 and
starts the move of config validation from component to confmap. We can
keep this in `xconfmap` while we determine whether to add the ability to
validate using struct field tags.
I think this has the following advantages:
1. Everything configuration-related is now in confmap instead of split
between confmap and component.
2. We can share things like the mapstructure tag and config key
separator as constants between unmarshaling and validation without
creating dependencies between confmap and component.
~The one uncertainty this creates is what to do with `component.Config`,
which would now be used as a thin alias for `any` without any meaningful
usage in component.~
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes
https://github.com/open-telemetry/opentelemetry-collector/issues/11524
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Follow-up to
https://github.com/open-telemetry/opentelemetry-collector/pull/12108.
This calls `component.ValidateConfig` on `otelcol.Config`, which causes
`Validate` to be recursively called on all eligible structs in the
config.
This has the following benefits:
1. `Validate` will now automatically be called instead of config structs
needing to call it on member structs.
2. Paths to the exact key that caused a validation error in the config
are now consistently printed.
3. If there are multiple errors in the config, they are now all returned
to the user instead of just the first error encountered.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Currently these are just printed, which hides validation issues with
`telemetry.Config`. If we don't want to return these errors, we should
document that and print them at a warning log level.
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>
#### Description
[gofumpt](https://golangci-lint.run/usage/linters/#gofumpt) is a
stricter format than gofmt, while being backwards compatible.
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
**Description:**
- Adds `component.MustNewType` to create a type. This function panics if
the type has invalid characters. Add similar functions
`component.MustNewID` and `component.MustNewIDWithName`.
- Adds `component.Type.String` to recover the string
- Use `component.MustNewType`, `component.MustNewID`,
`component.MustNewIDWithName` and `component.Type.String` everywhere in
this codebase. To do this I changed `component.Type` into an opaque
struct and checked for compile-time errors.
Some notes:
1. All components currently on core and contrib follow this rule. This
is still breaking for other components.
2. A future PR will change this into a struct, to actually validate this
(right now you can just do `component.Type("anything")` to bypass
validation). I want to do this in two steps to avoid breaking contrib
tests: we first introduce this function, and after that we change into a
struct.
**Link to tracking Issue:** Updates #9208
* [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>
* [pipelines] Change test to not reuse same processor twice in one pipeline
* Add note to documentation about reuse of processors within a pipeline
* can -> MUST
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>
The problem was that the MetricProvider is initialized into the "service.telemetry.MetricProvider" after components were created. This change was not a trivial change because the process telemetry initialization requires the ballast size, which is available after the extensions are initialized, because of that I split the initialization of the MetricProvider/oc.Registry from the initialization of the process telemetry.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Yang Song
Jade Guiton
Pablo Baeyens
Bogdan Drutu
Evan Bradley
Matthew Sainsbury
Alex Boten
Matthieu MOREL
Tyler Helmuth
Alex Boten
Daniel Jaglowski
Ziqi Zhao