On Thu, Jan 05, 2006 at 07:02:52PM +0200, Buchan Milne wrote:
On Thursday 05 January 2006 18:21, Charles Jones wrote:
*real 0m1.912s* user 0m0.022s sys 0m0.008s
Almost 2 seconds there....and just for one command.
I keep wondering how long the equivalent snmp query takes ... or in fact gathering all the data asynchronously via snmp ...
Let's see ... Net-SNMP includes an "snmpdf" command:
$ time snmpdf -v 1 -c somepassword somehost Description size (kB) Used Available Used% / 5969124 754896 5214228 12%
real 0m0.201s user 0m0.154s sys 0m0.019s
$ time ssh somehost df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 5969124 754896 4911004 14% /
real 0m0.535s user 0m0.011s sys 0m0.004s
So: 0.2 seconds for snmp, 0.5 seconds for ssh. (No, I don't know why they calculate the available disk size differently - df probably leaves out the 5% filesystem space that is reserved for "root" use).
SNMP probably wins because it is UDP based, so you avoid a lot of overhead from the TCP connection setup. Plus the SNMP daemon is running, so it doesn't need to start a new process to respond.
But I do agree with Charles - using a "bbfetch" style method of pulling data from clients to the server only works for a small number of hosts. On the scale that I work with on a daily basis - 2000 hosts or more - it is simply not practical to contact all hosts every 5 minutes.
I'm still willing to implement the agent-less data collection in Hobbit, because sometimes that is just going to be the only way you can get information about a server. So it is an OK way of doing this, if you know what it should - and should not - be used for.
(BTW, the issue that was raised about updates being easier if you don't have to deploy them on all clients - that's a non-issue. It boils down to whether or not you have an (automated) procedure for software and patch distribution - if you don't have that, then you're in trouble no matter how Hobbit collects data.)
Regards, Henrik