## TkNetmon :: Руководство программиста

Данный документ предназначен для программиста или системного администратора, который будет устанавливать, сопровождать, адаптировать или расширять программу. В документе описано, зачем была написана программа, и какими принципами руководствовался разработчик в процессе работы. TkNetmon.

### Содержание

1. Архитектура
2. Принципы построения интерфейса пользователя
3. Интерпретация конфигурационного файла
4. Основные структуры данных
5. Требования к оборудованию и системному ПО.
6. Что можно и нужно настраивать
7. Иконки
8. Формат файла "hosts"
9. Формат файла "snmp.list"
10. Формат файла "targets.list"
11. Как настроить системные шрифты
12. Дополнительные программы
13. Заметки

1. Архитектура

   Одним из подходов к управлению компьютерной сетью является построение центрального узла слежения за состоянием сетевых устройств. В таком центре размещен выделенный компьютер(или несколько) который занимается периодическим сбором информации о состоянии сетевых устройств, накапливает ее, анализирует, и подает сигналы обслуживающему персоналу, если обнаружены симптомы неисправности.

   ##### Основные Задачи:

   - опрос сетевых устройств.
   - отображение состояния устройств.
   - активная сигнализация о неисправностях.
   - накопление данных.
   - анализ накопленных (за длительный период) данных. отчеты, графики и т.д.
   - инвентаризация сети - автоматическое обнаружение новых устройств, подключенных к сети.
   - подготовка отчетов

   ##### Общие требования

   - Основной сетевой протокол - IP.
   - Основной протокол управления - SNMP.
   - Независимость от платформы.
   - Минимальное количество используемых языков(систем) программирования.
   - Максимальное использование уже готовых программ и библиотек(вместо написания собственного кода).
   - Расширяемость.
   - Характерный масштаб сети - 100-300 сетевых устройств. Максимально - до 1000.

   ##### Требования по задачам

   - Опрос - централизованный, асинхронный, непрерывный.
     Опрос должен осуществляться так, чтобы не было значительных всплесков трафика. Опрос должен осуществляться независимо от того, работает ли операторская консоль.
   - Отображение - распределенное.
     Т.е. должно быть возможно установить несколько операторских консолей, каждая из которых может отображать всю сеть, или какой-либо ее сегмент.
   - Сигнализация
     В общем случае, сигналы должны подаваться на операторских консолях. Аварийные сигналы должны (независимо) дублироваться на пейджеры (мобильные телефоны) персонала.
   - Накопление данных
     оперативный режим - в ближнем (коротком) интервале времени важнее всего скорость доступа к данным. Исторический режим - важнее структурированность данных, для облегчения работы алгоритмов анализа.
   - Инвентаризация
     Должна осуществляться независимо от других задач. Должно быть предусмотрено расписание. Минимальный трафик. Возможность обнаружения хостов, фильтрующих входящий трафик. Обнаружение ситуации изменения хостом MAC адреса.

   ##### Детализация

   1. Инвентаризация
      - построение (автоматическое) топологии сети.
      - контроль топологии - оповещение об изменении топологии.
      - Алгоритмы
        - линейное сканирование диапазона IP адресов
        - Опрос маршрутизаторов и анализ таблиц маршрутизации и ARP таблиц, поиск хабов и свичей - таблицы MAC адресов на портах.
        - поиск транзитных маршрутизаторов с использованием флага RecordRoute ICMP пакетов.
      - Ограничения
        Должен быть определен диапазон IP адресов ( или несколько диапазонов ) которые нам принадлежат. При поиске, нужно проверять, является ли хост "нашим" или "чужим". Чужие хосты не нужно проверять и запоминать их параметры.
      - При поиске и формировании таблицы обнаруженных хостов нужно правильно обрабатывать ситуацию, когда у одного хоста более 1 IP адреса - несколько интерфейсов или алиасов. Хост в таблице должен быть один.
      - Нужно запоминать текущее состояние базы обнаруженных хостов между сеансами.
      - Для каждого обнаруженного хоста нужно хранить историю изменений.
   2. Оповещение
      - Изменение графического представления ( форма символа, цвет символа, мультипликация, мигание символа)
      - Звуковое:
        - Короткий одинарный сигнал
        - Непрерывнай сигнал до явного подтверждения оператором факта получения сигнала (возможно, с фиксированием в журнале времени реакции оператора)
        - Сообщение на пейджер (мобильный телефон -SMS) или E-mail
   3. Интерфейс оператора
      - использование одного конфигурационного файла; подготовка конфигураций для подсистем - автоматически.
      - заложить возможность использования нескольких(разных) программ низкоуровневого опроса сетевых устройств.
        Точки соприкосновения:
        - Конфигурация
        - Протокол получения данных
        - Форматы накопления данных, месторасположение данных.
      - заложить возможность интеграции с системой протоколирования проблем (и хода их решения.) (TroubleTiсket System)
   4. Накопление данных
      - общий журнал событий системы мониторинга.
        Записи о событиях могут быть классифициораны по важности. При отображении, записи разных категорий должны быть отображены разным цветом (напрмер, DOWN - красный WARN - желтый, UP-зеленый)
      - Поиск в журнале на основе регулярного выражения.
      - Фильтрация журнала на основе регулярного выражения.

   Из описаных выше требований следует двухуровневая архитектура системы. На нижнем уровне - ПО опроса и накопления данных. На верхнем - ПО отображения состояния сети.

   TkNetmon в данном контексте является операторской консолью.

   ##### Основной алгоритм:

   в цикле, c интервалом в несколько секунд запрашивать результаты работы netmond и в соответствии с полученными данными менять цвет иконок объектов и подавать звуковые сигналы.

   Все хосты размещаются в ОДНОМ окне. ( нет иерархической структуры )

