monitoring

[Sergei Gerasenko]

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-monit...
<http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monit...;,
but that requires MySQL or Postgres.

Thanks,
  Sergei

[Marc Sauton]

There is no collectd 389-ds plug-in, but there was a post with an example:
https://lists.fedoraproject.org/archives/list/[e-mail]...
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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>

[Sergei Gerasenko]

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(a)redhat.com&gt;
> wrote:
>  
>  There is no collectd 389-ds plug-in, but there was a post with an example:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> <https://lists.fedoraproject.org/archives/list/[e-mail]...
>  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(a)gmail.com
> <mailto:[e-mail]>> 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-monit...
> <http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monit...;,
> but that requires MySQL or Postgres.
>  
>  Thanks,
>    Sergei
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Sergei Gerasenko]

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
> <mailto:[e-mail]>> wrote:
> > 
> > There is no collectd 389-ds plug-in, but there was a post with an example:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> <https://lists.fedoraproject.org/archives/list/[e-mail]...
> > May be other users already run some similar plug-in?
> > Should we have such plug-in?
> > Thanks,

[Marc Sauton]

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...
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...

I may have forgotten some attributes.
Thanks,
M.

On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gerases(a)gmail.com&gt;
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&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>

[Sergei Gerasenko]

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&gt;
> 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...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>  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...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>  
>  I may have forgotten some attributes.
>  Thanks,
>  M.
>  
>  On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gerases(a)gmail.com
> <mailto:[e-mail]>> 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
> <mailto:[e-mail]>> wrote:
> >> 
> >> There is no collectd 389-ds plug-in, but there was a post with an example:
> >>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> <https://lists.fedoraproject.org/archives/list/[e-mail]...
> >> 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
> <mailto:[e-mail]>
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Marc Sauton]

That should work.
Thanks,
M.

On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gerases(a)gmail.com&gt; 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&gt; 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&gt;
>  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&gt; 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
>
>

[Sergei Gerasenko]

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(a)redhat.com&gt;
> wrote:
>  
>  That should work.
>  Thanks,
>  M.
>  
>  On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gerases(a)gmail.com
> <mailto:[e-mail]>> 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
> <mailto:[e-mail]>> 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...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
> > 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...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
> > 
> > I may have forgotten some attributes.
> > Thanks,
> > M.
> > 
> > On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gerases(a)gmail.com
> <mailto:[e-mail]>> 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
> <mailto:[e-mail]>> wrote:
> >>> 
> >>> There is no collectd 389-ds plug-in, but there was a post with an example:
> >>>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> <https://lists.fedoraproject.org/archives/list/[e-mail]...
> >>> 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
> <mailto:[e-mail]>
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> <mailto:[e-mail]>
> > 
> > 
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> <mailto:[e-mail]>
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> <mailto:[e-mail]>
>  
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

[Sergei Gerasenko]

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.