Replies: 1 comment
-
Hello @dmathieu, I thought about that, but unfortunately there are limitations about the SDK go (cannot depend on proto) which makes things a bit harder. I think a small library "to/from otel-go representation" is a good starting point. Also the collector wants to develop the internal representation in a way that will be as performant as possible for cases where otlp is received and exported, which means we will at one point add capabilities like lazy unmarshaling, etc. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey,
I'm not opening this as an issue, as it may have been covered elsewhere, and I feel I'm missing something regarding the reason this isn't the case.
It would be very convenient to be able to use the same exporter in both a non-collector project, and one transmitting its data to a collector.
So, have you considered matching the exporters' interfaces to match exporters from opentelemetry-go SDK?
Beta Was this translation helpful? Give feedback.
All reactions