[lightprometheusreceiver] initial working draft

[dloucasfx]

This is the initial working draft for lightprometheusreceiver

[rmfitzpatrick]

Would it be better to update the simple prometheus receiver that we already contributed instead of adding a new one? With prometheus, simple prometheus and the prometheus-exporter monitor this would be the fourth prometheus receiver for scraping metric views.

[rmfitzpatrick]

Please add an integration test. There's an existing one w/ internal metrics that could be used as a basis: https://github.com/signalfx/splunk-otel-collector/blob/main/tests/receivers/prometheus/internal_prometheus_test.go

Sorry, not sure how I missed that.

[hughesjj]

two nits but honestly LGTM otherwise, especially for a draft or triage.

[jinja2]

Would we consider adding an option to this receiver to drop certain type of prom metrics?
I have a use case where I want to collect prom metrics from some k8s components but am not really interested in the histogram metrics because the buckets are generated dynamically and w/o native UI support for histogram in O11y, visualizing these is not a good experience. So I would just like to not collect them instead of adding exclusion rules for specific metrics.

[dloucasfx]

good point, yes we can and I think we should. @atoulme wdyt?

[atoulme]

The usual guidance is to drop the metrics later in a processor filter. I think the signalfx exporter also translates histograms to a different metric type.
We can probably filter at the source though, while we're in here.

[dloucasfx]

right, filtering at the source will save us a few bytes... anything we can do to save one bit of memory at a time :-)

[atoulme]

let's do it in a separate PR. Less is more.

[atoulme]

OTL-2009 is filed to follow up.

[atoulme]

Would it be better to update the simple prometheus receiver that we already contributed instead of adding a new one?

True, the aim is to test it here and move it upstream, and see if we can use simpleprometheusreceiver. Tough though as it changes the config.

[hughesjj]

... Huh, I wonder if we can version Config schemas similar to how we version metrics schemas in otel. Not the first time I've seen such an ask.

that said additive config changes are usually pretty easy.