Теория работы плагинов nagios

Фактически плагин nagios – это обычная программа, которая взаимодействует с системой мониторинга через коды возврата и стандартного вывода. Коды возврата сообщают nagios о результате проверки, а из стандартного вывода формируется сообщение для web интерфейса. Со стандартным выводом все несколько сложнее, но сперва расскажу про коды возврата. Всего есть четыре кода возврата, которые может передать плагин в систему мониторинга:

0 – OK, т.е. проверка выполнена удачно и все работает как нужно.
1 – WARNING, проверка выполнена успешно, но проверяемая служба выдает показатели, превышающие порог нормальной работы.
2 – CRITICAL, проверка выполнена, но проверяемая служба не работает, или выдает значения, превышающие критический порог.
3 – UNKNOWN, такой код возврата говорит о невозможности плагином выполнить проверку. Причин для этого может быть несколько, например были введены неверные аргументы для плагина проверки или плагин не может создать какой-то дочерний процесс, открыть tcp сокет и т.п.

Один из этих кодов возврата плагин должен вернуть в любом случае. Кроме того плагин должен вывести что-то в стандартный вывод. Причем есть несколько вариантов. В самом простом варианте это должна быть просто одна строка, например:
DISK OK – free space: / 3326 MB (56%);
Этот вывод будет показан в web интерфейсе. Кроме описания произведенной проверки и ее показателей, можно выводить статистику. для разделения вывода в web интерфейс и статистики используется символ | . Формат статистики:
‘название’=значение[размерность];[warn];[crit];[min];[max]

название – текстовое обозначение выводимой величины, например /, или ‘Disk /’. Замечу, что кавычки в названии требуются, только при использовании в нем пробела, знака равно или кавычек.
значение – результат проверки.
размерность – размерность не указывается для значений, показывающих число процессов, пользователей и т.п. Если значение в процентах, то и размерность нужно указать, как %. Аналогично для времени (s), размеров данных (B, KB, MB, TB). Для постоянно увеличивающихся счетчиков используется размерность c.
warn – порог предупреждения
crit – порог критического состояния
min и max - допустимые минимальное и максимальное значения. Для размерности % указывать их не нужно понятно почему.

Можно выводить несколько параметров через пробел. Т.е. получается что-то такое:
DISKS OK – free space: / 3326 MB (56%); /home 184053 MB (27%) | /=2643MB;5948;5958;0;5968 /home=69357MB;253404;253409;0;253414
Кроме того есть третий вариант, который работает в nagios 3.x. Помимо сообщения и статистики можно выводить длинное описание, еще несколько строк, как показано вот в этом примере:
DISK OK – free space: / 3326 MB (56%); | /=2643MB;5948;5958;0;5968
/ 15272 MB (77%);
/boot 68 MB (69%);
/home 69357 MB (27%);
/var/log 819 MB (84%); | /boot=68MB;88;93;0;98
/home=69357MB;253404;253409;0;253414
/var/log=818MB;970;975;0;980
Красным выделено сообщение, оранжевым статистика и синем длинное описание. Помните, я говорил, что сообщение выводится в web интерфейс, а тогда где используется статистика и длинное описание? На самом деле все несколько сложнее. Для обработка каждого из типов вывода используется отдельный макрос:

Например статистику можно использовать для построения графиков через команду service_perfdata_command.
Теперь пожалуй с теории покончено, осталось только сказать, что в nagios есть механизм защиты от вывода слишком большого объема информации плагином, nagios прочитает только 4КБ данные, все остальное будет отброшено.

Несколько советов о практике написания плагинов

Чтобы запустить проверку, т.е. наш плагин, на удаленном сервере нужна некая служба, которая получает команды на запуск плагина от сервера nagios и отдает ему результат проверки. Различные варианты реализации такой службы я бы хотел вынести в отдельную статью, а сейчас давайте поговорим о другой проблеме.
Многие проверки, например проверка состояния raid массива, требует прав суперпользователя. Т.е. у нас есть внешняя служба на сервер, которой с одной стороны очень не хочется давать права суперпользователя, а с другой проверки, которым эти права суперпользователя нужны!
Есть два наиболее часто используемых варианта запуска на удаленном сервере плагина:
1) Плагин check_by_ssh умеет запускать на удаленном сервере заданную команду, т.е. на сервере nagios запускается плагин check_by_ssh, которому в качестве параметров передается имя проверяемого хоста и команду, которую нужно запустить.
2) Служба NRPE, на проверяемом сервере запускается служба NRPE, в ее настройках прописаны команды, которые может “попросить” выполнить сервера nagios. На стороне сервера проверка выполняется аналогично варианту с SSH, вызывается плагин check_by_nrpe с параметрами хоста и имени запускаемой команды.
Теперь вернемся к нашей проблеме, нам нужно запустить проверку с правами суперпользователя.
Вариант первый – путь камикадзе. Запускаем службу nrpe от имени root или разрешаем заход по ключу root с сервера nagios. Проблема решена, можно запускать любой плагин с правами суперпользователя. Теперь рассмотрим проблемы с безопасностью, который возникают при таком решении. Запуск любой внешней службы с правами суперпользователя всегда потенциально опасен, если в ней есть критическая уязвимость, то получить после удачного эксплойда права nobody и права root – это две большие разницы. В принципе при жесткой настройке правил фаервола для nrpe, такой вариант имеет права на жизнь, но с точки зрения системного подхода к обеспечению безопасности это явный fail. Для check_by_ssh вроде бы такой проблемы нет. Но подумайте вот о чем, если сервера nagios будет взломан, то с большой вероятностью злоумышленник получит доступ на все остальные ваши сервера!
Вариант второй – sudo. Данный вариант уже намного лучше. На проверяемом сервере создается пользователь nagios, под которым запускается nrpe или по ключу которого заходит по ssh сервер nagios. В sudo в настройках прописаны правила запуска плагинов проверки для пользователя nagios. Такой вариант намного лучше с точки зрения безопасности, но в данном варианте атака может быть направлена на запускаемый плагин. Атака маловероятная, но возможная. При грамотной настройке фаервола и прочих мерах безопасности данный вариант наиболее часто используется на практике.
Вариант третий – разделение логики проверки на собственно проверку и получение данных сервером nagios. Т.е. плагин, который мы пишем имеет два варианта запуска. В одном он выполняет проверку с правами root и сохраняет результат в какой-то файл. Права на файл выставляются так, чтобы пользователь, от имени которого запускаются проверки, мог прочитать этот файл. Эта проверка запускается через cron. Второй же вариант запуска нужен для чтения фала с результатами проверки. Из нюансов – нужно помнить, что плагин должен уметь проверять время создания файла, так чтобы не получилось, что проверка по какой-то причине давно не работает, а плагин раз за разом читает давно созданный файл и сообщает, что все ОК. Вариант с разделенной логикой наиболее безопасен, но распространен не очень сильно, так как под него придется переписывать все распространенные плагины.
Вот наверное и все, что нужно для начала написания своего плагина.

1. Собрать статистику утилизации CPU
2. Написать скрипт, который будет отдавать эту статистику в формате nagios
3. Настроить команды и сервисы nagios
4. Построить красивые графики

Собираем статистику утилизации CPU

Обязательным требованием при сборе любой статистики является время. Т.е. статистику нужно собирать в течение достаточно продолжительного периода времени, чтобы полученные данные отражали реально происходящие процессы, а не какие-то промежуточные состояния при одиночной проверке состояния. Или частота проверки должна примерно соответствовать частоте изменения данных. Для утилизации процессора это выглядит так: частота изменений утилизации процессора составляет доли секунд, частота проверки nagios – несколько минут. Обычный подход nagios “зайти и проверить” не подходит.

Можно подключиться к серверу по ssh/nrpe и запустить проверку, скажем на минуту. Такой вариант отвратителен. Остается другой способ – статистика уже должна быть на сервере, nagios только забирает ее. Для этого замечательно подходит утилита sar. Напишем небольшой скрипт, который будет создавать файл со статистикой. Скрипт запускаем через крон каждую минуту.

#!/bin/bash
LOCKFILE=/var/run/cpu-usage.sh.lock
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
if [ -f $LOCKFILE ]; then
        exit 0;
fi
printf $$ > $LOCKFILE
TIME=55
SARDATA=`sar -u $TIME | fgrep Average | awk '{print "user:" $3 ";system:" $5 ";iowait:" $6 ";idle:" $8}'`
SARFILE=/var/sar-cpu-usage
printf $SARDATA > $SARFILE
rm $LOCKFILE

В результате мы получим текстовый файл. Формат у файла очень простой, плагину nagios нужно будет только прочитать содержимое файла и вывести необходимые данные.

Пишем плагин для nagios

Сам скрипт достаточно прост, его нужно разместить на проверяемой машине.

#!/usr/bin/perl -w
use strict;
my $file = '/var/sar-cpu-usage';
my $line;                       

open FD, $file;
$line = ;
close FD;

my ($user, $system, $iowait, $idle, $nagios_data, $nagios_status, $exit_code);
my @arg;
@arg = split(/;/, $line);

# user
$arg[0] =~ /^user:(.*)$/;
$user = $1;
# system
$arg[1] =~ /^system:(.*)$/;
$system = $1;
# iowait
$arg[2] =~ /^iowait:(.*)$/;
$iowait = $1;
# idle
$arg[3] =~ /^idle:(.*)$/;
$idle = $1;

$nagios_data = sprintf("|user=%f;;; system=%f;;; iowait=%f;;; idle=%f;;; ",$user,$system,$iowait,$idle);
if ( $idle == 0 ) {
        $nagios_status = "CPU status: CRITICAL, idle $idle %";
        $exit_code = 2;
} elsif ( $idle < 5 ) {
        $nagios_status = "CPU status: WARNING, idle $idle %";
        $exit_code = 1;
} else {
        $nagios_status = "CPU status: OK, idle $idle %";
        $exit_code = 0;
}

print $nagios_status . $nagios_data;
exit $exit_code;

В результате получаем вот такой вывод скрипта:

Настраиваем nrpe и nagios

Первым делом нужно настроить nrpe на проверяемой машине, точнее добавить команду для проверки, так как я предполагаю, что сам nrpe уже был настроен. Добавляем в nrpe.cfg строчку:

command[check_cpu_usage]=/usr/nagios/libexec/check_cpu_usage

Теперь нужно настроить сервер nagios. Нужно добавить команду для проверки и сервис для проверяемого хоста.
Добавляем в описание команды и сервиса:

define command {
command_name check_nrpe_cpu_usage
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -t 60 -c check_cpu_usage
}

define service{
use template
host_name server.host-name.ru
service_description cpu usage
check_command check_nrpe_cpu_usage
}

На этом настройка nagios закончена. Напомню только, что use template требует определения шаблона под именем template. Но не спешите перегружать nagios.

Строим графики при помощи pnp4nagios

Я долгое время использовал nagios исключительно, как средство мониторинга текущего состояния, но в какой-то момент понял, что иногда хочу узнать что было с серверов в 5 часов утра. Из всех средств nagios предоставлял только логи алертов, чего, мягко говоря, мало. Пересмотрев несколько решений и попробовав написать свое, я остановился на php4nagios. Настройку его я пропущу здесь, расскажу только про настройку под рассматриваемую задачу.
Первым делом нужно создать файл настройки rrd базы, которую создаст php4nagios по данным от плагинов nagios. pnp ищет настройки в каталоге /etc/pnp/check_commands/ (так на gentoo). Файл настройки называется по имени команды (command_name) в настройках nagios. В нашем случае это check_nrpe_cpu_usage. Так что файл конфигурации будет называться /etc/pnp/check_commands/check_nrpe_cpu_usage.cfg :

CUSTOM_TEMPLATE = 0
DATATYPE = GAUGE,GAUGE,GAUGE,GAUGE

CUSTOM_TEMPLATE – определяет имя темплейта для построения графика из rrd файла. Цифры определяют имя темплейта. 0 – имя команды проверки, 1 – первый параметр команды. 2 – второй и так далее. Указываются через запятую.

CUSTOM_TEMPLATE=0,1,2

DATATYPE – определяет тип счетчика rrd, Счетчики передаются плагином nagios после пайпа (|)

|user=15.810000;;; system=1.430000;;; iowait=1.380000;;; idle=81.380000;;;

user – первый счетчик, system – второй и так далее. Плагин может возвращать данные и в таком формате user=15.810000;60;90;. 60 – значение для статуса проверки WARNING, 90 – для CRITICAL. Эти значения тоже могут быть использованы при построения графиков. Возвращаясь к DATATYPE. Каждое значение DATATYPE, которое тоже указывается через запятую, определяет один за другим типы счетчиков.

DATATYPE = GAUGE,GAUGE,GAUGE,GAUGE

В нашем случае все счетчики имеют тип GAUGE (подробнее про типа тут). Первый шаг сделан. Теперь нужно создать темплейт для отображения. Темплейты – это php файлы, в которых описаны команды, передаваемые rrdtool для генерации графиков. Для Gentoo они находятся в каталоге /usr/share/pnp/templates . Имя темплейта определяется по имени команды для проверки в настройках nagios, в нашем случае это будет опять check_nrpe_cpu_usage, и полный путь до файла будет /usr/share/pnp/templates/check_nrpe_cpu_usage.php. Рассказывать про rrdtool я не буду, так как это совсем отдельная тема, приведу файл, который использую я:

<?php
$opt[1] = "--slope-mode --vertical-label % --title \"CPU usage for $hostname\"";

$def[1] = "DEF:var1=$rrdfile:$DS[1]:AVERAGE " ;
$def[1] .= "DEF:var2=$rrdfile:$DS[2]:AVERAGE " ;
$def[1] .= "DEF:var3=$rrdfile:$DS[3]:AVERAGE " ;
$def[1] .= "DEF:var4=$rrdfile:$DS[4]:AVERAGE " ;

$def[1] .= "AREA:var4#00FF00:\"idle  \" ";
$def[1] .= "GPRINT:var4:MAX:\"\t%.1lf  max \" ";
$def[1] .= "GPRINT:var4:AVERAGE:\"%.1lf  average \" ";
$def[1] .= "GPRINT:var4:LAST:\"%.1lf  last \\n\" ";

$def[1] .= "AREA:var3#FF0000:\"iowait\" ";
$def[1] .= "GPRINT:var3:MAX:\"\t%.1lf  max \" ";
$def[1] .= "GPRINT:var3:AVERAGE:\"%.1lf  average \" ";
$def[1] .= "GPRINT:var3:LAST:\"%.1lf  last \\n\" ";

$def[1] .= "AREA:var1#FFFF00:\"user  \" ";
$def[1] .= "GPRINT:var1:MAX:\"\t%.1lf  max \" ";
$def[1] .= "GPRINT:var1:AVERAGE:\"%.1lf  average \" ";
$def[1] .= "GPRINT:var1:LAST:\"%.1lf  last \\n\" ";

$def[1] .= "AREA:var2#0000FF:\"system\" ";
$def[1] .= "GPRINT:var2:MAX:\"\t%.1lf  max \" ";
$def[1] .= "GPRINT:var2:AVERAGE:\"%.1lf  average \" ";
$def[1] .= "GPRINT:var2:LAST:\"%.1lf  last \\n\" ";

$def[1] .= "LINE1:var4#00FF00: ";
$def[1] .= "LINE1:var1#FFFF00: ";
$def[1] .= "LINE1:var2#0000FF: ";
$def[1] .= "LINE1:var3#FF0000: ";
?>

Теперь перезапускаем nrpe на проверяемой машине и nagios на сервера мониторинга, ждем какое-то время. В результате получается вот такая картинка:

Стандартные средства – это SNMP, ssh и nrpe. Посмотрим на них более внимательно.

SNMP – замечательный протокол для управления сетевыми устройствами и получения данных об их работе, но для мониторинга unix серверов не очень подходит. Поясню почему. SNMP позволяет получить обширный объем информации, но зачастую при мониторинге серверов нужно проверять какой-то специфичный сервис, для которого нет MIB-a. Это можно обойти, создав свой MIB и агента для него, вот в этой статье рассказано, как это сделать для MYSQL. Судя по статье работы там не мало, а результат тот же самый, что и при использовании ssh или nrpe. Т.е. лучше SNMP оставить сетевым устройствам и сосредоточиться на написании скриптов для получения данных сервисов, а не на доставке этих данных nagios.

Плагины check_by_ssh и check_nrpe фактически выполняют одну и ту же функцию, запускают на удаленной машине другие плагины nagios для проверки служб сервера. При проверке через ssh используется достаточно много ресурсов, как проверяемого, так и проверяющего сервера. В первую очередь CPU. Это не будет минусом на сервера nagios с небольшим числом проверяемых хостов и сервисов. Но сервер для сервера, проверяющего сотни и сотни хостов, это может стать узким местом. Основной целью создания NRPE как раз и было получение более “легкого” механизма проверки ресурсов на уделенных серверах.

Минусом считается безопасность. Но мне это утверждение кажется достаточно надуманным, так как соединение между nagios и проверяемым сервером шифруется при помощи SSL. Более того, демон NRPE размещается на отдельном tcp порту, который нужно закрыть фаерволом от всех, кроме сервера nagios. Уже двух этих мер хватает, чтобы сделать NRPE таким же безопасным, как и ssh.
Из минусов – необходимость установки демона на всех проверяемых серверах, раскидывание конфигов. Но это как раз и есть работа администратора, пусть и не самая приятная и интеллектуальная. Т.е. при выборе механизма удаленного запуска плагинов nagios лучше выбрать nrpe, чем ssh или snmp.