ікавішою можливістю веб-інтерфейсу є можливість побудови карти мережі в напівавтоматичному режимі.
Рис. 5.7 - Повна кругова карта мережі
За допомогою параметра parent кожного хоста і служби ми можемо створювати структуру або ієрархію нашої мережі, що визначить логіку роботи ядра мережевого моніторингу та подання хостів і служб на карті мережі. Є кілька режимів відображення, крім кругового, найбільш зручним є режим збалансованого дерева і кулястий.
Рис. 5.8 - Карта мережі - режим збалансованого дерева
Рис. 5.9 - Карта мережі - кулястий режим
У всіх режимах зображення кожного хоста є посиланням на його таблицю служб та їх станів.
Наступною важливою частиною інтерфейсу ядра моніторингу є будівник трендів. З його допомогою можна планувати заміну обладнання на більш продуктивно, наведемо приклад. Клацаємо по посиланню Trends. Вибираємо тип звіту - службу.
Step 1: Select Report Type: Service
Далі вибираємо саму службу і переходимо до наступного кроку.
Третім кроком вибираємо період підрахунку і генеруємо звіт.
Рис. 5.10 - Тренд
Ми згенерували тренд завантаженості процесора на маршрутизації. З нього можна зробити висновок, що протягом місяця цей параметр постійно погіршується і необхідно вже зараз вживати заходів або щодо оптимізації роботи хоста або готуватися до його заміни на більш продуктивний.
5.2 Опис веб-інтерфейсу модуля відстеження завантаження інтерфейсів
Веб-інтерфейс модуля відстеження завантаження інтерфейсів являє собою список каталогів, в яких розташовані ин?? ексние сторінки відслідковуваних хостів з графіками завантаження кожного інтерфейсу.
Рис. 5.11 - Стартова сторінка модуля відстеження завантаження інтерфейсів
Перейшовши по кожній із посилань, отримаємо графіки завантаження. Кожен графік є посиланням, що веде до статистикою за тиждень, місяць і рік.
Рис. 5.12 - Індексна сторінка графіків модуля відстеження завантаження інтерфейсів
5.3 Опис модуля збору системних журналів подій
У даний момент не потрібна покращена фільтрація системних журналів і можливість пошуку по ним через єдиний веб-інтерфейс, тому проблеми, які потребують перегляду цих журналів виникають досить рідко. Тому розробка бази даних під ці журнали і веб-інтерфейсу відкладена. В даний час доступ до них здійснюється за допомогою ssh і перегляду директорій у файловому менеджері mc [26, с. 213].
У результаті роботи цього модуля отримали наступну структуру каталогів:
/var/log
??? apache2
??? apt
??? asterix
??? bgp_router
??? db
??? dbconfig-common
??? dr
??? exim4
??? fsck
??? installer
? ??? cdebconf
??? isp
??? len58a_3lvl
??? mail
??? main
??? monitoring
??? mrtg
??? mysql
??? nagios3
? ??? archives
??? news
??? ocsinventory-client
??? ocsinventory-server
??? pppoe
??? quagga
??? router_krivous36b
??? router_lenina58a
??? router_su
??? router_ur39a
??? samba
??? shaper
??? ub13_router
??? univer11_router
??? voip
Кожен каталог є сховищем журналів подій для кожного окремого хоста.
Рис. 5.13 - Перегляд даних, зібраних модулем збору системних журналів подій
6. ТЕСТУВАННЯ РОБОТИ
При впровадженні системи проводилося поступове тестування роботи кожного компонента, починаючи з ядра системи. Розширення функціоналу проводилося тільки після остаточної наладки нижележащих по ієрархії рівнів модулів системи мережевого моніторингу зважаючи на багато залежностей різ...
