Мониторинг активности хостов::Журнал СА 12.2008
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 4346
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 5646
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 6875
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7270
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6342
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Мониторинг активности хостов

Архив номеров / 2008 / Выпуск №12 (73) / Мониторинг активности хостов

Рубрика: Администрирование /  Продукты и решения

Антон Борисов

Мониторинг активности хостов

Довольно часто возникают ситуации, когда необходимо производить мониторинг серверов или рабочих станций. И не просто иметь сведение о том, что конкретный хост выключен в данный момент, а иметь на руках статистические данные за определенный период.

Быстро узнать, включен ли определенный хост в нашей локальной сети, очень просто – достаточно запустить команду ping до этого хоста и посмотреть результат. Как правило, машина бывает включена и охотно откликается на запросы.

$ ping 10.66.2.1

PING 10.66.2.1 (10.66.2.1) 56(84) bytes of data.

64 bytes from 10.66.2.1: icmp_seq=1 ttl=61 time=0.227 ms

64 bytes from 10.66.2.1: icmp_seq=2 ttl=61 time=0.228 ms

64 bytes from 10.66.2.1: icmp_seq=3 ttl=61 time=0.225 ms

64 bytes from 10.66.2.1: icmp_seq=4 ttl=61 time=0.230 ms

64 bytes from 10.66.2.1: icmp_seq=5 ttl=61 time=0.227 ms

64 bytes from 10.66.2.1: icmp_seq=6 ttl=61 time=0.244 ms

64 bytes from 10.66.2.1: icmp_seq=7 ttl=61 time=0.229 ms

 

--- 10.66.2.1 ping statistics ---

7 packets transmitted, 7 received, 0% packet loss, time 5997ms

rtt min/avg/max/mdev = 0.225/0.230/0.244/0.005 ms

Естественно, что мы доверяем всем рабочим хостам в нашей локальной сети, и firewall пропускает ICMP Echo-запросы, на которые опирается при своей работе команда ping. Проверить определенный сервис, «висящий» на определенном порту, также не составляет труда.

$ telnet 10.66.2.1 22

Trying 10.66.2.1...

Connected to 10.66.2.1.

Escape character is '^]'.

SSH-2.0-dropbear_0.49

 $ telnet 10.66.2.1 80

Trying 10.66.2.1...

Connected to 10.66.2.1.

Escape character is '^]'.

GET / HTTP/1.0

 

HTTP/1.1 200 OK

Server: nginx/0.7.13

Date: Thu, 30 Oct 2008 16:06:50 GMT

Content-Type: text/html

Content-Length: 151

Last-Modified: Mon, 01 Sep 2008 13:04:23 GMT

Connection: close

Accept-Ranges: bytes

 

<html>

<head>

<title>Welcome to nginx!</title>

</head>

<body bgcolor="white" text="black">

<center><h1>Welcome to nginx!</h1></center>

</body>

</html>

Connection closed by foreign host.

Впрочем, это прописные истины. Проблемы возникают при необходимости не только контролировать большой парк ЭВМ и серверов, но и определять, а правильно ли работает сервис. Что если хост откликается на 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

Рисунок 1. Определяем подсеть класса A

Запустить NetWhistler с администраторскими правами, просканировать сеть и сохранить карту в нужный каталог. Далее загружать уже готовую карту, но с правами обычного пользователя.

  •  -a – показывать хосты, которые активны в настоящий момент;
  •  -r 1 – количество отправленных пакетов к определенному хосту;
  •  -e – показывать затраченное время при получении пакета от хоста;
  •  -t 1 – используемый тайм-аут при отправке пакета (в миллисекундах).

Пользователь с обычными (не суперпользовательскими правами) не может использовать время тайм-аута меньше 50 мс.

Итак, карта готова. Теперь нужно определиться, какие сервисы мы хотим контролировать на хосте.

Щелкаем на пиктограмме хоста, затем «Properties -> Services». Из списка выбираем нужную для контроля службу: FTP, SSH, SMTP, POP3, IMAP, SAMBA или CITRIX. К сожалению, добавить другую службу, помимо указанных, не представляется возможным.

Аналогично выставляем параметры для всех хостов и включаем мониторинг – «Monitoring -> Start Monitoring». Опрашиваются все машины, а также контролируемые сервисы. И видим, что у нас происходит в локальной сети. В частности, все узлы включены и работают нормально, кроме 10.66.2.250 и 10.66.2.2. Причем первый выключен, а на втором не работает веб-сервер (см. рис. 2).

Рисунок 2. Проблемные хосты или службы выделяются красным цветом

Рисунок 2. Проблемные хосты или службы выделяются красным цветом

Просмотреть произошедшие события можно, переключаясь между режимами просмотра: Topology View, Status View, Interface View, Events View и Graph View. В частности, в последнем режиме можно наглядно убедиться, каков процент «выживаемости» на текущий момент (см. рис. 3).

Рисунок 3. Визуальная карта позволяет оценить масштабы аварии

Рисунок 3. Визуальная карта позволяет оценить масштабы аварии

По мере возникновения ошибки существует возможность просигнализировать оператору об аварии. Либо визуально, показав окно предупреждения с проблемным хостом, либо отправив e-mail или же запустив внешнюю команду. Настройки параметров в закладке «Edit -> Options -> Alerts» (см. рис. 4).

Рисунок 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

Got answer from: 192.168.0.203

где, 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

08:59:35 icmp-echo-alarm "Host-51" "DOWN"

09:00:05 icmp-echo-alarm "Host-51" "DOWN"

