In reply to a post by Bam16:

Agreed... it looks like it is how BQM is trying to resolve the URL.

A hostname is not a URL; you need a fully qualified hostname within a URL.

The BQM uses an AAISP Firebrick, and it is not that long ago that DNS support was added. Previously you had to give the system an IP address and remember to change the BQM if your IP changed, or you pinged someone else.

This sounds like a possibility.
Thanks. AB

I did see your e-mail over the weekend and got the developer looking into this as we've had a handful of cases where some BQMs don't work. It's nothing obvious but the Firebrick isn't working properly with them but trying to find out why

seb

Thanks for looking at it.
I've tried a couple of things, and have (only now!) just realised that my hosted domain (tld or any subdomain) shows the same 'NO DATA' result.
So I'm now looking to see if there are any parameters I can change there.
AB

In reply to a post by ACC_B:

Thanks for looking at it.
I've tried a couple of things, and have (only now!) just realised that my hosted domain (tld or any subdomain) shows the same 'NO DATA' result.
So I'm now looking to see if there are any parameters I can change there.
AB

There's something weird going on with the firebrick.. I'm not sure right now if it's related to DNS resolution or not but I see no reason it shouldn't work.

if both urls are resolving to the same IP wouldnt the BQM only send the received ping data to the first monitor it finds with that IP. ?? and thus would by marking all data to the working bqm while showing no data on the duplicate ip bqm

Edited by pyarwood (Sun 02-Nov-25 17:47:57)

In reply to a post by pyarwood:

if both urls are resolving to the same IP wouldnt the BQM only send the received ping data to the first monitor it finds with that IP. ?? and thus would by marking all data to the working bqm while showing no data on the duplicate ip bqm

I saw this first time around and it didn't register with me But I think that the answer is this:

Probably BQM works primarily with host IPs. It will only work with URL's which resolve to an IP address. The problem here will be that when OP sets up a BQM for <hostname>/<IP redirect>, this will resolve to the IP for <hostname> and BQM need look no further for an IP address. Hence the BQM will only look at the IP address used by the hosting provider. BQM will not look beyond <hostname> and cannot interpret <hostname>/<IP redirect> as a different address because <hostname>/<IP redirect> has no meaning in IP address resolution syntax.

Or put another way, <hostname>/<IP redirect> is a URL only for HTTP[s] syntax whereas IP address resolution syntax works exclusively with hostnames and not with URLs.

In reply to a post by pyarwood:

if both urls are resolving to the same IP wouldnt the BQM only send the received ping data to the first monitor it finds with that IP. ?? and thus would by marking all data to the working bqm while showing no data on the duplicate ip bqm

We send the hostname to the Firebrick (the device which does the pings) which does the resolution. If two entries exist with the same hostname we will send both through (as we do with IPs). I'm not sure how it may or may not cache the resolved hostname. We separately track the hostname-to-ip mappings in another system for troubleshooting (including to deal with the "you're pinging me and I didn't ask you to" e-mails we get from time to time as they may be outdates BQMs on a hostname not IP.

Unless there's a firebrick bug there shouldn't be an issue with multiple monitors (although we do limit it to 3 in total per host/IP; that happens before the firebrick).

The 'no data' issue is weird.. we have situations where refreshing the page produces data.. We're just working on another thing but need to look into this.

seb