-
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
[exporter/loki] Auto convert OpenTelemetry ResourceAttributes to log labels #19215
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
cc @mar4uk |
I think we can go for it. Adding So basically, if users trust their downstream configurations and keep the number of resource attributes minimal, we can allow users to promote that attributes to labels automatically. The fact that we have We can add a warning to the description of this option in README: use with cautions since a high number of resource attributes can lead to high cardinality that will affect exploring such logs performance in Loki |
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. |
let's keep this issue for a little bit longer |
Were you still planning to implement resource_to_telemetry_conversion in the Loki Exporter? |
Yes, it would be good to have |
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. |
still relevant |
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. |
This issue is still relevant. But another road will be possible in the next loki version: https://grafana.com/docs/loki/next/send-data/otel/ |
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. |
@sandeepsukhani, do we have a logic like that already on the Loki side? |
Hey @jpkrohling, we have this logic documented. The code for converting otlp format to loki format can be found here. |
@mar4uk, do you think the logic can be reused? |
I think so.
All the rest resource attributes will be sent as structured metadata. Does it sound good? |
Yes, sounds good to me! |
I found this issue because I am also looking to store attributes as structured metadata. After the seeing the (static) list of converted attributes I was a little skeptical of the proposed solution. However, the docs clearly mention that it will be possible to extend or even replace this list. That would be amazing! Edit: for example, |
Also interesting about this issue. |
this is a feature i'd like as well. been spending hours and hours trying to get otelcol to send "native" loki labels. a plug-and-play option would be awesome. |
@mhulscher , @mk-raven , @crutonjohn , given that Loki 3.0 supports OTLP natively, I'm interested in knowing whether you still see the need for the Loki exporter. |
@jpkrohling hello! We needed this exporter because some service, use loki api for store telemetry data in Clickhouse DB. |
A quick look into both makes me believe they support OTLP natively as well. |
Its true, but Grafana UI doesn't support query in otlp format. Its has Clickhouse plugin, but for many people its hard to using. Better use natively LogQL, PromQL and TraceQL |
Ingesting data in OTLP doesn't mean you have to query data in OTLP (even if there was one query language for OTLP). You should still be able to send data in via OTLP and query them via LogQL, as we do with Grafana Cloud :-) |
But from otlp logs there no query filters in Grafana, if You use LogQL and Loki datasource. |
It's certainly possible to use LogQL to query a Loki data source containing logs that were ingested via OTLP. |
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. |
I'm closing, as the Loki exporter will be deprecated soon and this won't likely be sorted out on that component. |
Component(s)
exporter/loki
Is your feature request related to a problem? Please describe.
The
Resource Attributes
are very interesting to use as labels in the log events.With the current implementation, I need to declare an explicit mapping in my collector's configuration for each
Resource Attribute
. This approach requires to reconfigure myopentelemetry-collector
each time an application introduces a newResource Attribute
(available in SemConv or not).Moreover due to #14113 I need to declare each ResourceAttribute twice - which can be tedious.
Describe the solution you'd like
Since Loki's backend is largely inspired by the Prometheus backend (Loki uses Mimir implementation of Prometheus compliant backend), that seems natural to apply the same constraint and have the same feature sets than exporter/prometheusremotewriteexporter.
That would be great if the feature
resource_to_telemetry_conversion
could be ported into thelokiexporter
.Describe alternatives you've considered
No response
Additional context
@gouthamve #14113 (comment)
The text was updated successfully, but these errors were encountered: