Ingesting OTLP

[Julien Pivotto]

Hello,

I have seen the dev summit notes.

I would like to create a dependency between:

> Goutham: Reconsider OTLP Ingest

and

> Goutham: . (dots) and slashes in metric and label names.


I think we should FIRST address the special characters in the metric
names and label names before ingesting OTLP.

That way, when we implement the OTLP feature flag, we have a good user
experience since the start, and we don't need to change it later on,
confusing early adopters.

Regards

--
Julien Pivotto
@roidelapluie

[andrewsthompson. eth]

Thanks for reaching out, I’d like to move forward.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/Y21q7VJC/xTaS1%2Bn%40nixos.

--

@

Enter the cloud with confidence 

[Matthias Rampke]

Hmm, my assumption was that ingesting OTLP would be equivalent to running the OTel Collector + remote write, but without the collector in the middle. That implies using the same mappings as specified in the OTel spec / implemented in the collector.

This is something that can happen relatively quickly.

On the other hand, there are a lot of open questions about extending the metric naming. Aside from working out how to represent this in PromQL without breaking compatibility, we also need to think about managing the transition for existing users. That includes users of the OTel collector. I see that adding another place where the translation happens, right in Prometheus, adds to the complexity of that transition, but I don't think it makes it fundamentally harder, since we need a solution for the collector-remote write setup anyway.

Since "ingesting OTLP into Prometheus" is an existing problem with an existing (albeit suboptimal) solution, I would prefer not to put one tangible improvement on that solution on hold with no timeline for figuring out the other, much more complex one.

/MR