Re: monitoring

[Sergei Gerasenko <gerases@xxxxxxxxx>]

Excellent info, Mark. Thank you. I’m using collectd for graphing the results and since the backend trees are not readable by everyone, I’m thinking of granting read access to the collectd account. 

Is an ldif like the one below the right way to do it:

dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config

changetype: modify

add: aci

aci: (target ="ldap:///cn=monitor,cn=ldbm database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 3.0; acl “collectd access"; allow( read, search, compare ) userdn = "ldap:///uid=collectd,cn=users,cn=accounts,dc=mydomain,dc=net”;)

Thanks!

  Sergei

On Dec 21, 2017, at 3:20 PM, Marc Sauton <msauton@xxxxxxxxxx> wrote:

The SNMP counters are not always interesting, but they can provide the system memory use and some LDAP BIND info.

Under

cn=monitor , the most important are:

the difference between opsinitiated and opscompleted

and also

threads

currentconnections

and

backendmonitordn

so under

cn=monitor,cn=<backend-name>,cn=ldbm\ database,cn=plugins,cn=config objectclass=*

like for example

dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config

the following are important:

entrycachehitratio

currententrycachesize

maxentrycachesize

dncachehitratio

currentdncachesize

maxdncachesize

and the pagein and pageout values if too high

under

cn=monitor,cn=ldbm\ database,cn=plugins,cn=config

nsslapd-db-current-locks

nsslapd-db-configured-locks

nsslapd-db-page-ro-evict-rate

nsslapd-db-page-rw-evict-rate

the dbmon.sh tool can provide some info/hints/details

for replication, the attribute

nsDS5ReplicaLastUpdateStatus

nsDS5ReplConflict

nsruvReplicaLastModified

/usr/bin/ldapsearch -xLLL -h xx -p xx -D "cn=directory manager" -W -b "cn=mapping tree,cn=config" "(&(objectClass=nsDS5ReplicationAgreement)(nsDS5ReplicaHost=*)(nsDS5ReplicaPort=xx))" nsDS5ReplicaChangesSentSinceStartup nsDS5ReplicaLastUpdateStatus nsDS5ReplicaUpdateInProgress nsDS5ReplicaLastUpdateStart nsDS5ReplicaLastUpdateEnd

/usr/bin/ldapsearch -LLLx -o ldif-wrap=no -D "cn=directory manager" -W -b dc=example,dc=com nsds5ReplConflict=* dn cn 

see 

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status

http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html

there is also an old tool called

repl-monitor.pl

from the "Admin Express" feature, HTML colored page:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring

I may have forgotten some attributes.

Thanks,

M.

On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gerases@xxxxxxxxx> wrote:

I’ve implemented the solution described in the thread. My question now is: what should I really monitor? 

There are so many metrics to consider. The thread talks about cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each backend for example. Is there a recommended mininum set of things to monitor?

On Dec 14, 2017, at 6:23 PM, Marc Sauton <msauton@xxxxxxxxxx> wrote:

There is no collectd 389-ds plug-in, but there was a post with an example:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/

May be other users already run some similar plug-in?

Should we have such plug-in?

Thanks,

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx