What is the best practice in otlp-transformer?

[llc1123]

I am currently working on the otlp transformer for logs.

I see different practices of transforming internal types into otlp shape:

• In metrics, every ResourceMetrics is transformed into one IResourceMetrics, whether they have the same resources and scopes or not.
• In trace, ReadableSpans are consolidated into minimal IResourceSpanss and IScopeSpanss.

The first approach takes more network bandwidth and the second one has more performance overhead. I personally prefer the first one. Is there a guideline about this kind of situations?

[llc1123]

@fuaiyi

[fuaiyi]

@llc1123 Sorry for the late reply. I have implemented an otlp transformer of logs before (but it hasn't merged yet, so I need to mention mr after sdk merged): #3442. Hope it will be helpful to you

[llc1123]

Thank you. I have read your implementation but I still have the question: which one is the best practice?

[fuaiyi]

Logs use the second one, which is defined in the specification

[fuaiyi]

The root cause here is because the LogRecord/Span is associated with resources, but the Metric Point is not associated with resources (the idiosyncratic nature of Metrics) and you need to do resource aggregation before the Exporter.
In addition, the data from the exporter is aggregated by resource, so it doesn't cost more bandwidth. There's more bandwidth depending on how many times you call export,
I think there is not much performance cost, the number of exports at a time is not very large, this is almost negligible compared to the performance cost of sending a request.

[fuaiyi]

relevant specifications, hope to help you
SpanExporter
MetricExporter
LogRecordExporter