 |
|
|
|
Мониторинг активности хостов
Мониторинг активности хостов Довольно часто возникают ситуации, когда необходимо производить мониторинг серверов или рабочих станций. И не просто иметь сведение о том, что конкретный хост выключен в данный момент, а иметь на руках статистические данные за определенный период. Быстро узнать, включен ли определенный хост в нашей локальной сети, очень просто – достаточно запустить команду ping до этого хоста и посмотреть результат. Как правило, машина бывает включена и охотно откликается на запросы. $ ping 10.66.2.1
Естественно, что мы доверяем всем рабочим хостам в нашей локальной сети, и firewall пропускает ICMP Echo-запросы, на которые опирается при своей работе команда ping. Проверить определенный сервис, «висящий» на определенном порту, также не составляет труда. $ telnet 10.66.2.1 22
$ telnet 10.66.2.1 80
Впрочем, это прописные истины. Проблемы возникают при необходимости не только контролировать большой парк ЭВМ и серверов, но и определять, а правильно ли работает сервис. Что если хост откликается на ping, Apache, работающий на этом же хосту правильно отдает документы, а вот зайти, например, по протоколу SSH нельзя? Можно ли отслеживать в автоматическом режиме указанные сбои? Оказывается, можно. «Свистать всех наверх!» – Mila NetWhistler Элегантной и в то же время простой кажется разработка Александра Еремина под названием Mila NetWhistler. Это Java-приложение с обвязкой в виде fping (fast ping), traceroute, nmap и SNMP-утилит. В последней выпущенной версии 2.10 также есть возможность взаимодействия с MRTG. На данный момент NetWhistler может функционировать на следующих платформах: Linux, *BSD, Solaris, OpenVMS. Поддержка для Windows также задекларирована, но последняя рабочая версия, которую удалось найти под эту платформу, – это 2.6. Она вполне работоспособна, единственное, что в ней отсутствует, поддержкаMRTG и вместо fping используется обычный, привычный ping. Давайте рассмотрим на примере openSUSE 10.3, Sun JRE 1.5 и NetWhistler 2.10 [1], как построить карту сети. Установим пакет от имени суперпользователя: # chmod +x ./netwhistler2.10.bin # ./netwhistler2.10.bin И запускаем с правами обычного пользователя: $ /usr/local/netwhistler/netwhistler.sh Создаем описание новой сети, в данном случае подсеть класса A – 10.66.2.0/24 (см. рис. 1). И разрешаем программе самостоятельно определить количество хостов, работающих в данной сети, – нажимаем кнопку Discover. И убеждаемся, что ничего не обнаружено. Странно, но мы точно знаем, что рабочие машины есть. Что делать в этом случае?
Рисунок 1. Определяем подсеть класса A Запустить NetWhistler с администраторскими правами, просканировать сеть и сохранить карту в нужный каталог. Далее загружать уже готовую карту, но с правами обычного пользователя.
Пользователь с обычными (не суперпользовательскими правами) не может использовать время тайм-аута меньше 50 мс. Итак, карта готова. Теперь нужно определиться, какие сервисы мы хотим контролировать на хосте. Щелкаем на пиктограмме хоста, затем «Properties -> Services». Из списка выбираем нужную для контроля службу: FTP, SSH, SMTP, POP3, IMAP, SAMBA или CITRIX. К сожалению, добавить другую службу, помимо указанных, не представляется возможным. Аналогично выставляем параметры для всех хостов и включаем мониторинг – «Monitoring -> Start Monitoring». Опрашиваются все машины, а также контролируемые сервисы. И видим, что у нас происходит в локальной сети. В частности, все узлы включены и работают нормально, кроме 10.66.2.250 и 10.66.2.2. Причем первый выключен, а на втором не работает веб-сервер (см. рис. 2).
Рисунок 2. Проблемные хосты или службы выделяются красным цветом Просмотреть произошедшие события можно, переключаясь между режимами просмотра: Topology View, Status View, Interface View, Events View и Graph View. В частности, в последнем режиме можно наглядно убедиться, каков процент «выживаемости» на текущий момент (см. рис. 3).
Рисунок 3. Визуальная карта позволяет оценить масштабы аварии По мере возникновения ошибки существует возможность просигнализировать оператору об аварии. Либо визуально, показав окно предупреждения с проблемным хостом, либо отправив e-mail или же запустив внешнюю команду. Настройки параметров в закладке «Edit -> Options -> Alerts» (см. рис. 4).
Рисунок 4. Сообщить об аварии можно несколькими способами Какие присутствуют концептуальные особенности у данного решения? Во-первых, необходимость держать приложение в активном состоянии. Из-за того, что нет разбиения на серверную часть (в виде демона или службы) и графическую часть, которая непосредственно занимается отображением. Во-вторых, необходимость установленной Java-машины. И в-третьих, нет возможности контролировать произвольные порты, т.к. предлагаются к использованию только те, что «зашиты» в программу. А так, впечатление производит достойное. На поле действия выходит дилер. Сетевой Так как желание увидеть решение в классическом варианте, когда программа разбита на 2 части, серверную и клиентскую, вполне логично, то предлагаю обратить ваше внимание на netmond – Network Monitor Dealer. Программа предназначена для запуска в UNIX-средах, в частности в линейке FreeBSD, где с 2006 года находится в дереве портов – /usr/ports/net-mgmt/netmond. # cd /usr/ports/net-mgmt/netmond # make && make install && make clean Организуем автоматический старт netmond при загрузке системы – добавляем в /etc/rc.conf строчку: netmond_enable="YES" И займемся теперь составлением конфигурации – файл /usr/local/etc/netmond.conf. Итак: 1) RootDir "/var/netmon" 2) Polling 60 3) Timeout 2 4) Retries 3 5) Saving 300 6) TimeFmt "%H:%M:%S" В строке 1 объявляем директорию, где будут храниться логи программы. Опрос хостов производится каждые 60 секунд (строка 2), но не чаще, чем через 30 секунд. Будет произведено 3 опроса (строка 4) с тайм-аутом в 2 секунды (строка 3) для каждого объекта, который мы укажем чуть позднее. Сброс статистики, т.е. сохранение лог-файлов, происходит раз в 300 секунд (строка 5). Формат времени для записи события указан в строке 6. 7) Group "local" { # Разрешить хосту с DNS-именем localhost 8) Permit "^localhost$" # Рарешить хосту по IP-адресу 9) Permit "^127\\.0\\.0\\.1$" # запретить всем – по умолчанию 10) Deny ".*" 11)} В строках 7-11 объявляется группа доступа local для просмотра событий: 12) Group "remote" { 13) Permit "^192\\.168\\.1\\.*" 14)} И объявляется также группа remote, владельцы которой (а именно, сеть 192.168.1.0/24), смогут также подключаться к консоли управления и просматривать события. 15) NetState { # NetState server port number (mandatory) 16) Port 3333 # Client timeout (optional) 17) Timeout 30 # The number of Group references is unlimited 18) Group "local" # Match is done from top to bottom 19) Group "remote" 20)} Собственно включаем консоль управления на порту 3333 и разрешаем членам групп local и remote подключаться для анализа событий. Затем мы производим объявление различных методов контроля, по сути, мы создаем различные алгоритмы опроса портов. 21) Method "http" { 22) tcp port 80 23) ChatScript { 24) Send "GET $1 HTTP/1.0\r\n\r\n" 25) Expect "^HTTP/1.1 200 OK$" 26) } 27)} В строках 21-27 создаем метод с названием http для опроса порта 80. Фактически при вызове метода происходит следующее: хосту на порт 80 отправляется запрос в виде «GET $1 HTTP/1.0», где вместо параметра $1 будет выступать адрес документа. Например, /index.html. Если хост отвечает «HTTP/1.1 200 OK», т.е. документ /index.html найден и ошибок при его получении нет (статус ответа 200), то будет считаться, что сервис веб-службы работает без ошибок. 28) Method "pop3" { 29) tcp port 110 30) ChatScript { Send "" Expect "^\\+OK " Send "QUIT\r\n" Expect "" } 31)} Аналогичная ситуация для проверки POP3-сервиса (строки 28-31). Хосту на порт 110 ничего не отсылается, но проверяется, чтобы при подключении была выдана строка «+OK», что означало бы, что POP3-сервис работает. Затем отсылается комнада QUIT, сигнализирующая POP3-службе об отключении клиента, т.е. нашего запроса. 32) Method "smtp" { 33) tcp port 25 34) ChatScript { Send "" Expect "^220-" Send "QUIT\r\n" Expect "" } 35)} Строки 32-35 объявляют метод smtp, для проверки SMTP-службы. 36) Method "ftp" { 37) tcp port 21 38) ChatScript { Send "" Expect "^220 " Send "QUIT\r\n" Expect "" } 39)} И затем идет объявление метода для проверки уже FTP-службы. Проверяется, выдает ли хост на порту 21 строку, например «220 (vsFTPd 2.0.5)». Что означало бы, что FTP-служба активна. 40) Method "ssh" { 41) tcp port 22 42) ChatScript { Send "" Expect "^SSH-" Send "QUIT\r\n" Expect "" } 43)} Вы можете проследить аналогию также и для проверки SSH в методе ssh. Ожидается, что хост на порту 22 будет отдавать нечто похожее на «SSH-2.0-OpenSSH_4.6». На самом деле нас не интересует, как полностью выглядит строка ответа, главное, чтобы она начиналась на «SSH-». 44) Method "vnc" { 45) tcp port 5900 46) ChatScript { Send "" Expect "^RFB" Send "\r\n\r\n\r\n\r\n\r\n\r\n" } 47)} И затем мы делаем еще одно объявление, которое позволит нам мониторить VNC-службу, строки 44-47. Для сведения – чтобы осуществлять проверку работы сервисов, использующих SSL (например, HTTPS/SMTPS/IMAPS), вам придется отказаться от схемы с ChatScript. И производить вызов внешней UNIX-утилиты (под названием openssl), используя метод Exec (о нем расскажем чуть позже) в netmond.После этого мы должны организовать обработку событий, т.е. что делать с данными сигнализации. Отсылать по почте, сохранять в файл или что-то еще. 48) Save "change-state-alarm" { 49) Pipe "mail -s \"$0\" root" 50) State "$time $1 $name $state" 51)} В строках 48-51 объявляем обработчик change-state-alarm, который при наступлении события будет отсылать почту абоненту root, с темой письма, взятого из параметра $0. В письме будет содержаться строка вида: «10:23:45 icmp-echo-alarm "DHCP-Server1" "UP"». 52) Save "icmp-echo-alarm" { 53) File "%Y.%m.%d" 54) State "$time $0 $name $state" 55) } Обработчик icmp-echo-alarm будет сохранять изменения в файл, в отличие от рассмотренного выше. Формат файла – год, месяц, день. Например, так – 2008.10.29. Чтобы определить, активен ли сервис DHCP как таковой, стоит вызывать утилиту dhcping, например, так: dhcping -s 192.168.0.203 -c 192.168.0.201 -v -i
где, 192.168.0.203 – DHCP-сервер, а 192.168.0.201 – адрес сервера, откуда происходит мониторинг. Сам вызов утилиты «завернуть» в обертку метода Exec. И наконец приступаем к определению объектов, которые будем мониторить. В строке 56 указываем название объекта – DHCP-Server1. Именно с таким названием в /var/netmon будет создана поддиректория, хранящая записи о событиях с хоста. В строке 57 прописываем IP-адрес хоста и вызываем встроенный метод ping (строка 58). Это необходимо сделать для того, чтобы netmond определил для своих внутренних целей первоначальное состояние объекта – либо он включен (состояние UP), либо выключен (DOWN). В строке 59 указываем, что будет вызываться обработчик «icmp-echo-alarm» для всего объекта. И в строках 60-63, 64-67 используем 2 метода контроля хоста – соответственно для POP3-службы и веб-сервера. 56) Object "DHCP-Server1" { 57) Address "192.168.0.201" 58) Method Ping 59) Save "icmp-echo-alarm" "DHCP-Server1 ping" 60) Service "pop3" { 61) Method "pop3" 62) Save "icmp-echo-alarm" "DHCP-Server1 pop3" 63) } 64) Service "http" { 65) Method "http" "/index.html" 66) Save "icmp-echo-alarm" "DHCP-Server1 http" 67) } 68)} В качестве проверки работоспособности веб-службы будем проверерять доступность файла /index.html на объекте DHCP-Server1. Добавим еще один объект – Unit1. Его проверка будет заключаться в получении отклика по ICMP-протоколу. 69) Object "Unit1" { 70) Address "192.168.0.101" 71) Method Ping 72) Save "icmp-echo-alarm" "Unit1 ping" 73)} И добавляем рабочую станцию (Host-51), где помимо информации, включена она или нет, нас еще будет интересовать, а запущен ли на ней VNC-сервер. 74) Object "Host-51" { 75) Address "192.168.0.51" 76) Method Ping 77) Save "icmp-echo-alarm" "Host-51 ping" 78) Service "vnc" { 79) Method "vnc" 80) Save "icmp-echo-alarm" "Host-51 vnc" 81) } 82)} Теперь запускаем сервер netmond и ждем, пока не накопится статистика. Которая, как вы помните, складируется в /var/netmon/. Посмотрим, что у нас получилось: # tail -f /var/netmon/Host-51/2008.10.31
Рабочая станция включена в 09:04:17. И до сих пор не выключена. Как только произойдет перезагрузка либо выключение, то в лог-файле появится отметка – DOWN. Так как для этого объекта мы заказывали получение статистики еще и по предоставляемому сервису VNC, то найти его вы можете в директории /var/netmon/Host‑51/vnc/[ДатаФайла]. Структура лог-файла такая же, что и для всего объекта Host-51:
Просмотреть состояние мониторинга в реальном времени можно следующим образом – подключаемся к консоли управления (мы ее активизировали для групп local и remote на порту 3333) и вводим название объекта, который нам интересен. $ telnet 127.00.00.1 3333
Так, эта рабочая станция включена. Проверим объект Unit1. Набираем в консоли Object Unit1 для просмотра информации.
Вывод – указанный объект выключен. Чтобы просмотреть всю информацию, включая параметры объектов, текущее время и внутренние переменные, можно воспользоваться командой: any :* Так же, как и в NetWhistler, есть возможность реагировать на события, т.е. не только выдавать сообщения в лог-файл, а также отсылать email, но и запустить исполнение собственного скрипта. Посмотрим на пример: Save "down-alarm" { Exec "/root/system/pager.sh" When "$state == \"DOWN\"" 300 "$1 $name $state 5 minutes" } Если хост будет в нерабочем состоянии более 5 минут, то сигнализация запустит скрипт /root/system/pager.sh с параметрами даты, имени объекта и его состояния. Сравните со строками 48-51, которые мы рассмотрели выше. Организуем авторестарт узла Предположим, что у нас есть DSL-модем, который необходимо мониторить, в силу его не всегда правильного поведения, т.е. отслеживать ситуации, когда он на самом деле-то работает, только вот из внешней сети до него не достучаться. В качестве такого оригинального прибора пусть будет выступать D-Link 2500U. Чем он характерен? Тем, что у него есть веб-интерфейс управления и возможность зайти на него с помощью telnet. $ telnet 192.168.1.1
Выясняется, что это Linux-система, подобная тем, что у многих используется в качестве сервера. # cat /proc/uptime
Даже узнать uptime не составляет большого труда. Впрочем, как и запущенные процессы. # ps afx
Казалось бы, UNIX-система обязана работать долго и не требовать к себе особенного внимания. Однако практика доказывает (в данном конкретном случае) обратное, и выяснять, кто прав, а кто виноват – изготовитель модема или провайдер услуг – в случае потери связи не особенно хочется. Решение, как всегда, кроется на поверхности – нужно перезапустить модем. Сказано – сделано. Если рядом находится оператор, то никаких сложностей нажать на кнопку нет. Теперь представьте, что это автоматизированный комплекс, лишних рук просто нет. Что делать? Попытаться зайти автоматически в модем. Есть замечательная утилита под названием expect. Её помощью и воспользуемся. Составляем скрипт pager.sh: 1) #!/usr/local/bin/expect -f
2) set host 192.168.1.1 3) set user username_to_login 4) set pass password_to_login
5) spawn telnet "$host" 6) expect "login:" 7) send "$user\r" 8) expect "word:" 9) send "$pass\r"
10) expect "#" 11) send "ifconfig\r"
12) send "exit\r" 13) interact В строке 1 указываем название командного интерпретатора, в нашем случае expect. Выставляем значения переменных host, user, pass для доступа к D-Link (строки 2-4). Запускается внешнее приложение telnet (строка 5), программа ждет, пока не появится приглашение от D-Link в виде строки «login:» (строка 6), затем будет передано имя пользователя (строка 7). Аналогично реализовано для передачи пароля (строки 8-9). Ждем приглашения операционной системы D-Link и запрашиваем статистику по внутренним интерфейсам (строки 10-11). Затем завершаем сеанс и выходим из программы (строки 12-13). Просто и понятно. Если нас интересует все-таки возможность перезагрузки модема, то вместо получения статистики (строка 11) логично запустить D-Link через команду reboot. Новая строка выглядит как: send "reboot\r" На этом можно было бы успокоиться, настроить мониторинг какого-либо хоста на стороне провайдера и в случае пропадания связи запускать pager.sh. Оказалось, что в данном конкретном случае reboot не работает для D-Link 2500U и необходимо перезапускать через веб-интерфейс, что, как понимаете, возможно лишь из локальной сети этого модема. Либо вручную. Но последнее условие мы и хотели обойти автоматизацией процесса. Тупик? Вовсе нет. Несмотря на то, что в этом D-Link используется веб-сервер с авторизацией, есть все же возможность его перезагрузки. Не будем ходить вокруг да около, приступаем. # cat /root/system/pager2.sh #!/bin/sh REBOOT_TEXT=/root/system/modem_reboot.txt NC=/usr/bin/nc CAT=/bin/cat $CAT $REBOOT_TEXT | $NC 192.168.1.1 80 С помощью netcat присоединяемся к 80-му порту модема. И передаем текст: # cat /root/system/modem_reboot.txt GET /rebootinfo.cgi HTTP/1.1 Host: localhost Authorization: Basic aGVsbG86dGhlcmUK Который на самом-то деле запускает скрипт rebootinfo.cgi на стороне веб-сервера D-Link. Этот скрипт и перезапустит сам модем. А чтобы обойти интерактивный ввод данных авторизации для веб-сервера, мы добавили строку: «Authorization: Basic aGVsbG86dGhlcmUK», где строка после слова Basic является mime64-кодировкой имени пользователя и пароля. Чтобы получить ваш собственный кодированный текст, делайте так: $ echo «username_to_login:password_to_login» | base64 Проверяете – работает как часы. Теперь, как только перестает отвечать хост провайдера, например, в течение 5 минут DNS-сервер, это будет означать, что модем «споткнулся» на ровном месте и требуется его перезагрузка, которую мы и можем организовать, используя возможность запуска внешних скриптов – вызов Exec в netmond. Отлично, вручную мы знаем, как получить данные. Теперь хотелось бы пощелкать мышкой, чтобы получить те же данные в красивом виде. Как вы догадались, мы переходим к клиентской части «сетевого дилера». Визуализация происходит с помощью пакетов Tcl/Tk, TkTables, BLT и, если требуется, пакетов tcl-sql и snack. Последние два нужны прежде всего для возможности сохранять логи в SQL-базу и звукового оповещения статуса узлов. # cd /usr/ports/net-mgmt/tknetmon/ # make && make install && make clean Так получается, что и сам сервер netmond, и его клиентскую часть (TkNetmond) мы собрали на одном и том же узле управления. Но картинку мы хотим наблюдать на своем рабочем месте. Сделаем перенаправление экрана на свою машину и запустим визуализатор: $ export DISPLAY=myIP:0 $ wish8.4 /usr/local/lib/TkNetmon-2.0.7a/TkNetmon.tcl Получили незаполненную карту. Дальше можно вручную внести необходимые для контроля узлы на карту либо импортировать все узлы, что хранятся в работающем сервере netmond. Для последнего случая отправляетесь в меню Edit и нажимаете Discover NetState Server. Пара мгновений – и карта заполнена (см. рис. 5).
Рисунок 5. Узлы импортированы из работающего сервера netmond Можно подписать узлы, для которых требуется расшифровка и приступить к следующему шагу. А именно: включить визуализацию – кнопку «Monitoring -> Update». Теперь все узлы, что активны, обозначены зеленым цветом, проблемные – красным (см. рис. 6).
Рисунок 6. Хост на момент проверки выключен Карту можно загрузить и из файла конфигурации netmond, если он будет соответствовать «стилю» TkNetmon. «Стиль» состоит в том, что все директивы должны быть в «правильном» виде – для программы Object и OBJECT – разные команды. Первую он поймет и исполнит, вторую – не поймет. Ка должны выглядеть «правильные» директивы – можно посмотреть в файле lib/LoadFile.tcl. Там все директивы – это названия подпрограмм. Что делать, если запускать TkNetmon вы хотите с рабочего места, а не с сервера *BSD, ситуацию с котрым мы только что рассмотрели? Установить указанные выше пакеты! С единственным исключением – пакет sql-tcl вы, скорее всего, не сможете скомпилировать из-за очевидной его древности (последнее его обновление – 2001 год). С текущей, распространенной версией MySQL 5 он просто-напросто не соберется. В этом случае стоит убрать возможность хранения логов в SQL-базе. Закомментируйте строчки вызова процедуры EventsLog в файле TkNetmon.tcl (строки 681, 1598), lib/EventsLog.tcl (строка 809) и вызов пакета sql в lib/Sql.tcl (строка 10) и в lib/EventsLog.tcl (строка 31). Серверная часть этого решения, т.е. непосредственно сборщик данных, портированы в следующие ОС: FreeBSD, Linux, Solaris. Насчет Win32/Win64-окружения текущий разработчик дал такой ответ – «вероятность портирования близка к 0». Что касается клиентской части под Windows, то все «комплектующие» под эту систему есть: Tcl/Tk, TkTables, BLT. Так что вероятность запуска в последнем случае будет значительно выше 0. В заключение хотелось бы поблагодарить Виктора Фомичева, текущего разработчика проекта netmond и TkNetmod за помощь при подготовке материала. |
Антон Борисов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
