web-dev-qa-db-fra.com

Comment utiliser Nagios pour surveiller un fichier journal

Nous utilisons Nagios pour surveiller notre réseau avec beaucoup de succès. Cependant, nous avons un syslog pour les erreurs d’application critiques et lors de la configuration de check_log, il ne semble pas fonctionner aussi bien que contrôler un périphérique.

Les problèmes sont:

  • Il ne montre que la dernière entrée
  • Il ne semble pas y avoir de moyen de reconnaître l’erreur critique et de remettre le moniteur dans un bon état.

Est-ce que nagios est le mauvais outil ou ne configurons-nous pas correctement le service?

Voici mes entrées

# log file
define command{
        command_name    check_log
        command_line    $USER1$/check_log -F /var/log/applications/appcrit.log -O /tmp/appcrit.log -q ?
}


# Define the log monitering service
define service{
        name                            logfile-check           ;
        use                             generic-service         ;
        check_period                    24x7                    ;
        max_check_attempts              1                       ;
        normal_check_interval           5                       ;
        retry_check_interval            1                       ;
        contact_groups                  admins                  ;
        notification_options            w,u,c,r                 ;
        notification_period             24x7                    ;
        register                        0                       ;
        }

define service{
        use                             logfile-check
        Host_name                       localhost
        service_description             CritLogFile
        check_command                   check_log
}
23
Kenoyer130

Comme il existe de nombreuses façons d'atteindre un objectif, un plugin Nice de Consol est également disponible: https://labs.consol.de/lang/fr/nagios/check_logfiles/ }

  • prend en charge la regex
  • prend en charge la rotation du journal

Pour l'utiliser, vous avez besoin d'un fichier cfg, ceci est un exemple pour les bases de données Oracle

@searches = ({
  tag => 'oraalerts',
options => 'sticky=28800',
  logfile => '/u01/app/Oracle/diag/rdbms/davmdkp/DAVMDKP1/trace/alert_DAVMDKP1.log',
  criticalpatterns => [
      'ORA\-0*204[^\d]',        # error in reading control file
      'ORA\-0*206[^\d]',        # error in writing control file
      'ORA\-0*210[^\d]',        # cannot open control file
      'ORA\-0*257[^\d]',        # archiver is stuck
      'ORA\-0*333[^\d]',        # redo log read error
      'ORA\-0*345[^\d]',        # redo log write error
      'ORA\-0*4[4-7][0-9][^\d]',# ORA-0440 - ORA-0485 background process failure
      'ORA\-0*48[0-5][^\d]',
      'ORA\-0*6[0-3][0-9][^\d]',# ORA-6000 - ORA-0639 internal errors
      'ORA\-0*1114[^\d]',        # datafile I/O write error
      'ORA\-0*1115[^\d]',        # datafile I/O read error
      'ORA\-0*1116[^\d]',        # cannot open datafile
      'ORA\-0*1118[^\d]',        # cannot add a data file
      'ORA\-0*1122[^\d]',       # database file 16 failed verification check
      'ORA\-0*1171[^\d]',       # datafile 16 going offline due to error advancing checkpoint
      'ORA\-0*1201[^\d]',       # file 16 header failed to write correctly
      'ORA\-0*1208[^\d]',       # data file is an old version - not accessing current version
      'ORA\-0*1578[^\d]',        # data block corruption
      'ORA\-0*1135[^\d]',        # file accessed for query is offline
      'ORA\-0*1547[^\d]',        # tablespace is full
      'ORA\-0*1555[^\d]',        # snapshot too old
      'ORA\-0*1562[^\d]',        # failed to extend rollback segment
      'ORA\-0*162[89][^\d]',     # ORA-1628 - ORA-1632 maximum extents exceeded
      'ORA\-0*163[0-2][^\d]',
      'ORA\-0*165[0-6][^\d]',    # ORA-1650 - ORA-1656 tablespace is full
      'ORA\-16014[^\d]',      # log cannot be archived, no available destinations
      'ORA\-16038[^\d]',      # log cannot be archived
      'ORA\-19502[^\d]',      # write error on datafile
      'ORA\-27063[^\d]',         # number of bytes read/written is incorrect
      'ORA\-0*4031[^\d]',        # out of shared memory.
      'No space left on device',
      'Archival Error',
  ],
  warningpatterns => [
      'ORA\-0*3113[^\d]',        # end of file on communication channel
      'ORA\-0*6501[^\d]',         # PL/SQL internal error
      'ORA\-0*1140[^\d]',         # follows WARNING: datafile #20 was not in online backup mode
      'Archival stopped, error occurred. Will continue retrying',
  ]
});
3
risker