2. Принципы построения интерфейса пользователя (GUI).

   GUI состоит из основного окна и набора диалогов.

   Основное окно предназначено для размешения объектов сети и описательных (декоративных) объектов.

   Для ускорения работы ПО там где это возможно(и разумно), используется предгенерация интерфейса. Это значит, что в момент запуска ПО, для каждого диалога (из списка) запускается процедура создания интерфейса, который затем убирается с экрана до момента вызова этого диалога. В момент вызова диалога, он разворачивается на экране, в поля вносятся актуальные данные. По окончании работы с диалогом, он снова убирается с экрана, но не уничтожается.
   Основные параметры и настроки программы должны запоминаться между сеансами.
   Геометрия основного окна и диалогов должна запоминаться между сеансами.
   В формах ввода и корректировки данных проводить проверку корректности введенных (измененных) данных.
   Локализация меню, текстовых полей и собщений.
   Сообщения об ошибках времени исполнения выводятся в файл.

3. Интерпретация конфигурационного файла

   Синтаксис конфигурационного файла netmond хорошо ложится в синтаксис TCL. Конфигурационный файл рассматривается как скрипт TCL, и просто "исполняется" в интерпретаторе TCL. Директивы файла конфигурации рассматриваются как названия процедур TCL, параметры директив - как параметры процедур.

   В приципе, можно создавать конфигурационный файл NETMOND в текстовом редакторе, или в при помощи какого-то другого ПО.
   TkNetmon поймет этот файл, если будут соблюдены следующие условия:

   - Нельзя пользоваться комментариями в стиле "С". Т.е. нельзя писать конструкции вида:

         		...............
         		/* --------------------------
         		 Comments comments comments
         		----------------------------- */

     Такие комментарии интерпретируются особым образом в TkNetmon.

     Комментарии в стиле "SHELL" использовать можно. Но после сохранения файла они будут везде удалены, кроме как в теле определения методов опроса или накопления.

   - Названия директив должны быть приведены к каноническому виду: "Directiva" - то есть первая буква должна быть заглавной, а остальные - прописными.
   - В одной строке можно размещать только одну директиву с параметрами. Параметры директивы могут занимать несколько строк.
   - Директивы "%include" интерпретируются особым образом. Считается, что в конфигурационном файле может быть 2 директивы "%include" - одна перед первой директивой "Object", и одна в конце файла. Прочие - игнорируются.
   - Аргументом директивы "Address" внутри директиывы "Object" должен быть именно IP адрес хоста, но не его FQDN.

4. Основные структуры данных

   Информация о свойствах объектов хранится в наборе глобальных массивов. Ключем этих массивов является динамический индекс, так что у одного и того-же хоста в двух разных сеансах работы TkNetmon он может быть разным. Динамический индекс создается в момент чтения файла конфигурации или при создании объекта хоста и не освобождается до окончания работы программы, даже если объект удален.

   Для декоративных объектов ( линии, текст, связки ) никаких дополнительных данных не хранится. Все что нужно, хранится во внутренних структурах примитива CANVAS.

   Диалоги обычно имеют собственное пространство имен (namespace) в котором хранятся внутренние переменные этих диалогов.

5. Требования к оборудованию и системному ПО

   TkNetmon тестировался на следующих платформах:
   - FreeBSD 5.4 Intel P4-1,8Ghz RAM256Mb HDD:ATA-20Gb LAN:3c905c
   Никаких серьезных требований к оборудованию нет, должно работать вплоть до i486.

