30 Kvě
2018
30 Kvě
'18
9:56
Hi,
over the last weekend I did configure knot resolver on Turris Omnia to
write statistics to my influxdb instance.
Now that I have statistics, I am not entirely sure what all the data means.
Everything under answer is easy to understand.
But all data under cache is only 0, although answer.cached is not 0.
Please find some stats below. I would be very grateful for some explanation
what the data means.
My next step would be to try to use RPZ funtionality. is there statistics
for RPZ too?
/Ulrich
stats.list()
[answer.nxdomain] => 360546
[answer.100ms] => 64682
[answer.1500ms] => 2740
[answer.slow] => 12137
[answer.servfail] => 204137
[answer.250ms] => 84208
[answer.cached] => 430091
[answer.nodata] => 1533
[answer.1ms] => 462921
[answer.total] => 922236
[answer.10ms] => 58963
[answer.noerror] => 356015
[answer.50ms] => 195917
[answer.500ms] => 29794
[answer.1000ms] => 7525
[predict.learned] => 54
[predict.epoch] => 19
[predict.queue] => 520
[query.edns] => 152223
[query.dnssec] => 211
cache.stats()
[hit] => 0
[delete] => 0
[miss] => 0
[insert] => 0
--
Ulrich Wisser
ulrich(a)wisser.se
30 Kvě
30 Kvě
13:08
Hello Ulrich,
nice to hear you try knot-resolver!
On 05/30/2018 09:56 AM, Ulrich Wisser wrote:
Now that I have statistics, I am not entirely sure
what all the data
means.
Everything under answer is easy to understand.
But all data under cache is only 0, although answer.cached is not 0.
We know that deficiency. answer.cached vs. answer.total is probably
what you want, indicating the portion that was *fully* answered from
cache. Details: https://gitlab.labs.nic.cz/knot/knot-resolver/issues/324
Please find some stats below. I would be very grateful
for some
explanation what the data means.
My next step would be to try to use RPZ funtionality. is there
statistics for RPZ too?
There is no statistics collection in the policy module (and thus RPZ);
I/we haven't thought of that yet, but it shouldn't be difficult to add
in some form - the main thing is to decide which events/numbers to
collect :-) What particular ones would you like? Simple counts of
DENY/DROP/... with one number per type of action, by default?
[predict.learned] => 54
[predict.epoch] => 19
[predict.queue] => 520
I don't remember details in predict module with certainty ATM, but
*epoch* is a periodically incremented serial number, and in each such
interval it may *learn* some common queries, and it may *queue* some
(other) queries for prefetching based on what it's learned in previous
epochs.
[query.edns] => 152223
[query.dnssec] => 211
*edns* and *dnssec* are answers that contain EDNS and DO bit,
respectively. (the other being a subset of the first)
--Vladimir
13:13
On 05/30/2018 01:08 PM, Vladimír Čunát wrote:
*edns* and *dnssec* are answers that contain EDNS and
DO bit,
respectively. (the other being a subset of the first)
To be clear, this is done as counting answers from knot-resolver, just
like for stats.list(), but in correct setup these properties should be
exactly the same as in the corresponding requests.
31 Kvě
31 Kvě
15:32
Hi Vladimir,
I find the query stats strange. If you count on the answers, why aren't
they answer stats? And why aren't the other flags counted. I for one would
be interested in AD.
I think the prefetch stats need some more definition. Right now I can't see
a real use. I would like to see how many queries are considered for
prefetch (is this prefetch.queue?) and the total amount of prefetches done.
For the RPZ I think it would be very interesting to see which RPZ and
action combination was hit how many times.
Maybe you could look at pihole https://pi-hole.net/ these people have a
nice dashboard and good statistics for their DNS service.
/Ulrich
Vladimír Čunát <vladimir.cunat(a)nic.cz> schrieb am Mi., 30. Mai 2018 um
13:13 Uhr:
On 05/30/2018 01:08 PM, Vladimír Čunát wrote:
**edns** and **dnssec** are answers that contain EDNS and DO bit,
respectively. (the other being a subset of the first)
To be clear, this is done as counting answers from knot-resolver, just
like for stats.list(), but in correct setup these properties should be
exactly the same as in the corresponding requests.
--
Ulrich Wisser
ulrich(a)wisser.se
2 Čen
2 Čen
8:29
On 05/31/2018 03:32 PM, Ulrich Wisser wrote:
I find the query stats strange. If you count on the
answers, why
aren't they answer stats? And why aren't the other flags counted. I
for one would be interested in AD.
I find that an implementation detail. Usage of EDNS and the DO flag are
determined by the query having them set, so it feels more natural (to
me) to count them as properties of the queries rather than answers.
I think the prefetch stats need some more definition.
Right now I
can't see a real use. I would like to see how many queries are
considered for prefetch (is this prefetch.queue?) and the total amount
of prefetches done.
They are actually documented, but I suppose it's not particularly
enlightening unless you know how the prefetch module works.
http://knot-resolver.readthedocs.io/en/stable/modules.html#exported-metrics
For the RPZ I think it would be very interesting to
see which RPZ and
action combination was hit how many times.
Maybe you could look at pihole https://pi-hole.net/ these people have
a nice dashboard and good statistics for their DNS service.
Basically all this turned out to require more than a few minutes to fix,
so I collected the ideas here:
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/364
--Vladimir
4 Čen
4 Čen
19:41
Vladimír Čunát <vladimir.cunat(a)nic.cz> schrieb am Sa., 2. Juni 2018 um
08:29 Uhr:
On 05/31/2018 03:32 PM, Ulrich Wisser wrote:
I find the query stats strange. If you count on the answers, why aren't
they answer stats? And why aren't the other flags counted. I for one would
be interested in AD.
I find that an implementation detail. Usage of EDNS and the DO flag are
determined by the query having them set, so it feels more natural (to me)
to count them as properties of the queries rather than answers.
I agree that it isn't that important where the flags are counted.
But I would like a count of all flags, not only these two.
I think the prefetch stats need some more definition.
Right now I can't
see a real use. I would like to see how many queries are considered for
prefetch (is this prefetch.queue?) and the total amount of prefetches done.
They are actually documented, but I suppose it's not particularly
enlightening unless you know how the prefetch module works.
http://knot-resolver.readthedocs.io/en/stable/modules.html#exported-metrics
I have actually read the documentation. Here is my understanding
predict.epoch is no statistic at all, more a marker of the current period
predict.queue is the number of queries that are considered for prefetching
predict.learned is the number of fetched executed in the current period
If that is true, the values are actually unusable for statistics. The
graphite modules will write statistics to the database every 5s. What will
the predict values tell me?
For the RPZ I think it would be very interesting to
see which RPZ and
action combination was hit how many times.
Maybe you could look at pihole https://pi-hole.net/
these people have a
nice dashboard and good statistics for their DNS service.
Basically all this turned out to require more than a few minutes to fix,
so I collected the ideas here:
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/364
Of course, I didn't expect a quick fix.
/Ulrich
--
Ulrich Wisser
ulrich(a)wisser.se
2160
days inactive
2165
days old
knot-resolver-users@lists.nic.cz
5 comments
2 participants
participants (2)
-
Ulrich Wisser -
Vladimír Čunát