Voici une documentation sur l’installation de Icinga et sa configuration sous docker

  • source : http://xmodulo.com/monitor-server-memory-usage-nagios-remote-plugin-executor.html
  • Etat : En construction

A explioquer comme ça : https://morgan-durand.com/poc-installation-de-nagios-superviser-application-http-docker/

Trop lourd pour être implémenté facielment : Dashing

https://github.com/bodsch/docker-dashing-icinga2

Plan

Methode avec icinga director

https://www.howtoforge.com/how-to-add-hosts-to-icinga2-using-the-icinga-director/

Tutoriel installation docker

Télécharger le docker ici :

https://github.com/blop03/docker_infra_perso/tree/master/Icinga2

Docker-compose up -d

Tous les paramètres nécessaires sont dans le docker-compose

Etape 1 : Lancement du docker-compose up -d

Configuration

Plus d’info ici : https://memodugeek.info/modifier-un-service-sur-icinga2/

1 La première fois

ssh-keygen -t rsa

1  Ajout d’un hôte

Créer un utilisateur avec la commande ci-dessous

Shell

Installer les pquets monitoring-plugins

Shell

Copie de check_docker sur le serveur

Liste de plugin ici : https://github.com/HariSekhon/Nagios-Plugins

1.2      Ajouter un hote

Shell

Le module docker est a rajouter :

https://github.com/timdaman/check_docker/tree/master/check_docker

Les plugins

Source : https://raymii.org/s/articles/Essential_Monitoring_checks.html

Ceux du monitoring plugins

Les bases :

  • check_diskstat.sh -> Permet d’obtenir les i/o de la VM
  • check_docker -> Permet de superviser les dockers ( CPU, status, containeur créé)
  • check_snmp_printer -> Permet de checker les imprimantes

Fichier total des commandes ci-dessous

Shell

Plugin de bases sur les hôtes fixes (Hyperviseur, fixe )

1 – Check smart HDD

Plugin utilisé : check_ide_smart

Shell

2 – Température et ventilateur

Plugin utilisé : utilisation de lmsensor

https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details

Plain Text

Les pannes de ventilateur

Plain Text

3 – RAID logiciel

A faire

4 – Check pile CMOS

Dans le cas d’un ILO ou IDRAC

Plugin utilisé : open_manager plugin

System Board CMOS Battery: ENABLED/OK [PRESENCEDETECTED]

5 – Consommation électrique

Dans le cas d’un ILO ou IDRAC

OK - Power Consumption in under the warning level psu status
PU 1: ENABLED/OK, RedundancyStatus: FULL, SystemBoard Pwr Consumption: 250 W

6 – Redondance et état de l’alimentation

Dans le cas d’un ILO ou IDRAC

Plugin de bases sur les VM

Classé pour moi par ordre d’importance

1 – Ping

Plugin utilisé : Monitoring Plugins -> check_ping

Vérification ping depuis votre serveur de surveillance vers l’instance que vous surveillez. Bon pour mesurer la latence et vérifier si l’hôte est opérationnel ou non

PING OK - Packet loss = 0%, RTA = 3.41 ms

Problème de latence ou de perte de paquets :

PING CRITICAL - Packet loss = 100%
PING CRITICAL - Packet loss = 80%, RTA = 5.80 ms
PING CRITICAL - Packet loss = 0%, RTA = 211.72 ms

Ping peut également être utilisé à l’intérieur d’un cluster. La plupart de mes hôtes de cluster haute disponibilité ont un contrôle ping sur l’équilibreur de charge et le routeur de ce cluster, pour mesurer la latence interne du réseau.

2 – Load

Plugin utilisé : Monitoring Plugins -> check_load

La moyenne de charge Linux ne doit pas être supérieure au nombre de cœurs CPU de votre système. Load n’est pas la même chose que l’utilisation du CPU, cet article explique en détail ce que signifie la moyenne de charge Linux.

Voir this article.

Si tout est ok :

OK - load average: 1.51, 1.47, 1.47

Trop sur un système à 2 coeurs (15 min avg) :

CRITICAL - load average: 10.19, 5.10, 3.49

3 – RAM & swap

Shell

