Hello,
I’m trying to set up collectd to monitor 389-ds by using the values under cn=monitor. Is there something out there (e.g., a collectd plugin?) that could do this? I’ve seen this: http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-... http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html, but that requires MySQL or Postgres.
Thanks, Sergei
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.... May be other users already run some similar plug-in? Should we have such plug-in? Thanks, M.
On Thu, Dec 14, 2017 at 2:45 PM, Sergei Gerasenko gerases@gmail.com wrote:
Hello,
I’m trying to set up collectd to monitor 389-ds by using the values under cn=monitor. Is there something out there (e.g., a collectd plugin?) that could do this? I’ve seen this: http://directory. fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor- ldap-monitoring.html, but that requires MySQL or Postgres.
Thanks, Sergei
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Thank you for the ref to the post. In absense of anything else, I might go with the python solution. If there’s an easier way though, I’m also interested.
On Dec 14, 2017, at 6:23 PM, Marc Sauton msauton@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@lists.fedoraproject.... 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, M.
On Thu, Dec 14, 2017 at 2:45 PM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@gmail.com> wrote: Hello,
I’m trying to set up collectd to monitor 389-ds by using the values under cn=monitor. Is there something out there (e.g., a collectd plugin?) that could do this? I’ve seen this: http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-... http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html, but that requires MySQL or Postgres.
Thanks, Sergei
389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@redhat.com mailto:msauton@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@lists.fedoraproject.... 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,
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/ht... 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/ht...
I may have forgotten some attributes. Thanks, M.
On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko gerases@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@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@ 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
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@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/ht... 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 http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html
there is also an old tool called repl-monitor.pl http://repl-monitor.pl/ from the "Admin Express" feature, HTML colored page: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht... 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@gmail.com mailto:gerases@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@redhat.com mailto:msauton@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@lists.fedoraproject.... 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 mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
That should work. Thanks, M.
On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko gerases@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@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@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@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-leave@lists.fedoraproject.org
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Cool. Another question: just going off the snmp,monitor path, I’m graphing searchops and errors. Here’s what that looks like:
As you can see, the search ops correspond exactly to the error peaks. The error logs are empty though. Is this correlation of any concern? How can I get more detail on the errors metric?
Thanks, Sergei
On Dec 21, 2017, at 5:46 PM, Marc Sauton msauton@redhat.com wrote:
That should work. Thanks, M.
On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gerases@gmail.com mailto:gerases@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@redhat.com mailto:msauton@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/ht... 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 http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html
there is also an old tool called repl-monitor.pl http://repl-monitor.pl/ from the "Admin Express" feature, HTML colored page: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht... 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@gmail.com mailto:gerases@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@redhat.com mailto:msauton@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@lists.fedoraproject.... 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 mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify add: aci aci: (target ="ldap:///cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 3.0; acl "monitor3"; allow( read, search, compare ) userdn = "ldap:///anyone";)
Odd, but when I try to apply the above ldif, I get "ldap_modify: Server is unwilling to perform (53)”.
If I stop the server and modify dse.ldif manually, it does seem to work.
389-users@lists.fedoraproject.org
-
Marc Sauton -
Sergei Gerasenko