на вручну, а можна скористатися йдуть у складі пакету генераторами конфігурацій:
# cfgmaker lt; community string gt; @ lt; hostname gt; gt; lt; config path gt;
Після генерації конфігураційного файлу рекомендується перевірити його, тому в ньому можуть знаходиться опису інтерфейсів, які нам не потрібно аналізувати на завантаженість. У такому випадку певні рядки у файлі коментуються або видаляються. Приклад конфігураційного файлу MRTG наведено у Додатку М. Через великого об'єму цих файлів наведено лише приклад одного файлу.
Далі необхідно згенерувати індексні файли майбутніх веб сторінок, робиться це також за допомогою спеціального генератора:
# indexmaker lt; config path gt; gt; lt; index path gt;
Індексні сторінки являють собою звичайні html файли і їх вміст особливого інтересу не представляє, тому наводити їх приклади не має сенс. У Додатку Н показаний приклад відображення графіків завантаження інтерфейсів.
На завершення необхідно організувати перевірку завантаженості інтерфейсів за розкладом. Досягти цього найпростіше засобами операційної системи, а саме параметрами crontab.
4.5 Встановлення та налаштування модуля збору системних журналів подій
В якості модуля збору системних журналів подій був обраний пакет syslog-ng.ng (syslog next generation) - це багатофункціональна служба протоколювання системних повідомлень. У порівнянні зі стандартною службою syslogd, він має ряд відмінностей:
§ вдосконалена схема конфігурації
§ фільтрація повідомлень не тільки за пріоритетами, а й за їх змістом
§ підтримка regexps (regular expressions)
§ більш гнучке маніпулювання і організація логів
§ можливість шифрування каналу передачі даних за допомогою IPSec/Stunnel
У наступній таблиці представлені підтримувані апаратні платформи.
Таблиця 4.1 - Підтримувані апаратні платформи
x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 amp; 5.3НетНетНетДаПо запросуНетDebian etchДаДаНетНетНетНетFreeBSD 6.1 * ДаПо запросуПо запросуНетНетНетHP-UНет 11iНетНетНетНетНетДаIBM System iНетНетНетДаНетНетRed Hat ES 4/CentOS 4ДаДаНетНетНетНетRed Hat ES 5/CentOS 5ДаДаНетНетНетНетSLES 10/openSUSE 10.0ДаПо запросуНетНетНетНетSLES 10 SP1/openSUSE 10.1ДаДаНетНетНетНетSolaris 8НетНетДаНетНетНетSolaris 9По запросуНетДаНетНетНетSolaris 10По запросуДаДаНетНетНетWindowsДаДаНетНетНетНет Прімеченіе: * Доступ до бази даних Oracle Не підтримується
Детальний порівняння технічних особливостей наведено в Додатку П.
Файли опису правил і фільтрів, а також конфігурація віддалених хостів наведені у Додатку Р.
Існує документ RFC, детально описує протокол syslog, в загальному вигляді роботу модуля збирача системних журналів можна представити наступною схемою
Рис. 4.6 - Схема роботи модуля збору системних журналів
На клієнтському хосте кожне окреме додаток пише свій журнал подій, утворюючи тим самим джерело. Далі потік повідомлень для журналів проходить через визначення місця для зберігання, далі через фільтри визначається його мережеве напрямок, після чого, потрапляючи на сервер логування, для кожного повідомлення знову визначається місце зберігання. Обраний модуль має великі можливості масштабування і ускладненою конфігурації, наприклад фільтри можуть розгалужуватися, таким чином, що повідомлення про системні події будуть відправлятися в кілька напрямків залежно від кількох умов, як показано на малюнку нижче.
Рис. 4.7 - Галуження фільтрів
Можливість масштабування увазі, що з метою розподілу навантаження, адміністратор буде розгортати мережу з допоміжних фільтруючих серверів, так званих реле.
Рис. 4.8 - Масштабування і розподіл навантаження
У кінцевому підсумку, максимально спрощено, описати роботу модуля можна так - клієнтські хости передають повідомлення журналів подій різних додатків розвантажує серверам, ті, у свою чергу можуть передавати їх по ланцюжку реле, і так до центральних серверів збору.
Рис. 4.9 - Узагальнена схема роботи модуля
У нашому випадку потік даних не настільки великий щоб розгортати систему розвантажуючих серверів, тому було вирішено використовувати спрощену схему роботи клієнт - сервер [31, с. 64].
Рис. 4.10 - Прийнята схема роботи
5. КЕРІВ...
