|
Netmond V2. Примеры конфигурацииВ этом документе приводится несколько принципиальных приемов по настройке конфигурации Netmond с краткими пояснениями по тексту.
Проверка качества связи с хостомПроверка наличия и качества связи с удаленным хостом в сети обычно заключается в простом тестировании коннективити с помощью системной утилиты ping. При этом оценивается время отклика и процент отвеченных пакетов определенного размера в серии из нескольких десятков пакетов. Сначала продекларируем метод тестирования с определенными параметрами, что-бы его можно было потом использовать многократно для разных хостов в сети: RootDir "/var/netmon"
Polling 120 # каждые пару минут
TimeFmt "%H:%M:%S" # формат вывода $TIME
Method "test" {
ICMP # используем ICMP-echo а-ля ping
Size 512 # пакеты по 512 байт
Send 10 # последовательно 10 контрольных запросов
Timeout 1 # каждый отклик ждем не более секунды
Retries 1 # переповторов не делаем
}
Обьявим и подходящий метод сохранения, который будет сообщать нам об изменениях в состоянии хостов в сети с результатами контрольных замеров: Save "test" {
Pipe "mail2staff" # эта програмка будет извещать нас почтой
State "$TIME $Name $STATE $test.send/$test.recv $test"
# пример: "14:20:00 host-1 UP 10/10 15.432"
}
Теперь применим эти методы на тестирумых хостах в сети: Object "host-1" {
Address "host.foo.bar"
Method "test"
Save "test"
}
Напомним, что не везде в сети обязательно должны проходить пакеты ICMP-echo, кое-где они могут оказаться зафильтрованы промежуточными роутерами или файрволами. Опрос обьекта методом Remote ShellРешая задачу мониторинга загрузки серверов на сети мы можем воспользоваться удаленным вызовом штатной Unix-команды uptime. Сначала продекларируем метод опроса что-бы его можно было потом использовать многократно для разных обьектов в сети. В аргументе будем передавать имя пользователя, так как на разных серверах они могут быть разными: RootDir "/var/netmon"
Polling 60 # раз в минуту
Method "get-loadave" {
TCP Port 514 # стандартный tcp порт сервера rshd
Localport 512 1023 # локальный порт должен быть в этом диапазоне
ChatScript {
Send "0" # поток stderr не используется
Send "$1" # тут будет локальное имя пользователя
Send "$1" # удаленное имя пользователя такое же
Send "uptime" # выполнить эту команду на удаленном сервере
Expect "^$" # ожидать 0 (так работает rsh протокол)
Expect "averages: ([0-9]+\.[0-9]*)" # найти нужные цифры в ответе
{ $LoadAve } # и положить их в эту переменную
}
}
Обьявим и подходящий метод сохранения, который проверит величину текущей загрузки и сообщит нам когда она слишком велика. В аргументе будем передавать ее критическую величину, так как для разных серверов она может быть разной. Save "check-loadave" {
Pipe "mail2staff" # эта програмка будет извещать нас почтой
When "$LoadAve >= $1" # проверим величину загрузки
180 # условие должно выполняться не менее 3мин.
"$Name too heave loaded: $LoadAve" # такой текст придет в письме
}
Теперь применим это все на серверах, которые мы мониторим по загрузке: Object "server-1" {
Address "host.foo.bar"
Method "get-loadave" "john" # на этот сервер ходить под именем john
Save "check-loadave" "3.5" # проверим загрузку на эту величину
}
Кроме этого, на каждом обьекте автоматически возникнет переменная с именем метода опроса - $get-loadave, которая будет содержать строку диагностики последней попытки запроса. И при выполнении нашего условия на обьекте также возникнет переменная $WHEN, содержащая ту самую строку вывода текста. Возможно эти переменные нам пригодятся для внешних интерфейсных программ, работающих с Netmond по NetState протоколу. Напомним, что на соответствующих серверах нужно настроить удаленное выполнение команд под определенным пользователем так, что-бы Netmond мог к ним обращаться. Мониторинг сетевых сервисовПрежде всего опишем простые сценарии для тестирования типовых сервисов в сети: RootDir "/var/netmon"
Polling 60
TimeFmt = "%H:%M:%S"
Method "ftp" {
TCP Port 21
ChatScript { Send "" Expect "^220 " Send "QUIT\r\n" Expect "" }
}
Method "ssh" {
TCP Port 22
ChatScript { Send "" Expect "^SSH-" Send "QUIT\r\n" Expect "" }
}
Method "smtp" {
TCP Port 25
ChatScript { Send "" Expect "^220-" Send "QUIT\r\n" Expect "" }
}
Method "pop3" {
TCP Port 110
ChatScript { Send "" Expect "^\\+OK " Send "QUIT\r\n" Expect "" }
}
Method "http" {
TCP Port 80
ChatScript {
Send "GET $1 HTTP/1.0\r\n\r\n" # в $1 будет имя документа
Expect "^HTTP/1.1 200 OK$"
}
}
Опишем универсальный метод сохранения, который будет извещать нас об изменении состояния любого сервиса: # аргументы: $1 - имя сервера, $2 - имя сервиса
Save "state-alarm" {
Pipe "mail -s \"$1/$2 $0\" root" # послать письмо
State "$TIME $1/$2 $STATE $$2" # такого содержания
}
И применим их на интересующих нас серверах: Object "server-1" {
Address "server.foo.bar"
Method Ping # прежде проверим доступен ли вообще этот сервер
Save "state-alarm" "server-1 ping" # аргументы для $1 и $2
Service "pop3" {
Method "pop3"
Save "state-alarm" "server-1 pop3"
}
Service "http" {
Method "http" "/index.html" # передадим имя документа
Save "state-alarm" "server-1 http"
}
Service "dns" {
Method dns "foo.bar" # встроенный метод DNS проверит нашу зону
Save "state-alarm" "server-1 dns"
}
}
Заметим, что обьект - владелец сервисов, также должен быть опрошен
каким-либо методом, иначе его состояние будет
неизвестно - NONE. А опрос подобьектов всегда производится только
на обьектах в состоянии UP.
Настройка специфического SNMP трапаРассмотрим в качестве простого примера использование Cisco Enterprise ciscoConfigManMIBNotification группы трапов. Так выглядит трейс трапа, полученный с помощью UCD snmptrapd: 15:43:27.853: snmp_trap(192.168.1.1): enterprise .1.3.6.1.4.1.9.9.43.2 Enterprise Specific Trap .1.3.6.1.4.1.9.9.43.2.0.1 .1.3.6.1.4.1.9.9.43.1.1.6.1.3.1 = 1 .1.3.6.1.4.1.9.9.43.1.1.6.1.4.1 = 4 .1.3.6.1.4.1.9.9.43.1.1.6.1.5.1 = 2 Так должен выглядеть соответстующий ему фрагмент конфигурации Netmond: Trap "config-notify" {
Enterprise 1.3.6.1.4.1.9.9.43.2.0 # ciscoConfigManMIBNotificationPrefix
Specific 1 # ciscoConfigManEvent трап
Community "$1"
}
Object "cisco-router" {
Address "192.168.1.1"
...
$commandSource 1.3.6.1.4.1.9.9.43.1.1.6.1.3.1
$configSource 1.3.6.1.4.1.9.9.43.1.1.6.1.4.1
$configDestination 1.3.6.1.4.1.9.9.43.1.1.6.1.5.1
Trap "config-notify" "router-community"
...
}
В соответствии с документом CISCO-CONFIG-MAN-MIB-V1SMI.my указанные переменные могут принимать следующие значения:
Как мы теперь видим, данный трап известил нас о том, что с командной строки Cisco роутера с IP адресом 192.168.1.1 была выполнена команда show startup-config. Сбор статистики по портамПрактически каждый Интернет Провайдер однажды решает для себя задачу сбора статистики по портам клиентских подключений. Наиболее простой и стандартный способ это периодический SNMP поллинг и возможно трапинг, которые могут обеспечить подробное протоколирование работы роутеров, свичей и их сетевых интерфейсов, с фиксацией времени работы, обьемов прошедшего трафика, колличества ошибок и некоторых других параметров. Для решения этой задачи мы можем воспользоваться встроенным методом опроса обьектов с интерфейсами Router, который позволит нам автоматизировать всю работу по сбору таких данных в сети. Применим также и стандартные трапы, которые могут ускорить поступление информации о происходящих событиях в сети. Накопленные данные будем хранить для простоты в текстовых файлах, сгруппировав их в удобную иерархическую систему. Для сохранения данных по роутерам и свичам будем использовать встроенный метод сохранения Router. Встроенным же методом Interface пользоваться не будем, так как он пишет все данные в один файл. Разнесем периодическое сохранение счетчиков интерфейсов и журнал работы портов по разным файлам: RootDir "/var/netmon"
Polling 60 # опрашиваем раз в минуту
Saving 600 # пишем данные каждые 10 минут
TimeFmt "%H:%M:%S" # формат вывода перенной $TIME
# для периодического сохранения каунтеров интерфейсов
Save "IntData" {
File "%Y.%m.%d" # файлы с данными по-суточно, например 2002.08.24
Data "$TIME" # эти данные пойдут одной строкой
" $ifInOctets.delta $ifOutOctets.delta"
" $ifInUcastPkts.delta $ifOutUcastPkts.delta"
" $ifInDrops.delta $ifOutDrops.delta"
" $ifInErrors.delta $ifOutErrors.delta"
}
# фиксация изменений на интерфейсе
Save "IntChange" {
File "%Y.%m.changes" # эти файлы по-месячно, например 2002.08.changes
State "$TIME $ifSpeed $STATE $ciscoIfReason" # изменение состояния
When "$ifSpeed.old && $ifSpeed != $ifSpeed.old" 0
"$TIME BW $ifSpeed.old -> $ifSpeed" # изменение скорости
}
И применим эти методы сохранения на всех клиентских портах разных роутеров и свичей в нашей сети: # роутер с клиентами
Object "router-1" {
Address "cisco.foo.bar" # или IP адрес
Trap Generic "community" # надеемся получать трапы от роутера
Method Router "community" # этот метод опросит роутер и интерфейсы
Save Router # встроенный метод сохранения данных
Interface "FastEthernet0/0.1" {
DataDir "Customer1" # это подкаталог куда пишем данные
Save "IntData"
Sace "IntChange"
}
Interface "Serial1/0" {
DataDir "Customer2"
Save "IntData"
Save "IntChange"
}
}
# свич с портами клиентов
Object "switch-2" {
Address "catalyst.foo.bar"
Trap Generic "community"
Method Router "community" # для свича этот метод тоже подойдет
Save Router
Interface 12 { # но используем индексы интерфейсов
DataDir "Customer3"
Save "IntData"
Save "IntChange"
}
}
В результате данные будут выводиться в файлы в следующей иерархии: /var/netmon/
router-1/Файлы данных по работе router-1
...
Customer1/Данные с порта FastEthernet0/0.1
...
Customet2/Данные с порта Serial1/0
...
switch-2/Файлы данных по работе switch-1
...
Customer3/Данные с порта номер 12
...
Если же мы заменим File на Pipe или Exec в декларации наших методов сохранения, то сможем загружать данные в нашу СУБД вместо записи их в файлы. Смотри также: © 1998-2002, Rinet Software
|