> Le 17 mai 2017 à 10:42, Johannes Weber <johan...@webernetz.net> a écrit :
>
> Hi list,
>
> some months ago I asked about NTP monitoring. Thanks for your answers!
>
> I tried Brians' version which sets some mru parameters. But it's not
> working as I expected. Does anyone see my mistake?
>
> I set the following parameter: "mru mindepth 30 maxage 1200" in order to
> delete all addresses that are older than 1200 seconds in case the list
> is longer than 30.
>
> However, this is not the case. I hit my NTP server with 50 probes (via
> RIPE Atlas) yesterday, but they are still stored as you can see the "78"
> addresses:
>
> pi@ntp2:~ $ ntpq -c mon
> enabled: 0x1
> addresses: 78
> peak addresses: 78
> maximum addresses: 14563
> reclaim above count: 30
> reclaim older than: 1200
Mine works ok. I don’t think there is an issue. The entries aren’t deleted
when the limit is reached, unless there a request for a new client which
arrives after it.
Maybe you had no new requests coming in?
Here I have limited the entry count to 5 and age to 30
mike@bb3:~$ ntpq -c mrulist
Ctrl-C will stop MRU retrieval and display partial results.
Retrieved 6 unique MRU entries and 0 updates.
lstint avgint rstr r m v count rport remote address
==============================================================================
3 15 1c0 . 4 4 69 123 bb2.home
5 15 1c0 . 4 4 69 123 bb1.home
5 15 1c0 . 4 4 69 123 muon.stratum1.ddns.net
114 1 0 . 3 4 4 49741 raspb3.stratum1.ddns.net
313 1 0 . 3 4 4 46493 raspb2.stratum1.ddns.net
328 4 0 . 3 4 8 59803 electron.home
here I did an ntpdate -d from client raspb4
mike@bb3:~$ ntpq -c mrulist
Ctrl-C will stop MRU retrieval and display partial results.
Retrieved 6 unique MRU entries and 0 updates.
lstint avgint rstr r m v count rport remote address
==============================================================================
2 1 0 . 3 4 4 36616 raspb4.stratum1.ddns.net
12 15 1c0 . 4 4 72 123 bb2.home
14 15 1c0 . 4 4 72 123 muon.stratum1.ddns.net
14 15 1c0 . 4 4 72 123 bb1.home
171 1 0 . 3 4 4 49741 raspb3.stratum1.ddns.net
371 1 0 . 3 4 4 46493 raspb2.stratum1.ddns.net
you can see that the entry or electron has been removed.
Mike
> kilobytes: 5
> maximum kilobytes: 1024
>
> They are all still in the list:
>
> pi@ntp2:~ $ ntpq -c mru
> Ctrl-C will stop MRU retrieval and display partial results.
> Retrieved 78 unique MRU entries and 0 updates.
> lstint avgint rstr r m v count rport remote address
> ==============================================================================
>
>
> [...]
>
> 69885 0 1d0 . 3 4 3 55430 2001:67c:10ec:3548:8000::1337
> 69885 0 1d0 . 3 4 3 38038 2a02:a40:300::12
> 69885 0 1d0 . 3 4 3 36528 2a01:360:1:18:c24a:ff:fecc:59ac
> 69885 0 1d0 . 3 4 3 45882
> 2a02:29b0:1004:0:c66e:1fff:fe5b:cc64
> 69885 0 1d0 . 3 4 3 39951
> 2a00:ca60:11:6000:f6f2:6dff:fe5d:971a
> 69885 0 1d0 . 3 4 3 48751 2a02:f48:1:200:16cc:20ff:fe48:d0e2
> 69885 0 1d0 . 3 4 3 43509 2a06:eac0:3000::4
> 69885 0 1d0 . 3 4 3 37525 2a03:1ae0:0:270:185:65:96:253
> 69885 0 1d0 . 3 4 3 40210 2a06:6bc0:0:2:ea94:f6ff:fee3:6d5a
> 69885 0 1d0 . 3 4 3 58714 2001:638:80a:2:6666:b3ff:feb0:e194
> 69885 0 1d0 . 3 4 3 42365
> 2a00:4ae0:4000:0:6666:b3ff:feb0:d85c
> 69885 0 1d0 . 3 4 3 43873 2a0b:2f00:29:0:fa1a:67ff:fe4d:847f
>
>
> Any ideas?
>
> Thanks again,
>
> Johannes
>
> ---
> Johannes Weber
> Webernetz.net - Network Security Consulting
> mail: johan...@webernetz.net
> mobile: +49 174 1880211
>
> blog: https://blog.webernetz.net
> twitter: @webernetz [1]
>
> Am 14.02.2017 23:31, schrieb Brian Inglis:
>
>> On 2017-02-06 13:10, Johannes Weber wrote:
>>
>>> I have one question concerning the monstats and mrulist commands. I am
>>> monitoring my NTP servers and I want to graph the current clients. I am
>>> using the "addresses" line from the monstats output.
>>> However, it seems that every client that is gone many days ago (!) is
>>> still listed within the "addresses" section and not only in the "peak
>>> addresses". Same is true within the mrulist output which lists addresses
>>> that have a lstint many days ago.
>>>
>>> So my question is: How can I get a number of the "most recent" clients,
>>> i.e., clients that have a lstint < 2000 or the like. (One bad approach
>>> might be to use the mrulist output and to grep all lines that have an
>>> lstint < 2000. But I am searching for a better way to do it.)
>>
>> You can tweak the monitor stats collection with the mru conf statement:
>>
>> mru [maxdepth count | maxmem kilobytes | mindepth count | maxage seconds
>> | initalloc count | initmem kilobytes | incalloc count
>> | incmem kilobytes]
>>
>> https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#mru
>>
>> e.g. you may want to increase maxage to e.g. 86400s from default 64s
>> and reduce mindepth to your max peak addresses count from default 600,
>> so when you hit your peak addresses count, anything older than a day
>> is evicted and replaced by a newer entry.
>>
>> I'd use awk for simple filtering of values like this e.g.
>>
>> $ ntpq -c mrulist 2> /dev/null | awk '$8 == "123" && $1 <= 86400'
>>
>> which you can easily expand on to do stats, or pass to a plot package.
>
>
> Links:
> ------
> [1] https://twitter.com/webernetz
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
"The power of accurate observation is commonly called cynicism by those who
have not got it. »
George Bernard Shaw
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
