Meilleures pratiques du serveur Nagios?

Je gère un serveur Nagios de taille moyenne. Il surveille environ 40 serveurs avec 180 services actuellement et ne fait que croître de jour en jour.

J'ai migré d'une ancienne configuration de Nagios qui était configurée de manière très ésotérique, me forçant à tout reconfigurer à partir de zéro.

Maintenant que le serveur fonctionne et fonctionne pour la plupart de nos besoins , je cherche à le rendre un peu plus évolutif; actuellement, chaque hôte possède son propre fichier /etc/nagios/hosts/et chaque hôte a tous ses services dans le même fichier. Ce n'est évidemment pas optimal, mais ni obscurcir toute ma configuration dans des centaines de fichiers différents.

Donc, ma question est la suivante: pour tous les administrateurs Nagios expérimentés, quelle est la meilleure façon d'utiliser les groupes d'hôtes / groupes de services sans trop compliquer la configuration?

Groupes d'hôtes et modèles.

Les modèles vous permettent de définir des classes pour vos hôtes et services, par exemple "service normal", "service critique", "hôte à faible priorité". Ils servent également de moyen utile pour diviser les responsabilités si vous avez plusieurs équipes avec des responsabilités différentes, vous pouvez donc avoir un modèle "hôte Linux" et un modèle "hôte Windows", chacun définissant les informations de contact appropriées.

Vous pouvez utiliser plusieurs modèles sur une seule ressource, afin de pouvoir composer des modèles orthogonaux appropriés. Par exemple, vous pouvez avoir

host foo {
    use windows-host,normal-priority-host
    ...
}

ce qui entraînerait les informations de contact (et les escalades) pour l'équipe Windows et les taux d'interrogation et les seuils pour un hôte "normal".

Les groupes d'hôtes vous permettent de regrouper toutes les vérifications d'un sous-ensemble de vos hôtes. Ayez des choses comme "baseline-linux-hosts" qui vérifient la charge, l'espace disque, la sshcapacité et tout ce qui devrait être sur chaque hôte que vous surveillez. Ajoutez des groupes comme "https-servers" avec des vérifications de la connectivité HTTP, de la connectivité HTTPS et des dates d'expiration des certificats SSL; "serveurs de fichiers" avec des vérifications d'accessibilité NFS et SMB et des vérifications de disque peut-être plus agressives; ou "machines virtuelles" avec vérification du bon fonctionnement des outils d'accessibilité VM.

Mettez chaque hôte et groupe d'hôtes dans son propre fichier. Ce fichier doit contenir la définition d'hôte ou de groupe d'hôtes en premier, suivie des définitions des services qui lui sont applicables.

Si vous utilisez la cfg_dirdirective dans votre nagios.cfgfichier, Nagios effectuera une recherche récursive dans ce répertoire. Profitez-en. Pour un paramètre de cfg_dir=/etc/nagios/conf.d, vous pouvez avoir une arborescence de répertoires comme celle-ci:

• /etc/nagios/conf.d/
  • commands.d /
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

J'ai tendance à créer un répertoire pour chaque type de ressource (commandes, groupes de contacts, contacts, escalades, groupes d'hôtes, hôtes, groupes de services, périodes de temps), à l'exception des services, qui sont regroupés avec les hôtes ou les groupes d'hôtes qui les utilisent.

La structure précise peut varier selon vos besoins organisationnels. Lors d'un travail passé, j'ai utilisé des sous-répertoires sous hosts.dpour chaque site différent. Dans mon travail actuel, la plupart des définitions d'hôte Nagios sont gérées par Puppet, il y a donc un répertoire pour les hôtes gérés par Puppet et un autre pour les hôtes gérés manuellement.

Notez que ce qui précède décompose également les commandes en plusieurs fichiers, généralement par protocole. Ainsi, le nrpe.cfgfichier aurait les commandes check_nrpeet check_nrpe_1arg, alors que http.cfgpourrait avoir check_http, check_http_port, check_https, check_https_portet check_https_cert. ¹

Je n'ai généralement pas un grand nombre de modèles, donc je n'ai généralement qu'un hosts.d/templates.cfgfichier et un services.d/templates.cfgfichier. Si vous les utilisez plus intensivement, ils peuvent aller dans des fichiers correctement nommés dans un templates.drépertoire.

