|[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.