You can check whether the script generates output properly by manually running the following command on localhost. When used with NRPE, this command is supposed to check free memory, warn when free memory is less than 20%, and generate critical alarm when free memory is less than 10%.

# ./check_mem -f -w 20 -c 10
OK - 34.0% (2735744 kB) free.|TOTAL=8035340KB;;;; USED=5299596KB;6428272;7231806;; FREE=2735744KB;;;; CACHES=2703504KB;;;;

Exemple sur un hyperviseur qui n’est pas utilisé :

Memory: OK Total: 773557 MB - Used: 11197 MB - 1% used

Lors d’un test de charge sur un hyperviseur :

Memory: CRITICAL Total: 386939 MB - Used: 383085 MB - 99% used!

En général, vous ne voulez pas que votre swap soit utilisé, en particulier sur du matériel avec beaucoup de RAM. Sur les machines virtuelles avec une quantité limitée de RAM, l’échange peut être utile, mais assurez-vous de régler vm.swappiness sysctl à un niveau bas.

4 – Disk space & inodes

Voici un exemple de check du disque dur :

DISK OK - free space: / 23150 MB (60% inode=93%): /home/web/domains 30471 MB (74% inode=99%): /glusterfs/xvda3 30472 MB (74% inode=99%):

Warning:

DISK WARNING - free space: / 35606 MB (93% inode=94%): /mnt/export 49504 MB (10% inode=97%):

Make sure to tweak the alert value to your specific setup. By default it’s 10%, but on a 4 TB disk, that is 400 GB and that can be way to much to already alert. I generally set it to 10 GB.

Sert a la vérification d’Inodes :

L’espace disque utilisé peut avoir encore beaucoup d’espace, mais les inodes (df -i) peuvent être tous utilisés

5 – Time

Correct time on your server is important for correct funcionality and logging.

6 – Processus zombie

Les processus zombies sont des choses que vous ne voulez pas sur votre système.

Les processus zombies sont souvent causés par des problèmes d’entrées-sorties de disque ou des défaillances, de sorte que vos autres contrôles se déclenchent également.

PROCS OK: 0 processes with STATE = Z

7 – Uptime

Plugin utilisé : check_uptime

Les mises à jour régulières, les noyaux plus récents, les vérifications de disque (fsck) et le nettoyage général de cruft sont des raisons utilisées pour redémarrer les machines de temps en temps.

System Uptime - up 458 days, 5 Hours, 43 Minutes

8 – Utilisateurs connectés

When you use a configuration management system, you often never have to login to a server by yourself to install or update stuff. Only when troubleshooting an issue, but for that you should have your central log cluster. I’m not a big fan of this check, but there are situations where it is usefull. A jumphost, VPN server, remote desktop machine, etc. Example check output:

USERS OK - 0 users currently logged in

The default limit is set to 6, but I have it set to 2. No alerting.

9 – Application : HTTP/HTTPS check

Dans le cas d’une application Web, vérification du code d’état HTTP(s)

Exemple de sorti du plugin :

Plain Text

10 – IO & IOPS

Io Wait and IOPS

check_diskstat, check_iostat and check_iowait are just like the connection sockets checks usefull to graph and get insight in the performance of your environment. Good to kick your VM provider if their platform has issues with IO performance, especially when you’re able to show what stats are normal.

check_diskstat:

OK - summary: 0 io/s, read 0 sectors (0kB/s), write 816 sectors (1kB/s), queue size 0 in 300 seconds

check_iostat:

OK - I/O stats: Transfers/Sec=649.9 Read Requests/Sec=5.7 Write Requests/Sec=644.2 KBytes Read/Sec=264.4 KBytes_Written/Sec=8341.75

check_iowait

OK - Wait Time Stats: Avg I/O Wait Time (ms)=10.05 Avg Read Wait Time (ms)=11.27 Avg Write Wait Time (ms)=0.50 Avg Service Wait Time (ms)=0.54 Avg CPU Utilization=1.16

11 – Check de cron

Quel que soit le cronjob, il peut être important de surveiller s’il a fonctionné correctement

check_file_age + check_period