09:00:35 icmp-echo-alarm "Host-51" "DOWN"

09:01:05 icmp-echo-alarm "Host-51" "DOWN"

09:01:35 icmp-echo-alarm "Host-51" "DOWN"

09:02:05 icmp-echo-alarm "Host-51" "DOWN"

09:02:35 icmp-echo-alarm "Host-51" "DOWN"

09:03:11 icmp-echo-alarm "Host-51" "DOWN"

09:03:47 icmp-echo-alarm "Host-51" "DOWN"

09:04:17 icmp-echo-alarm "Host-51" "UP"

Рабочая станция включена в 09:04:17. И до сих пор не выключена. Как только произойдет перезагрузка либо выключение, то в лог-файле появится отметка – DOWN.

Так как для этого объекта мы заказывали получение статистики еще и по предоставляемому сервису VNC, то найти его вы можете в директории /var/netmon/Host‑51/vnc/[ДатаФайла]. Структура лог-файла такая же, что и для всего объекта Host-51:

 

09:34:29 icmp-echo-alarm "vnc" "UP"

09:39:00 icmp-echo-alarm "vnc" "DOWN"

09:40:00 icmp-echo-alarm "vnc" "UP"

09:58:00 icmp-echo-alarm "vnc" "DOWN"

09:59:00 icmp-echo-alarm "vnc" "UP"

 

Просмотреть состояние мониторинга в реальном времени можно следующим образом – подключаемся к консоли управления (мы ее активизировали для групп local и remote на порту 3333) и вводим название объекта, который нам интересен.

$ telnet 127.00.00.1 3333

 

Trying 127.0.0.1...

Connected to localhost.lib.

Escape character is '^]'.

NetState server ready (timeout 30 sec.)

Compress: ZLIB 1.2.3

!

Object Host-51

!OBJECT

Host-51!NAME = "Host-51"

Host-51!ADDRESS = "192.168.0.51"

Host-51!POLLING = 60

Host-51!TIMEOUT = 2

Host-51!RETRIES = 3

Host-51!SAVING = 300

Host-51!DATADIR = "/var/netmon/Host-51"

Host-51!STATE = "UP"

Host-51!QUERYTIME = 1225454401

Host-51!REPLYTIME = 1225454401

Host-51!LASTCHANGE = 1225433058

Host-51!HOPCOUNT = 1

Host-51!PING = 14

Host-51!PING.ok = 1

Host-51!PING.send = 1

Host-51!PING.recv = 1

 

Так, эта рабочая станция включена. Проверим объект Unit1. Набираем в консоли Object Unit1 для просмотра информации.

 

Unit1!NAME = "Unit1"

Unit1!ADDRESS = "192.168.0.101"

Unit1!POLLING = 60

Unit1!TIMEOUT = 2

Unit1!RETRIES = 3

Unit1!SAVING = 300

Unit1!DATADIR = "/var/netmon/Unit1"

Unit1!STATE = "DOWN"

Unit1!QUERYTIME = 1225454852

Unit1!LASTCHANGE = 1225454852

 Unit1!PING = "Host is down"

Unit1!PING.ok = 0

Unit1!PING.send = 0

Unit1!PING.recv = 0

Вывод – указанный объект выключен.

Чтобы просмотреть всю информацию, включая параметры объектов, текущее время и внутренние переменные, можно воспользоваться командой:

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

 

Trying 192.168.1.1...

Connected to 192.168.1.1.

Escape character is '^]'.

BCM96338 ADSL Router

(none) login: admin

Password:

 

BusyBox v1.00 (2005.04.12-18:11+0000) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

Выясняется, что это Linux-система, подобная тем, что у многих используется в качестве сервера.

# cat /proc/uptime

12501.58 12042.20

Даже узнать uptime не составляет большого труда.

Впрочем, как и запущенные процессы.

# ps afx

  PID  Uid     VmSize Stat Command

    1 admin       220 S   init              

    2 admin           SW< [ksoftirqd/0]

    3 admin           SW< [events/0]

    4 admin           SW< [khelper]

    5 admin           SW< [kblockd/0]

    6 admin           SW  [pdflush]

    7 admin           SW  [pdflush]

    8 admin           SW  [kswapd0]

    9 admin           SW< [aio/0]

   10 admin           SW  [mtdblockd]

   17 admin       292 S   -sh

  120 admin       164 S   pvc2684d

  166 admin       188 S   igmp lo

  225 admin       408 S   telnetd

  229 admin       144 S   bftpd

  233 admin       212 S   tftpd

  237 admin       608 S   snmp

  258 admin       680 S   httpd

  263 admin       264 S   pppd -c 1.32.1 -i nas_1_32 -u 100101 -p ******* -f 0

 2405 admin       188 S   /bin/dnsprobe

 2409 admin       240 S   upnp -L br0 -W ppp_1_32_1 -D

15441 admin       300 S   -sh

15448 admin       256 R   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

Рисунок 5. Узлы импортированы из работающего сервера netmond

Можно подписать узлы, для которых требуется расшифровка и приступить к следующему шагу. А именно: включить визуализацию – кнопку «Monitoring -> Update».

Теперь все узлы, что активны, обозначены зеленым цветом, проблемные – красным (см. рис. 6).

Рисунок 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 за помощь при подготовке материала.

  1. http://netwhistler.sourceforge.net/downloads.shtml.
  2. http://vfom.narod.ru/TkNetmon/index.html.
  3. http://neon.heavennet.ru/netmond_rrdtool.html.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru