« CheckMK » : différence entre les versions

De Justine's wiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 58 : Ligne 58 :
#test on another host
#test on another host
nc -v <ip address> 6556
nc -v <ip address> 6556
</source>
= Ecriture d'un check SNMP =
https://docs.checkmk.com/master/en/devel_check_plugins.html#snmp
https://docs.checkmk.com/master/en/snmp.html
http://www.pawelko.net/?s=check_mk
Traditionnellement, CMK procède de la façon suivante : la cible (machine supervisée) possède un agent. Le serveur de supervision va interroger cette cible qui renvoie alors ces informations. Les informations sont récupérées grâce à des commandes shell et mise en forme dans un long str qui est renvoyé au serveur. Dans le cas de SNMP, c'est différent.On ne passe par cet agent : le serveur CMK va utiliser des scripts qu'il possède afin de savoir comment interroger la cible via SNMP.
== Les bases de SNMP ==
[[SNMP]]
Il faut configurer le serveur en question pour qu'il accepte les requêtes SNMP. On peut utiliser n'importe quelle version et community.
Ensuite, on créée le serveur dans CMK, on donne les paramètres SNMP, on fait un diag pour voir si ça fonctionne. Simple.
== Création du plugin en lui-même ==
=== Principe ===
La détection de service se fait en deux phases. D'abord, D'abord, une détection SNMP a lieu, afin de déterminer quels plugins sont utilisables sur la machine en question. Pour ça, on scanne quelques OIDs, le plus important étant sysdescr : 1.3.6.1.2.1.1.0. Cet OID donne toujours une description de l'appareil, par exemple "Cisco NX-OS(tm) n5000". Rien qu'en se basant sur cet OID, on peut déterminer si un plugin sera utile; si ça ne suffit pas, on peut ajouter d'autres OID à la détection SNMP.
Ensuite, la découverte des des données de supervision proprement dites a lieu (c'est la détection de services, comme avec un agent quand je vais découvrir les services que celui-ci me renvoie). Elles sont ensuite combinées dans une table et fournies à la fonction de discovery du check dans l'argument "section", qui comme d'habitude détermine les items à surveiller.
Enfin, les checks ont lieu. On sait alors déjà quels plugins sont utilisés puisqu'on a fait nos découvertes. Ici les données sont récupérées par un walk SNMP et à partir de ça l'argument "section" peut être renseigné.
En résumé, on a pas besoin d'un agent, mais:
* d'OIDs individuels et de texte à y chercher pour la détection SNMP (est-ce que mon plugin s'applique ici ?)
* de zones SNMP sur lesquelles faire des walks afin de récupérer les infos.
=== Un mot sur les MIBs ===
Alors, les MIBs, CMK peut fonctionner sans. Il a son propre set de MiBs par défaut, qui décrivent des zones générales dans l'arbre des OID. Mais il se peut qu'elles ne suffisent pas : on peut alors récupérer une MIB sur le site du vendeur, afin que CMK puisse traduire des OIDs en noms lors de ses walks. Les MIBs se mettent alors dans local/share/check_mk/mibs :
<source>
root@supervision:/home/adm-pelletreau# su - upecsys
OMD[upecsys]:~$ cd local/share/check_mk/mibs/
OMD[upecsys]:~/local/share/check_mk/mibs$ ls
OMD[upecsys]:~/local/share/check_mk/mibs$ #Déposer les mibs ici :)
</source>
</source>

Version du 28 janvier 2021 à 14:46

Cette page contient diverses astuces pour l'outil de supervision qu'est Check_MK

Lire / vider les logwatch

Pour cela, il suffit d'accéder à l'interface de logwatch via https://adressedu/site/logwatch.py

Tester un agent

A faire depuis le serveur.

<syntaxhighlight lang='bash'> OMD[mysite]:~$ telnet 10.1.1.2 6556 Trying 10.1.1.2... Connected to 10.1.1.2. Escape character is '^]'. <<<check_mk>>> Version: 1.2.7i1 AgentOS: linux AgentDirectory: /etc/check_mk DataDirectory: /var/lib/check_mk_agent SpoolDirectory: /var/lib/check_mk_agent/spool PluginsDirectory: /usr/lib/check_mk_agent/plugins </syntaxhighlight>

Installer un agent avec systemd (à tester)

<source lang="bash">

  1. How to install Check MK Agent on ubuntu 16.04
  1. Install check_mk_agent:
  2. - sudo apt-get install check-mk-agent (will install older version)
  3. - On your Check_MK dashboard, go to "Monitoring Agents", click the link for "Check_MK Agent for Linux", save the raw text
  4. on your server:

sudo vi /usr/bin/check_mk_agent

  1. paste Check_MK dashboard > Monitoring Agents > Check_MK Agent for Linux

sudo chmod +x /usr/bin/check_mk_agent

  1. Setup Systemd

sudo vi /etc/systemd/system/check_mk.socket

  1. paste Check_MK dashboard > Monitoring Agents > systemd SOCKET definition file

sudo vi /etc/systemd/system/check_mk@.service

  1. paste Check_MK dashboard > Monitoring Agents > systemd SERVICE definition file
  1. start

sudo systemctl daemon-reload sudo systemctl enable check_mk.socket sudo systemctl start check_mk.socket

  1. Add firewall rule from specific OMD Server IP

sudo ufw allow from 15.15.15.0/24 to any port 6556

  1. test on another host

nc -v <ip address> 6556 </source>

Ecriture d'un check SNMP

https://docs.checkmk.com/master/en/devel_check_plugins.html#snmp https://docs.checkmk.com/master/en/snmp.html http://www.pawelko.net/?s=check_mk

Traditionnellement, CMK procède de la façon suivante : la cible (machine supervisée) possède un agent. Le serveur de supervision va interroger cette cible qui renvoie alors ces informations. Les informations sont récupérées grâce à des commandes shell et mise en forme dans un long str qui est renvoyé au serveur. Dans le cas de SNMP, c'est différent.On ne passe par cet agent : le serveur CMK va utiliser des scripts qu'il possède afin de savoir comment interroger la cible via SNMP.

Les bases de SNMP

SNMP

Il faut configurer le serveur en question pour qu'il accepte les requêtes SNMP. On peut utiliser n'importe quelle version et community.

Ensuite, on créée le serveur dans CMK, on donne les paramètres SNMP, on fait un diag pour voir si ça fonctionne. Simple.

Création du plugin en lui-même

Principe

La détection de service se fait en deux phases. D'abord, D'abord, une détection SNMP a lieu, afin de déterminer quels plugins sont utilisables sur la machine en question. Pour ça, on scanne quelques OIDs, le plus important étant sysdescr : 1.3.6.1.2.1.1.0. Cet OID donne toujours une description de l'appareil, par exemple "Cisco NX-OS(tm) n5000". Rien qu'en se basant sur cet OID, on peut déterminer si un plugin sera utile; si ça ne suffit pas, on peut ajouter d'autres OID à la détection SNMP.

Ensuite, la découverte des des données de supervision proprement dites a lieu (c'est la détection de services, comme avec un agent quand je vais découvrir les services que celui-ci me renvoie). Elles sont ensuite combinées dans une table et fournies à la fonction de discovery du check dans l'argument "section", qui comme d'habitude détermine les items à surveiller.

Enfin, les checks ont lieu. On sait alors déjà quels plugins sont utilisés puisqu'on a fait nos découvertes. Ici les données sont récupérées par un walk SNMP et à partir de ça l'argument "section" peut être renseigné.

En résumé, on a pas besoin d'un agent, mais:

  • d'OIDs individuels et de texte à y chercher pour la détection SNMP (est-ce que mon plugin s'applique ici ?)
  • de zones SNMP sur lesquelles faire des walks afin de récupérer les infos.

Un mot sur les MIBs

Alors, les MIBs, CMK peut fonctionner sans. Il a son propre set de MiBs par défaut, qui décrivent des zones générales dans l'arbre des OID. Mais il se peut qu'elles ne suffisent pas : on peut alors récupérer une MIB sur le site du vendeur, afin que CMK puisse traduire des OIDs en noms lors de ses walks. Les MIBs se mettent alors dans local/share/check_mk/mibs :

<source> root@supervision:/home/adm-pelletreau# su - upecsys OMD[upecsys]:~$ cd local/share/check_mk/mibs/ OMD[upecsys]:~/local/share/check_mk/mibs$ ls OMD[upecsys]:~/local/share/check_mk/mibs$ #Déposer les mibs ici :) </source>