Converting Traces and Metrics into logs. #120
Conversation
Asking for feedback to see if this is headed in the right direction.
…trace-log-conversion.md
avik-so
requested review from
bogdandrutu,
carlosalberto,
jmacd,
reyang,
SergeyKanzhelev,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
|
I signed it |
| * [Issue 398](https://github.com/open-telemetry/opentelemetry-specification/issues/398) | ||
| * [Issue 617](https://github.com/open-telemetry/opentelemetry-specification/issues/617) | ||
|
|
||
| The [aim here](https://gitter.im/open-telemetry/logs?at=5ee284f2ef5c1c28f0194a89) is to create a standard method to convert a trace or metric into a log for Otel exporters to reduce confusion and increase compatibility. |
There was a problem hiding this comment.
Is the intent to create a human readable representation of metrics and traces in the logs or a machine readable one? Depending on what the goal is there are likely different choices to be made. It is not clear from this document which one is the goal (or maybe the goal is something else). It would be useful to call this out.
FYI, there is a human-readable version of metric and traces in the logs in the Collector: https://github.com/open-telemetry/opentelemetry-collector/blob/master/exporter/loggingexporter/logging_exporter.go
There was a problem hiding this comment.
Good points. After some other feedback I got, I'll make the intention more clear, and also shift the goals a bit. The updates will include multiple export formats depending on intent and purpose, instead of only having a single way of doing things. Also, thank you for making me aware of that prior work.
There was a problem hiding this comment.
@avik-so do you intend to update this OTEP?
There was a problem hiding this comment.
I do.
Still doing research on my part. I'm happy to get assistance.
There was a problem hiding this comment.
As for Metrics, see open-telemetry/opentelemetry-proto#181.
This PR amounts to a (rejected) proposal for OTLP. The problem with open-telemetry/opentelemetry-proto#181 is that it was better at describing the input of an aggregation, not the output of an aggregation.
I think if we're logging, the idea is to log raw metric events (i.e., no aggregation). The proposal in that PR has a MetricDescriptor with these fields:
- Temporality (Cumulative, Delta)
- Structure (Adding Monotonic, Adding, Grouping)
- Continuity (Continuous, Snapshot)
= 12 combinations
These 12 combinations can be thought of as six instruments crossed with cumulative/delta, which completely and accurately describes the current OTel API metric event.
That led to very lengthy explanations of what it means for various kinds aggregation. If we're only considering raw metric events, then this may be a good protocol.
Technical notes
The problem with open-telemetry/opentelemetry-proto#181 may have been predicted by #88 and #93, where more than six potential kinds of instrument were described and then some of them were rejected. See also open-telemetry/opentelemetry-proto#199 believe that a metric descriptor with Structure=Grouping and Temporality=Delta could also be described as the hypothetical "Interval" temporality mentioned there.
There is also a question of whether you can derive system.cpu.utilization or process.cpu.utilization correctly with whatever logging format is proposed: open-telemetry/opentelemetry-specification#819
| | trace.start.timestamp | log.Body.StartTimeStamp | | ||
| | trace.end.timestamp | log.Body.EndTimeStamp | | ||
| | trace.parentId | log.Body.ParentId | | ||
| | trace semantic conventions** | log.Resource | |
There was a problem hiding this comment.
Which semantic conventions? There are conventions for Resources and conventions for Spans. Does this suggest to put Span attributes that are defined in the semantic conventions into the Resource? If so then it is not clear why.
There was a problem hiding this comment.
My intent here was the semantic conventions for resources, I missed the fact that they also exist for span attributes.
| | metric.AggregationType | log.Attributes.AggregationType | | ||
| | metric.Instrumentation | log.Attributes.Instrumentation | | ||
|
|
||
| |Open Telemetry Trace field| Open Telemetry Log field| |
There was a problem hiding this comment.
Probably better to refer to "Span field" instead of "Trace field" since the table lists Span fields.
There was a problem hiding this comment.
Since Trace is a high level concept and span isn't, can you point out the differences to me? I obviously missed something here.
| | trace.Events | log.Attributes.Events | | ||
| | trace.Tracestate | log.Attributes.Tracestate | | ||
| | trace.status | log.Attributes.status | | ||
| | trace.kind | log.Attributes.kind | |
There was a problem hiding this comment.
What do we do with the Span Resource? It is missing in this table.
The PR has not been updated and looks like a candidate for closing since no progress has been made for a long while. |
|
@avik-so I'm going to close this OTEP, please check out the connectors and other work going on in the Collector. If you are still interested in this, please update the OTEP and reopen. |
This OTEP is a proposal for how to standardize the conversion of traces and metrics into Open Telemetry logs.