blackbox_exporter icon indicating copy to clipboard operation
blackbox_exporter copied to clipboard

Added support set schema, port, path to HTTP probe

Open zloidemon opened this issue 4 years ago • 5 comments

zloidemon avatar Jul 08 '21 08:07 zloidemon

What are you trying to achieve? the target contains those information already

roidelapluie avatar Jul 08 '21 09:07 roidelapluie

What are you trying to achieve? the target contains those information already

I'm going to use https://github.com/mbelloiseau/website-monitoring but in the special location with custom port. Ping probe won't work if I set up my target as https://somesite:9999/blah. Use multiple targets will produce a long dropdown menu with multiple fileds which contains the same hostname on grafana dashboard.

Ping probe output:

ts=2021-07-08T09:17:45.872635175Z caller=icmp.go:91 module=icmp target=https://google.com:9999/blah level=error msg="Resolution with IP protocol failed" err="lookup https://google.com:9999/blah: no such host"
ts=2021-07-08T09:17:45.87271371Z caller=main.go:130 module=icmp target=https://google.com:9999/blah level=warn msg="Error resolving address" err="unable to find ip; no fallback: lookup https://google.com:9999/blah: no such host"

image

zloidemon avatar Jul 08 '21 09:07 zloidemon

If I understand correctly what you are trying to do @zloidemon, you could achieve that with relabelling.

My guess is that you have something like:

probe_success{instance="https://google.com:9999/blah", job="blackbox"}
probe_success{instance="google.com", job="blackbox"}
probe_success{instance="google.com:9999", job="blackbox"}

and you actually want:

probe_success{instance="google.com", job="http"}
probe_success{instance="google.com", job="icmp"}
probe_success{instance="google.com", job="tcp"}

or even:

probe_success{instance="google.com", job="blackbox", check="http"}
probe_success{instance="google.com", job="blackbox", check="icmp"}
probe_success{instance="google.com", job="blackbox", check="tcp"}

That's where the relabelling comes in.

mem avatar Jul 08 '21 21:07 mem

@mem

If I understand correctly what you are trying to do @zloidemon, you could achieve that with relabelling.

My guess is that you have something like:

probe_success{instance="https://google.com:9999/blah", job="blackbox"}
probe_success{instance="google.com", job="blackbox"}
probe_success{instance="google.com:9999", job="blackbox"}

and you actually want:

probe_success{instance="google.com", job="http"}
probe_success{instance="google.com", job="icmp"}
probe_success{instance="google.com", job="tcp"}

or even:

probe_success{instance="google.com", job="blackbox", check="http"}
probe_success{instance="google.com", job="blackbox", check="icmp"}
probe_success{instance="google.com", job="blackbox", check="tcp"}

That's where the relabelling comes in.

Yes exactly I need the same thing!! Could you help me achieve that? @zloidemon any luck figuring this out with relabling?

hkpanchani avatar Jan 17 '23 07:01 hkpanchani

I also have a need that can be addressed by this PR.

My use case is the following:

  • I monitor multiple sites with HTTP and ICMP jobs + a custom job to check domain validity ;
  • I've built a dashboard, filtered by target, to aggregate the metrics of the 3 jobs ;
  • Some of the monitored sites don't automatically redirect to HTTP even when it is available ;
  • I must keep target consistent across jobs to maintain dashboard aggregation.

Allowing to force protocol will allow me to circumvent this problem and keep my dashboard working.

Also, I use a static file for the target (via file config discovery) and I share it across the three jobs. Adding the protocol in the target will break this abstraction, as ICMP et domain job are failing when using protocol in the target.

Using relabelling breaks the dashboard aggregation, it's not a viable solution for me neither.

Hope it's clear enough.

tuarrep avatar Mar 17 '23 14:03 tuarrep