6. Что можно и нужно настраивать

   Для адаптации программы в конкретном окружении нужно редактировать
   1. методы опроса
      Можно создать методы опроса, которые будут проверять работоспособность сервисов, или собирать статистику о работе сервисов хоста, если эти данные невозможно или не удобно получать по SNMP. Подробнее о формате описания метода опроса можно прочитать в документации netmond.
   2. Алерты Алерт - это такой специальный метод опроса, который сам никаих данных не собирает, а лишь производит вычисления над данныим, которые собрали другие методы. Если такой метод вычисляется как FALSE, то изменяется статус хоста. С помощью алертов можно отслеживать (и отображать на карте) превышение порогов производительности сервера.
   3. методы накопления
      Собранные данные можно сохранять в файл в заданном формате, либо передававть внешней программе для дальнейшей обработки. Таким образом, в частности, можно посылать сообщения на пейджер ( или SMS) в случае наступления каких-либо событий. Подробнее о формате описания метода накопления можно прочитать в документации netmond
   4. сервисные меню.
      Для различных хостов (классов хостов) можно создать разные сервисные меню. Так, например, для WinXX машин можно добавить в меню команду вызова vncviewer -a, Для UNIX хостов-SSH, для cisco - telnet, или другие внешние программы.
      В сервисных меню можно использовать 2 типа команд:
      - внешние программы (Команды)
        Указанная внешняя программа будет запущена на исполненеие (через вызов exec). Ей можно передать только небольшое количество параметров, через командную строку - ip адрес хоста, его имя, SNMP community, адрес и порт NetState сервера. Здесь можно использовать дополнительные программы
      - внутренние процедуры (Функции) Внутренняя процедура является частью TkNetmon, и имеет доступ ко всем внутренним данным. На текущий момент реализована только одна такая функция - Просмотр журнала хоста. (showObjectsEventsLog). Все такие функции должны быть перечислены в глобальном списке functionsList.

        Написание собственных функций для использования в сервисных меню требует знания языка Tcl/Tk, и внутреннего устройства программы TkNetmon и структур данных. (пример смотри в lib\EventsLog.tcl )

   5. SNMP переменные
      Вы можете опрашивать определенные SNMP переменные у хоста, если это не делается встроенными методами. Это почти то-же самое, что метод опроса.

7. Иконки

   В качестве иконок используются GIF-каpтинки 32x32 с пpозpачной подложкой. Вообще, pазмеpы каpтинок могут быть любые. Пpогpамма ссылается на иконки по имени файла, без pасшиpения.

8. Формат файла "hosts"

   Напрмер:

       	    ............................
       	    192.168.1.5  router # Cisco 2509
       	    192.168.1.6  server
       	    192.168.1.7
       	    ............................

   Первое слово в строке интерпретируется как IP адрес. Если оно не соответствует виду IP адреса, вся строка игнорируется.
   Второе слово - название хоста. Если его нет - используется IP адрес.
   Все остальные слова до конца строки помещаются в комментарий для этого хоста.
   Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.

9. Формат файла "snmp.list"

   Например:

       	    192.168.1.5 secret
       	    192.168.1.6 serversecret

   Первое слово в строке интерпретируется как IP адрес. Если оно не соответствует виду IP адреса, вся строка игнорируется.
   Второе слова - snmpget Community.
   Из этого следует, в частности, что SNMP COMMUNITY должно быть одним словом, т.е. не содержать пробелов, табуляций и др. подобных символов. Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.

10. Формат файла "targets.list"

    Например:

        	    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 адрес.
    Строки, которые начинаются с символа # считаются комментариями, и не рассматриваются.

11. Как настроить системные шрифты

    Рекомендую установить TTF шрифты их коллекции "MS WEBFONTS" ( /usr/ports/x11-fonts/webfonts ) Это позволит добиться того, чтобы карта сети выглядела примерно одинаково как на UNIX машине, так и на Windows-машине.

    Системные шрифты или шрифты, используемые при построении диалогов, меню, форм и т.д. назначены в системном RC файле - /usr/local/lib/TkNetmon-NNN/.tknetmonrc в виде опций для соответствующего класса графических объектов

12. Дополнительные программы

    Дополнительные программы, входящие в пакет размещены в подкаталоге libexec. Они могут использоваться как совместно с TkNetmon так и отдельно.
    - TkPortHistory.tcl
    - EventsLog.tcl
    - TkDeviceView.tcl
    - TkSnmpTable.tcl
    - TkIfUtil.tcl
    - NodeReport.tcl
    - SystemLog.tcl

13. Заметки

    - Каталог накопления данных - относительное имя. Для объектов-хостов - это путь относительно RootDir. Для инерфейсов, сервисов и AS - это путь относительно каталога родительского хоста.

Last change: