Influx push handler

[colega]

What this PR does

Adds an http handler that accepts writes in the Influx Line protocol. This code is brought from https://github.com/grafana/influx2cortex with some minor adjustments.

Which issue(s) this PR fixes or relates to

None yet, internal discussion.

Checklist

• Tests updated
• End-to-end tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[colega]

The code here is easy (pending to add some e2e tests which would be straightforwards), it's more about the conversation about whether we want this to be achieved this way (i.e., having this code directly in Mimir).

IMO, this is the way we should go, given the simplicity of the implementation and maintenance.

[pstibrany]

I agree with you that integrating with Mimir would make it easy to use. But it also adds maintenance burden and expands Mimir in a way that's not compatible with its primary focus ("Grafana Mimir is an open source, horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.").

We had similar discussion here: cortexproject/cortex#3708

[pracucci]

expands Mimir in a way that's not compatible with its primary focus ("Grafana Mimir is an open source, horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.").

Disagree. Mimir is not Cortex. Mimir wants to be a "open source, horizontally scalable, highly available, multi-tenant, time series database". We're abandoning the "for Prometheus" in our story and we want to be able to ingest your metrics, whatever protocol you want to use.

[pstibrany]

expands Mimir in a way that's not compatible with its primary focus ("Grafana Mimir is an open source, horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.").

Disagree. Mimir is not Cortex. Mimir wants to be a "open source, horizontally scalable, highly available, multi-tenant, time series database". We're abandoning the "for Prometheus" in our story and we want to be able to ingest your metrics, whatever protocol you want to use.

We should drop "for Prometheus" from our webpage in that case.

Right now there is an effort to open-source our proxies. Having some protocols support in proxies and others directly in Mimir is confusing.

Personally I prefer proxies approach as it's more flexible and allows different backends too (if coded using public API only). But as as Oleg points out, it's also not as convenient and simple to use. (That said, if we decide to have everything in Mimir, I'm happy to commit to that approach.)

[56quarters]

I agree with Peter that using one approach for some protocols and another for other protocols is confusing.

FWIW, in GEM we use the following approach:

• The code for implementing each protocol lives in a separate repo, maintained by the query team.
• That code is added to GEM as a dependency.
• Each supported proxy is started within GEM as a module with its own corresponding target, e.g. -target=graphite-write.

I think this is a decent balance between ease of use for users and ease of maintenance for us.

[colega]

I think this is a decent balance between ease of use for users and ease of maintenance for us.

Vendoring code doesn't simplify maintenance but only makes it more complicated, while end users don't really care if code comes from vendor/ or from pkg/

[56quarters]

I think this is a decent balance between ease of use for users and ease of maintenance for us.

Vendoring code doesn't simplify maintenance but only makes it more complicated, while end users don't really care if code comes from vendor/ or from pkg/

My point was more that the query squad would maintain it and be able to iterate on it as they please, the code in Mimir would only be responsible for wiring up the configuration for it.