Project-Id-Version: Trac 0.12
Report-Msgid-Bugs-To: trac-dev@googlegroups.com
POT-Creation-Date: 2013-01-27 11:21+0900
PO-Revision-Date: 2010-07-19 23:05+0200
Last-Translator: Jeroen Ruigrok van der Werven <asmodai@in-nomine.org>
Language-Team: en_US <trac-dev@googlegroups.com>
Plural-Forms: nplurals=2; plural=(n != 1)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Generated-By: Babel 0.9.6

Configuration/Icinga2 – Trac ResEl
wiki:Configuration/Icinga2

Icinga 2

Installation

Pour avoir une version à jour d'Icinga2 et Icingaweb2, ajouter _/etc/apt/sources.list.d/icinga.list_ :

deb http://packages.icinga.org/debian icinga-jessie main
deb-src http://packages.icinga.org/debian icinga-jessie main 

Puis :

apt-get install icinga2 icinga2-ido-mysql
apt-get install monitoring-plugins

Une fois Icinga2 installé et configuré, terminer avec :

apt-get install icingaweb2

Configuration

Accès

Service icinga2 sur *Héra*. Interface web à l'adresse https://icinga.resel.fr, URL portée par Marité.

Architecture

Icinga2 permet très facilement de profiter de fonctionnalités de Haute Disponibilité, de monitoring distribué et de synchronisation des configurations sur plusieurs serveurs, et c'est ce genre d'architecture qui a été mis en place au ResEl pour : décharger Hera, avoir encore du monitoring en cas de perte du I11, ou du lien Brest-Rennes par exemple.

En prenant cela en compte, trois machines font actuellement tourner Icinga : *Cadillac* à Rennes, *Hera* et *Eris* à Brest. La configuration est automatiquement synchronisée entre ces trois serveurs; Hera et Eris font en plus du load-balancing.

  • Toute la configuration se fait sur Hera, dans le répertoire /etc/icinga2/zones.d/.* Il y a plusieurs répertoires importants dedans :
  • global-templates : le contenu de ce dossier sera synchronisé sur tous les membres du cluster. Il contient la définition des commandes et des services propres à toutes les machines (ssh, http, mailq par exemple), les users, les définitions et scripts des notifications.
  • brest : les fichiers de configuration des serveurs, switchs, et bornes de la zone de Brest.
  • rennes : les mêmes éléments, pour la zone de Rennes.

Ici, la *zone* correspond à des éléments définis dans le fichier *zones.conf* (et ici, ça correspond à la répartition géographique des machines). La zone Brest a été définie comme _parent_ de la zone Rennes, ainsi Rennes accepte les fichiers de configuration venant des serveurs de Brest.

Ajouter un nouveau serveur

Selon la zone du serveur, rendez-vous dans le répertoire Brest ou Rennes, et créez le fichier _serveur_.conf, sur le modèle des autres fichiers présents. Décortiquons le fichier de configuration type. Il se compose de la définition d'un objet, et de plusieurs variables en son sein :

object Host "idaho" {
        import "generic-host"
        display_name = "Idaho - Hyperviseur Xen"
        address = "idaho.adm.maisel.enst-bretagne.fr"

        groups += ["munin-servers", "ssh-servers"]
        vars.os = "Linux"
}

Ici, on définit un *objet* qui porte le nom du serveur, en l’occurrence Idaho. La 1ère importe un contenu générique (un autre objet Host, avec d'autres variables), et après on définit quelques variables :

  • _address_ : pas besoin d'expliquer je pense :p. On peut préférer l'adresse IP au nom DNS.
  • _displayname_ : Son petit nom et une très courte description qui apparaîtra sur l'interface web, dans les notifications..
  • _checkcommand_ : Définit la commande à exécuter pour savoir si la machine est UP ou DOWN.
  • _groups_ : on définit les groupes auquel la machine appartient. Cela dépend des services lancés dessus; pour d'autres groupes voir le fichier global-templates/groups.conf. En principe, toutes les machines font tourner ssh et munin-node et appartiennent donc au moins à ces deux groupes.
  • _vars.os_ : une variables custom (précédée par _vars._) qui contient l'OS. Cela permet entre autres de distinguer facilement une machine qui utilise apt, ou pkg par exemple.

* Dans la plupart des cas, la configuration peut s'arrêter ici : le monitoring de base peut commencer. En cas d'installation d'Icinga, si de nouveaux services tournent ou pour mieux comprendre le fonctionnement du logiciel, la suite est là.*

A partir de là, comment monitorer la machine et ses services ? Il faut créer ce qu'on appelle un (attention) service.

Ajouter un service

Les services sont communs à toutes les zones, avec quelques exceptions, et se trouvent donc dans les fichiers de configuration dans le répertoire global-templates. Là encore, les services de bases sont assez simples : on définit un objet de type Service avec un nom, et on lui ajoute quelques variables. Spécificité des services, on précise sur quels hôtes ils sont à vérifier, dans une syntaxe proche des langages de programmation classiques. Exemple du service le plus simple, j'ai nommé le ping :

apply Service "ping4" {
  import "generic-service"

  check_command = "ping4"

  assign where host.address
}

On retrouve la même structure que plus haut, et une nouvelle variable, _checkcommand_. Dans Icinga et les autres forks de Nagios, la commande représente un objet qui fait directement le lien entre un programme, un plugin, une commande Linux.. à exécuter pour connaître l'état d'un hôte et ses services. Ici, la commande utilisée, est le ping (version IPv4). Comment savoir sur quel hôte appliquer ce service ? On pourrait rentrer à la main les noms d'hôte, mais au lieu de cela on peut _appliquer_ le service à des hôtes qui respectent certaines expressions :

  • assign where host.address : applique le service à tous les hôtes dont l'adresse est donnée.

On peut les combiner, la doc donne d'autres exemples :

  assign where match("*mysql*", host.name) && match("db-*", host.vars.prod_mysql_db)
  ignore where host.vars.test_server == true
  ignore where match("*internal", host.name)

Les commandes

todo : mettre un ping4 minimal

template CheckCommand "ping-common" {
        import "plugin-check-command"

        command = [ PluginDir + "/check_ping" ]

        arguments = {
                "-H" = "$ping_address$"
                "-w" = "$ping_wrta$,$ping_wpl$%"
                "-c" = "$ping_crta$,$ping_cpl$%"
                "-p" = "$ping_packets$"
                "-t" = "$ping_timeout$"
        }

        vars.ping_wrta = 100
        vars.ping_wpl = 5
        vars.ping_crta = 200
        vars.ping_cpl = 15
}

Comment tester une nouvelle configuration et la valider

  • Pour tester la configuration actuelle (dans /etc/icinga2/icinga2.conf par défaut ):
    icinga2 daemon --validate
    
  • Pour valider la configuration et l'appliquer à icinga2:
    systemctl reload icinga2.service
    
  • Et pour vérifier le status du service et démon après reload (pour les vieux paranos) :
    systemctl status icinga2.service
    
  • TRÈS IMPORTANT : commit et push ses modifications :-)
    • On vérifie la liste des fichiers modifiés depuis le dernier commit (au cas où quelqu'un aurait oublié de commit !) :
      git status
      
    • Si seuls les fichiers qu'on a modifié soi-même sont différents, vérifier pour chaque fichier que seules nos modifications sont là :
      git diff ./fichier1
      
    • Si tout va bien on peut commit le tout avec un message:
      git commit -a -m "Ajout de trucmuche, maj de machin pour le service truc"
      
    • Puis on push:
      git push
      

Plugins

Les plugins utilisés se trouvent dans _/usr/local/nagios/libexec/_. Certains plugins-contrib sont utilisés :

Pour compiler, mettre à jour, etc.. les sources se trouvent dans /root/icinga-plugins-contrib/

Monitoring distribué : Faire communiquer deux zones

TODO :

  • Génération des certificats
  • API

Utiliser l'API pour récupérer des informations

Prévoir une maintenance

Icingaweb2

F.A.Q.

Q : Je me connecte sur icinga.r.f mais il n'y a rien... R : Il faut être ajouté dans le groupe _administrateurs_ , par défaut les utilisateurs n'ont aucun droit. La v2.0 finale arrive début octobre et permet de modifier les permissions par défaut.

Q : On peut pas copier la conf de Nagios ? R : Non, Icinga1 était totalement compatible mais il y a quelques modifications à faire avec Icinga2.

Last modified 22 months ago Last modified on Nov 7, 2016, 3:09:49 PM