Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. gathering Poller Performance data? (Joseph Bernard)
2. Re: gathering Poller Performance data? (Christian Ramseyer)
3. Re: gathering Poller Performance data? (Joseph Bernard)
--- Begin Message ---
Has anyone come up with an easier way than scraping the Poller Performance page
to keep historical data about performance? Our server people LOVE to
oversubscribe everything which kills performance, but I don’t notice until days
later when things have gotten really bad. At that point the stats have
refreshed off the page, so I can’t tell them when everything went in the toilet.
Everything on the box looks okay in top, but Poller Performance numbers tell
the real story. If anyone has any advice on how to get those numbers or what I
should be looking at instead, that would be a big help. I do know how to run
commands off the backend database if the info is there as well.
Thanks,
Joseph B.
--- End Message ---
--- Begin Message ---
Hi Joseph
I'm using this query in a cronjob that writes into a time series database:
with cte as (
select
(select count(*) from device where last_macsuck > (current_timestamp
- interval '1 minute')) as macsuck_lastmin,
(select count(*) from device where last_arpnip > (current_timestamp
- interval '1 minute')) as arpnip_lastmin
)
select to_char(current_timestamp, 'YYYY-MM-DD HH24:MI:SS') as timestamp,
c.macsuck_lastmin,
c.arpnip_lastmin,
((select count(*) from device where last_discover >
current_timestamp - interval '72 hours' ) / ((c.macsuck_lastmin +
c.arpnip_lastmin + 0.001) / 2))::int as estim_cycle_min
from cte c
Output looks something like this:
timestamp | macsuck_lastmin | arpnip_lastmin | estim_cycle_min
2020-04-29 14:33:02 | 32 | 59 | 30
2020-04-29 14:34:03 | 38 | 66 | 26
2020-04-29 14:35:03 | 33 | 61 | 29
2020-04-29 14:36:03 | 18 | 26 | 62
The third column is an approximation of how long it will take to poll
all your devices with the poll performance for the current minute. This
is only meaningful while polling, if the _lastmin's are zero then this
will approach infinity.
This is not exactly what the poller performance page shows, but it was
very helpful in the past when tuning number of workers, postgres
parameters etc. in a big installation.
The exact stuff the page does uses the admin queue table, and the SQL
can be found here:
https://github.com/netdisco/netdisco/blob/master/lib/App/Netdisco/DB/Result/Virtual/PollerPerformance.pm
IIRC I came up with the first query since I had some issues with the way
the admin page does it. I think if a single device in the whole batch
stays somehow queued, it will never show it as completed. But this was
years ago and I'm unfortunately a bit foggy on the details, might work
just fine nowadays.
Hope that helps.
Cheers
Christian
On 13.09.20 21:33, Joseph Bernard wrote:
> Has anyone come up with an easier way than scraping the Poller
> Performance page to keep historical data about performance? Our server
> people LOVE to oversubscribe everything which kills performance, but I
> don’t notice until days later when things have gotten really bad. At
> that point the stats have refreshed off the page, so I can’t tell them
> when everything went in the toilet.
>
>
>
> Everything on the box looks okay in top, but Poller Performance numbers
> tell the real story. If anyone has any advice on how to get those
> numbers or what I should be looking at instead, that would be a big
> help. I do know how to run commands off the backend database if the
> info is there as well.
>
>
>
>
>
> Thanks,
>
> Joseph B.
>
>
>
>
>
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
>
--- End Message ---
--- Begin Message ---
This is perfect!
Thank you,
Joseph B.
On 9/13/20, 9:13 PM, "Christian Ramseyer" <[email protected]> wrote:
Hi Joseph
I'm using this query in a cronjob that writes into a time series database:
with cte as (
select
(select count(*) from device where last_macsuck > (current_timestamp
- interval '1 minute')) as macsuck_lastmin,
(select count(*) from device where last_arpnip > (current_timestamp
- interval '1 minute')) as arpnip_lastmin
)
select to_char(current_timestamp, 'YYYY-MM-DD HH24:MI:SS') as timestamp,
c.macsuck_lastmin,
c.arpnip_lastmin,
((select count(*) from device where last_discover >
current_timestamp - interval '72 hours' ) / ((c.macsuck_lastmin +
c.arpnip_lastmin + 0.001) / 2))::int as estim_cycle_min
from cte c
Output looks something like this:
timestamp | macsuck_lastmin | arpnip_lastmin | estim_cycle_min
2020-04-29 14:33:02 | 32 | 59 | 30
2020-04-29 14:34:03 | 38 | 66 | 26
2020-04-29 14:35:03 | 33 | 61 | 29
2020-04-29 14:36:03 | 18 | 26 | 62
The third column is an approximation of how long it will take to poll
all your devices with the poll performance for the current minute. This
is only meaningful while polling, if the _lastmin's are zero then this
will approach infinity.
This is not exactly what the poller performance page shows, but it was
very helpful in the past when tuning number of workers, postgres
parameters etc. in a big installation.
The exact stuff the page does uses the admin queue table, and the SQL
can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netdisco_netdisco_blob_master_lib_App_Netdisco_DB_Result_Virtual_PollerPerformance.pm&d=DwIDaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4Pt1z80PQIvvfw2j1-oSIA&m=RaJCWH2tieJkABDQch5h_RGgDYV6BILC0HgpAAmQxqQ&s=o_z7TvlyedHsQLdzdr3YSw1fAClgvxyNhNfhaIoXafQ&e=
IIRC I came up with the first query since I had some issues with the way
the admin page does it. I think if a single device in the whole batch
stays somehow queued, it will never show it as completed. But this was
years ago and I'm unfortunately a bit foggy on the details, might work
just fine nowadays.
Hope that helps.
Cheers
Christian
On 13.09.20 21:33, Joseph Bernard wrote:
> Has anyone come up with an easier way than scraping the Poller
> Performance page to keep historical data about performance? Our server
> people LOVE to oversubscribe everything which kills performance, but I
> don’t notice until days later when things have gotten really bad. At
> that point the stats have refreshed off the page, so I can’t tell them
> when everything went in the toilet.
>
>
>
> Everything on the box looks okay in top, but Poller Performance numbers
> tell the real story. If anyone has any advice on how to get those
> numbers or what I should be looking at instead, that would be a big
> help. I do know how to run commands off the backend database if the
> info is there as well.
>
>
>
>
>
> Thanks,
>
> Joseph B.
>
>
>
>
>
> _______________________________________________
> Netdisco mailing list
> [email protected]
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_netdisco_mailman_netdisco-2Dusers_&d=DwIDaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4Pt1z80PQIvvfw2j1-oSIA&m=RaJCWH2tieJkABDQch5h_RGgDYV6BILC0HgpAAmQxqQ&s=F14NJa5EgxEdasNTdCWSerw4QPgZavGM8mUu-Owdxak&e=
>
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