Pour les journaux de surveillance avec Nagios, le vérificateur de journal renvoie un avertissement uniquement pour les messages d'erreur nouvellement découverts chaque fois qu'il est appelé (il doit donc conserver un état afin de savoir comment les ignorer lors des exécutions suivantes). Par conséquent, je règle habituellement:

max_check_attempts              1
is_volatile                     1

Cela force Nagios à envoyer l'alerte immédiatement, mais une seule fois, puis à revenir à la normale.

Mon vérificateur de journaux préféré est logwarn , mais je suis partial parce que je l’ai écrit moi-même après ne pas avoir trouvé d’existant qui me plaisait. Le paquet logwarn inclut un plugin Nagios.

28
Archie

Il existe un plug-in Nagios que vous pouvez utiliser pour vérifier les fichiers journaux: il s'appelle check_logfiles et il est utilisé pour balayer les lignes d'un fichier à la recherche d'expressions régulières.

Le lien suivant montre comment installer et configurer check_logfiles pour Nagios et Opsview: https://www.opsview.com/resources/nagios-alternative/blog/syslog-monitoring-nagios-opsview }

4
ahmed

Rien dans votre configuration ne me saute aux yeux comme étant mal configuré. 

De par sa conception, check_log n'affichera qu'un message OK ou la dernière entrée de journal ayant déclenché une alerte. Si vous devez voir plusieurs entrées, vous devrez modifier le plug-in.

Cependant, je trouve le fait que vous n'obtenez pas de recouvrement quelque peu étrange. La façon dont check_log fonctionne (en comparant le journal actuel à la version précédente), vous devriez obtenir une récupération lors du prochain contrôle de service. Sauf bien sûr, quand des entrées correspondantes supplémentaires ont été ajoutées au journal depuis la dernière vérification.

Forcer un autre contrôle de service (ou plusieurs) entraîne-t-il la récupération?

De plus, je ne le préviens pas de façon méchante, mais assurez-vous que tout fonctionne vraiment mal… .. Votre journal reçoit-il des entrées de correspondance supplémentaires entre les contrôles, ce qui l'empêche de récupérer? Votre chèque correspond "?" qui correspondra à tout ce qui est nouveau dans le journal. Quelque chose d'autre (une non-erreur) est-il ajouté au journal et provoque-t-il par inadvertance une correspondance?

Si rien de ce qui précède n’est le problème, je suggérerais de le réduire en retirant Nagios de l’équation. Essayez de lancer check_log manuellement (à partir de la ligne de commande, mais avec le même utilisateur que nagios) et avec un ancien journal différent. Cela devrait aller quelque chose comme ça -

  1. lancer la vérification avec un nouveau "oldlog" - obtenir le message d'initialisation
  2. exécuter check - check OK
  3. faire la modification pour vous connecter
  4. lancer la vérification - échec de la vérification
  5. exécuter check - check OK

Si cela ne fonctionne pas, vous devez vous concentrer sur le journal, l'ancien journal et la manière dont check_log effectue le contrôle.

Si cela fonctionne, alors il pointe davantage vers un problème avec la configuration de votre nagios.

3
Bill B

Je crois qu’il existe maintenant un véritable plug-in Nagios qui surveille les journaux de manière efficace. 

http://support.nagios.com/forum/viewtopic.php?f=6&t=8851&p=42088&hilit=unixautomation#p42088

La page d'accueil du plug-in Nagios sur cette page est Nagios Log Monitor

Your [ commands.cfg file ] will contain:

define command {
                            command_name         NagiosLogMonitor
                            command_line            $USER1$/NagiosLogMonitor $HOSTNAME$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ '$ARG5$' '$ARG6$' $ARG7$ $ARG8$ $ARG9$ $ARG10$
}


OR


define command {
                            command_name         NagiosLogMonitor
                            command_line            $USER1$/NagiosLogMonitor $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ '$ARG5$' '$ARG6$' $ARG7$ $ARG8$ $ARG9$ $ARG10$
}




Your [ services.cfg file ] will look similar to:

define service {
                      check_command                         NagiosLogMonitor!logrobot!autofig!/var/log/proteus.log!15!500.html!500 Internal Server Error!1!2!-foundn
                      max_check_attempts                  1
                      service_description                     500_ERRORS_LOGCHECK
                      Host_name                                  sky.blat-01.net,sky.blat-02.net,sky.blat-03.net
                      use                                              fifteen-minute-interval
 }
1
LordOfKings

Nagios dispose désormais d’une solution qui s’intègre étroitement à Nagios Core, XI, etc.

Nagios Log Server qui peut alerter toute requête sur n’importe quel fichier journal sur n’importe quel système de votre infrastructure.

0
Scott Wilkerson