Подтвердить что ты не робот

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

Мы используем Nagios для мониторинга нашей сети с большим успехом. Тем не менее, у нас есть syslog для критических ошибок приложения, и, хотя я настраивал 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
}
4b9b3361

ОТВЕТЫ

Ответ 1

Поскольку существует множество способов достижения цели, есть также хороший плагин из 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',
  ]
});

Ответ 2

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

max_check_attempts              1
is_volatile                     1

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

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

Ответ 3

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

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

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

Задействует ли другая проверка обслуживания (или несколько) ее восстановление?

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

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

  • выполнить проверку с помощью нового "старого журнала" - получить сообщение об инициализации
  • выполнить проверку - проверить ОК
  • внести изменения в журнал
  • выполнить проверку - проверить не удалось.
  • выполнить проверку - проверить ОК

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

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

Ответ 4

Существует плагин nagios, который вы можете использовать для проверки файлов журнала, это check_logfiles, который использовался для сканирования строк файла для регулярных выражений. Эта ссылка показывает, как установить и настроить ее для nagios и opsview http://www.osupport.net/2011/log-files-monitoring-with-nagios-opsview/

Ответ 5

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

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

Домашняя страница плагина Nagios на этой странице 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
 }

Ответ 6

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

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