Как использовать Nagios для мониторинга файла журнала - PullRequest
Новая
       8

Как использовать Nagios для мониторинга файла журнала

23 голосов
/ 03 марта 2010

Мы используем Nagios для мониторинга нашей сети с большим успехом. Тем не менее, у нас есть системный журнал для критических ошибок приложения, и хотя я настраиваю check_log, он, похоже, не работает так же, как мониторинг устройства.

Проблемы:

  • Показывает только последнюю запись
  • Кажется, нет способа признать критическую ошибку и вернуть монитор в нормальное состояние

Является ли nagios неправильным инструментом или мы просто не настраиваем мониторинг служб, верно?

Вот мои записи 

# 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
}

Ответы [ 6 ]

28 голосов
/ 26 января 2011

Для мониторинга журналов с помощью Nagios, как правило, средство проверки журналов будет выдавать предупреждение только для вновь обнаруженных сообщений об ошибках каждый раз, когда оно вызывается (поэтому оно должно сохранять некоторое состояние, чтобы знать, чтобы игнорировать их при последующих запусках). Поэтому я обычно задаю: 

max_check_attempts              1
is_volatile                     1

Это заставляет Nagios немедленно отправлять оповещение, но только один раз, а затем возвращаться в нормальное состояние.

Мой любимый журнал проверки - logwarn , но я пристрастен, потому что сам написал его после того, как не нашел существующих, которые мне понравились. В пакет logwarn входит плагин Nagios.

4 голосов
/ 13 ноября 2011

Существует плагин Nagios, который можно использовать для проверки файлов журнала: он называется check_logfiles и используется для сканирования строк файла на наличие регулярных выражений.

Следующая ссылка показывает, как установить и настроить check_logfiles для Nagios и Opsview: https://www.opsview.com/resources/nagios-alternative/blog/syslog-monitoring-nagios-opsview

3 голосов
/ 26 января 2015

Поскольку есть много способов достичь цели, есть также хороший плагин от Consol: https://labs.consol.de/lang/en/nagios/check_logfiles/

  • поддерживает регулярное выражение
  • поддерживает ротацию логов

Чтобы использовать его, вам нужен файл cfg, это пример для баз данных оракула 

@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 голосов
/ 03 марта 2010

Ничто в вашей конфигурации не выскакивает у меня как неправильно настроенное.

По умолчанию в check_log будет отображаться только сообщение OK или последняя запись в журнале, которая вызвала предупреждение. Если вам нужно увидеть несколько записей, вам нужно изменить плагин.

Однако я нахожу тот факт, что вы не получаете восстановления несколько странным. Как работает check_log (сравнивая текущий журнал с предыдущей версией), вы должны получить восстановление при следующей проверке сервиса. За исключением, конечно, если с момента последней проверки в журнал были добавлены дополнительные подходящие записи.

Вызывает ли принудительная проверка (или несколько) другой сервис его восстановление?

Кроме того, я не имею в виду этого, но убедитесь, что это действительно неисправно. Ваш журнал получает дополнительные совпадающие записи между проверками, заставляя его не восстанавливаться? Ваш чек соответствует "?" который будет соответствовать чему-либо новому в журнале. Что-то еще (без ошибок) добавляется в журнал и непреднамеренно вызывает совпадение?

Если ни один из вышеперечисленных не является проблемой, я бы предложил сузить ее, исключив Нагиоса из уравнения. Попробуйте запустить check_log вручную (из командной строки, но от имени того же пользователя, что и nagios) и с другим oldlog. Должно быть что-то вроде этого -

  1. запустить проверку с новым "oldlog" - получить сообщение об инициализации
  2. выполнить проверку - проверьте ОК
  3. внести изменения в журнал
  4. выполнить проверку - проверка не пройдена
  5. проверка запуска - проверка ОК

Если это не сработает, тогда вы знаете, как сосредоточиться на журнале, старом журнале и на том, как check_log выполняет проверку.

Если это работает, то это больше указывает на проблему с вашей конфигурацией nagios.

1 голос
/ 26 февраля 2013

Я считаю, что теперь есть настоящий плагин Nagios, который эффективно контролирует журналы.

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

Домашняя страница плагина Nagios на этой странице: Монитор журнала Nagios 

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
 }
0 голосов
/ 23 октября 2014

Nagios теперь имеет решение, которое тесно интегрируется с Nagios Core, XI и т. Д.

Nagios Log Server , который может оповещать о любом запросе к любому файлу журнала в любой системе вашей инфраструктуры.

...