That should work.
Thanks,
M.
On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gerases(a)gmail.com> wrote:
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(a)redhat.com> 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(a)gmail.com>
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(a)redhat.com> 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@list
>
s.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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org