-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[exporter/loki] Refactor component, reducing configuration #12873
Comments
Loki only has a concept of labels, not resource labels and attribute labels. So, would you not just want the key to be
At the moment (as far as I'm aware), the attribute processor wouldn't meet the requirements in the current form - it does not support setting a key to a list of values, it does not support resource attributes and it cannot extract non-attribute fields such as severity. In principle, however, this approach would work for me. |
Pinging code owners: @gramidt @jpkrohling. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
The exporter would need to know whether a specific attribute is part of the resource or regular attributes. While we can parse both and return the most specific one (regular, when both regular and resource are present), allowing users to be explicit would reduce confusion and would allow for a small optimization on the lookup.
There's the resource processor for that.
I'll do some PoC, but wouldn't the transform processor also help here? |
My issue was resolved by setting up the attribute. Thanks all |
@gregoryfranklin, I just checked and you are right, the attributes processor does not support slices in its current form: opentelemetry-collector-contrib/internal/coreinternal/processor/filterhelper/filterhelper.go Lines 24 to 39 in 29a3e33
However, I'll play a bit with it, but if this doesn't work, we could do something like: processors:
attributes:
actions:
- action: insert
key: loki.attribute.labels
value: "host.name, pod.name" Not the best, but not too bad either. What do you think? |
This commit brings a new implementation of the Loki exporter while maintaining compatibility with the previous version (called "legacy" in this PR). The new exporter has a cleaner logic, allowing the Loki labels to be configured as part of the data points themselves instead of being part of the static configuration. This will be useful in the future when migrating from the Loki exporter to a native OTLP endpoint in Loki. Fixes #12873 Signed-off-by: Juraci Paixão Kröhling <[email protected]>
This commit brings a new implementation of the Loki exporter while maintaining compatibility with the previous version (called "legacy" in this PR). The new exporter has a cleaner logic, allowing the Loki labels to be configured as part of the data points instead of being part of the static configuration. This will be useful in the future when migrating from the Loki exporter to a native OTLP endpoint in Loki. Fixes #12873 Signed-off-by: Juraci Paixão Kröhling <[email protected]>
In preparation for having a possible OTLP endpoint in Loki to ingest logs, we need to refactor the Loki exporter to have minimal configuration, potentially with only the endpoint. All other configuration options would be hints to be provided as resource or regular attributes, like the following:
We still have questions about the tenant information. We could either have a generic solution that would work for all HTTP and/or gRPC-based clients, or we could have a hint similar to the example above, like:
To accomplish this, we need to provide an initial PR deprecating the current options and translation to the new approach.
One option will be removed without replacement, namely the "format". We'd like to hear from you if you currently use this and cannot use the JSON format. If we don't hear a concrete reason why people need the "body" option, which is currently the default, we'll switch the default to "json" and remove the "format" option altogether.
The changes proposed here are needed because we'll need the same hints in the future when we add OTLP support for Loki. Making those changes now will make the migration path and future deprecation of the Loki exporter easier.
The text was updated successfully, but these errors were encountered: