[Date Prev][Date Next]
Q: monitoring attributes
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least).
I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values.
Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity):
It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing.
Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"?
I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP?
The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111".
Also: is "cn=Connection 0,cn=Connections,cn=Monitor" a bug? I see it twice:
dn: cn=Connection 0,cn=Connections,cn=Monitor