[Date Prev]   [Date Next] [Thread Prev]   [Thread Next] [Date Index]   [Thread Index]

 

     Re: [snips-users] hostmon-client.linux & /proc/

> in practice SNMP model has access control, encryption and authentification. hostmon lacks all of those (except ACL)
>
	Not disputing that.
>
> snmpd code is also by far better tested and patches are available in case of problems - hostmon lacks all that too. 
>
	Well, that I'll dispute on the grounds that hostmon lacks better
testing and patching due to there being no real major following for it. I
think we all have wanted to do major work to it, but it never got formalized.
I think if we did, and people really started to see movement, we could 
bring it into line.
>
> SNMPd is standart and supported part of most OSes - hostmon is not.
>
	I partially disagree with this. While there is SNMP for most platforms,
its questionable in what capacity, and in what way we expect things to be
there. OS vendors supply it for the most part, but then there are MIB issues,
not always getting the complete information from the MIBS you need (We 
track FTP connections for one client, MYSQL calls for another) from a base
SNMPd, and I'm not sure if Net-SNMP handles it. If we expect people to 
extend their SNMP, we have to make sure we support all the possible ones.
If we force them to use Net-SNMP, its just as bad as forcing them to load
perl, or anything else.
>
> adding/configuring snmpd as part of jumstart/kickstart is trivial and supported.
>
	Don't disagree. We have Nocol as part of our FreeBSD and Solaris
jump starts too. ;)
>
> many system management tools require running SNMP agent anyway.
>
	I don't disagree, but its what we can get from said agent.
>
> snmp agent is also lighter then hostmon, doesn't fork processes, doesn't hang on resources as hostmon does (mounts, dns resolution, etc)
>
	I partially disagree. I'm not sure why you consider SNMP to be lighter,
I don't think either are major resource hogs. Forking it only does if you want
it to be able to be contacted remotely on its own port. If you want to use
RSH it won't fork (Except for the system program calls, unless thats what
you meant). And as for hanging on resources, we have had issues with it, and
for the ones we REALLY have had issues for, I've modified hostmon-osclient or
the collector to account for it.
> 
> yes hostmon is easier for older OSes that don't have snmp agent with Host MIB.
>
	Not just that, but for what MIB's don't have and can't be extended.
>
> HOST SNMP MIB is in RFC, but output of vmstat netstat etc is not.
>
	And thats why there are different .OSNAME's. Granted, its not standard,
but on the platform itself its standard.
>
> see hostmon code and you'll see how people are fighting with output of multiple versions of vmstat (SunOS,Solaris,Linux, RHEL,)
>
	Believe me, I've put in alot more work on getting it to get the 
time properly on FreeBSD and Solaris. But if I was to put this back into 
the tree, no one else would have to worry.
> 
> but hostmon has things that snmp agent doesn't have - like mailq (maybe sendmail MIB has it?)
> (hovewer mailq output is broken in RHEL linux - there is permission issue)
>
	I'm sure we could program around this. A wrapper, a cron, etc.
> 
> It is easier, that's true. especially due to the fact that many MNS sofware vendors take this shortcut and just keep scripting that in shell/perl
> as oppose to do it the right way :-)))))
>
	No comment. ;)
> 
> >  (PS - Besides, I multiply my load by 100 and change my refresh
> > down to 4 minutes... And I know how to do that in perl. ;) )
> 
> when chaning your refresh make sure you recreate RRD, it doesn't like changes in time intervals.
> 
	No, I meant in hostmon-osclient. We multiply the load in there so
50 is 0.50, and 123 is 1.23 . And I have it run every 4 minutes instead of
every 5 since we were getting alot of "old data" warnings.

		Tuc/TTSG Internet Services, Inc.

Zyrion Traverse Network Monitoring & Network Management Software