пятница, 2 августа 2013 г.

Мониторинг веб-сервера Nginx c помощью zabbix trapper



   Рассмотрим случай, когда требуется настроить мониторинг сервера по множеству однотипных или динамических метрик, которые отсутствуют в zabbix-агенте.
   В такой ситуации в zabbix-агенте можно создавать ключи для проверки с помощью параметра конфигурации - UserParameter. Для каждого параметра в zabbix_agentd.conf создаётся строка вида:

UserParameter=<key>,<shell command>


   Однако, если значений слишком много, такой способ может оказаться не удобным.
Второй способ заключается в использовании элемента данных zabbix типа trapper (zabbix-ловушки). Принцип очень простой: в zabbix-сервере создаются элементы данных этого типа с произвольным именем ключа. Затем, с помощью утилиты zabbix_sender формируется специальный запрос, в котором указывается ключ ловушки, значение параметра и имя хоста. Если параметров много, то можно сформировать файл в формате zabbix_sender и отправить все значения из файла за одно соединение с сервером.
Строки в файле должны быть оформлены в таком виде:
- <ключ> <значение> (дефис в начале строки обязателен)
или
<имя_хоста> <ключ> <значение>


   Рассмотрим, как использовать эту возможность на примере мониторинга популярного веб-сервера Nginx.  Для этого веб-сервера есть возможнось использовать модуль stub_status, который показывает в цифрах текущую нагрузку на Nginx примерно в таком виде:
Active connections: 26
server accepts    handled     requests
1344375             1344375    3208201
Reading: 0 Writing: 2 Waiting: 24


   Из этих данных мы можем получить, например, такие метрики для мониторинга:
  • nginx_status.active   -  количество всех открытых соединений
  • nginx_status.reading -  количество запросов, у которых nginx читает заголовки запроса
  • nginx_status.writing - количество запросов, у которых в данный момент сервер читает тело запроса, обрабатывает запрос или пишет ответ клиенту
  • nginx_status.waiting  -  количество неактивных(keep-alive) соединений
  • nginx_status.accepts - количество принятых запросов в секунду
  • nginx_status.handled - количество обрабатываемых запросов в секунду
  • nginx_status.requests  - количество запросов в секунду
   Благодаря этим параметрам можно оценить нагрузку на сервер (в течении дня, недели и т.д.) , а также оценить узкие места в его работе (медленный ли канал у сервера, медленные ли каналы у клиентов, медленно ли обрабабатываются запросы и т.д.).


   Скрипт, формирующий файл для zabbix_sender-а и запускающий zabbix_sender, может запускаться zabbix-агентом.
   Для этого в конфигурационном файле агента zabbix_agentd.conf создадим ключ nginx_status:
UserParameter=nginx_status,/home/zabbix/nginx.sh 127.0.0.1


   Содержимое /home/zabbix/nginx.sh примерно такое:
#!/bin/sh

# this script tries to collect nginx data

########################################
# Active connections: 768              #
# server accepts handled requests      #
#  133844 133844 601894                #
# Reading: 63 Writing: 21 Waiting: 684 #
########################################

WGET="/usr/local/bin/wget"
ZBX_STATS_FILE="/var/log/zabbix/ZabbixStats.txt"
ZBX_SENDER="/home/zabbix/bin/zabbix_sender"
ZBX_CONFIG="/home/zabbix/conf/zabbix_agentd.conf"
ZBX_HOSTNAME=`grep "^Hostname" ${ZBX_CONFIG} | cut -f2 -d"="`

NGX_STATS_FILE="/var/log/zabbix/NginxStats.txt"
if [ -z $1 ]; then
   NGX_HOSTNAME="localhost"
else
   NGX_HOSTNAME="${1}"
fi

$WGET -q -O ${NGX_STATS_FILE} -t3 -T5 http://${NGX_HOSTNAME}/nginx-status

if [ $? == 0 ]; then
       cat ${NGX_STATS_FILE} | awk -v myhost=$ZBX_HOSTNAME '/Active connections/ {active = int($NF)}
                      /\W*([0-9]+)\W*([0-9]+)\W*([0-9]+)/ {accepts = int($1); handled = int($2); requests = int($3)}
                      /Reading:/ {reading = int($2); writing = int($4); waiting = int($NF)}
                      END {
                      print myhost, "nginx_status.active", active;
                      print myhost, "nginx_status.reading", reading;
                      print myhost, "nginx_status.writing", writing;
                      print myhost, "nginx_status.waiting", waiting;

                      print myhost, "nginx_status.accepts", accepts;
                      print myhost, "nginx_status.handled", handled;
                      print myhost, "nginx_status.requests", requests;
                      }' > ${ZBX_STATS_FILE}

       ${ZBX_SENDER} -i ${ZBX_STATS_FILE} -c ${ZBX_CONFIG} >/dev/null
       echo 1;
       exit 0
else
       echo "0"
       exit 1
fi
При запросе сервером zabbix ключа nginx_status, скрипт вышлет данные серверу.


   Создаем в zabbix-сервере шаблон - Template App Nginx.
   Создаём в шаблоне элемент данных типа zabbix agent, запускающий скрипт /home/zabbix/nginx.sh (Рис. 1).
Рисунок. 1 Элемент данных, запускающий скрипт /home/zabbix/nginx.sh


   Скрипт в случае успешного получения страницы nginx-status возвращает 1 и 0 - в противном случае. Полезно создать триггер отслеживающий эту ситуацию (Рис. 2).
Рисунок 2. Тригер, отслеживаюший возможность получения статуса с Nginx.


   Далее для каждого параметра создаем элемент данных типа zabbix trapper. На Рис.2  пример для метритки nginx active connections.
Рисунок 3. Создание элемента данных для метрики nginx active connections.


   По аналогии делаем элементы для остальных метрик. Изменяется только название элемента данных (Name) и ключ (Key).


   После объединения графиков в группы получаются графики как на Рис. 4 и Рис. 5.
Рисунок 4. Статус соединений.


Рисунок 5. Нагрузка на сервер.


   Шаблон для мониторинга nginx можно скачать отсюда: http://forum.itrm.ru/t/94/

понедельник, 3 июня 2013 г.

Мониторинг и управление ИТ


Общий взгляд на ИТ-мониторинг

Для понимания, какое место занимает ИТ-мониторинг в управлении ИТ, необходимо понимать, как вообще управляются технические (и не только) системы. А для управления ими, как правило, используются либо замкнутый, либо разомкнутый контур передачи воздействия. Тут все зависит от того, какой информацией о системе мы уже обладаем или можем получить в процессе  управления.

Если у нас есть статистическая информация по ИТ-системе, что за квартал объем данных возрастает на 10 Тб, и данные надо собирать и хранить год, а в течение этого времени у нас не будет возможности контролировать дисковое пространство, мы можем заранее купить и установить диски на 40 Тб, чтобы система работала стабильно в требуемом временном интервале. Это пример управления ИТ при помощи разомкнутого контура на основе заранее собранной и проанализированной информации.

Другой пример, если у нас есть возможность контролировать определенные параметры ИТ-системы в реальном режиме времени и сразу реагировать на них. Например, свободное место на том же диске. Как только будет превышен определенный порог, это станет нам сразу же известно, и мы сможем удалить ненужные данные или перенести часть из них в резервное хранилище, чтобы система продолжала работать стабильно. Это пример управления с замкнутым контуром.

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

ИТ-Мониторинг с точки зрения ITIL

В ITIL (библиотека, описывающая лучшие практики управления IT) ИТ-Мониторинг играет одну из ключевых ролей в управлении ИТ-услугами.

Из глоссария ITIL:
Мониторинг -  это постоянное наблюдение за Конфигурационной единицей, ИТ-услугой или Процессом с целью обнаружения Событий и обеспечения информированности о текущем состоянии.
 
А вот управление Событиями, о которых информирует ИТ-мониторинг уже является основным процессом в управлении ИТ-услугами. ITIL классифицирует События в зависимости от значимости на Инциденты, Проблемы и Изменения и далее по каждому из видов Событий рекомендует использовать соответственно процессы управления Инцидентами, управления Проблемами и управления Изменениями, что в конечном итоге позволяет значительно повысить качество ИТ-услуг.


ИТ-Мониторинг с точки зрения COBIT

В COBIT Мониторинг выведен в отдельный домен "Мониторинг и оценка". Всего доменов в последней 5-ой версии пять, они схематически изображены на рисунке ниже.  

Рисунок 1. Домены процессов в COBIT 5

Домен "Мониторинг и оценка"состоит из 4-х процессов:

- Мониторинг и оценка эффективности ИТ;

- Мониторинг и оценка системы внутреннего контроля

- Обеспечение соответствия внешним требованиям

- Обеспечение корпоративного управления ИТ

 
По COBIT Мониторинг необходим для уверенности в том, что все делается правильно, в соответствии с принятыми направлениями и политиками.
 
Так как COBIT специализируется на контроле и аудите ИТ, то в отличии от ITIL, специализирующегося в основном на управлении ИТ,  для COBIT более важное значение имеют не События, а статистическая информация. Этот вид информации, который Мониторинг собирает и хранит в базе, позволяет руководству компании делать текущие выводы на основе исторических данных, принимать стратегические управленческие решения, прогнозировать затраты и эффективность информационных технологий для организации.  


Какую систему мониторинга выбрать
 
Когда ставится вопрос о системе мониторинга, то выбор стоит между системами с открытым программным обеспечением (Open Source Software) и  платным (требующим оплату за лицензии). В большинстве случаев выбор сводится к четырем вариантам.
 
Две системы c открытым исходным кодом:
Nagios
Zabbix
 
И две, требующие оплаты за использование ПО:
IBM Tivoli
HP Software (в прошлом HP OpenView)

Платные системы мониторинга имеет смысл использовать, если есть наличие промышленных приложений уровня SAP, Oracle, возможность интеграции с системами поддержки и управления ИТ-услугами (ServiceDesk), системами управления бизнес-услугами (Business Service Management, BSM), требование гарантированной технической поддержки от разработчиков данного программного обеспечения, а также возможность платить за лицензии.
 
Open Source системы мониторинга можно использовать в тех случаях, когда вы готовы своими силами дописывать скрипты для мониторинга каких-либо специфических метрик, нет необходимости в короткие сроки настроить мониторинг редких промышленных приложений, так как под них вы скорее всего не найдете готовых шаблонов, и придется их разрабатывать самостоятельно. А также у вас нет необходимости интеграции с ServisDesk, BSM, и в случае возникновения проблем с системой мониторинга вы готовы решать их самостоятельно.
 
Большой плюс систем мониторинга с открытым программным обеспечением в том, что, в принципе, вы можете самостоятельно настроить мониторинг практически любых метрик при возможности их получения каким-либо способом.

C уважением,
Андрей
Компания ITRM

понедельник, 20 мая 2013 г.

Автоматизация мониторинга доступности динамического списка серверов и сетевых устройств в системе мониторинга Zabbix


В вычислительных сетях с большим количеством устройств (например, сеть банкоматов или сетевых устройств) часто требуется мониторинг доступности узлов с возможностью сбора и графического отображения статистической информации по задержкам и потерям пакетов в канале до данных узлов. Иногда список устройств для которого требуется мониторинг доступности бывает динамическим, то есть может периодически меняться как сам список устройств, так и их ИП-адреса или названия.


В данной статье мы решили описать решение этой задачи при помощи системы мониторинга Zabbix.


В Zabbix-е начиная с версии 2.0 доступна новая функция: низкоуровневое обнаружение.
Низкоуровневое обнаружение предоставляет возможность автоматического создания элементов данных, триггеров и графиков для разных ресурсов на компьютере. Так, в дистрибутив включена возможность автоматического обнаружения сетевых интерфейсов и дисков на сервере. Рассмотрим, как ещё можно применять данную возможность.


Есть задача осуществлять мониторинг доступности серверов - порядка 200-300 единиц. Допустим, что требуется раз в 2 минуты с серверов клиента проверять их доступность по сети, время отклика и потери пакетов. По всем параметрам должна собираться и графически отображаться статистика. При этом список серверов обновляется динамически в текстовом файле выглядящем следующим образом::
имя_сервера1 192.168.1.11
имя_сервера2 192.168.2.22
и т.д.


Для решения этой задачи удобно использовать низкоуровневое обнаружение.
Создаем скрипт, который будет запрашиваться с сервера, где работает система мониторинга Zabbix. Его результатом будет текст в формате json, который требуется для низкоуровневого обнаружения:


#!/usr/bin/perl

$latest_file=`ip.servers.lst`;  # Текстовый файл с динамическим списком узлов

print "{\n";
print "\t\"data\":[\n\n";

for (`cat $latest_file`)
{
    ($clname, $clip) = m/\S_(\S+) (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/; # $clname - имя сервера, $clip - его IP-адрес

   print "\t{\n";
   print "\t\t\"{#CLNAME}\":\"$clname\",\n";
   print "\t\t\"{#CLIP}\":\"$clip\"\n";
   print "\t},\n";
}

print "\t]\n";
print "}\n";


Вывод этого скрипта будет примерно таким:
{
       "data":[
       {
               "{#CLNAME}":"server_name1",
               "{#CLIP}":"192.168.1.11"
       },
       {
               "{#CLNAME}":"server_name2",
               "{#CLIP}":"192.168.2.22"
       },



       ]
}


Добавляем скрипт в конфигурацию агента Zabbix zabbix_agentd.conf  в разделе UserParameter:
UserParameter=cl.discovery,/home/zabbix/cl.discovery.pl


В web-интерфейсе Zabbix-сервера создаем правило “create discovery rule” (Рис. 1) для хоста, с которого осуществляется мониторинг серверов и сети:
  • Name discovery clients
  • Type zabbix agent
  • Key такой же, что указан в UserParameter (cl.discovery)
  • Keep lost resources period (in days) 0 (если не хотим хранить информацию о серверах, которые не требуется мониторить)

     
Рисунок 1. Правило “create discovery rule”


В разделе Item prototypes (Рис. 2) создаем прототипы требуемых элементов данных (create item prototype):
Для времени отклика:
  • Name ICMP ping response time to {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingsec[{#CLIP}]
  • Type of information Numeric(float)
  • Units ms

Рисунок 2. Раздел Item prototypes.


Для потерь пакетов:
  • ICMP ping percentage of loss packets {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingloss[{#CLIP}]
  • Type of information Numeric(float)
  • Units %


В разделе Graph prototypes (Рис. 3) создаем (create graph prototype) прототип графиков привязанные к созданным прототипаv элементов данных.


Рисунок 3. Разделе Graph prototypes.


В разделе Trigger prototypes создаём прототипы тригеров к созданным прототипам элементов данных.


Теперь при изменении списка с серверами в zabbix-сервере автоматически будут создаваться и удаляться соответствующие элементы данных и графики (Рис. 4).


Рисунок 4. Графики по задержкам и потерям пакетов в канале до определенного узла.

C уважением,
Компания ITRM