But so that the performance is measured from our PiHole (location)
Maybe with the following features:
a check on configurable intervals (e.g. every 1, 5, ...60 minutes)
with an FQDN we can specify in the settings
the check runs against all preconfigured DNS server(providers) and the custom dns servers we've specified in PiHole
if the query takes longer than 1 second, it should be considered as a timeout
Showing following values:
performance: the speed when querying each nameserver directly
quality: shows the up-time of nameservers. For example if a provider has 4 NS and 1 fails then quality is 75% for that location and benchmark. This means even though the provider is marked as down a real user could still get an answer thanks to the round robin algorithm used by DNS. "Quality" does not represent the real up-time of a provider
up-time: shows the real up-time of DNS provider. A provider is marked as down only if all nameservers go down at the same time. (in the select location)
In a first phase, I wouldn't mind to set the settings via a config file
getting the graph displayed nicely is already a good challenge I think
I guess some performance stats woud be very useful, but until then there's a really simple change that could make it easier for us to manually measure response times: use the complete timestamp format on the log messages (don't hide milliseconds).
In the database the timestamps are saved as 10 digit number - so in second interval. For getting milliseconds they must be saved as 13 digit numbers. If you wish that should happen, please open a new feature request.
Oh I didn't know that, I thought it was just a formatting limitation. But then how is UI capable of showing the response time like in "CNAME (570.2ms)"? Is this information obtained somewhere else? How can I get it outside the UI?
This is a one time operation. It would be nice to have that value for each query being made by pihole. In fact, somehow it's already there, because the UI is able to print it like "CNAME (570.2ms)"
I'm not sure, this is a question to the devs. I guess the information is retrieved directly from the request's answer (like time dig abc.com or even only dig abc.com) and held in FTL's memory for a certain amount of time but is never stored in the database.
That really seems to be the case, and I don't need to create a FR because I just found one about that here.
Meanwhile, I'm gonna get my hands dirty and make a workaround. I'm thinking about mirroring the log to another file, tailing it as it is being written, but replacing the timestamp being used to the complete current time. It is not the same precision, but enough to measure some stats about query performances.
While response times are an in-memory only issue, you actually can query those values with ms granularity via Pi-hole's Telnet API .
You are looking for the last column of the getallqueries result set. Note that these values lose the decimal fraction by the query returning only the integer part.
I just tried it here and got results like "1593693154 AAAA adc3-launch.adcolony.com 192.168.0.65 1 0 4 3 N/A -1".
So even the latest queries only get a 10-digit timestamp. BTW it's in the first column (I don't know what the last column means).
The output follows the layout of the Query Log UI, and it would seem Pi-hole 5 has added two additional columns to that telnet output - my bad, I obviously wasn't aware of this (and our telnet documentation would need an update also).
So the response time in ms I was referring to would be 3 in your example, which would translate to 0.3 ms as shown in Pi-hole's UI.