Custom HTTP headers in exporters and integrations

[Richard Hartmann]

Dear all,

in some cases, users might need to set custom HTTP headers.

In the case of security headers to get past misconfigured WAF/DPI
systems, this would arguably be a technological solution for an
organizational problem.

I was wondering if there are other use cases not considered yet.

An approach to solving this issue would be
https://github.com/grafana/node_exporter/commit/20dddf4d7761cdfb639d75f98354bcbc80279ded

A related question is if there should be a common helper function to
make creating nicer landing pages of exporters easier.


Richard

[Julien Pivotto]

On 10 Feb 13:45, Richard Hartmann wrote:
> Dear all,
>
> in some cases, users might need to set custom HTTP headers.
>
> In the case of security headers to get past misconfigured WAF/DPI
> systems, this would arguably be a technological solution for an
> organizational problem.
>
> I was wondering if there are other use cases not considered yet.

Another use case would be to put some exporters behind a caching system
and define the cache TTL. Could be useful e.g. with the snmp exporter.

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

[Richard Hartmann]

On Mon, Feb 10, 2020 at 1:50 PM Julien Pivotto <roidel...@inuits.eu> wrote:

> Another use case would be to put some exporters behind a caching system
> and define the cache TTL. Could be useful e.g. with the snmp exporter.

This is a use case I can get 100% behind even though I suspect that
this stance will not be unanimous in -team.


Richard

[Ben Kochie]

This might be interesting to include in promhttp. If there are useful headers, even if they're not strictly necessary, we can include them in the defaults.

I was also thinking we might want to improve on our standard exporter landing page. We could have a prometheus/common helper function for building the / landing page for various exporters.

On Mon, Feb 10, 2020 at 1:50 PM Julien Pivotto <roidel...@inuits.eu> wrote:

--
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/20200210125044.GA13002%40oxygen.

[Julien Pivotto]

Sure, but so far I understood that the question was gathering use cases.

Regarding the question about nicer landing pages I agree that we can
find a common ground but that should not contain fancy css or things
like that. Something minimalist with some inline css and a link to
/metrics.

>
>
> Richard

[Richard Hartmann]

Some baseline info on / like uptime, build version, number of scrapes, link to docs and/or source, some short summary of what this exporter does, etc might be fun.

Yes, I am aware part of that can be read out from the metrics endpoint, but it would be quicker not to.

[Richard Hartmann]

Also, `debug/pprof/*` is another web endpoint which might need to be
covered at some point.

--
Richard

[Julien Pivotto]

Not sure we want to expose that as there might be scrapers in some infras that
are smart enough to try to fetch it :)

[Bjoern Rabenstein]

On 10.02.20 13:56, Ben Kochie wrote:
> This might be interesting to include in promhttp. If there are useful headers,
> even if they're not strictly necessary, we can include them in the defaults.

`promhttp` is only returning a handler for the metrics endpoint (which
users usually bind to `/metrics`). The handler could add headers, but
they would only affect the `/metrics` endpoint then. `promhttp` is not
the right place to add certain headers to every HTTP request.

> I was also thinking we might want to improve on our standard exporter landing
> page. We could have a prometheus/common helper function for building the /
> landing page for various exporters.

That's long standing
https://github.com/prometheus/client_golang/issues/166 . Help wanted,
PRs welcome. This could even be a GSoC or Community Bridge project.

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

[Brian Brazil]

On Mon, 10 Feb 2020 at 12:56, Ben Kochie <sup...@gmail.com> wrote:

This might be interesting to include in promhttp. If there are useful headers, even if they're not strictly necessary, we can include them in the defaults.

I agree on this. If there's static headers that universally make sense (as distinct from getting around over-aggressive organisation-specific network policies), I don't see an issue with adding them.

 

I was also thinking we might want to improve on our standard exporter landing page. We could have a prometheus/common helper function for building the / landing page for various exporters.

That's Beorn's call for Go, as that would belong in client_golang.

On the Python/Java front I don't think there's enough exporters for it to be worth it.

Brian

 

On Mon, Feb 10, 2020 at 1:50 PM Julien Pivotto <roidel...@inuits.eu> wrote:

On 10 Feb 13:45, Richard Hartmann wrote:
> Dear all,
>
> in some cases, users might need to set custom HTTP headers.
>
> In the case of security headers to get past misconfigured WAF/DPI
> systems, this would arguably be a technological solution for an
> organizational problem.
>
> I was wondering if there are other use cases not considered yet.

Another use case would be to put some exporters behind a caching system
and define the cache TTL. Could be useful e.g. with the snmp exporter.

--
 (o-    Julien Pivotto
 //\    Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu

--
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/20200210125044.GA13002%40oxygen.

--
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/CABbyFmqx4uQz6rnyBPwKrM3VVgJHSBUXdOFf%3DL2ekb10wyNusw%40mail.gmail.com.

--

Brian Brazil

www.robustperception.io