#### Description
Move the telemetry implementation from `service/telemetry` to
`service/telemetry/otelconftelemetry`, with the exception of the
Settings type which is intended to remain in the `service/telemetry`
package permanently. The goal here is to separate the interface (which
is to be defined in a followup) and implementation, so multiple
implementations can exist.
This move is in preparation for creating a new Telemetry and Factory
interface, similar to pipeline components. In the end, the
implementation (e.g. otelconftelemetry) will be completely self
contained, providing a NewFactory function to obtain a factory that can
be used to construct a Telemetry implementation.
The next steps after this PR would be:
1. Update
7bf3615b56/cmd/opampsupervisor/supervisor/config/config.go (L25)
to use otelconftelemetry. Eventually the opampsupervisor should probably
use the Factory & Telemetry, but that can be done later on.
2. Create the Factory and Telemetry interface in service/telemetry, and
update otelconftelemetry to implement it, encapsulating the creation of
the SDK & SDK resource. We would continue directly constructing the
otelconftelemetry factory to keep the change contained. At this stage we
could close
https://github.com/open-telemetry/opentelemetry-collector/issues/8170.
3. Update otelcol and service packages to inject the telemetry factory &
default config into the service's settings and default config, and
remove direct references to otelconftelemetry in the service package. At
this stage we could close
https://github.com/open-telemetry/opentelemetry-collector/issues/4970.
#### Link to tracking issue
Part of
https://github.com/open-telemetry/opentelemetry-collector/issues/4970
#### Testing
N/A, non-functional change.
#### 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
#### Description
Simplify code by using the SDK.Shutdown method, which internally shuts
down each of the providers.
#### 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
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
There are two main changes here:
- We move the componentattribute logger core wrapping and Logger to
LoggerProvider tee'ing to the service package. This will enable the
wrapping to be performed independently of the implementation of
telemetry providers.
- We move away from using zapcore.NewTeeCore, and introduce a new
zapcore.Core implementation that only copies log entries accepted by the
native Zap core to the OTel LoggerProvider.
The second change is necessary due to the first: because the
LoggerProvider will in the future be injectable, and because the
telemetry configuration will be opaque to the service package, we must
always tee the logs from the zap logger to the LoggerProvider. When
using zapcore.NewTeeCore, the resulting core will duplicate all entries
to all cores - which is not what we want.
There's also some light refactoring of tests, and the service package
tests are now ~30s faster by replacing a sleep with assert.Eventually.
#### Link to tracking issue
Preparation work for
https://github.com/open-telemetry/opentelemetry-collector/issues/4970
#### Testing
Unit tests pass
#### Documentation
N/A
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
This PR changes the config struct corresponding to
`service::telemetry::traces` to embed the full `TracerProvider` config
struct from `otelconf`, instead of including only its `Processors`
field.
Something similar was previously done for the `MeterProvider` struct in
#12433.
This has the effect of letting users enable sampling on internal
Collector traces using [the `sampler` section of the declarative
config](9c8ff31553/examples/kitchen-sink.yaml (L294)).
#### Link to tracking issue
I couldn't find any relevant issue.
#### Testing
I added a basic example of using the `sampler` to
`service/telemetry/internal/migration/testdata/v0.3.0_traces.yaml` to
test that we can unmarshal this section properly.
#### Documentation
Just a changelog.
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Yang Song <songy23@users.noreply.github.com>
#### Description
I was using the supervised collector today and ran into an issue where
the agent (collector) was crashing on startup and I wasn't seeing the
logs exported via the configured logger, but I knew it existed bc I was
getting the `Setting up own telemetry...` log.
Turns out in `service.New`, once we've created the logger, we aren't
using it to log and following errors. Instead, they are being returned
by `service.New` and handled by the fallbackLogger.
I propose that, since we have a logger, we use it.
As a followup it would be nice if any confmap errors could be reported
using the instantiated logger, but that would be a bigger refactor.
#### Testing
Tested locally with the following config:
```yaml
receivers:
nop:
exporters:
nop:
otlphttp:
endpoint: "${MISSING_ENV_VAR}:4318"
service:
pipelines:
traces:
receivers: [nop]
processors: []
exporters: [otlphttp]
telemetry:
logs:
processors:
- batch:
exporter:
otlp:
endpoint: https://api.honeycomb.io:443
headers:
- name: x-honeycomb-team
value: `[READACTED]`
protocol: http/protobuf
```
console output:
```
2025-05-22T17:25:30.764-0600 info service/service.go:200 Setting up own telemetry... {"resource": {}}
2025-05-22T17:25:30.764-0600 error service/service.go:223 failed to initialize service graph {"resource": {}, "error": "failed to build pipelines: failed to create \"otlphttp\" exporter for data type \"traces\": endpoint must be a valid URL"}
go.opentelemetry.io/collector/service.New
/Users/tylerhelmuth/projects/opentelemetry-collector/service/service.go:223
go.opentelemetry.io/collector/otelcol.(*Collector).setupConfigurationComponents
/Users/tylerhelmuth/projects/opentelemetry-collector/otelcol/collector.go:197
go.opentelemetry.io/collector/otelcol.(*Collector).Run
/Users/tylerhelmuth/projects/opentelemetry-collector/otelcol/collector.go:312
go.opentelemetry.io/collector/otelcol.NewCommand.func1
/Users/tylerhelmuth/projects/opentelemetry-collector/otelcol/command.go:39
github.com/spf13/cobra.(*Command).execute
/Users/tylerhelmuth/go/1.24.0/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1015
github.com/spf13/cobra.(*Command).ExecuteC
/Users/tylerhelmuth/go/1.24.0/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1148
github.com/spf13/cobra.(*Command).Execute
/Users/tylerhelmuth/go/1.24.0/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1071
main.runInteractive
/Users/tylerhelmuth/projects/opentelemetry-collector/cmd/otelcorecol/main.go:57
main.run
/Users/tylerhelmuth/projects/opentelemetry-collector/cmd/otelcorecol/main_others.go:10
main.main
/Users/tylerhelmuth/projects/opentelemetry-collector/cmd/otelcorecol/main.go:50
runtime.main
/Users/tylerhelmuth/go/1.24.0/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.1.darwin-arm64/src/runtime/proc.go:283
2025-05-22T17:25:30.758-0600 warn envprovider/provider.go:61 Configuration references unset environment variable {"name": "MISSING_ENV_VAR"}
Error: failed to build pipelines: failed to create "otlphttp" exporter for data type "traces": endpoint must be a valid URL
2025/05/22 17:25:30 collector server run finished with error: failed to build pipelines: failed to create "otlphttp" exporter for data type "traces": endpoint must be a valid URL
```
Proof that the error log exported:
#### 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
Process registration protection for telemetry level being set to "None"
#### Link to tracking issue
Fixes#12098
#### Testing
Manual testing on an AIX 7.3 system rented from SiteOx:
```
-bash-5.2# ./otelcorecol_aix_ppc64 --config ./example.yaml
2025-03-11T16:52:04.318-0500 info service@v0.121.0/service.go:193 Setting up own telemetry...
2025-03-11T16:52:04.318-0500 info service@v0.121.0/service.go:238 Skipped telemetry setup.
2025-03-11T16:52:04.318-0500 info service@v0.121.0/service.go:260 Starting otelcorecol... {"Version": "0.121.0-dev", "NumCPU": 8}
2025-03-11T16:52:04.319-0500 info extensions/extensions.go:40 Starting extensions...
2025-03-11T16:52:04.319-0500 info service@v0.121.0/service.go:283 Everything is ready. Begin running and processing data.
2025-03-11T16:52:13.786-0500 info otelcol@v0.121.0/collector.go:342 Received signal from OS {"signal": "interrupt"}
2025-03-11T16:52:13.786-0500 info service@v0.121.0/service.go:325 Starting shutdown...
2025-03-11T16:52:13.786-0500 info extensions/extensions.go:68 Stopping extensions...
2025-03-11T16:52:13.786-0500 info service@v0.121.0/service.go:339 Shutdown complete.
```
#### 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
#### Description
This PR:
- requires "level: normal" before outputting batch processor metrics (in
addition to one specific metric which was already restricted to "level:
detailed")
- clarifies wording in the telemetry level guidelines and documentation,
and adds said guidelines to the requirements for stable components.
Some rationale for these changes can be found in the tracking issue and
[this
comment](https://github.com/open-telemetry/opentelemetry-collector/issues/7890#issuecomment-2684652956).
#### Link to tracking issue
Resolves#7890
#### To be discussed
Should we add a feature gate for this, in case a user relies on "level:
basic" outputting batch processor metrics? This feels like a niche use
case, so considering the "alpha" stability level of these metrics, I
don't think it's really necessary.
Considering batch processor metrics had already been switched to
"normal" once (#9767), but were turned back to basic at some later point
(not sure when), we might also want to add tests to avoid further
regressions (especially as the handling of telemetry levels is bound to
change further with #11754).
---------
Co-authored-by: Dmitrii Anoshin <anoshindx@gmail.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 -->
Moves `extension.Settings.ModuleInfo` to a `service.Host.GetModuleInfo`
method.
This field probably fits better on `extension.Settings` or even in
`component.BuildInfo`, but since its contents are a bit in flux per
discussions like #12283, I would like to move it here to not stabilize
it alongside the rest of `extension`.
The field is not used in any public code on Github, so I think it won't
have a huge impact to remove it in one go, happy to do this in two steps
if preferred.
One relevant difference is that this information is no longer available
at extension build time, but rather after the `Start` method is called.
Another relevant difference is that this is now available for all
component kinds, not just extensions. This could be worked around (we
could pass a different host depending on the component kind) but I don't
see the use right now.
#### Link to tracking issue
Updates #12283
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Fixes#11061.
Depends on releasing the deprecation.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Pass the missing async error channel into telemetry.Settings
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#11417
<!--Describe what testing was performed and which tests were added.-->
#### Testing
With the same setup as in #11417, building new otelcol with the changes
in this PR, and running 2 instances with the same config using the same
metric port, we would see proper crash error messages:
```
# config used:
receivers:
nop:
exporters:
nop:
service:
pipelines:
logs:
receivers:
- nop
exporters:
- nop
telemetry:
metrics:
readers:
- pull:
exporter:
prometheus:
host: localhost
port: 8889
```
```
# first instance log:
./otelcol-custom --config otel-config.yaml
2025-01-16T17:36:34.638-0800 info service@v0.117.0/service.go:165 Setting up own telemetry...
2025-01-16T17:36:34.638-0800 info telemetry/metrics.go:70 Serving metrics {"address": "localhost:8889", "metrics level": "Normal"}
2025-01-16T17:36:34.639-0800 info service@v0.117.0/service.go:231 Starting otelcol-custom... {"Version": "", "NumCPU": 16}
2025-01-16T17:36:34.639-0800 info extensions/extensions.go:39 Starting extensions...
2025-01-16T17:36:34.639-0800 info service@v0.117.0/service.go:254 Everything is ready. Begin running and processing data.
```
```
# second instance's log (using same config)
./otelcol-custom --config otel-config.yaml
2025-01-16T17:36:37.270-0800 info service@v0.117.0/service.go:165 Setting up own telemetry...
2025-01-16T17:36:37.270-0800 info telemetry/metrics.go:70 Serving metrics {"address": "localhost:8889", "metrics level": "Normal"}
2025-01-16T17:36:37.271-0800 info service@v0.117.0/service.go:231 Starting otelcol-custom... {"Version": "", "NumCPU": 16}
2025-01-16T17:36:37.271-0800 info extensions/extensions.go:39 Starting extensions...
2025-01-16T17:36:37.271-0800 info service@v0.117.0/service.go:254 Everything is ready. Begin running and processing data.
2025-01-16T17:36:37.273-0800 error otelcol@v0.117.0/collector.go:325 Asynchronous error received, terminating process {"error": "listen tcp 127.0.0.1:8889: bind: address already in use"}
go.opentelemetry.io/collector/otelcol.(*Collector).Run
go.opentelemetry.io/collector/otelcol@v0.117.0/collector.go:325
go.opentelemetry.io/collector/otelcol.NewCommand.func1
go.opentelemetry.io/collector/otelcol@v0.117.0/command.go:36
github.com/spf13/cobra.(*Command).execute
github.com/spf13/cobra@v1.8.1/command.go:985
github.com/spf13/cobra.(*Command).ExecuteC
github.com/spf13/cobra@v1.8.1/command.go:1117
github.com/spf13/cobra.(*Command).Execute
github.com/spf13/cobra@v1.8.1/command.go:1041
main.runInteractive
go.opentelemetry.io/collector/cmd/builder/main.go:49
main.run
go.opentelemetry.io/collector/cmd/builder/main_others.go:10
main.main
go.opentelemetry.io/collector/cmd/builder/main.go:42
runtime.main
runtime/proc.go:272
2025-01-16T17:36:37.273-0800 info service@v0.117.0/service.go:296 Starting shutdown...
2025-01-16T17:36:37.274-0800 info extensions/extensions.go:66 Stopping extensions...
2025-01-16T17:36:37.274-0800 info service@v0.117.0/service.go:310 Shutdown complete.
```
<!--Please delete paragraphs that you did not use before submitting.-->
---------
Co-authored-by: Antoine Toulme <antoine@toulme.name>
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>
The tracer and logger provider were instantiating different resources
objects that didn't have a `service.instance.id` attribute. This change
fixes that by instantiating the SDK in the service and passing it to the
factory via the telemetry.Settings struct.
This also removes the duplicate code to instantiate the SDK multiple
times, which will be useful when we move to instantiating MeterProvider
via the config SDK. This bug is blocking the change to bump up the
dependency on the config package.
There are a few alternatives that were considered:
1. could set the resource's service.instance.id on the config object
instead. this seemed messy as it would be editing the config struct and
the instantiation of the SDK would remain duplicated.
2. update the factory to pass in a resource object option, i didn't want
to update the NewFactory func.
3. update the CreateLogger, CreateTracerProvider to receive either a
resource or sdk parameter, both of those seemed incorrect as well.
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This allows us to use the otel-go/config package to support configuring
external destinations for logs. I'm putting this in draft to gather
community feedback on whether this is a desirable feature for the
collector.
I used the following configuration with this PR to send data to an OTLP
backend:
```yaml
telemetry:
logs:
processors:
- batch:
exporter:
otlp:
protocol: http/protobuf
endpoint: https://api.honeycomb.io:443
headers:
"x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
```
This allowed me to see logs in my backend:
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Came across these in the work to support v0.3.0 of the configuration
schema, split them into a separate PR to reduce complexity of the
review.
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
This PR removes the `Ready` method from `status.Reporter`. This check
was necessary when `ReportStatus` was on `TelemetrySettings` as it
should not be called until component start-time, but was available to a
component at create-time. This method now resides on `host` which is not
available until component start, making this check unnecessary. This is
an internal refactor that should not affect any other users. I'm not
sure if this needs a changelog, but I generated one anyways and set the
type to breaking, as it removes a method from an interface.
#### Link to tracking issue
Fixes#10792
#### Testing
Units
---------
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This bug caused proctelemetry metrics to not be registered if a user
configured the Collector's internal telemetry via `readers` only and
disabled `address`. The check in the `if` statement is no longer needed
since a no-op meter provider will be configured unless the telemetry
level is set.
Mentioned in #10919
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
This configuration of the internal collector telemetry has been using
the SDK configuration for some time. Moving this gate from alpha to
beta.
#### Link to tracking issue
Related to #6629
---------
Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
#### Description
This PR removes the deprecated memory ballast extension and all the
logic in place in memorylimiter and service that was using it.
#### Link to tracking issue
Related to
https://github.com/open-telemetry/opentelemetry-collector/issues/8343. I
don't want to close it until the [helm
chart](https://github.com/open-telemetry/opentelemetry-helm-charts/pull/1268)
is updated.
#### Testing
Unit tests
---------
Co-authored-by: Antoine Toulme <antoine@toulme.name>
Co-authored-by: Curtis Robert <crobert@splunk.com>
Co-authored-by: Pablo Baeyens <pablo.baeyens@datadoghq.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the processor builder out of the `processor` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the exporter builder out of the `exporter` package, and into
`service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the connector builder out of the `connector` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
While this is not technically required for the profiles work (there is
no notion of signals in extensions), this PR is here to keep things
consistent.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This moves the connector builder out of the `connector` package, and
into `service/internal/builders`.
There's no real reason for this struct to be public (folks shouldn't
call it), and making it private will allow us to add profiling support
to it.
<!-- Issue number if applicable -->
#### Link to tracking issue
https://github.com/open-telemetry/opentelemetry-collector/pull/10375#pullrequestreview-2144929463
Andrew Wilkins
Andres Borja
Matthieu MOREL
Jade Guiton
Bogdan Drutu
Israel Blancas
Tyler Helmuth
Daniel Jaglowski
Alex Boten
Sudipto Baral
Dylan Myers
Matthew Sainsbury
Pablo Baeyens
Marlon Ou
Matthew Wear
Damien Mathieu