Skip to content

kafkareceiver: add signal-specific topic/encoding #38985

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

axw
Copy link
Contributor

@axw axw commented Mar 26, 2025

Description

Add signal-specific configuration for topic and encoding.

The topics are already signal-specific by default, it just hasn't been possible to explicitly configure a different topic for each signal. Thus if you set the topic: foo, it would be used for all signals, which is never going to work with the receiver.

Similarly, while the default encoding is the same for all signals (i.e. otlp_proto), some encodings are available only for certain signals, e.g. azure_resource_logs is (obviously) only available for logs. This means you could not use the same receiver for multiple signals unless they each used the same encoding.

To address both of these issues we introduce signal-specific configuration: logs::topic, metrics::topic, traces::topic, logs::encoding, metrics::encoding, and traces::encoding.

The existing topic and encoding configuration have been deprecated. If the new fields are set, they will take precedence; otherwise if the deprecated fields are set they will be used. The defaults have not changed.

Link to tracking issue

Fixes #32735

Testing

Unit tests added.

Documentation

README updated.

Add signal-specific configuration for topic and encoding.

The topics are already signal-specific by default,
it just hasn't been possible to explicitly configure
a different topic for each signal. Thus if you set the
`topic: foo`, it would be used for all signals, which is
never going to work with the receiver.

Similarly, while the default encoding is the same for all
signals (i.e. otlp_proto), some encodings are available
only for certain signals, e.g. azure_resource_logs is
(obviously) only available for logs. This means you could
not use the same receiver for multiple signals unless they
each used the same encoding.

To address both of these issues we introduce signal-specific
configuration: `logs::topic`, `metrics::topic`, `traces::topic`,
`logs::encoding`, `metrics::encoding`, and `traces::encoding`.

The existing `topic` and `encoding` configuration have been
deprecated. If the new fields are set, they will take precedence;
otherwise if the deprecated fields are set they will be used.
The defaults have not changed.

Fixes open-telemetry#32735
@axw axw force-pushed the kafkareceiver-persignal-config branch from 69bf554 to 063f012 Compare April 9, 2025 08:26
@axw axw marked this pull request as ready for review April 9, 2025 08:47
@axw axw requested a review from a team as a code owner April 9, 2025 08:47
@MovieStoreGuy MovieStoreGuy merged commit 2766731 into open-telemetry:main Apr 11, 2025
174 checks passed
@github-actions github-actions bot added this to the next release milestone Apr 11, 2025
@axw axw deleted the kafkareceiver-persignal-config branch April 11, 2025 04:31
akshays-19 pushed a commit to akshays-19/opentelemetry-collector-contrib that referenced this pull request Apr 23, 2025
#### Description

Add signal-specific configuration for topic and encoding.

The topics are already signal-specific by default, it just hasn't been
possible to explicitly configure a different topic for each signal. Thus
if you set the `topic: foo`, it would be used for all signals, which is
never going to work with the receiver.

Similarly, while the default encoding is the same for all signals (i.e.
otlp_proto), some encodings are available only for certain signals, e.g.
azure_resource_logs is (obviously) only available for logs. This means
you could not use the same receiver for multiple signals unless they
each used the same encoding.

To address both of these issues we introduce signal-specific
configuration: `logs::topic`, `metrics::topic`, `traces::topic`,
`logs::encoding`, `metrics::encoding`, and `traces::encoding`.

The existing `topic` and `encoding` configuration have been deprecated.
If the new fields are set, they will take precedence; otherwise if the
deprecated fields are set they will be used. The defaults have not
changed.

#### Link to tracking issue

Fixes open-telemetry#32735

#### Testing

Unit tests added.

#### Documentation

README updated.
Fiery-Fenix pushed a commit to Fiery-Fenix/opentelemetry-collector-contrib that referenced this pull request Apr 24, 2025
#### Description

Add signal-specific configuration for topic and encoding.

The topics are already signal-specific by default, it just hasn't been
possible to explicitly configure a different topic for each signal. Thus
if you set the `topic: foo`, it would be used for all signals, which is
never going to work with the receiver.

Similarly, while the default encoding is the same for all signals (i.e.
otlp_proto), some encodings are available only for certain signals, e.g.
azure_resource_logs is (obviously) only available for logs. This means
you could not use the same receiver for multiple signals unless they
each used the same encoding.

To address both of these issues we introduce signal-specific
configuration: `logs::topic`, `metrics::topic`, `traces::topic`,
`logs::encoding`, `metrics::encoding`, and `traces::encoding`.

The existing `topic` and `encoding` configuration have been deprecated.
If the new fields are set, they will take precedence; otherwise if the
deprecated fields are set they will be used. The defaults have not
changed.

#### Link to tracking issue

Fixes open-telemetry#32735

#### Testing

Unit tests added.

#### Documentation

README updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[receiver/kafka]: Replace "topic" setting by "traces_topic", "logs_topic" and "metrics_topic"
3 participants