Il est possible de configurer le check_file_age pour alerter si ce fichier journal est plus vieux qu’une heure avec un check_period juste après la fin du cronjob. De cette façon, le contrôle s’exécute après la fin de cronjob et n’alerte que si le fichier journal n’a pas été mis à jour.

12 – API test

./check_http -H api.somedomain.com -u /api/data -k blablah

https://www.zylk.net/en/web-2-0/blog/-/blogs/monitoring-ambari-with-nagios-

https://support.nagios.com/forum/viewtopic.php?f=7&t=40933

Plain Text

A tchecker

13 – Ports (Facultatif)

Si un port se bloque soudainement, vous voulez aller voir pourquoi (intrus ou erreur humaine) ?

Ou peut-être que votre développeur a mis en place une virtualbox avec sa VM en mode Bridged.

alerter si un port fait beaucoup plus de trafic qu’il n’en fait régulièrement

14 – Log parser

Plugin utilisé : check_log3.pl -> Lien

surveiller fichier de log et être alerté si la ligne que vous choisissez apparait dedans.

Par exemple : vérifier les échecs d’authentification dans une application interne

Shell

15 – Applicatif : POSTGRESQL

check_postgres

CPU usage

The percent of CPU usage and the 7 other states are usefull indicators of arising problems. If your machine is using 100% CPU all the time, something is wrong. Incidental bursts are often not a problem, since the capacity is meant to be used. The performance data of this check is usefull, for example in virtual environments to catch CPU steal (a hypervisor that is overloaded). This article explains the CPU statistics in detail.

Perfdata captured:

Label   Value
id      61.4%   # CPU idle time
usage   38%     # usage %
us      27.6%   # user space
sy      7.1%    # kernel
si      3.4%    # software interrupts
wa      0.5%    # idle while waiting on I/O
ni      0%      # niced processes
hi      0%      # hardware interrupts
st      0%      # CPU steal, how long the virtual CPU has spent waiting for the hypervisor to service another virtual CPU running on a different virtual machine.

I only alert on high wait or CPU steal on virtual machines, since that is an indication of something wrong with the hypervisor or storage. No escalation, since other checks will escalate if needed.

  • Conntrack

On hypervisors, loadbalancers and routers this is a usefull check to have. The iptables firewall keeps track of connections in the conntrack table. If it’s full, new connections experience issues.

Example output:

OK conntrack table is 0% full and timeout is 14400

Example output when issues arise:

WARN conntrack table is 14% full and timeout is 14400
INFO: tcp connections for src 192.81.222.236 reached CRIT 271464 > 262144
INFO: tcp connections for dst 10.200.10.9 reached WARN 137531 > 65536
INFO: tcp connections for dst 172.32.173.163 reached WARN 137442 > 65536

More info on conntrack can be found here. This is the check I use.

On dedicated firewall appliances this kind of check can also be usefull (Fortigate, Sophos, pfSense etc).

NSCLIENT

http://blog.nicolargo.com/2007/10/surveiller-vos-serveurs-windows-avec-nagios.html

Puis ajouter les services offerts par NSClient (dans le fichier services.cfg):

# Affiche la version du NSClient
define service {
use generic-service
host_name billgates
service_description VERSION
check_command check_nt!CLIENTVERSION
}

# Temps écoulé depuis le dernier reboot (uptime)
define service {
use generic-service
host_name billgates
service_description UPTIME
check_command check_nt!UPTIME
}

# Charge CPU
# WARNING si charge > 80% pendant plus de 5 minutes
# CRITICAL si charge > 90% pendant plus de 5 minutes
define service {
use generic-service
host_name billgates
service_description CPU
check_command check_nt!CPULOAD!-l 5,80,90
}

# Etat de la mémoire vive libre
# WARNING si mémoire > 80%
# CRITICAL si mémoire > 90%
define service {
use generic-service
host_name billgates
service_description MEM
check_command check_nt!MEMUSE!-w 80 -c 90
}

# Etat de la mémoire disque libre (sur disque c:)
# WARNING si mémoire > 80%
# CRITICAL si mémoire > 90%
define service {
use generic-service
host_name billgates
service_description DISK
check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90
}

Il est également possible de surveiller l’état d’un service (SERVICESTATE) ou d’un processus (PROCSTATE).