¹ J'aime aussi avoir une check_http_blindlycommande, qui est essentiellement check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; il renvoie OK même s'il obtient un code de réponse 403.

Faites un usage intensif des services et des groupes d'hôtes et des modèles. Créez des groupes d'hôtes et attribuez des services aux groupes d'hôtes. Utilisez des groupes de services pour les dépendances, les escalades et le regroupement logique dans l'interface utilisateur Web.

Si vous avez des groupes pour tout, l'ajout d'un nouvel hôte ne comporte que 3 ou 4 lignes: nom, adresse, modèle (s) et (éventuellement) groupes d'hôtes. Tout peut être modelé.

Assurez-vous de lire les documents sur l' héritage , ainsi que la page des astuces pour gagner du temps . L'héritage multiple peut devenir délicat, mais lorsqu'il est utilisé correctement, il représente un énorme gain de temps.

J'étais habitué à configurer mes serveurs nagios (avant de passer à Icinga) de cette façon, et les performances ne manquent pas jusqu'à ce que vous atteigniez plus de 500 services au moins avec un serveur 512 Mo de mémoire / 1 CPU. les groupes d'hôtes et les groupes de services peuvent être traités complètement séparément, et je recommanderais cette approche car elle permet d'avoir un fichier par serveur (services pour ce serveur définis dans ce fichier) puis, sur fichier par groupe d'hôtes / groupes de services. Ce n'est que plus compréhensible / clair.

Si vous rencontrez des problèmes d'évolutivité, vous voudrez peut-être jeter un œil à nagios-nrpe-server, qui effectue des vérifications côté client et tout ce que fait votre serveur nagios ne demande que des résultats; qui épargnent la ressource du chèque. (Nagios lance check_nrpe, le client est demandé, effectue des vérifications localement et répond en retour à nagios). Gardant à l'esprit que toutes les vérifications ne peuvent pas être traitées de cette façon (SNMP par exemple).

Pour finir, et même si cela peut sembler hors de portée concernant votre question, je suggère de passer à Icinga, qui est beaucoup plus évolutif, détenu par une communauté plus forte qui se soucie vraiment des nouvelles implémentations de fonctionnalités et du support utilisateur. La configuration est la même (mêmes fichiers de configuration, même syntaxe).

J'utilise ce schéma:

• hôtes,
• groupes d'hôtes,
• services à distance,
• services locaux.

Chaque entité a son propre fichier. Outre les modèles, vous pouvez toujours rendre votre nettoyeur de configuration plus lisible. Par exemple, vous pouvez avoir une moyenne de charge, de l'espace disque et de la mémoire sur chaque hôte. Il est donc assez facile et pratique de créer un modèle générique et de l'utiliser.

Vous ne pouvez pas compliquer la configuration avec la création de groupes. Comme le dit asciiphil, vous créez un fichier ou vous pouvez définir les mêmes groupes dans certains des fichiers existants comme (hosts.cfg ou quoi que ce soit), et vous créez ce fichier ou vous dites à nagios que ce fichier est actif (c'est si vous créez un nouveau champ, sinon il est déjà actif), et c'est dans le fichier nagios.cfg où vous mettez le chemin du fichier nouvellement créé. "cfg_file = / usr / local / nagios / etc / objects / NEW_FILE.cfg"

L'autre chose consiste simplement à créer des groupes en fonction de votre infrastructure. Si, par exemple, j'ai Linux et Windows Server, je ferai deux groupes différents, un pour Linux et un autre pour Windows. C'est la même chose avec les services. Selon la façon dont vous souhaitez configurer et voir lorsque vous surveillez sur le moniteur, comment souhaitez-vous les voir en tant que groupes.

Et pour le fichier ou la partie comment faire un groupe c'est simple.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

Et sur la configuration de l'hôte / ou si vous utilisez un modèle ou si vous avez déjà défini un modèle ou un service hôte et en utilisant use, vous pouvez dire automatiquement à tous les hôtes / fenêtres ou hôtes linux d'être membres d'un groupe d'hôtes défini que vous avez créé.