Dave, I suggest that our conversation goes at an impasse.
I want you to look this problem from usability side. Currently there is no opensource monitoring tools that can easy and without any functionality loss handle such data representation, you can easely check this by your self , or ask peoples from communities. I advise you make separate indexes and you can reject it, but i want to make a deal with you. ENTITY-SENSOR-MIB is good stuff, but as i described, one single table to store meterage of different sensors, it's bad for usability. Anyway I can implement it and if it will be good enough you will accept it, but this implementation will have two different oid roots, first one - single table (as described in IETF ), second one - each table for each sensors type with separate indexes. Thu, 21 Oct 2010 00:51:18 +0400 the letter from maap maap <[email protected]>: > > > 2010/10/20 maap maap <[email protected]>: > > > I moved to the new kernel and now all sensors are managed by kernel, > > > so fan and temperature sensors's indexes been changed > > Yes - that's perfectly normal with SNMP. > > You cannot assume that index values are necessarily stable across > > restarts of the agent. Monitoring applications need to be prepared > > to handle changes of indexing. > > You can use the lmXxxSensorsDevice values to spot when re-mapping > > is necessary. > Most of the monitoring applications can't automatically handle with such > situation. > i tried - cacti,zabbix,groundwork,zennos. > only cacti have neccessary functional. > Even with cacti, I have to fix sensors.conf on every server to use same > sensor's names because indexing by names is > only existing way to fix this issue over all applications that I ever seen. > If you still have any doubt about this, just install for example zabbix, and > try to add at least 10 devices with 3 > graphs (1 for each sensor type). > Yes I can patch every application I use to handle it, > but is that correct way ? > Why unresonable strange data representation can't be fixed within snmpd ? > You can at least leave old representation and add new one (with separate > indexing) within new root oid. > > > Also for example I know that all my devices have 6 fans and 5 temperature > > and 15 power sensors at max. > > > If I am using current code I have to configure all my devices separately > > to monitor em. > > > But with separate indexes i can create one single template which contains > > maximum > > > number of all sensors and use it for all devices. > > I don't quite follow. > > Why not configure your template to monitor the whole of the relevant tables, > > rather than individual ranges? Or select a very high maximum (say 255), > > and let the monitoring application determine which instances are > > currently valid. > In this way, how you should represent stored data to analyze it ? > One huge diagram and 255 curves within ? > Even so, any diagrams have list of curves and values that they represent > (often placed at the bottom). > Any mentioned application returned huge and ugly screen. > > > If you want me to change my code, just say how exactly it should looks > > like to avoid misunderstanding. > > > I can add one more single table with any sensors available in the system, > > should I ?. > > If you are looking at extending the sensors capability of the agent, > > then I suggest you draw up a proposal for exactly what you have in mind. > > I know that there are people here who have expressed an interest in sensors > > in the past (and probably know much more about this than I do). > > If you are considering a single, combined-sensors MIB table, then I'd > > suggest > > it would be a very good idea to at least look at the Entity Sensors MIB, > > rather than re-inventing the wheel. > > Dave ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
