OpenLDAP génère des statistiques (cf la documentation très incomplète du projet) : nombre de connexions, nombre de requêtes par type (ajout, suppression, modification, recherche, etc.), etc.. Un module fourni par défaut, back-monitor, permet de les exposer via une requête LDAP standard. Il suffit ensuite d'écrire un script de supervision / métrologie qui parse la sortie d'un ldapsearch.

Il faut activer et configurer ce module de slapd :

• Créer un fichier /tmp/ldap-activer-module-supervision.ldif avec le contenu suivant :

  dn: cn=module{0},cn=config
  changetype: modify
  add: olcModuleLoad
  olcModuleLoad: back_monitor

  
  

• ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/ldap-activer-module-supervision.ldif
  
  

• Créer un fichier /tmp/ldap-configurer-module-supervision.ldif avec le contenu suivant (dans mon cas, l'utilisateur mentionné dans l'ACL existait déjà, sinon il convient de le créer d'abord) :

  dn: olcDatabase={2}Monitor,cn=config
  objectClass: olcDatabaseConfig
  objectClass: olcMonitorConfig
  olcDatabase: {2}Monitor
  olcAccess: {0}to dn.subtree="cn=Monitor" by dn.base="cn=supervision,ou=ldap,dc=masociete,dc=example" read by * none

  
  

• ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/ldap-configurer-module-supervision.ldif

Visualiser les informations disponibles : ldapsearch -xLLL -H ldaps://serveurldap.masociete.example -D cn=supervision,ou=ldap,dc=masociete,dc=example -W -b cn=Monitor -s sub +

Branches intéressantes (ou non) :

• cn=Operations,cn=Monitor : nombre total de requêtes initiées (monitorOpInitiated) / terminées (monitorOpCompleted) par type (recherche, ajout, etc.) depuis le démarrage de slapd ;
  
  
• cn=Connections,cn=Monitor : nombre total et instantané de connexions (y compris celles permettant la réplication), et détails techniques de chaque connexion. On peut ainsi surveiller si l'on n'arrive pas trop près de la limite du nombre de fichiers ouverts, qui comptabilise aussi les sockets, donc les connexions ;
  
  
• cn=Uptime,cn=Time,cn=Monitor : le nom parle de lui même ;
  
  
• cn=Statistics,cn=Monitor : nombre de paquets, d'octets et d'entrées envoyés par le serveur ;
  
  
• Je ne trouve pas pertinente la branche cn=Waiters,cn=Monitor. C'est toujours utile de surveiller les clients en attente de lecture et d'écriture, car ça peut révéler des problèmes de tenue de charge. L'ennui, c'est que les connexions persistantes sont considérées comme étant en attente de lecture, donc l'info est redondante avec la cn=Current,cn=Connections,cn=Monitor et un nombre élevé n'indique pas forcément un problème, mais l'existence d'un nombre elevé de connexions persistantes… qui peuvent être légitime si l'on a des applications qui font beaucoup de requêtes.

Quelques notes :

• La différence entre le nombre de bind (authentifications, même anonymes) et d'unbind (déconnexions) s'explique par les connexions persistantes et les déconnexions sauvages (un client ne signale pas la fin de l'échange, c'est un timeout qui le clôture brutalement) ;
  
  
• Si les compteurs de requêtes d'écriture (add, modify, modrdn, etc.) sont supérieurs à 0 sur un « consumer » (a priori bloqué en écriture), cela ne veut pas dire qu'une écriture a eu lieu, mais qu'elle a été demandée par un logiciel client, et que slapd a comptabilisé la requête… avant de rediriger le demandeur vers le serveur LDAP « producer » (principe du referral).