Jason King wrote: > If (as was suggested) we add the ability to present kstats in a more > generic fashion (I think that would be in addition to the above > piece), it would need to be in a way that if new kstats are added, or > old ones deleted, the MIB would not need to be updated. I think > everyone here knows that kstats are subject to change without notice. > However if that's all that's available at the time, a working 'wrong' > solution is better than a non-existant 'right' solution.
The normal SNMP way to do this is to enumerate the kstat names in one area, index them, and hold the data under another OID. See for example how network interfaces are handled dynamically. netInterfaces.0.0-N is the index->MIBsubnumber mapping (usually 1->1, 2->2, etc) netInterfaces.1.0-N is the name of the indexed name netInterfaces.2.0-N is the 1st relevant stat, etc. (I don't have the NET-2 MIB at hand, so the actual value of 0 may vary) So consider the OID kstat.1.1 holding "vmem" kstat.1.1.1 "semaphore" kstat.1.1.1.1 4289 (instance # of this semaphore) kstat.1.1.1.1.1 "crtime" kstat.1.1.1.1.2 1268894.0219505 I'm not sure how well SNMP MIBs handle different classes of OID trees having radically different structures (vmem would have a totally different set of children than ufs) --Joe _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
