-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Default routing to receiver-specific data streams #34246
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
/label -needs-triage enhancement |
…amic_index config (open-telemetry#35417) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Implement receiver-based routing under *_dynamic_index config. e.g. Set data_stream.dataset to hostmetricsreceiver (or hostmetricsreceiver.otel in the OTel output mode) for the scope name github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/cpuscraper **Link to tracking Issue:** <Issue number if applicable> Fixes open-telemetry#34246 **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.>
Component(s)
exporter/elasticsearch
Is your feature request related to a problem? Please describe.
When dynamic indexing to data streams is enabled, we currently route signals to
<type>-generic.otel-default
, for examplelogs-generic-default
. A challenge with that is that the data for all receivers is going to the same data streams. We should instead separate the data a bit better according to the data stream naming scheme, without risking a data stream explosion.As this impacts the default routing, we should implement this before GA as changing the data streams can be considered to be a breaking change.
Describe the solution you'd like
If the scope.name matches the regex
\/receiver\/(\w*receiver)
, the dataset will be set to the capture group 1 ($1
). For example,hostmetricsreceiver
(orhostmetricsreceiver.otel
in the OTel output mode) for the scope namegithub.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/cpuscraper
. This ensures that we don't send all metrics from well-known receivers tometrics-generic.otel-default
. As tracing instrumentations typically set a different scope name for each instrumented library, and because it can be user-defined with an unknown cardinality, we don't want to route by any generic scope name to not risk an explosion of data streams. Instead, we only route based on receivers by default, where the granularity and cardinality is limited and matches well with the definition of the data stream naming scheme.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: