Назад | Перейти на главную страницу

Как контролировать узлы веб-сервера через HAproxy с помощью Icinga / Nagios в CentOS 6

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

Итак, вот возможный сценарий:

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

Итак, вот подход параноиков:

Тогда перейдем к делу ...

Прежде всего вам нужно включить вставку файлов cookie в haproxy и назначить каждому внутреннему узлу свой уникальный ключ. Обычно это используется для закрепления сеанса - то есть вы не хотите, чтобы кто-то посещал ваш сайт, чтобы всегда получать один и тот же серверный узел, если он все еще доступен. Но его также можно использовать для мониторинга отдельных узлов, отправив соответствующий файл cookie. Поэтому, если они отсутствуют, добавьте файлы cookie в определения вашего сервера haproxy:

cookie SERVERID insert indirect nocache
server webA1 10.0.0.1:80 cookie S1 
server WebA2 10.0.0.2:80 cookie S2 

Во-вторых, вам нужно будет выяснить, что имеет наибольший смысл для проверки, по этому поводу вам нужно будет немного подумать и поиграть самостоятельно, чтобы выяснить, что имеет наибольший смысл и как это проверить, используя потрясающий check_http от nagios. Для полноты картины ниже я приведу сложный пример того, как вы можете протестировать POST-запрос на внутреннюю веб-службу. Для этого примера сценария требования:

 - Post data should be <echo>Hello</echo>
 - A successful execution will return the echo string back
 - Disable any cache through HTTP headers
 - Set content-type to text/xml and expect the same back
 - SSL should be used
 - Host name is example.com
 - Port is 443
 - URI is /service
 - Max response time is 3 seconds

Об этом позаботятся следующие аргументы для check_http (/ usr / lib64 / nagios / plugins / check_http в Cent OS 6)

-P "<echo>Hello</echo>"
-r 'Hello'
-k "Cache-Control: no-cache" -k "Pragma: no-cache"
-k "Content-Type: text/xml; charset=UTF-8" -k "Accept: text/xml"
-S 
-H example.com
-p 443
-u /service
-t 3

Итак, все это вместе должно дать вам хороший результат, сначала пусть это работает.

Затем пришло время для некоторых настраиваемых аспектов, позволяющих выбрать узел через файл cookie, а также, при необходимости, отправить IP-адрес, который вы можете использовать для переопределения DNS, если вы, например, хотите проверить путь через пассивный центр обработки данных. Для этого мы напишем небольшую оболочку сценария оболочки вокруг check_http, которая будет принимать один параметр в качестве имени хоста внутреннего узла (для удобства давайте использовать то, что icinga считает именем хоста) и необязательный параметр, переопределяющий IP проверяемого сервера (в обход DNS-поиска). Все это приводит к тому, что сценарий оболочки выглядит примерно так (я предлагаю поместить его в / usr / lib64 / nagios / plugins / и chown, chmod его в соответствии с другими плагинами):

#/bin/bash

if [  -z "$1" ]
  then
    echo "Usage: $0 host-name [haproxy-ip]"
  exit 2
fi

if [[ $# -eq 2 ]]; then
    APPEND_OPTS=" -I $2"
fi

#Map icinga/nagios host names to haproxy node names in case these differ and you don't want to expose them on the internetz
declare -A nodes
nodes=(["webA1"]="S1"
        ["webA2"]="S2"
        ["webB1"]="S3"
        ["webB2"]="S4")
node=${nodes["$1"]}


/usr/lib64/nagios/plugins/check_http -P "<echo>Hello</echo>" -r 'Hello' -k "Cache-Control: no-cache" -k "Pragma: no-cache" -k "Content-Type: text/xml; charset=UTF-8" -k "Accept: text/xml" -S -H example.com -p 443 -u /service -t 3 -k "Cookie: SERVERID=$node" $APPEND_OPTS

Обратите внимание, что SERVERID - это имя файла cookie, установленного в haproxy.

Как только это будет сделано, вы можете определить свои команды проверки nagios следующим образом:

#Check path through av A fw and haproxy
define command{
        command_name    check_node_external_a
        command_line    $USER1$/check_node '$HOSTNAME$' '<A external IP>'
        }

Где check_node - это имя сценария оболочки, а «Внешний IP-адрес» - это IP-адрес, используемый для доступа к системе в центре обработки данных A.

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