ltb-project / nagios-plugins Goto Github PK

Starting at line 580:

    if ( $deltacsn < $warning ) {
        print
"OK - directories are not in sync - $deltacsn seconds late (W:$warning - C:$critical)$perfparse";
        exit $ERRORS{'OK'};
    }
    elsif ( $deltacsn > $warning and $deltacsn < $critical ) {
        print
"WARNING - directories are not in sync - $deltacsn seconds late (W:$warning - C:$critical)$perfparse";
        exit $ERRORS{'WARNING'};
    }
    else {
        print
"CRITICAL - directories are not in sync - $deltacsn seconds late (W:$warning - C:$critical)$perfparse";
        exit $ERRORS{'CRITICAL'};
    }

...if $warning is equal to $deltacsn, then the warning is incorrectly reported as CRITICAL. Line 585:

 elsif ( $deltacsn > $warning and $deltacsn < $critical ) {

...should be:

 elsif ( $deltacsn >= $warning and $deltacsn < $critical ) {

Very useful overall. Thank you.

Bob

Since OpenLDAP 2.4.49, we can read entries count in cn=monitor : http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=9154;selectid=9154

We should add this option to check monitor script.

Found by Geert Hendrickx:

I noticed an issue with the way you calculate the time difference:

my $deltacsn = abs( $mastercsn_elts[0] - $slavecsn_elts[0] );

and then print:

"WARNING - directories are not in sync with $master_host - $deltacsn seconds late (W:$warning - C:$critical)$perfparse";

However the delta between two ContextCSN timestamps in decimal notation cannot simply be interpreted as seconds...

For example, take 2016/09/21 13:02:23 and 2016/09/21 12:07:24.
You calculate: 20160921130223 - 20160921120724 and print: "9499 seconds late", while it is fact only 54:59 or 3299 seconds.
You need to substract seconds/minutes/hours(days?) individually and then glue them back together.

It's not just a display problem. Eg. an alert threshold of 300 seconds (5 minutes) is reached already after 3:00 (3 minutes).

Hello

Your latest commit for check_ldap_syncrepl_status isn't tagged, I fixed the path issue on my side before realizing.

Best regards,

An example connection string, notice the (connection lost) at the end. If the module performed an UNBIND operation, we would not receive this error.

Nov 3 12:07:37 y slapd[11164]: conn=1037 fd=25 ACCEPT from IP=x.x.x.x:35998 (IP=z.z.z.z:636)
Nov 3 12:07:37 y slapd[11164]: conn=1037 fd=25 TLS established tls_ssf=256 ssf=256
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=0 BIND dn="" method=128
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=0 RESULT tag=97 err=0 text=
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=1 SRCH base="" scope=0 deref=2 filter="(objectClass=)"
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=1 SRCH attr=namingcontexts
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=2 SRCH base="dc=x,dc=gov" scope=0 deref=2 filter="(objectClass=)"
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=2 SRCH attr=contextCSN
Nov 3 12:07:37 y slapd[11164]: conn=1037 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

++++. UNBIND should happen here ++++++

Nov 3 12:07:37 y slapd[11164]: conn=1037 fd=25 closed (connection lost)

In some plugins (like check_ldap_monitor) we only search utils.pm in /usr/local/nagios/libexec

We should always use:

use lib qw(/usr/local/nagios/libexec /usr/lib/nagios/plugins /usr/lib64/nagios/plugins);

hi,
How to define the -w -c options in the ldap_monitor script. what is the best value to choose please.
The same thing about a number of threads.

thx

Hello,

i use check_lmdb_usage and forgot to install mdb_stat, i got this error

check_lmdb_usage.pl -S /usr/bin/mdb_stat -H /var/lib/ldap/ -w 80 -c 90
Can't exec "/usr/bin/mdb_stat": No such file or directory at ./check_lmdb_usage.pl line 195.
Illegal division by zero at ./check_lmdb_usage.pl line 217.

Cheers

In check_ldap_query and check_ldap_monitor.pl, we can choose greater/lesser mode for the warning and critical threshold, but it seems the behavior is inverted:

clement@ader-worteks:~/dev/nagios-plugins$ perl check_ldap_query.pl -H localhost -b dc=example,dc=com -m lesser -w 10 -c 50
CRITICAL - 500 entries returned  
clement@ader-worteks:~/dev/nagios-plugins$ perl check_ldap_monitor.pl -H localhost -T currentconnections -m lesser -w 5 -c 10
OK - 1 current connections returned 
clement@ader-worteks:~/dev/nagios-plugins$ perl check_ldap_monitor.pl -H localhost -T currentconnections -m greater -w 50 -c 10
CRITICAL - 1 current connections returned 

Hello,

when running the check_ldap_monitor on stretch with the following parameters i got perl errors.

check_ldap_monitor.pl -H ldap://localhost -D "cn=monitoring,cn=monitor" -b cn=monitor -P tester -T currentconnections -m greater -w 10 -c 15 -f -vvv
VERBOSE 3 ===> Enter &get_ldapconn
VERBOSE 2 ===> Connected to ldap://localhost
VERBOSE 2 ===> Bind with cn=monitoring,cn=monitor
VERBOSE 3 ===> Leave &get_ldapconn
VERBOSE 3 ===> Enter &get_value
Use of uninitialized value $result in concatenation (.) or string at ./check_ldap_monitor.pl line 395, <DATA> line 751.
VERBOSE 2 ===> Found value 
VERBOSE 3 ===> Leave &get_value
Use of uninitialized value $value in concatenation (.) or string at ./check_ldap_monitor.pl line 592, <DATA> line 751.
Use of uninitialized value $value in numeric lt (<) at ./check_ldap_monitor.pl line 597, <DATA> line 751.
Use of uninitialized value $value in concatenation (.) or string at ./check_ldap_monitor.pl line 598, <DATA> line 751.
OK -  current connections returned |'currentconnections'=;10;15

Cheers

check_lmdb_usage.pl has the function to monitor the numbers (free pages/maximum number of pages) and (used pages/maximum number of pages). However it needs access to the LMDB files.

Over cn=monitor provides the same numbers, that are reported by mdb_stat. But check_ldap_monitor.pl cannot do the same warning/calculations as check_lmdb_usage.pl

The feature of relative lmdb pages is very useful and should be released

check_lmdb_usage.pl and check_ldap_monitor.pl read

  Max pages: 768
  Number of pages used: 148
  Free pages: 31

And calculate:

• per cent of free pages = 31 * 100 / 768 = 4.03%
• per cent of used pages = 148 * 100 / 768 = 19.27%

Contrary to intuition, the sum of the per cent is not 100.

I kindly ask to extend the documentation and include explanation, why the sum is not 100%.

With this explanation it will be easier to understand what OpenLDAP monitoring does and what one wants really to monitor.

Our check_lmdb relies on number of pages used, but it seems to most accurate is to rely on free pages.