That should work.
Thanks,
M.

On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gera...@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 <msau...@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 <gera...@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 <msau...@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@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>
>>
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
>
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

Reply via email to