-
Одним из подходов к управлению компьютерной сетью является построение центрального
узла слежения за состоянием сетевых устройств. В таком центре размещен выделенный
компьютер(или несколько) который занимается периодическим сбором информации о состоянии
сетевых устройств, накапливает ее, анализирует, и подает сигналы обслуживающему
персоналу, если обнаружены симптомы неисправности.
Основные Задачи:
- опрос сетевых устройств.
- отображение состояния устройств.
- активная сигнализация о неисправностях.
- накопление данных.
- анализ накопленных (за длительный период) данных.
отчеты, графики и т.д.
- инвентаризация сети - автоматическое обнаружение новых устройств,
подключенных к сети.
- подготовка отчетов
Общие требования
- Основной сетевой протокол - IP.
- Основной протокол управления - SNMP.
- Независимость от платформы.
- Минимальное количество используемых языков(систем) программирования.
- Максимальное использование уже готовых программ и библиотек(вместо написания собственного кода).
- Расширяемость.
- Характерный масштаб сети - 100-300 сетевых устройств. Максимально - до 1000.
Требования по задачам
- Опрос - централизованный, асинхронный, непрерывный.
Опрос должен осуществляться так, чтобы не было значительных всплесков
трафика. Опрос должен осуществляться независимо от того,
работает ли операторская консоль.
- Отображение - распределенное.
Т.е. должно быть возможно установить
несколько операторских консолей, каждая из которых
может отображать всю сеть, или какой-либо ее сегмент.
- Сигнализация
В общем случае, сигналы должны подаваться на операторских
консолях. Аварийные сигналы должны (независимо) дублироваться на
пейджеры (мобильные телефоны) персонала.
- Накопление данных
оперативный режим - в ближнем (коротком) интервале времени
важнее всего скорость доступа к данным.
Исторический режим - важнее структурированность данных,
для облегчения работы алгоритмов анализа.
- Инвентаризация
Должна осуществляться независимо от других задач.
Должно быть предусмотрено расписание.
Минимальный трафик. Возможность обнаружения хостов, фильтрующих
входящий трафик.
Обнаружение ситуации изменения хостом MAC адреса.
Детализация
- Инвентаризация
- построение (автоматическое) топологии сети.
- контроль топологии - оповещение об изменении топологии.
- Алгоритмы
- линейное сканирование диапазона IP адресов
- Опрос маршрутизаторов и анализ таблиц маршрутизации и ARP таблиц,
поиск хабов и свичей - таблицы MAC адресов на портах.
- поиск транзитных маршрутизаторов с использованием флага RecordRoute ICMP пакетов.
- Ограничения
Должен быть определен диапазон IP адресов ( или несколько диапазонов )
которые нам принадлежат. При поиске, нужно проверять, является ли
хост "нашим" или "чужим". Чужие хосты не нужно проверять и запоминать
их параметры.
- При поиске и формировании таблицы обнаруженных хостов нужно правильно
обрабатывать ситуацию, когда у одного хоста более 1 IP адреса - несколько
интерфейсов или алиасов. Хост в таблице должен быть один.
- Нужно запоминать текущее состояние базы обнаруженных хостов между сеансами.
- Для каждого обнаруженного хоста нужно хранить историю изменений.
- Оповещение
- Изменение графического представления ( форма символа, цвет символа, мультипликация,
мигание символа)
- Звуковое:
- Короткий одинарный сигнал
- Непрерывнай сигнал до явного подтверждения оператором факта получения сигнала
(возможно, с фиксированием в журнале времени реакции оператора)
- Сообщение на пейджер (мобильный телефон -SMS) или E-mail
- Интерфейс оператора
- использование одного конфигурационного файла; подготовка конфигураций
для подсистем - автоматически.
- заложить возможность использования нескольких(разных) программ
низкоуровневого опроса сетевых устройств.
Точки соприкосновения:
- Конфигурация
- Протокол получения данных
- Форматы накопления данных, месторасположение данных.
- заложить возможность интеграции с системой протоколирования проблем (и хода
их решения.) (TroubleTiсket System)
- Накопление данных
- общий журнал событий системы мониторинга.
Записи о событиях могут быть
классифициораны по важности. При отображении, записи разных категорий
должны быть отображены разным цветом (напрмер, DOWN - красный WARN - желтый,
UP-зеленый)
- Поиск в журнале на основе регулярного выражения.
- Фильтрация журнала на основе регулярного выражения.
Из описаных выше требований следует двухуровневая архитектура системы.
На нижнем уровне - ПО опроса и накопления данных. На верхнем - ПО отображения
состояния сети.
TkNetmon в данном контексте является операторской консолью.
Основной алгоритм:
в цикле, c интервалом в несколько секунд запрашивать
результаты работы netmond и в соответствии с полученными данными
менять цвет иконок объектов и подавать звуковые сигналы.
Все хосты размещаются в ОДНОМ окне. ( нет иерархической структуры )
-
GUI состоит из основного окна и набора диалогов.
Основное окно предназначено для размешения объектов сети и описательных
(декоративных) объектов.
Для ускорения работы ПО там где это возможно(и разумно), используется
предгенерация интерфейса. Это значит, что в момент запуска ПО, для каждого
диалога (из списка) запускается процедура создания интерфейса, который затем
убирается с экрана до момента вызова этого диалога. В момент вызова диалога,
он разворачивается на экране, в поля вносятся актуальные данные. По окончании
работы с диалогом, он снова убирается с экрана, но не уничтожается.
Основные параметры и настроки программы должны запоминаться между сеансами.
Геометрия основного окна и диалогов должна запоминаться между сеансами.
В формах ввода и корректировки данных проводить проверку корректности
введенных (измененных) данных.
Локализация меню, текстовых полей и собщений.
Сообщения об ошибках времени исполнения выводятся в файл.
-
Синтаксис конфигурационного файла netmond хорошо ложится в синтаксис TCL.
Конфигурационный файл рассматривается как скрипт TCL, и просто "исполняется"
в интерпретаторе TCL. Директивы файла конфигурации рассматриваются как названия
процедур TCL, параметры директив - как параметры процедур.
В приципе, можно создавать конфигурационный файл NETMOND в текстовом редакторе,
или в при помощи какого-то другого ПО.
TkNetmon поймет этот файл, если будут соблюдены следующие условия:
- Нельзя пользоваться комментариями в стиле "С". Т.е. нельзя писать конструкции
вида:
...............
/* --------------------------
Comments comments comments
----------------------------- */
Такие комментарии интерпретируются особым образом в TkNetmon.
Комментарии в стиле "SHELL" использовать можно. Но после сохранения файла
они будут везде удалены, кроме как в теле определения методов опроса
или накопления.
- Названия директив должны быть приведены к каноническому виду: "Directiva" -
то есть первая буква должна быть заглавной, а остальные - прописными.
- В одной строке можно размещать только одну директиву с параметрами.
Параметры директивы могут занимать несколько строк.
- Директивы "%include" интерпретируются особым образом. Считается, что в
конфигурационном файле может быть 2 директивы "%include" - одна перед первой
директивой "Object", и одна в конце файла. Прочие - игнорируются.
- Аргументом директивы "Address" внутри директиывы "Object" должен быть
именно IP адрес хоста, но не его FQDN.
-
-
Информация о свойствах объектов хранится в наборе глобальных массивов.
Ключем этих массивов является динамический индекс, так что у одного и того-же
хоста в двух разных сеансах работы TkNetmon он может быть разным. Динамический
индекс создается в момент чтения файла конфигурации или при создании объекта
хоста и не освобождается до окончания работы программы, даже если объект удален.
Для декоративных объектов ( линии, текст, связки ) никаких дополнительных данных
не хранится. Все что нужно, хранится во внутренних структурах примитива CANVAS.
Диалоги обычно имеют собственное пространство имен (namespace) в котором хранятся
внутренние переменные этих диалогов.
-
TkNetmon тестировался на следующих платформах:
- FreeBSD 5.4 Intel P4-1,8Ghz RAM256Mb HDD:ATA-20Gb LAN:3c905c
Никаких серьезных требований к оборудованию нет, должно работать вплоть до i486.
-
Для адаптации программы в конкретном окружении нужно редактировать
- методы опроса
Можно создать методы опроса, которые будут проверять
работоспособность сервисов, или собирать статистику о работе сервисов хоста,
если эти данные невозможно или не удобно получать по SNMP. Подробнее о формате
описания метода опроса можно прочитать в документации netmond.
- Алерты
Алерт - это такой специальный метод опроса, который сам никаих данных
не собирает, а лишь производит вычисления над данныим, которые собрали другие
методы. Если такой метод вычисляется как FALSE, то изменяется статус хоста.
С помощью алертов можно отслеживать (и отображать на карте) превышение порогов
производительности сервера.
- методы накопления
Собранные данные можно сохранять в файл в заданном формате, либо передававть
внешней программе для дальнейшей обработки. Таким образом, в частности, можно
посылать сообщения на пейджер ( или SMS) в случае наступления каких-либо событий.
Подробнее о формате описания метода накопления можно прочитать в документации
netmond
- сервисные меню.
Для различных хостов (классов хостов) можно создать разные сервисные меню.
Так, например, для WinXX машин можно добавить в меню команду вызова vncviewer -a,
Для UNIX хостов-SSH, для cisco - telnet, или другие внешние программы.
В сервисных меню можно использовать 2 типа команд:
- SNMP переменные
Вы можете опрашивать определенные SNMP переменные у хоста, если это не делается
встроенными методами. Это почти то-же самое, что метод опроса.
-
В качестве иконок используются GIF-каpтинки 32x32 с
пpозpачной подложкой. Вообще, pазмеpы каpтинок могут быть любые.
Пpогpамма ссылается на иконки по имени файла, без pасшиpения.
-
Напрмер:
............................
192.168.1.5 router # Cisco 2509
192.168.1.6 server
192.168.1.7
............................
Первое слово в строке интерпретируется как IP адрес. Если оно не соответствует виду IP
адреса, вся строка игнорируется.
Второе слово - название хоста. Если его нет - используется IP адрес.
Все остальные слова до конца строки помещаются в комментарий для этого хоста.
Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.
-
Например:
192.168.1.5 secret
192.168.1.6 serversecret
Первое слово в строке интерпретируется как IP адрес. Если оно не соответствует виду IP
адреса, вся строка игнорируется.
Второе слова - snmpget Community.
Из этого следует, в частности, что SNMP COMMUNITY должно быть одним словом, т.е. не
содержать пробелов, табуляций и др. подобных символов.
Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.
-
Например:
192.168.1.0 192.168.1.250
192.168.2.0 192.168.2.64
192.168.4.22
Первое слово в строке интерпретируется как IP адрес начала непрерывного диапазона
IP адресов. Второе слово в строке интерпретируется как IP адрес конца диапазона.
Если одно из этих слов не соответствует виду IP адреса или начальный адрес "больше"
конечного - строка игнорируется.
Если конец диапазона не указан - диапазон вырожден и содержит всего 1 IP адрес.
Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.
-
Рекомендую установить TTF шрифты их коллекции "MS WEBFONTS" ( /usr/ports/x11-fonts/webfonts )
Это позволит добиться того, чтобы карта сети выглядела примерно
одинаково как на UNIX машине, так и на Windows-машине.
Системные шрифты или шрифты, используемые при построении диалогов, меню, форм и т.д.
назначены в системном RC файле - /usr/local/lib/TkNetmon-NNN/.tknetmonrc
в виде опций для соответствующего класса графических объектов
-
Дополнительные программы, входящие в пакет размещены в подкаталоге libexec.
Они могут использоваться как совместно с TkNetmon так и отдельно.
-
- Каталог накопления данных - относительное имя. Для объектов-хостов - это
путь относительно RootDir. Для инерфейсов, сервисов и AS - это путь относительно
каталога родительского хоста.