Would it make sense to fold these all into cn=monitor,cn=userroot,... That way if you mix/match bdb/lmdb (which is unlikely but ...), then we have the right monitor data in "one place" per backend? Even if we have say a single bdb env, there is not much harm in "duplicating" those stats through the various monitors.

It also means when you want to look at how a be is performing all the data you need is in a single place too which helps make it easier to see and understand the situation.

What do you think?

Would it make sense to fold these all into cn=monitor,cn=userroot,... That way if you mix/match bdb/lmdb (which is unlikely but ...), then we have the right monitor data in "one place" per backend? Even if we have say a single bdb env, there is not much harm in "duplicating" those stats through the various monitors.
It also means when you want to look at how a be is performing all the data you need is in a single place too which helps make it easier to see and understand the situation.
What do you think?

Yeah I think that sounds good. I don't think we can or should roll all of our monitors into a single entry, but we have way too many monitors that are scattered around and hard to find:

Server Monitors

• cn=monitor
• cn=counters,cn=monitor
• cn=disk space,cn=monitor
• cn=snmp,cn=monitor

Database related monitors

• cn=monitor,cn=ldbm database,cn=plugins,cn=config
• cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config
• cn=monitor,cn=userroot,cn=ldbm database,cn=plugins,cn=config

At least the Server monitors are all children of cn=monitor which makes them easy to find and search for. They should stay as is. It's the database monitors that are in need of some consolidation and organization. I agree we should just have a single monitor for each backend, and no global monitor backend monitor which is what I think you are suggesting: cn=monitor,cn=userroot,cn=ldbm database,cn=plugins,cn=config. This monitor could contain the global DB stats (non-backend stats) and that backend's stats. So yeah if there are multiple backends you would see "duplicate" global stats across each backen's monitor, but at least it's all there in a single entry. As an Admin that sounds a lot easier to deal with than having to check multiple entries.

The issue with making changes here is that it can break existing clients. So it's important to think about when and where this has to land, and the release notes/documentation. And obviously we also have to have the deal with different stats from different database types :-)

At least the Server monitors are all children of cn=monitor which makes them easy to find and search for. They should stay as is.

Yeah, no disagreement from me about that.

It's the database monitors that are in need of some consolidation and organization. I agree we should just have a single monitor for each backend, and no global monitor backend monitor which is what I think you are suggesting: cn=monitor,cn=userroot,cn=ldbm database,cn=plugins,cn=config. This monitor could contain the global DB stats (non-backend stats) and that backend's stats. So yeah if there are multiple backends you would see "duplicate" global stats across each backen's monitor, but at least it's all there in a single entry. As an Admin that sounds a lot easier to deal with than having to check multiple entries.

Yeah, that's exactly what I have in mind. Plus a lot of deployments are single backend only, so nice and easy to see everything need at once.

The issue with making changes here is that it can break existing clients. So it's important to think about when and where this has to land, and the release notes/documentation. And obviously we also have to have the deal with different stats from different database types :-)

It's always a bit tricky, because we don't really define "what is and isn't api stable" really.

Perhaps the best way to start is a feature flag for old/new monitors so we can develop and test this sooner, than for a major version we flip the default? Then later we can remove the flag etc.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4254

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.