Внедрение системы сетевого мониторинга верхнепышминской городской сети передачи данных общего доступа ООО Геркон

Настоящий документ является техническим проектом разработки и внедрения системы сетевого мониторинга верхнепышминской городской сети передачи данных общего доступа ООО Геркон. В проекте проведено исследование существующих систем сетевого мониторинга, анализ текущей ситуации на предприятии и обоснован выбор конкретных компонентов системы сетевого мониторинга.

2014-07-24

2.14 MB

236 чел.


Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск


Оглавление

[1] Оглавление

[2]
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ И ТЕРМИНОВ

[3]
1 СИСТЕМЫ СЕТЕВОГО МОНИТОРИНГА

[4] 1.1 Программные средства диагностики

[5] 1.1.1 Анализаторы протоколов

[6] 1.1.2 Протоколы мониторинга

[7] 1.2 Популярные системы управления сетями

[8]
2 ПОСТАНОВКА ЗАДАЧИ

[9] 2.1 Техническое задание

[10] 2.2 Уточненное техническое задание

[11]
3 ПРЕДЛАГАЕМАЯ СИСТЕМА

[12] 3.1 Выбор системы сетевого мониторинга

[13]
4 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

[14] 4.1 Установка ядра системы

[15] 4.1.1 Описание установки ядра системы их исходных кодов

[16] 4.1.2 Описание установки ядра системы из репозитария

[17] 4.2 Конфигурирование ядра системы

[18] 4.2.1 Описание работы ядра системы

[19] 4.2.2 Описание взаимодействия конфигурационных файлов

[20] 4.2.3 Заполнение описаний хостов и служб

[20.0.1] Файл contacts.cfg

[21] 4.2.4 Написание плагинов

[22] 4.2.5 Настройка SNMP на удаленных хостах

[23] 4.2.6 Настройка агента на удаленных хостах

[24] 4.4 Установка и настройка модуля отслеживания загрузки

[25] 4.5 Установка и настройка модуля сбора системных журналов событий

[26] 5.1 Описание веб-интерфейса системы

[27] 5.2 Описание веб-интерфейса модуля отслеживания загрузки интерфейсов

[28] 5.3 Описание модуля сбора системных журналов событий

[29]
6 ТЕСТИРОВАНИЕ РАБОТЫ

[30]
7 Информационная безопасность

[31] 7.1 Характеристика рабочего места

[32] 7.2 Безопасность труда

[33] 7.2.1 Электробезопасность

[34] 7.2.2 Защита от шума

[35] 7.2.3 Защита от электромагнитного излучения

[36] 7.2.4 Защита от электростатического поля

[37] 7.3 Условия труда

[38] 7.3.1 Микроклимат производственного помещения

[39] 7.3.2 Производственное освещение

[40] 7.4 Эргономика рабочего места

[41] 7.4.1 Организация рабочего места

[42] 7.4.2 Режим труда и отдыха

[43] 7.5 Пожарная безопасность

[44] 7.6 Чрезвычайные ситуации

[45]
8 ЭКОНОМИЧЕСКАЯ ЧАСТЬ

[46] 8.1 Расчет затрат на разработку проекта

[47] 8.2 Расчет накладных расходов

[48] 8.3 Эффективность

[49]
ЗАКЛЮЧЕНИЕ

[50]
БИБЛИОГРАФИЧЕСКИЙ СПИСОК

[51] №

[52] Наименован.

[53] Марка, характеристики, номер.

[54] Назначение.

[55] № сертификата соответствия.

[56] 1

[57] Модемный пул

[58] Robotics MP/16 v/34 S/n:000930014196552

[59] Коммутируемое соединение

[60] ОС/1-СПД-105

[61] 2

[62] Модем

[63] Robotics Courier v/34 S/n:310ZB2D812TC

[64] Коммутируемое соединение

[65] ОС/1-ТФ-439

[66] 3

[67] Модем

[68] Robotics Courier v/34 S/n:310ZB2A79E6X

[69] Коммутируемое соединение

[70] ОС/1-ТФ-439

[71] 4

[72] Модем

[73] Robotics Courier v/34 S/n:310ZB2979AC9

[74] Коммутируемое соединение

[75] ОС/1-ТФ-439

[76] 5

[77] Модем

[78] Robotics Courier v/34 S/n:310ZB2A79IV2

[79] Коммутируемое соединение

[80] ОС/1-ТФ-439

[81] 6

[82] Модем

[83] Robotics Courier v/34 S/n:310ZB2A79J1E

[84] Коммутируемое соединение

[85] ОС/1-ТФ-439

[86] 7

[87] ISP- сервер

[88] AQUARIUS SERVER T40 S41, Linux Debian.

[89] Электронная почта,  WEB сервер.

[90] ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

[91] 8

[92] Диалап – сервер

[93] AQUARIUS SERVER E40 S20, Linux Debian

[94] Мультеплексирование РРР соединений

[95] ГОСТ Р 51318.22-99 (класс В),ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

[96] 9

[97] Маршрутизатор входной.

[98] AQUARIUS SERVER T40 S41, Linux Debian.

[99] Fire Wall Маршрутизация сетей провайдеров.

[100] ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

[101] 10

[102] Резерв.

[103] PC Pentium 466 mHz, 2,4HDD, 128 mBit RAM, Linux Debian.

[104] Fire Wall

[105] 11

[106] Концентратор (хаб)

[107] AT – FS708LE s/n:LITA419B

[108] Коммутация серверов

[109] ОС/1-СПД-791

[110] 12

[111] DB - сервер

[112] AQUARIUS SERVER T50 D60, Linux Debian

[113] Сервер баз данных

[114] ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002,СанПиН 2.2.2/2.4.1340-03

[115] 13

[116] Центральный коммутатор с функцией биллинга.

[117] AT-9924T S/n: 64691073

[118] Коммутация серверов, учет трафика, система авторизации клиентов

[119] ОС/3-СПД-0208

[120] 14

[121] Оптический модем

[122] FE-C120S5.S20

[123] Вход внешнего канала ГТ

[124] ОС/1-СПД-0031

[125] 15

[126] Модем

[127] Вход внешнего канала УСИ

[128] ОС/1-ТМ-318

[129] 16

[130] Коммутатор

[131] Коммутация абонентских линий

[132] ОС/3-СПД-0208

[133] 17

[134] Коммутатор

[135] Коммутация абонентских линий

[136] ОС/3-СПД-0208

[137] 18

[138] Коммутатор

[139] Коммутация абонентских линий

[140] ОС/3-СПД-0208

[141] 19

[142] Коммутатор

[143] Коммутация абонентских линий

[144] ОС/3-СПД-0208

[145] 20

[146] Коммутатор

[147] Коммутация абонентских линий

[148] ОС/3-СПД-0208

[149] 21

[150] Коммутатор

[151] Коммутация абонентских линий

[152] ОС/3-СПД-0208

[153] 22

[154] Коммутатор

[155] Коммутация абонентских линий

[156] ОС/3-СПД-0208

[157] 23

[158] Маршрутизатор

[159] Коммутация оптических магистралей

[160] ОС/3-СПД-0208

[161] 24

[162] Коммутатор

[163] Коммутация абонентских линий

[164] ОС/3-СПД-0208

[165] 25

[166] Коммутатор

[167] Коммутация абонентских линий

[168] ОС/3-СПД-0208

[169] 26

[170] Коммутатор

[171] Коммутация абонентских линий

[172] ОС/3-СПД-0208

[173] 27

[174] WiFi точка доступа

[175] Организация WiFi сети

[176] 28

[177] WiFi точка доступа

[178] Организация WiFi сети

[179] 29

[180] WiFi точка доступа

[181] Организация WiFi сети


РЕФЕРАТ

Настоящий документ является техническим проектом разработки и внедрения системы сетевого мониторинга верхнепышминской городской сети передачи данных общего доступа ООО Геркон. В проекте проведено исследование существующих систем сетевого мониторинга, анализ текущей ситуации на предприятии и обоснован выбор конкретных компонентов системы сетевого мониторинга.

Документ содержит описание проектных решений и спецификации оборудования.

Результатом проектирования являются разработанные решения по внедрению и использованию системы:

  •  Полное описание всех этапов проектирования, разработки и внедрения системы;
  •  Руководство системного администратора, включающее описание пользовательского интерфейса системы.

Настоящий документ представляет законченные проектные решения и может быть использован для внедрения системы.
ПЕРЕЧЕНЬ ЛИСТОВ ГРАФИЧЕСКИХ ДОКУМЕНТОВ

Таблица 1 – Перечень листов графических документов

1

Системы сетевого мониторинга

220100 401000

2

Логическая структура сети

220100 401000

3

Алгоритм работы ядра сетевого мониторинга и оповещений

220100 401000

4

Структура анализатора загрузки сетевых интерфейсов

220100 401000

5

Структура сборщика системных журналов событий

220100 401000

6

Интерфейс Nagios

220100 401000

7

Обобщенная структура системы сетевого мониторинга

220100 401000


ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ И ТЕРМИНОВ

Ethernet – стандарт передачи данных, выпущенный IEEE. Определяет как передавать или получать данные из общей среды передачи данных. Формирует нижний транспортный уровень и используется различными высокоуровневыми протоколами. Обеспечивает скорость передачи данных 10Мбит/сек.

Fast Ethernet – технология передачи данных со скоростью 100Мбит/сек, использующая CSMA/CD метод, как и 10Base-T.

FDDIFiber Distributed Data Interface – волоконно-оптический интерфейс распределенной передачи данных – технология передачи данных со скоростью 100Мбит/сек, использующая метод маркерного кольца.

IEEEInstitute of Electrical and Electronic Engineers (Институт инженеров по электротехнике и электронике) – организация, разрабатывающая и публикующая стандарты.

LAN – Local Area Network – локальная сеть, ЛВС.

MAC адрес – Media Access Control – идентификационный номер сетевого устройства, определяемый, как правило, производителем.

RFCRequest for Comments – свод документов, выпускаемых организацией IEEE, и включающих в себя описание стандартов, спецификаций и др.

TCP/IP – Transmission Control Protocol/ Internet Protocol – протокол управления передачей/протокол Internet.

ЛВС – Локальная вычислительная сеть.

ОС – Операционная система.

ПО – Программное обеспечение.

СКС – Структурированная кабельная система.

СУБД – Система управления базами данных.

Тренд – Долговременная статистика, которая позволяет построить так называемую тенденцию.

Утилизация – Загрузка канала или сегмнета.

ЭВМ – Электронно-вычислительная машина.


ВВЕДЕНИЕ

Информационная инфраструктура современного предприятия представляет собой сложнейший конгломерат разномасштабных и разнородных сетей и систем. Чтобы обеспечить их слаженную и эффективную работу, необходима управляющая платформа корпоративного масштаба с интегрированными инструментальными средствами. Однако до недавнего времени сама структура индустрии сетевого управления препятствовала созданию таких систем – «игроки» этого рынка стремились к лидерству, выпуская продукты ограниченной области действия, использующие средства и технологии, не совместимые с системами других поставщиков.

Сегодня ситуация меняется к лучшему - появляются продукты, претендующие на универсальность управления всем разнообразием корпоративных информационных ресурсов, от настольных систем до мэйнфреймов и от локальных сетей до ресурсов Сети. Одновременно приходит осознание того, что управляющие приложения должны быть открыты для решений всех поставщиков [13, с. 28].

Актуальность данной работы обусловлена тем, что в связи с распространением персональных компьютеров и созданием на их основе автоматизированных рабочих мест (АРМ) возросло значение локальных вычислительных сетей (ЛВС), диагностика которых, является  объектом нашего исследования. Предметом исследования являются основные  методы организации и проведения   диагностики современных компьютерных сетей.

"Диагностика локальной сети" - процесс (непрерывного) анализа состояния информационной сети. При возникновении неисправности сетевых устройств фиксируется факт неисправности, определяется ее место и вид. Сообщение о неисправности передается, устройство отключается и заменяется резервным [5, с. 153].

Сетевой администратор, на которого чаще всего ложатся функции по проведению диагностики, должен начинать изучать особенности своей сети уже на фазе ее формирования т.е. знать схему сети и подробное описание конфигурации программного обеспечения с указанием всех параметров   и  интерфейсов.  Для оформления и хранения этой информации  подойдут   специальные системы документирования сети.  Используя их, системный администратор,  будет заранее знать все возможные  «скрытые дефекты» и  «узкие места» своей системы, для того, чтобы в случае возникновения  нештатной ситуации   знать, с чем связана проблема    с оборудованием или программным обеспечением, повреждена программа или к ошибке привели действия оператора.

Сетевому администратору следует помнить, что с  точки зрения пользователей качество работы прикладного программного обеспечения в сети оказывается определяющим.   Все прочие критерии, такие как число ошибок передачи данных, степень загруженности сетевых ресурсов, производительность оборудования и т. п., являются вторичными. "Хорошая сеть" - это такая сеть, пользователи которой не замечают, как она работает [27, с. 135].

Предприятие

Преддипломная практика проходила на предприятии ООО «Геркон» в отделе сопровождения в должности системного администратора. Предприятие предлагает услуги доступа в Интернет в городах Верхняя Пышма и Среднеуральск по технологии Ethernet и коммутируемым (dial-up) каналам с 1993 года и является одним из первых поставщиков услуг Интернет в этих городах. Правила предоставления услуг урегулированы публичной офертой и регламентом.

Структура работы предприятия показана в Приложении А.

Научные и производственные задачи подразделения

Отдел сопровождения решает следующий спектр задач в пределах данного предприятия:

  •  техническая и технологическая организация предоставления доступа в Интернет по коммутируемым и выделенным каналам;
  •  техническая и технологическая организация беспроводного доступа в Интернет;
  •  выделение дискового пространства для хранения и обеспечения работы сайтов (хостинг);
  •  поддержка работы почтовых ящиков или виртуального почтового сервера;
  •  размещение оборудования клиента на площадке провайдера (колокация);
  •  аренда выделенных и виртуальных серверов;
  •  резервирование данных;
  •  развертывание и поддержка корпоративных сетей частных предприятий.

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


1 СИСТЕМЫ СЕТЕВОГО МОНИТОРИНГА

Несмотря на множество приемов и инструментов обнаружения и устранения неполадок в компьютерных сетях, «почва под ногами» сетевых администраторов все еще остается достаточно зыбкой. Компьютерные сети все чаще включают волоконно-оптические и беспроводные компоненты, наличие которых делает бессмысленным применение традиционных технологий и инструментов, предназначенных для обычных медных кабелей. Вдобавок к нему при скоростях свыше 100 Мбит/с традиционные подходы к диагностике зачастую перестают работать, даже если средой передачи является обычный медный кабель. Однако, возможно, наиболее серьезным изменением в компьютерных сетевых технологиях, с которым пришлось столкнуться администраторам, стал  неизбежный переход от сетей Ethernet с разделяемой средой передачи к коммутируемым сетям, в которых в качестве коммутируемых сегментов часто выступают отдельные серверы или рабочие станции.

Правда, по мере осуществления технологических преобразований некоторые старые проблемы решились сами собой. Коаксиальный кабель, в котором выявить электротехнические неисправности всегда было труднее, чем в случае витой пары, становится редкостью в корпоративных средах. Сети Token Ring, главной проблемой которых была их несхожесть с Ethernet (а вовсе не слабость в техническом отношении), постепенно заменяются коммутируемыми сетями Ethernet.  Порождающие  многочисленные сообщения об ошибках протоколов сетевого уровня протоколы, такие, как SNA, DECnet и AppleTalk, замещаются протоколом IP. Сам же стек протоколов IP стал более стабильным и простым для поддержки, что доказывают миллионы клиентов и миллиарды страниц Web в Internet. Даже закоренелым противникам Microsoft приходится признать, что подключение нового клиента Windows к Internet существенно проще и надежнее установки применявшихся ранее стеков TCP/IP сторонних поставщиков и отдельного программного обеспечения коммутируемого доступа.

Как бы многочисленные современные технологии ни затрудняли выявление неполадок и управление производительностью сетей, ситуация могла бы оказаться еще тяжелее, если бы технология АТМ получила широкое распространение на уровне ПК. Свою положительную роль сыграло и то, что в конце 90-х, не успев получить признание, были отвергнуты и некоторые другие высокоскоростные технологии обмена данными, включая Token Ring с пропускной способностью 100 Мбит/с, 100VG-AnyLAN и усовершенствованные сети ARCnet. Наконец, в США был отклонен очень сложный стек протоколов OSI (который, правда, узаконен рядом правительств европейских стран) [8, с. 15].

Рассмотрим некоторые  актуальные проблемы, возникающие у сетевых администраторов предприятий.

Иерархическая топология компьютерных сетей с магистральными каналами Gigabit Ethernet и выделенными портами коммутаторов на 10 или даже 100 Мбит/с для отдельных клиентских систем, позволила увеличить максимальную пропускную способность, потенциально доступную пользователям, как минимум в 10—20 раз. Конечно, в большинстве компьютерных сетей существуют узкие места на уровне серверов или маршрутизаторов доступа, поскольку приходящаяся на отдельного пользователя пропускная способность существенно меньше 10 Мбит/с. В связи с этим замена порта концентратора с пропускной способностью 10 Мбит/с на выделенный порт коммутатора на 100 Мбит/с для конечного узла отнюдь не всегда приводит к значительному увеличению скорости. Однако если учесть, что стоимость коммутаторов в последнее время снизилась, а на большинстве предприятий проложен кабель Категории 5, поддерживающий технологию Ethernet на 100 Мбит/с, и установлены сетевые карты, способные работать на скорости 100 Мбит/с сразу после перезагрузки системы, то становится ясно, почему так нелегко сопротивляться искушению модернизации. В традиционной локальной сети с разделяемой средой передачи анализатор протоколов или монитор может исследовать весь трафик данного сегмента сети.

Рис. 1.1 -  Традиционная  локальная сеть с разделяемой средой передачи и анализатором  протоколов

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

Рис. 1.2 – Коммутируемая сеть

В коммутируемой сети анализатор протоколов в одной точке может «видеть» только единственный сегмент, если коммутатор не способен зеркально отображать несколько портов одновременно.

Для сохранения контроля над сильно сегментированными сетями производители коммутаторов предлагают разнообразные средства для восстановления полной «видимости» сети, однако на этом пути остается немало трудностей. В поставляемых сейчас коммутаторах обычно поддерживается «зеркальное отображение» портов, когда трафик одного из них дублируется на ранее незадействованный порт, к которому подключается монитор или анализатор.

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

Частичным решением при анализе агрегированных параметров трафика является использование возможностей мониторинга агентов mini-RMON, тем более что они встроены в каждый порт большинства коммутаторов Ethernet. Хотя агенты mini-RMON не поддерживают группу объектов Capture из спецификации RMON II, обеспечивающих полнофункциональный анализ протоколов, они тем не менее позволяют оценить уровень использования ресурсов, количество ошибок и объем многоадресной рассылки.

Некоторые недостатки технологии зеркального отображения портов могут быть преодолены установкой «пассивных ответвителей», производимых, например, компанией Shomiti. Эти устройства представляют собой заранее устанавливаемые Y-коннекторы и позволяют отслеживать с помощью анализаторов протокола или другого устройства не регенерированный, а реальный сигнал [23, с. 17].

Следующей актуально проблемой, является проблема с особенностями оптики. Администраторы компьютерных сетей обычно используют специализированное оборудование диагностики оптических сетей только для решения проблем с оптическими кабелями. Обычное стандартное программное обеспечение управления устройствами на базе SNMP или интерфейса командной строки способно выявить проблемы на коммутаторах и маршрутизаторах с оптическими интерфейсами. И только немногие сетевые администраторы сталкиваются с необходимостью проводить диагностику устройств SONET.

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

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

Предприятиям, развернувшим крупную оптическую инфраструктуру и самостоятельно ее обслуживающим, может понадобиться приобрести оптический временный рефлектометр (Optical Time Domain Reflecto-meter, OTDR), выполняющего те же функции для оптического волокна, что и рефлектометр для медного кабеля (Time Domain Reflectometer, TDR). Прибор действует подобно радару: он посылает импульсные сигналы по кабелю и анализирует их отражения, на основании которых он выявляет повреждения в проводнике или какую-либо другую аномалию, и затем сообщает експерту, в каком месте кабеля следует искать источник проблемы.

Хотя различные поставщики кабельных соединителей и разъемов упростили процессы терминирования и разветвления оптического волокна, для этого по-прежнему требуется некоторый уровень специальных навыков, и при разумной политике предприятие с развитой оптической инфраструктурой вынуждено будет обучать своих сотрудников. Как бы хорошо ни была проложена кабельная сеть, всегда существует возможность физического повреждения кабеля в результате какого-либо неожиданного происшествия [2, с. 24].

При диагностике беспроводных локальных сетей стандарта 802.11b  также могут возникнуть проблемы. Сама по себе диагностика,  столь же проста, как и в случае сетей Ethernet на базе концентраторов, так как беспроводная среда передачи информации разделяется между всеми обладателями клиентских радиоустройств. Компания Sniffer TechНlogies первой предложила решение для анализа протоколов таких сетей с пропускной способностью до 11 Мбит/с, и впоследствии большинство лидирующих поставщиков анализаторов представили аналогичные системы.

В отличие от концентратора Ethernet с проводными соединениями, качество беспроводных клиентских соединений далеко от стабильного. Микроволновые радиосигналы, используемые во всех вариантах локальной передачи, слабы и порой непредсказуемы. Даже небольшие изменения положения антенны могут серьезно сказаться на качестве соединений. Точки доступа беспроводной локальной сети снабжаются консолью управления устройствами, и это часто более действенный метод диагностики, чем посещение клиентов беспроводной сети и наблюдение за пропускной способностью и условиями возникновения ошибок с помощью портативного анализатора.

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

Как правило, операторы корпоративных беспроводных сетей будут (или должны) препятствовать развертыванию чрезмерно открытых систем, в которых любой пользователь, находящийся в зоне действия сети и обладающий совместимой интерфейсной картой, получает доступ к каждому информационному кадру системы. Протокол безопасности беспроводных сетей WEP (Wired Equivalent Privacy) обеспечивает аутентификацию пользователей, гарантию целостности и шифрование данных, однако, как это обычно случается, совершенная система безопасности осложняет анализ причин сетевых неполадок. В защищенных сетях с поддержкой WEP специалисты по диагностике должны знать ключи или пароли, защищающие информационные ресурсы и контролирующие доступ в систему. При доступе в режиме приема всех пакетов анализатор протоколов сможет видеть все заголовки кадров, но содержащаяся в них информация без наличия ключей будет бессмысленной [23, с. 19].

При диагностировании туннелированных каналов, которые многие производители называют виртуальными частными сетями с удаленным доступом, возникающие проблемы аналогичны имеющим место при анализе беспроводных сетей с шифрованием. Если трафик не проходит через туннелированный канал, то причину неисправности определить нелегко. Это может быть ошибка аутентификации, поломка на одной из оконечных точек или затор в общедоступной зоне Internet. Попытка использования анализатора протоколов для выявления высокоуровневых ошибок в туннелированном трафике будет пустой тратой сил, потому что содержание данных, а также заголовки прикладного, транспортного и сетевого уровней зашифрованы. Вообще, меры, принимаемые в целях повышения уровня безопасности корпоративных сетей, обычно затрудняют выявление неисправностей и проблем производительности. Межсетевые экраны, proxy-серверы и системы выявления вторжений могут дополнительно осложнить локализацию неполадок [2, с. 31].

Таким образом,  проблема диагностики компьютерных  сетей является актуальной и в конечном счете, диагностирование неисправностей является задачей управления. Для большинства критически важных корпоративных систем, проведение продолжительных восстановительных работ не допустимо, поэтому единственным решением будет использование резервных устройств и процессов, способных взять на себя необходимые функции немедленно после возникновения сбоев. На некоторых предприятиях сети всегда имеют дополнительный резервный компонент на случай сбоя основного, т. е. n х 2 компонентов, где n — количество основных компонентов, необходимое для обеспечения приемлемой производительности. Если среднее время восстановления (Mean Time To Repair, MTTR) достаточно велико, то может понадобиться еще большая избыточность. Дело в том, что время устранения неисправности предсказать нелегко, а значительные затраты в течение непредсказуемого периода восстановления являются признаком плохого управления.

Для менее важных систем резервирование может оказаться экономически неоправданным, и в этом случае будет целесообразно вкладывать средства в наиболее эффективные инструменты (и в обучение персонала), чтобы максимально ускорить процесс диагностики и устранения неисправностей на предприятии. Кроме того, поддержку определенных систем можно доверить сторонним специалистам, либо привлекая их на предприятие по контракту, либо пользуясь возможностями внешних центров обработки данных, либо обращаясь к провайдерам услуг по сопровождению приложений (Application Service Providers, ASP) или провайдерам услуг управления. Помимо затрат наиболее значительным фактором, влияющим на решение об обращении к услугам сторонних организаций, можно считать уровень компетентности собственного персонала. Сетевые администраторы должны решить, не является ли некоторая конкретная функция настолько тесно связанной со специфическими задачами предприятия, что от стороннего специалиста нельзя будет ожидать более качественного выполнения работы, чем это будет сделано силами служащих компании.

Почти сразу после того, как были развернуты первые корпоративные сети, надежность которых оставляла желать лучшего, производители и разработчики выдвинули концепцию «самовосстанавливающихся сетей». Современные сети, безусловно, надежнее, чем они были в 90-х гг., но не потому, что неполадки стали самоустраняться. Ликвидация сбоев программного обеспечения и аппаратных средств современных сетей все еще требуют вмешательства человека, и в ближайшей перспективе в таком положении дел не предвидится никаких принципиальных изменений. Методы и инструменты диагностики вполне соответствуют современной практике и технологиям, но они еще не достигли такого уровня, который позволил бы значительно сэкономить время сетевых администраторов в их борьбе с неполадками сетей и дефицитом производительности [23, с. 23].

1.1 Программные средства диагностики

Среди программных средств диагностики компьютерных сетей, можно выделить специальные системы управления сетью (Network Management Systems) - централизованные программные системы, которые собирают данные о состоянии узлов и коммуникационных устройств сети, а также данные о трафике, циркулирующем в сети. Эти системы не только осуществляют мониторинг и анализ сети, но и выполняют в автоматическом или полуавтоматическом режиме действия по управлению сетью - включение и отключение портов устройств, изменение параметров мостов адресных таблиц мостов, коммутаторов и маршрутизаторов и т.п. Примерами систем управления могут служить популярные системы HPOpenView, SunNetManager, IBMNetView.

Средства управления системой (System Management) выполняют функции, аналогичные функциям систем управления, но по отношению  к коммуникационному  оборудованию. Вместе с тем, некоторые функции этих двух видов систем управления могут дублироваться, например, средства управления системой могут выполнять простейший анализ сетевого трафика [2, с. 38].

Экспертные системы. Этот вид систем аккумулирует человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние. Экспертные системы часто реализуются в виде отдельных подсистем различных средств мониторинга и анализа сетей: систем управления сетями, анализаторов протоколов, сетевых анализаторов. Простейшим вариантом экспертной системы является контекстно-зависимая help-система. Более сложные экспертные системы представляют собой так называемые базы знаний, обладающие элементами искусственного интеллекта. Примером такой системы является экспертная система, встроенная в систему управления Spectrum компании Cabletron.

1.1.1 Анализаторы протоколов

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

Для этих целей могут быть использованы разные средства и прежде всего - средства мониторинга в системах управления сетью, которые уже обсуждались ранее. Некоторые измерения на сети могут быть выполнены и встроенными в операционную систему программными измерителями, примером тому служит компонента ОС Windows Performance Monitor. Даже кабельные тестеры в их современном исполнении способны вести захват пакетов и анализ их содержимого [2, с. 45].

Но наиболее совершенным средством исследования сети является анализатор протоколов. Процесс анализа протоколов включает захват циркулирующих в сети пакетов, реализующих тот или иной сетевой протокол, и изучение содержимого этих пакетов. Основываясь на результатах анализа, можно осуществлять обоснованное и взвешенное изменение каких-либо компонент сети, оптимизацию ее производительности, поиск и устранение неполадок. Очевидно, что для того, чтобы можно было сделать какие-либо выводы о влиянии некоторого изменения на сеть, необходимо выполнить анализ протоколов и до, и после внесения изменения.

Анализатор протоколов представляет собой либо самостоятельное специализированное устройство, либо персональный компьютер, обычно переносной, класса Нtebook, оснащенный специальной сетевой картой и соответствующим программным обеспечением. Применяемые сетевая карта и программное обеспечение должны соответствовать топологии сети (кольцо, шина, звезда). Анализатор подключается к сети точно также, как и обычный узел. Отличие состоит в том, что анализатор может принимать все пакеты данных, передаваемые по сети, в то время как обычная станция - только адресованные ей. Программное обеспечение анализатора состоит из ядра, поддерживающего работу сетевого адаптера и декодирующего получаемые данные, и дополнительного программного кода, зависящего от типа топологии исследуемой сети. Кроме того, поставляется ряд процедур декодирования, ориентированных на определенный протокол, например, IPX. В состав некоторых анализаторов может входить также экспертная система, которая может выдавать пользователю рекомендации о том, какие эксперименты следует проводить в данной ситуации, что могут означать те или иные результаты измерений, как устранить некоторые виды неисправности сети.

Несмотря на относительное многообразие анализаторов протоколов, представленных на рынке, можно назвать некоторые черты, в той или иной мере присущие всем им:

Пользовательский интерфейс. Большинство анализаторов имеют развитый дружественный интерфейс, базирующийся, как правило, на Windows или Motif. Этот интерфейс позволяет пользователю: выводить результаты анализа интенсивности трафика; получать мгновенную и усредненную статистическую оценку производительности сети; задавать определенные события и критические ситуации для отслеживания их возникновения; производить декодирование протоколов разного уровня и представлять в понятной форме содержимое пакетов.

Буфер захвата. Буферы различных анализаторов отличаются по объему. Буфер может располагаться на устанавливаемой сетевой карте, либо для него может быть отведено место в оперативной памяти одного из компьютеров сети. Если буфер расположен на сетевой карте, то управление им осуществляется аппаратно, и за счет этого скорость ввода повышается. Однако это приводит к удорожанию анализатора. В случае недостаточной производительности процедуры захвата, часть информации будет теряться, и анализ будет невозможен. Размер буфера определяет возможности анализа по более или менее представительным выборкам захватываемых данных. Но каким бы большим ни был буфер захвата, рано или поздно он заполнится. В этом случае либо прекращается захват, либо заполнение начинается с начала буфера [23, с. 26].

Фильтры. Фильтры позволяют управлять процессом захвата данных, и, тем самым, позволяют экономить пространство буфера. В зависимости от значения определенных полей пакета, заданных в виде условия фильтрации, пакет либо игнорируется, либо записывается в буфер захвата. Использование фильтров значительно ускоряет и упрощает анализ, так как исключает просмотр ненужных в данный момент пакетов [2, с. 54].

Переключатели - это задаваемые оператором некоторые условия начала и прекращения процесса захвата данных из сети. Такими условиями могут быть выполнение ручных команд запуска и остановки процесса захвата, время суток, продолжительность процесса захвата, появление определенных значений в кадрах данных. Переключатели могут использоваться совместно с фильтрами, позволяя более детально и тонко проводить анализ, а также продуктивнее использовать ограниченный объем буфера захвата [23, с. 32].

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

Методология проведения анализа может быть представлена в виде следующих шести этапов:

1. Захват данных.
2. Просмотр захваченных данных.
3. Анализ данных.
4. Поиск ошибок. (Большинство анализаторов облегчают эту работу, определяя типы ошибок и идентифицируя станцию, от которой пришел пакет с ошибкой.)
5. Исследование производительности. Рассчитывается коэффициент использования пропускной способности сети или среднее время реакции на запрос.
6. Подробное исследование отдельных участков сети. Содержание этого этапа конкретизируется по мере того, как проводится анализ.

Обычно процесс анализа протоколов занимает относительно немного времени - 1-2 рабочих дня.

Большинство современных  анализаторов позволяют  анализировать сразу несколько протоколов глобальных сетей, таких, как X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, протоколы мостов/маршрутизаторов (3Com, Cisco, Bay Networks и другие). Такие анализаторы позволяют измерять различные параметры протоколов, анализировать трафик в сети, преобразование между протоколами локальных и глобальных сетей, задержку на маршрутизаторах при этих преобразованиях и т. п. Более совершенные приборы предусматривают возможность моделирования и декодирования протоколов глобальных сетей, 'стрессового' тестирования, измерения максимальной пропускной способности, тестирования качества предоставляемых услуг.   В целях универсальности почти все анализаторы протоколов глобальных сетей реализуют функции тестирования ЛВС и всех основных интерфейсов. Некоторые приборы способны осуществлять анализ протоколов телефонии. А самые современные модели могут декодировать и представлять в удобном варианте все семь уровней OSI. Появление ATM привело к тому, что производители стали снабжать свои анализаторы средствами тестирования этих сетей. Такие приборы могут проводить полное тестирование сетей АТМ уровня E-1/E-3 с поддержкой мониторинга и моделирования. Очень важное значение имеет набор сервисных функций анализатора. Некоторые из них, например возможность удаленного управления прибором, просто незаменимы [2, с. 65].

Таким образом, современные анализаторы протоколов WAN/LAН/ДTM позволяют обнаружить ошибки в конфигурации маршрутизаторов и мостов; установить тип трафика, пересылаемого по глобальной сети; определить используемый диапазон скоростей, оптимизировать соотношение между пропускной способностью и количеством каналов; локализовать источник неправильного трафика; выполнить тестирование последовательных интерфейсов и полное тестирование АТМ; осуществить полный мониторинг и декодирование основных протоколов по любому каналу; анализировать статистику в реальном времени, включая анализ трафика локальных сетей через глобальные сети.

1.1.2 Протоколы мониторинга

Протокол SNMP

SNMP (англ. Simple Network Management Protocol — простой прото-кол управления сетью) — это  протокол управления сетями связи на основе архитектуры TCP/IP.

На основе концепции TMN в 1980—1990 гг. различными органами стандартизации был выработан ряд протоколов управления сетями передачи данных с различным спектром реализации функций TMN. К одному из типов таких протоколов управления относится SNMP. Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

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

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

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

Аппаратный агент - встроенная аппаратура (с процессором и памятью), в которой хранятся программные агенты.

Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (Management Information Bases (MIBs)).

На сегодня существует несколько стандартов на базы данных управляющей информации [3, 4]. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого, существуют стандарты для специальных MIB устройств конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет до 114 объектов, которые подразделяются на 8 групп:

• System - общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).

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

• AddressTranslationTable - описывается соответствие между сетевыми и физическими адресами (например, по протоколу ARP).

• InternetProtocol - данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика об IP-пакетах).

• ICMP - данные, относящиеся к протоколу обмена управляющими сообщениями ICMP.

• TCP - данные, относящиеся к протоколу TCP (например, о TCP-соединениях).

• UDP - данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).

• EGP - данные, относящиеся к протоколу обмена маршрутной информацией ExteriorGatewayProtocol, используемому в сети Internet (число принятых с ошибками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10 [7, с. 19].

Агенты RMON

Новейшим добавлением к функциональным возможностям SNMP яв-ляется спецификация RMON, которая обеспечивает удаленное взаимодействие с базой MIB.

Стандарт на RMON появился в ноябре 1991 года, когда Internet Engineering Task Force выпустил документ RFC 1271 под названием "Remote Network Monitoring Management Information Base" ("Информационная база дистанционного мониторинга сетей"). Данный документ содержал описание RMON для сетей Ethernet.

RMON — протокол мониторинга компьютерных сетей, расширение SNMP, в основе которого, как и в основе SNMP, лежит сбор и анализ информации о характере информации, передаваемой по сети. Как и в SNMP, сбор информации осуществляется аппаратно-программными агентами, данные от которых поступают на компьютер, где установлено приложение управления сетью. Отличие RMON от своего предшественника состоит, в первую очередь, в характере собираемой информации — если в SNMP эта информация характеризует только события, происходящие на том устройстве, где установлен агент, то RMON требует, чтобы получаемые данные характеризовали трафик между сетевыми устройствами.

До появления RMON протокол SNMP не мог использоваться удален-ным образом, он допускал только локальное управление устройствами. База RMON MIB обладает улучшенным набором свойств для удаленного управления, так как содержит агрегированную информацию об устрой-стве, что не требует передачи по сети больших объемов информации. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа графических трендов и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB более интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных коммуникационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих на универсальных ПК и ноутбуках (примером может служить LANalyzerНvell).

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

Сбор информации RMON осуществляется аппаратно-программными зондами, подключаемыми непосредственно к сети. Чтобы выполнить задачу сбора и первичного анализа данных, зонд должен обладать достаточными вычислительными ресурсами и объемом оперативной памяти. В настоящее время на рынке имеются зонды трех типов: встроенные, зонды на базе компьютера, и автономные. Продукт считается поддерживающим RMON, если в нем реализована хотя бы одна группа RMON. Разумеется, чем больше групп данных RMON реализовано в данном продукте, тем он, с одной стороны, дороже, а с другой - тем более полную информацию о работе сети он предоставляет.

Встроенные зонды представляют собой модули расширения для сетевых устройств. Такие модули выпускаются многими производителями, в частности, такими крупными компаниями, как 3Com, Cabletron, Bay Networks и Cisco. (Кстати, 3Com и Bay Networks недавно приобрели компании Axon и ARMON, признанных лидеров в области разработки и производства средств управления RMON. Такой интерес к этой технологии со стороны крупнейших производителей сетевого оборудования лишний раз показывает, насколько нужным для пользователей является дистанционный мониторинг.) Наиболее естественным выглядит решение встраивать модули RMON в концентраторы, ведь именно из наблюдения за этими устройствами можно со-ставить себе представление о работе сегмента. Достоинство таких зондов очевидно: они позволяют получать информацию по всем основным группам данных RMON при относительно невысокой цене. Недостатком в первую очередь является не слишком высокая производительность, что проявляется, в частности, в том, что встроенные зонды часто поддерживают далеко не все группы данных RMON. Не так давно 3Com объявила о намерении выпустить поддерживающие RMON драйверы для сетевых адаптеров Etherlink III и Fast Ethernet. В результате окажется возможным собирать и анализировать данные RMON непосредственно на рабочих станциях в сети.

Зонды на базе компьютера - это просто подключенные к сети компьютеры с установленным на них программным агентом RMON. Такие зонды (к числу которых относится, например, продукт Cornerstone Agent 2.5 компании Network General) обладают более высокой производительностью, чем встроенные зонды, и поддерживают, как правило, все группы данных RMON. Они более дороги, чем встроенные зонды, но гораздо дешевле автономных зондов. Помимо этого, зонды на базе компьютера имеют довольно большой размер, что может иногда ограничивать возможности их применения.

Автономные зонды обладают наивысшей производительностью; как легко понять, это одновременно и наиболее дорогие продукты из всех описанных. Как правило, автономный зонд - это процессор (класса i486 или RISC-процессор), оснащенный достаточным объемом оперативной памяти и сетевым адаптером. Лидерами в этом секторе рынка являются компании Frontier и Hewlett-Packard. Зонды этого типа невелики по размеру и весьма мобильны - их очень легко подключать к сети и отключать от нее. При решении задачи управления сетью глобального масштаба это, конечно, не слишком важное свойство, однако если средства RMON применяются для анализа работы корпоративной сети средних размеров, то (учитывая высокую стоимость устройств) мобильность зондов может сыграть весьма положительную роль.

Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет в соответствии с документом RFC 1271,   состоит из десяти групп данных.

• Statistics - текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т.п.

• History - статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.

• Alarms - пороговые значения статистических показателей, при превышении которых агент RMON посылает сообщение менеджеру.  Позволяет пользователю определить ряд пороговых уровней (эти пороги могут относиться к самым разным вещам - любому параметру из группы статистики, амплитуде или скорости его изменения и многому другому), по превышении которых генерируется аварийный сигнал. Пользователь может также определить, при каких условиях превышение порогового значения должно сопровождаться аварийным сигналом - это позволит избежать генерации сигнала "по пустякам", что плохо, во-первых, потому, что на постоянно горящую красную лампочку никто не обращает внимания, а во-вторых, потому, что передача ненужных аварийных сигналов по сети приводит к излишней загрузке линий связи. Аварийный сигнал, как правило, передается в группу событий, где и определяется, что с ним делать дальше.

• Host - данных о хостах сети, в том числе и об их MAC-адресах..

• HostTopN - таблица наиболее загруженных хостов сети. Таблица N главных хостов (HostTopN) содержит список N первых хостов, характеризующихся максимальным значением заданного статистического параметра для заданного интервала. Например, можно затребовать список 10 хостов, для которых наблюдалось максимальное количество ошибок в течение последних 24 часов. Список этот будет составлен самим агентом, а приложение управления получит только адреса этих хостов и значения соответствующих статистических параметров. Видно, до какой степени такой подход экономит сетевые ресурсы

• TrafficMatrix - статистика об интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы.  Строки этой матрицы пронумерованы в соответствии с MAC-адресами станций - источников сообщений, а столбцы - в соответствии с адресами станций-получателей. Матричные элементы характеризуют интенсивность трафика между соответствующими станциями и количество ошибок. Проанализировав такую матрицу, пользователь легко может выяснить, какие пары станций генерируют наиболее интенсивный трафик. Эта матрица, опять-таки, формируется самим агентом, поэтому отпадает необходимость в передаче больших объемов данных на центральный компьютер, отвечающий за управление сетью.

• Filter - условия фильтрации пакетов. Признаки, по которым фильтруются пакеты, могут быть самыми разнообразными - например, можно потребовать отфильтровывать как ошибочные все пакеты, длина которых оказывается меньше некоторого заданного значения. Можно сказать, что установка фильтра соответствует как бы организации канала для передачи пакета. Куда ведет этот канал - определяет пользователь. Например, все ошибочные пакеты могут перехватываться и направляться в соответсвующий буфер. Кроме того, появление пакета, соответствующего установленному фильтру, может рассматриваться как событие (event), на которое система должна реагировать заранее оговоренным образом.

• PacketCapture - условия захвата пакетов. В состав группы перехвата пакетов (packet capture) входят буфера для захвата, куда направляются пакеты, чьи признаки удовлетворяют условиям, сформулированным в группе фильтров. При этом захватываться может не пакет целиком, а, скажем, только первые несколько десятков байт пакета. Содержимое буферов перехвата можно впоследствии анализировать при помощи различных программных средств, выясняя целый ряд весьма полезных характеристик работы сети. Перестраивая фильтры на те или иные признаки, можно характеризовать разные параметры работы сети.

• Event - условия регистрации и генерации событий. В группе событий (events) определяется, когда следует отправлять аварийный сигнал приложению управления, когда - перехватывать пакеты, и вообще - как реагировать на те или иные события, происходящие в сети, например, на превышение заданных в группе alarms пороговых значений: следует ли ставить в известность приложение управления, или надо просто запротоколировать данное событие и продолжать работать. События могут и не быть связаны с предачей аварийных сигналов - например, направление пакета в буфер перехвата тоже представляет собой событие.

Данные группы пронумерованы в указанном порядке, поэтому, например, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Десятую группу составляют специальные объекты протокола TokenRing.

Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафиксированных в двух документах - RFC 1271 для сетей Ethernet и RFC 1513 для сетей TokenRing [28, с. 95].

Отличительной чертой стандарта RMON MIB является его независи-мость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому, его удобно использовать в гетерогенных средах, использующих различные протоколы сетевого уровня.

1.2 Популярные системы управления сетями

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

Системы  управления  сетями должны  обладать целым рядом качеств:  

• истинной распределенностью в соответствии с концепцией кли-ент/сервер,

• масштабируемостью,

• открытостью, позволяющей справиться с разнородным - от настольных компьютеров до мейнфреймов - оборудованием.

Первые два свойства тесно связаны. Хорошая масштабируемость достигается за счет распределенности системы управления. Распределенность означает, что система может включать несколько серверов и клиентов. Серверы (менеджерами) собирают данные о текущем состоянии сети от агентов (SNMP, CMIP или RMON), встроенных в оборудование сети, и накапливают их в своей базе данных. Клиенты представляют собой графические консоли, за которыми работают администраторы сети. Программное обеспечение клиента системы управления принимает запросы на выполнение каких-либо действий от администратора (например, построение подробной карты части сети) и обращается за необходимой информацией к серверу. Если сервер обладает нужной информацией, то он сразу же передает ее клиенту, если нет - то пытается собрать ее от агентов.

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

Поддержка разнородного оборудования - скорее желаемое, чем реально существующее свойство сегодняшних систем управления. К числу наиболее популярных продуктов сетевого управления относятся четыре системы: Spectrum компании CabletronSystems, OpenView фирмы Hewlett-Packard, NetView корпорации IBM и Solstice производства SunSoft - подразделения SunMicrosystems. Три компании из четырех сами выпускают коммуникационное оборудование. Естественно, что система Spectrum лучше всего управляет оборудованием компании Cabletron, OpenView - оборудованием компании Hewlett-Packard, а NetView- оборудованием компании IBM.

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

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей. Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании BayNetworks, CiscoWorks компании CiscoSystems, Transcend компании 3Com. Система Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании BayNetwork, полностью используя все их возможности и свойства. Оборудование других производителей под-держивается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNetManager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими системами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью [9, с. 76].

Тем не менее, если в сети преобладает оборудование от какого-либо одного производителя, то наличие приложений управления этого производителя для какой-либо популярной платформы управления позволяет администраторам сети успешно решать многие задачи. Поэтому разработчики платформ управления поставляют вместе с ними инструментальные средства, упрощающие разработку приложений, а наличие таких приложений и их количество считаются очень важным фактором при выборе платформы управления.

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как Oracle, Ingres или Informix. Использование универсальных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

В Приложении Б в виде таблицы показан обзор наиболее популярных систем сетевого мониторинга на сегодняшний день.


2 ПОСТАНОВКА ЗАДАЧИ

С ростом клиентской базы, а как следствие и числа активного оборудования, возникла необходимость оперативного отслеживания состояния сети в целом и отдельных её элементов в подробности. До внедрения системы сетевого мониторинга сетевому администратору приходилось подключаться посредствам протоколов telnet, http, snmp, ssh и т.п. к каждому интересующему узлу сети и пользоваться встроенными средствами мониторинга и диагностики. На данный момент емкость сети составляет 5000 портов, 300 коммутаторов 2-го уровня, 15 маршрутизаторов и 20 серверов внутреннего пользования.

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

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

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

2.1 Техническое задание

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

 2.2 Уточненное техническое задание

В ходе дальнейшей формулировки проблемы и исследования предметной области, с учетом экономических и временных вложений было проведено уточнение технического задания:

Система должна удовлетворять следующим требованиям:

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


3 ПРЕДЛАГАЕМАЯ СИСТЕМА

3.1 Выбор системы сетевого мониторинга

В соответствии с уточненным техническим заданием, лучше всего в качестве ядра системы сетевого мониторинга подходит система Nagios, так как она обладает следующими качествами:

  •  имеются средства генерирования диаграмм;
  •  имеются средства генерирования отчетностей;
  •  есть возможность логического группирования;
  •  существует встроенная система записи трендов и их прогнозирования;
  •  имеется возможность автоматического добавления новых устройств (Autodiscovery) при помощи официального плагина;
  •  имеется возможность расширенного мониторинга хоста с использованием агента;
  •  поддержка протокола SNMP через плагин;
  •  поддержка протокола Syslog через плагин;
  •  поддержка внешних скриптов;
  •  поддержка самописных плагинов и возможность их быстрого и простого создания;
  •  встроенные триггеры и события;
  •  полнофункциональный веб-интерфейс;
  •  возможность распределенного мониторинга;
  •  инвентаризация через плагин;
  •  возможность хранения данных как в файлах, так и в базах данных SQL, что очень важно при увеличении объемов;
  •  лицензия GPL, а следовательно бесплатная базовая поставка, поддержка и открытые исходные коды ядра системы и сопровождающих компонентов;
  •  динамические и настраиваемые карты;
  •  управление доступом;
  •  встроенный язык описания хостов, сервисов и проверок;
  •  возможность отслеживания пользователей.

Система сетевого мониторинга Zabbix обладает схожим набором параметров, но на момент внедрения обладала гораздо более меньшим функционалом, чем Nagios и имела статус beta-версии. Кроме того, исследование тематических форумов и новостных лент показало наибольшую распространенность среди пользователей именно Nagios, что означает наличие написанной пользователями документации и максимально подробно описанных сложных моментов в настройке.

Nagios позволяет производить мониторинг таких сетевых сервисов как SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и многих других. Кроме этого, можно следить за использованием ресурсов серверов, таких как расход дискового пространства, свободная память и загруженность процессора. Существует возможность создавать свои собственные обработчики событий. Эти обработчики будут выполняться при возникновении тех или иных событий, инициированных проверками сервисов или серверов. Такой подход позволит активно реагировать на происходящие события и пытаться автоматически решать возникшие проблемы. К примеру, можно создать обработчик событий, который будет самостоятельно перезапускать повисший сервис. Еще одним достоинством системы мониторинга Nagios является возможность управлять ею удаленно с помощью wap интерфейса мобильного телефона. Используя концепцию "родительских" хостов, легко описать иерархию и зависимости между всеми хостами. Такой подход чрезвычайно полезен для больших сетей, потому что позволяет производить сложную диагностику. А это качество, в свою очередь, помогает отличить не работающие хосты, от тех, что недоступны в данный момент из-за неполадок в работе промежуточных звеньев. Nagios умеет строить графики работы наблюдаемых систем и карты контролируемой сетевой инфраструктуры.

Из своей практики работы с Nagios автор может привести пример, показывающий, насколько полезен он оказался для в его личной практике. На внешнем сетевом интерфейсе брандмауэра с периодичностью в несколько часов начиналась потеря пакетов. Из-за неисправности терялось до 20 процентов проходящего трафика. По истечении минуты - другой интерфейс снова начинал работать как положено. По причине плавающего характера этой неполадки несколько недель не удавалось выяснить, почему при работе с Интернет периодически происходят кратковременные сбои. Без Nagios поиск неисправности затянулся бы надолго.

Многим из администраторов хорошо знаком предок Nagios по имени NetSaint. Несмотря на то, что сайт проекта NetSaint все еще исправно функционирует, новые разработки базируются уже на исходном коде Nagios. Поэтому всем рекомендуется потихоньку перебираться на Nagios.

В документации, поставляемой с Nagios, говорится, что он будет стабильно работать и со многими другими Unix подобными системами. Для отображения web-интерфейса Nagios нам понадобится сервер Apache. Вы вольны, использовать любой другой, но в данной работе будет рассматриваться именно Apache, как наиболее распространенный на Unix платформах web-сервер. Можно установить систему мониторинга вообще без web-интерфейса, но мы так делать не станем, потому что это существенно уменьшает удобство пользования [35, с. 52].


4 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В качестве аппаратной части внедряемой системы можно использовать обычный IBM-совместимый компьютер, однако с учетом возможности дальнейшего повышения нагрузки и требований надежности и наработки на отказ, а также ГосСвязьНадзора, было приобретено сертифицированное серверное оборудование фирмы Aquarius.

В существующей сети активно используется операционная система Debian на базе ядра Linux, имеется обширный опыт использования этой системы, отлажено большинство операций по управлению, настройке и обеспечению стабильности её работы. Кроме того, данная ОС распространяется по лицензии GPL, что говорит о её бесплатности и открытости исходных кодов, что соответствует уточненному техническому заданию на проектирование системы сетевого мониторинга.

Linux (полное название GNU/Linux, произносится «гну слэш ли́нукс», также в некоторых языках «GNU+Linux», «GNU-Linux» и др.) — общее название UNIX-подобных операционных систем на основе одноимённого ядра и собранных для него библиотек и системных программ, разработанных в рамках проекта GNU.

GNU/Linux работает на PC-совместимых системах семейства Intel x86, а также на IA-64, AMD64, PowerPC, ARM и многих других.

К операционной системе GNU/Linux также часто относят программы, дополняющие эту операционную систему, и прикладные программы, делающие её полноценной многофункциональной операционной средой.

В отличие от большинства других операционных систем, GNU/Linux не имеет единой «официальной» комплектации. Вместо этого GNU/Linux поставляется в большом количестве так называемых дистрибутивов, в которых программы GNU соединяются с ядром Linux и другими программами. Наиболее известными дистрибутивами GNU/Linux являются Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Российские дистрибутивы — ALT Linux и ASPLinux.

В отличие от Microsoft Windows (Windows NT), Mac OS (Mac OS X) и коммерческих UNIX-подобных систем, GNU/Linux не имеет географического центра разработки. Нет и организации, которая владела бы этой системой; нет даже единого координационного центра. Программы для Linux — результат работы тысяч проектов. Некоторые из этих проектов централизованы, некоторые сосредоточены в фирмах. Многие проекты объединяют хакеров со всего света, которые знакомы только по переписке. Создать свой проект или присоединиться к уже существующему может любой и, в случае успеха, результаты работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую, что позволяет быстро находить и исправлять ошибки и реализовывать новые возможности.

История развития UNIX-систем. GNU/Linux является UNIX-совместимой, однако основывается на собственном исходном коде

Именно такая гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность[источник не указан 199 дней] GNU/Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение людей из разных стран, обладающих разным видением проблем, защита кода лицензией GPL — всё это стало причиной успеха свободных программ.

Конечно, такая высокая эффективность разработки не могла не заинтересовать крупные фирмы, которые стали открывать свои проекты. Так появились Mozilla (Netscape, AOL), OpenOffice.org (Sun), свободный клон Interbase (Borland) — Firebird, SAP DB (SAP). IBM способствовала переносу GNU/Linux на свои мейнфреймы.

С другой стороны, открытый код значительно снижает себестоимость разработки закрытых систем для GNU/Linux и позволяет снизить цену решения для пользователя. Вот почему GNU/Linux стала платформой, часто рекомендуемой для таких продуктов, как СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Сообщество GNU/Linux поддерживает связь посредством групп пользователей Linux.

Большинство пользователей для установки GNU/Linux используют дистрибутивы. Дистрибутив — это не просто набор программ, а ряд решений для разных задач пользователей, объединённых едиными системами установки, управления и обновления пакетов, настройки и поддержки.

Самые распространённые в мире дистрибутивы:

Ubuntu — быстро завоевавший популярность дистрибутив, ориентированный на лёгкость в освоении и использовании.

openSUSE — бесплатно распространяемая версия дистрибутива SuSE, принадлежащая компании Novell. Отличается удобством в настройке и обслуживании благодаря использованию утилиты YaST.

Fedora — поддерживается сообществом и корпорацией RedHat, предшествует выпускам коммерческой версии RHEL.

Debian GNU/Linux — международный дистрибутив, разрабатываемый обширным сообществом разработчиков в некоммерческих целях. Послужил основой для создания множества других дистрибутивов. Отличается строгим подходом к включению несвободного ПО.

Mandriva — французско-бразильский дистрибутив, объединение бывших Mandrake и Conectiva (англ.).

Slackware — один из старейших дистрибутивов, отличается консервативным подходом в разработке и использовании.

Gentoo — дистрибутив, собираемый из исходных кодов. Позволяет очень гибко настраивать конечную систему и оптимизировать производительность, поэтому часто называет себя мета-дистрибутивом. Ориентирован на экспертов и опытных пользователей.

Archlinux — ориентированный на применение самых последних версий программ и постоянно обновляемый, поддерживающий одинаково как бинарную, так и установку из исходных кодов и построенный на философии простоты KISS, этот дистрибутив ориентирован на компетентных пользователей, которые хотят иметь всю силу и модифицируемость Linux, но не в жертву времени обслуживания.

Помимо перечисленных, существует множество других дистрибутивов, как базирующихся на перечисленных, так и созданных с нуля и зачастую предназначенных для выполнения ограниченного количества задач.

Каждый из них имеет свою концепцию, свой набор пакетов, свои достоинства и недостатки. Ни один не может удовлетворить всех пользователей, а потому рядом с лидерами благополучно существуют другие фирмы и объединения программистов, предлагающие свои решения, свои дистрибутивы, свои услуги. Существует множество LiveCD, построенных на основе GNU/Linux, например, Knoppix. LiveCD позволяет запускать GNU/Linux непосредственно с компакт-диска, без установки на жёсткий диск.

Для желающих досконально разобраться с GNU/Linux подойдёт любой из дистрибутивов, однако довольно часто для этой цели используются так называемые source-based дистрибутивы, то есть предполагающие самостоятельную сборку всех (или части) компонентов из исходных кодов, такие как LFS, Gentoo, ArchLinux или CRUX [9, с. 94].

4.1 Установка ядра системы

Nagios можно устанавливать двумя способами – из исходных кодов и из собранных пакетов. У обоих способов есть преимущества и недостатки, рассмотрим их.

Плюсы установки пакета их исходных кодов:

  •  возможность детального конфигурирования системы;
  •  высокая степень оптимизации приложения;
  •  наиболее полное представление работы программы.

Минусы установки пакета их исходных кодов:

  •  требуется дополнительное время на сборку пакета, часто превышающее время на его настройку и наладку;
  •  невозможность удалить пакет вместе с конфигурационными файлами;
  •  невозможность обновить пакет вместе с конфигурационными файлами;
  •  невозможность централизованного контроля за установленными приложениями.

При установке Nagios из предварительно собранного пакета, достоинства «сырого» метода установки становятся недостатками, и  наоборот. Однако, как показала практика, собранный заранее пакет удовлетворяет всем требованиям, предъявляемым к системе и нет смысла тратить время на ручную сборку пакета [29, с. 35].

Так как изначально были опробованы оба метода установки, то рассмотрим более детально каждый из них.

4.1.1 Описание установки ядра системы их исходных кодов

Требуемые пакеты.

Необходимо удостовериться, что следующие пакеты установлены до начала развертывания Nagios. Детальное рассмотрение процесса их установки выходит за рамки данной работы.

  •  Apache 2
  •  PHP
  •  GCC компилятор и библиотеки разработчика
  •  GD библиотеки разработчика

Можно использовать утилиту apt-get (лучше aptitude) для их установки следующим образом:

% sudo apt-get install apache2
% sudo apt-get install libapache2-mod-php5
% sudo apt-get install build-essential
% sudo apt-get install libgd2-dev

1) Создание нового пользовательского непривилигированного аккаунта

Новый аккаунт создается для запуска службы Nagios. Можно это делать и из-под учетной записи суперпользователя, что создаст серьезную угрозу для безопасности системы.

Станем суперпользователем:

% sudos

Создадим новую учетную запись пользователя nagios и дадим ей пароль:

# /usr/sbin/useradd -m -s /bin/bash nagios

# passwd nagios

Создадим группу nagios и добавим в неё пользователя nagios:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

Создадим группу nagcmd для разрешения выполнения внешних команд, переданных через веб-интерфейс. Добавим в эту группу пользователей nagios и apache:

# /usr/sbin/groupadd nagcmd

# /usr/sbin/usermod -a -G nagcmd nagios

# /usr/sbin/usermod -a -G nagcmd www-data

2) Скачаем Nagios и плагины к нему

Создадим директорию для хранение скаченных файлов:

# mkdir ~/downloads

# cd ~/downloads

Качаем сжатые исходные коды Nagios и его плагинов (http://www.nagios.org/download):

# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.0.tar.gz

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz

3) Компилируем и устанавливаем Nagios

Распакуем сжатые исходные коды Nagios:

# cd ~/downloads

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Запускаем конфигурационный скрипт Nagios, передав ему имя группы, которую мы создали ранее:

# ./configure --with-command-group=nagcmd

Полный список параметров конфигурационного скрипта:

#./configure --help

`configure' configures this package to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as

VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:

-h, --help              display this help and exit

    --help=short       display options specific to this package

    --help=recursive  display the short help of all the included packages

-V, --version           display version information and exit

-q, --quiet, --silent  do not print `checking...' messages

    --cache-file=FILE cache test results in FILE [disabled]

-C, --config-cache   alias for `--cache-file=config.cache'

-n, --no-create        do not create output files

    --srcdir=DIR         find the sources in DIR [configure dir or `..']

Installation directories:

--prefix=PREFIX         install architecture-independent files in PREFIX[/usr/local/nagios]

--exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX[PREFIX]

By default, `make install' will install all the files in `/usr/local/nagios/bin', `/usr/local/nagios/lib' etc.  You can specify an installation prefix other than `/usr/local/nagios' using `--prefix', for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:

--bindir=DIR           user executables [EPREFIX/bin]

--sbindir=DIR          system admin executables [EPREFIX/sbin]

--libexecdir=DIR       program executables [EPREFIX/libexec]

--datadir=DIR          read-only architecture-independent data [PREFIX/share]

--sysconfdir=DIR      read-only single-machine data [PREFIX/etc]

--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]

--localstatedir=DIR    modifiable single-machine data [PREFIX/var]

--libdir=DIR              object code libraries [EPREFIX/lib]

--includedir=DIR       C header files [PREFIX/include]

--oldincludedir=DIR   C header files for non-gcc [/usr/include]

--infodir=DIR           info documentation [PREFIX/info]

--mandir=DIR           man documentation [PREFIX/man]

System types:

--build=BUILD     configure for building on BUILD [guessed]

--host=HOST       cross-compile to build programs to run on HOST [BUILD]

Optional Features:

--disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)

--enable-FEATURE[=ARG]  include FEATURE [ARG=yes]

--disable-statusmap=disables compilation of statusmap CGI

--disable-statuswrl=disables compilation of statuswrl (VRML) CGI

--enable-DEBUG0 shows function entry and exit

--enable-DEBUG1 shows general info messages

--enable-DEBUG2 shows warning messages

--enable-DEBUG3 shows scheduled events (service and host checks... etc)

--enable-DEBUG4 shows service and host notifications

--enable-DEBUG5 shows SQL queries

--enable-DEBUGALL shows all debugging messages

--enable-nanosleep enables use of nanosleep (instead sleep) in event timing

--enable-event-broker enables integration of event broker routines

--enable-embedded-perl will enable embedded Perl interpreter

--enable-cygwin enables building under the CYGWIN environment

Optional Packages:

--with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]

--without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)

--with-nagios-user=<user> sets user name to run nagios

--with-nagios-group=<grp> sets group name to run nagios

--with-command-user=<user> sets user name for command access

--with-command-group=<grp> sets group name for command access

--with-mail=<path_to_mail> sets path to equivalent program to mail

--with-init-dir=<path> sets directory to place init script into

--with-lockfile=<path> sets path and file name for lock file

--with-gd-lib=DIR sets location of the gd library

--with-gd-inc=DIR sets location of the gd include files

--with-cgiurl=<local-url> sets URL for cgi programs (do not use a trailing slash)

--with-htmurl=<local-url> sets URL for public html

--with-perlcache turns on cacheing of internally compiled Perl scripts

Some influential environment variables:

CC          C compiler command

CFLAGS    C compiler flags

LDFLAGS   linker flags, e.g. -L<lib dir> if you have libraries in a

               nonstandard directory <lib dir>

CPPFLAGS  C/C++ preprocessor flags, e.g. -I<include dir> if you have

                headers in a nonstandard directory <include dir>

CPP           C preprocessor

Use these variables to override the choices made by `configure' or to help

it to find libraries and programs with nonstandard names/locations.

Компилируем исходный код Nagios.

# make all

Установим бинарные файлы, скрипт инициализации, примеры конфигурационных файлов и установим разрешения на директорию внешних команд:

# make install

# make install-init

# make install-config

# make install-commandmode

4) Изменим конфигурацию

Примеры конфигурационных файлов установлены в директорию /usr/local/nagios/etc. Они должны сразу быть рабочими. Нужно сделать лишь одно изменение перед тем, как продолжить.

Отредактируем конфигурационный файл /usr/local/nagios/etc/objects/contacts.cfg любым текстовым редактором и изменим email адрес привязанный к определению контакта nagiosadmin на адрес, на который мы собираемся принимать сообщения о неполадках.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Настройка веб-интерфейса

Установим конфигурационный файл веб-интерфейса Nagios в директорию Apache conf.d.

# make install-webconf

Создадим учетную запись nagiosadmin для входа в веб-интерфейс Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Перезапустим Apache, чтобы изменения вступили в силу.

# /etc/init.d/apache2 reload

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

6) Компилируем и устанавливаем плагины Nagios

Распакуем сжатые исходные коды плагинов Nagios:

# cd ~/downloads

# tar xzf nagios-plugins-1.4.11.tar.gz

# cd nagios-plugins-1.4.11

Компилируем и устанавливаем плагины:

# ./configure --with-nagios-user=nagios --with-nagios-group=nagios

# make

#make install

7) Запускаем службу Nagios

Настроим Nagios на автоматическую загрузку при включении операционной системы:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Проверим синтаксическую правильность примерных конфигурационных файлов:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Если ошибок нет, то запускаем Nagios:

# /etc/init.d/nagios start

8) Входим на веб-интерфейс

Теперь можно войти в веб-интерфейс Nagios, используя следующий URL. Будет выдан запрос на ввод имени пользователя (nagiosadmin) и пароля, которые мы задали ранее.

http://192.168.10.2/nagios3/

9) Прочие настройки

Для получения напоминаний по email о событиях Nagios, необходимо установить пакет mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Необходимо отредактировать команды напоминаний Nagios файле /usr/local/nagios/etc/objects/commands.cfg и изменить все ссылки с '/bin/mail' на '/usr/bin/mail'. После этого необходимо перезапустить службу Nagios:

# sudo /etc/init.d/nagios restart

 Подробная конфигурация почтового модуля описана в Приложении Г.

4.1.2 Описание установки ядра системы из репозитария

Как было показано выше, установка Nagios из исходных текстов занимает значительное время и имеет смысл только при требовании тщательной оптимизации приложения или желании досконально разобраться с механизмом работы системы. В рабочих условиях большинство программного обеспечения устанавливается из репозитариев в виде предкомпилированных пакетов. В этом случае установка сводится к вводу одной команды:

% sudo aptitude install nagios

Менеджер пакетов самостоятельно удовлетворит все зависимости и установит необходимые пакеты.

 4.2 Конфигурирование ядра системы

Перед детальной настройкой следует понимать то, как работает ядро Nagios. Его графическое описание приведено ниже в иллюстрации 6.2.

4.2.1 Описание работы ядра системы

На следующем рисунке показана упрощенная схема работы службы Nagios.

Рис. 4.1 – Ядро системы

Служба Nagios читает основной конфигурационный файл, в котором помимо основных параметров работы службы имеются ссылки на файлы ресурсов, файлы описания объектов и конфигурационные файлы CGI [9, с. 94].

Алгоритм и логика работы ядра сетевого мониторинга показаны ниже.

Рис. 4.2 – Алгоритм оповещений Nagios

Диаграмма работы ядра сетевого мониторинга показана в Приложении Д.

4.2.2 Описание взаимодействия конфигурационных файлов

В директории /etc/apache2/conf.d/ находится файл nagios3.conf, из которого веб-сервер apache берет настройки для nagios.

Конфигурационные файлы nagios находятся в директории /etc/nagios3.

Файл /etc/nagios3/htpasswd.users содержит пароли для пользователей nagios. Команда для создания файла и установки пароля для пользователя nagios по умолчанию приведена выше. В дальнейшем, необходимо будет опустить аргумент "-c" при задании пароля для нового пользователя, иначе новый файл затрет старый.

Файл /etc/nagios3/nagios.cfg содержит основную конфигурацию самого nagios. Например, файлы журналов событий или путь к остальным конфигурационным файлам, которые nagios зачитывает при старте.

В директории /etc/nagios/objects задаются новые хосты и сервисы.

Схематично взаимодействие конфигурационных файлов показано в Приложении Ж.

4.2.3 Заполнение описаний хостов и служб

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

Созданная структура показана в Приложении З.

Файл hosts.cfg

Сначала нужно описать хосты, за которыми будет выполняться наблюдение. Можно описать сколь угодно много хостов, но в этом файле мы ограничимся общими параметрами для всех хостов.

Здесь описанный хост это не настоящий хост, а шаблон, на котором основываются описания всех остальных хостов. Такой же механизм можно встретить и в других конфигурационных файлах, когда конфигурация основывается на предварительно определенном множестве значений по умолчанию.

Файл hostgroups.cfg

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

Файл contactgroups.cfg

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

Следующим шагом нужно указать контактную информацию и настройки оповещений.

Файл contacts.cfg

Помимо того, что в этом файле приводится дополнительная контактная информация пользователей, одно из полей, contact_name, имеет ещё одно назначение. CGI-cкрипты используют имена, заданные в этих полях для того чтобы определить, имеет пользователь право доступа к какому-то ресурсу или нет. Вы должны настроить аутентификацию, основывающуюся на .htaccess, но кроме этого нужно использовать те же имена, которые использованы выше, для того чтобы пользователи могли работать через Web-интерфейс.

Теперь, когда хосты и контакты настроены, можно переходить к настройке мониторинга отдельных сервисов, за которыми должно проводиться наблюдение.

Файл services.cfg

Здесь мы как и в файле hosts.cfg для хостов, задали лишь общие параметры для всех служб.

Доступно огромное количество дополнительных модулей Nagios, но если какой-то проверки всё же нет, её можно всегда написать самостоятельно. Например, нет модуля, проверяющего работает или нет Tomcat. Можно написать скрипт, который загружает jsp страницу с удалённого Tomcat-сервера и возвращает результат в зависимости от того, если в загруженной странице какой-то текст на странице или нет. (При добавлении новой команды нужно обязательно упомянуть её в файле checkcommand.cfg, который мы не трогали).

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

Стоит отметить, что Windows хосты проходят мониторинг посредством протокола SNMP и NSClienta, поставляемого с Nagios. Ниже представлена схема его работы:

Рис. 4.3 – Схема мониторинга Windows хостов

В тоже время *nix хосты проходят мониторинг также посредством SNMP, а также NRPE плагина. Схема его работы показана на рисунке:

Рис. 4.4 – Схема мониторинга *nix хостов

4.2.4 Написание плагинов

Помимо написания скриптов инициализации, определения хостов и служб, были использованы следующие плагины:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

 Большая часть их них поставляется вместе с пакетом Nagios. Исходные тексты плагинов, не входящих в комплект поставки и использованных в системе, представлены в Приложении И.

4.2.5 Настройка SNMP на удаленных хостах

Чтобы иметь возможность проводить мониторинг по протоколу SNMP, на сетевом оборудовании необходимо предварительно настроить агентов этого протокола. Схема работы SNMP в связке с ядром системы сетевого мониторинга показана на рисунке ниже.

Рис. 4.5 – Схема мониторинга посредством протокола SNMP

Конфигурационные параметры хостов представлены в Приложении З. Безопасность осуществляется путем индивидуальной настройки пакетного фильтра на каждом из хостов в отдельности и посредством организации защищенных системных подсетей, в которые имеет доступ только авторизованный персонал предприятия. Кроме того настройка произведена таким образом, что посредством SNMP протокола можно производить только чтение параметров, а не их запись [18, с. 58].

4.2.6 Настройка агента на удаленных хостах

Для получения возможностей расширенного мониторинга хостов и служб, необходимо установить на них агента Nagios, который называется nagios-nrpe-server:

# aptitude install nagios-nrpe-server

Конфигурация агента представлена в Приложении Л. Схема работы агента показана на Рисунке 4.5 выше.

4.4 Установка и настройка модуля отслеживания загрузки

MRTG (Multi Router Traffic Grapher) – сервис, позволяющий посредством протокола SNMP получать из нескольких устройств информацию и отображать в окне вашего браузера графики загруженности канала (входящий трафик, исходящий, максимальный, средний) с шагом в минуты, часы, дни и за год.

Требования к установке

Для работы MRTG требуются следующие библиотеки:

  •  gd – graph drawing library. Библиотека, ответственная за формирование графики (http://www.boutell.com/gd/);
  •  libpng – требуется gd для создания графики в формате png (http://www.libpng.org/pub/png/src/);
  •  zlib – данная библиотека используется для компрессии созданной графики (ftp://sunsite.cnlab-switch.ch/mirror/infozip/zlib/).

В нашем случае установка сводится к выполнению одной команды, т.к. выбран способ установки предкомпиленного пакета из репозитория:

# aptitude install mrtg

Создавать конфигурационные файлы можно вручную, а можно воспользоваться идущими в составе пакета генераторами конфигураций:

# cfgmaker <community string>@<hostname> > <config path>

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

Далее необходимо сгенерировать индексные файлы будущих веб страниц, делается это также при помощи специального генератора:

# indexmaker <config path> > <index path>

 Индексные страницы представляют собой обычные html файлы и их содержимое особого интереса не представляет, поэтому приводить их примеры не имеет смысл. В Приложении Н показан пример отображения графиков загрузки интерфейсов.

В завершение необходимо организовать проверку загруженности интерфейсов по расписанию. Достигнуть этого проще всего средствами операционной системы, а именно параметрами crontab, что показано в Приложении О [16, с. 94].

4.5 Установка и настройка модуля сбора системных журналов событий

В качестве модуля сбора системных журналов событий был выбран пакет syslog-ng.

syslog-ng (syslog next generation) - это многофункциональная служба протоколирования системных сообщений. По сравнению со стандартной службой syslogd, он имеет ряд отличий:

  •  усовершенствованная схема конфигурации
  •  фильтрация сообщений не только по приоритетам, но и по их содержанию
  •  поддержка regexps (regular expressions)
  •  более гибкое манипулирование и организация логов
  •  возможность шифрования канала передачи данных с помощью IPSec/Stunnel

В следующей таблице представлены поддерживаемые аппаратные платформы.

Таблица 4.1 - Поддерживаемые аппаратные платформы

x86

x86_64

SUN SPARC

ppc32

ppc64

PA-RISC

AIX 5.2 & 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 РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА

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

5.1 Описание веб-интерфейса системы

Для того чтобы выполнять интерактивное наблюдение за службами было удобнее в систему интегрирован web-интерфейс. Web-интерфейс ещё хорош тем, что даёт полную картину системы благодаря умелому применению графических средств и предоставления дополнительной статистической информации.

При входе на веб-страницу Nagios будет запрошен ввод имени пользователя и пароля, которые мы установили в процессе настройки. Стартовая страница веб-интерфейса показана на рисунке ниже.

Рис. 5.1 – Стартовая страница веб-интерфейса системы

Слева находится навигационная панель, справа результаты различного представления данных о состоянии сети, хостов и служб. Нас будет интересовать в первую очередь раздел Monitoring. Посмотрим на страницу Tactical Overview.

Рис. 5.2 – Стартовая страница веб-интерфейса системы

На этой странице располагается суммирующая информация по всем параметрам мониторинга и состоянию хостов и служб, при этом никаких подробностей не приводится, однако, если возникают какие-либо проблемы, то они выделяются особым цветом и становятся гиперссылкой, ведущей к подробному описанию возникшей проблемы. В нашем случае на текущий момент среди всех хостов и служб имеется одна неразрешенная проблема, перейдем по этой ссылке (1 Unhandled Problems).

Рис. 5.3 – Обнаруженная проблема службы

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

Перейдем по ссылке службы CPU Load.

Рис. 5.4 – Подробное описание состояния службы

Здесь мы видим полное описание проблемы, эта страница полезна при глубоком анализе проблемы, когда не совсем ясна причина её возникновения, например она может быть в слишком жестко заданных пороговых значениях критичности состояния или неправильно заданных параметрах запуска плагина, что также будет оцениваться системой как критичное состояние. Кроме описания, с этой страницы возможно выполнение команд над службой, например отключить проверки, назначить другое время следующей проверки, принять данные пассивно, принять проблему на рассмотрение, отключить оповещения, отправить оповещение вручную, запланировать отключение службы, отключить обнаружение нестабильного состояния и написать комментарий.

Перейдем на страницу Service Detail.

Рис. 5.5 – Детальное представление всех служб

Здесь мы видим список всех хостов и служб, вне зависимости от их текущего состояния. Эта возможность может быть и полезна, но просматривать длинный список хостов и служб не совсем удобно и нужна она скорее чтобы время от времени визуально представить объем работы, выполняемой системой. Здесь каждый хост и служба, как и на рисунке 6.3 является ссылкой, ведущей к более подробному описанию параметра.

Перейдем по ссылке Host Detail.

Рис. 5.6 – Полный подробный список хостов

В данной таблице представлен полный подробный список хостов, их статусы, время последней проверки, продолжительность текущего статуса и дополнительная информация. В нашей системе принято, что статус хоста проверяется при помощи проверки доступности хоста по протоколу ICMP (8), то есть командой ping, однако в общем случае проверка можно быть какой угодно. Значки в колонке справа от имени хоста говорят о группе, к которой он принадлежит, сделано это для удобства восприятия информации. Значек светофора это ссылка, ведущая к подробному списку служб данного хоста, описывать эту таблицу отдельно не имеет смысла, она точно такая же, как и на рисунке 10.4, только информация представлена о единственном хосте.

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

Рис. 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 ТЕСТИРОВАНИЕ РАБОТЫ

При внедрении системы проводилось постепенное тестирование работы каждого компонента, начиная с ядра системы. Расширение функционала проводилось только после окончательной наладки нижележащих по иерархии уровней модулей системы сетевого мониторинга ввиду многих зависимостей различных подсистем. Пошагово, в общем и целом можно описать процесс внедрения и тестирования следующим образом:

1) Установка и наладка ядра на базе Nagios;

2) Наладка мониторинга удаленных хостов базовым функционалом Nagios;

3) Наладка модуля отслеживания загрузки сетевых интерфейсов посредством MRTG;

4) Расширение функционала ядра системы и интеграция её с модулем MRTG;

5) Наладка модуля сбора системных журналов;

6) Написание скрипта инициализации пакетного фильтра системы мониторинга в целях обеспечения безопасности системы.


7 Информационная безопасность

7.1 Характеристика рабочего места

К вредным факторам, влияющим на работу при использовании ПЭВМ относятся:

  •  повышенное значение напряжения электрического тока;
  •  шум;
  •  электромагнитное излучение;
  •  электростатическое поле.

Для обеспечения наилучших условий для эффективной и безопасной работы нужно создать такие условия труда, которые будут комфортными и максимально уменьшающими воздействие данных вредных факторов. Необходимо, чтобы перечисленные вредные факторы согласовывались с установленными правилами и нормами.

7.2 Безопасность труда

7.2.1 Электробезопасность

Проектируемое программное средство создается в расчете на работу на имеющемся сервере, расположенном в специально оборудованном техническом помещении. Оно оборудовано кабельными коробами для прокладки кабелей. К каждому серверу подведено электропитание ~220В, частотой 50Гц, с рабочим заземлением. Перед вводом электропитания в помещение установлены автоматы, отключающие электропитание в случае короткого замыкания. Отдельно проведено защитное заземление.

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

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

Применяются технические меры, обеспечивающие защиту от поражения электрическим током при прикосновении к корпусу электроустановки в случае пробоя изоляции токоведущих частей, к которым относятся:

  •  защитное заземление;
  •  защитное зануление;
  •  защитное отключение.

7.2.2 Защита от шума

Исследования показывают, что в условиях шума, прежде всего, страдают слуховые функции. Но действие шума не ограничивается влиянием только на слух. Он вызывает заметные сдвиги ряда физиологических психических функций. Шум вредно влияет на нервную систему и снижает скорость и точность сенсомоторных процессов, возрастает число ошибок при решении интеллектуальных задач. Шум оказывает заметное влияние на внимание человека и вызывает негативные эмоции.

Основным источником шума в помещениях, где находятся ЭВМ, является оборудование для кондиционирования воздуха, печатная и копировальная техника, а в самих ЭВМ вентиляторы систем охлаждения.

В производственном помещении активно используются следующие меры борьбы с шумом:

  •  применение бесшумных охлаждающих механизмов;
  •  изоляция источников шума от окружающей среды средствами звукоизоляции и звукопоглощения;
  •  использование звукопоглощающих материалов для облицовки помещений.

В помещении на рабочем месте присутствуют следующие источники шума:

  •  системный блок (кулер (25дБ), жесткий диск (29дБ), блок питания (20дБ));
  •  принтер (49дБ) [49].

Общий шум L, испускаемый этими устройствами, вычисляется по формуле:

    (7.1)

где Li – уровень шума одного устройства, дБ

L = 10*lg(316,23+794,33+100+79432,82) = 10*4,91 = 49,1дБ

 По СН 2.2.4/2.1.8.562-96 [48] уровень шума на рабочем месте математиков-программистов и операторов видеоматериалов не должен превышать 50 дБ.

7.2.3 Защита от электромагнитного излучения

Защита от электромагнитного воздействия обеспечивается экранами с электропроводящей поверхностью и использованием мониторов, снабженных системой Low Radiation, которая сводит к минимуму уровень вредных излучений, а также жидкокристаллических мониторов, в которых электромагнитное излучение полностью отсутствует.

7.2.4 Защита от электростатического поля

Для защиты от воздействия электростатического заряда применяется заземленный защитный фильтр, увлажнители воздуха, а полы покрыты антистатическим покрытием. Для поддержания нормированных значений концентрации положительных и отрицательных ионов в помещениях с ЭВМ установлены кондиционеры, устройства ионизации воздуха и проводится естественное проветривание длительностью не менее 10 минут после каждых 2 часов работы.

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

7.3 Условия труда

7.3.1 Микроклимат производственного помещения

Рассматриваемое в данном дипломном проекте оборудование в процессе работы не вырабатывает  никаких вредных веществ. Таким образом, воздушная среда в помещении, где они используются, вредных воздействий на организм человека не оказывает и удовлетворяет требованиям I категории работ, согласно ГОСТ 12.1.005-88 [36].

Оптимальные нормы температуры, относительной влажности и скорости движения воздуха в рабочей зоне производственных помещений нормируются ГОСТ 12.1.005-88 [36] и приведены в таблице 7.1.

Таблица 7.1 –Параметры микроклимата

Нормируемый параметр

Значение

Оптимальное

Допустимое

Фактическое

Температура воздуха, С

20 – 22

18 - 20

20

Влажность, %

40 – 60

Не более 80

45

Скорость движения воздуха, м/с

0,2

0,3

0..0,3

Микроклимат соответствует оптимальным условиям.

 7.3.2 Производственное освещение

Для расчета выбираем отдел сопровождения в ООО Геркон в городе Верхняя Пышма, где происходила разработка данного проекта:

  •  площадь помещения равна 60м2;
  •  площадь световых проемов 10 м2;
  •  установлено 4 автоматизированных рабочих мест.

Расчет естественной освещенности производится по формуле СНиП 23.05-95 [37]:

S0 = Sп * eн * Кз * N0 * КЗД / 100% * Т0 * Т1 (7.2)

где S0 – площадь световых проемов, м2;

 Sп  – площадь пола помещения, м2, 60;

 eн – коэффициент естественной освещенности, 1,6;

Кз  – коэффициент запаса, 1,5;

 N0  – световая характеристика окон, 1;

КЗД – коэффициент, учитывающий затемнение окон противостоящими зданиями, 1,2;

Т0 – общий коэффициент светопропускания, 0,48;

Т1 – коэффициент отражения от поверхности помещения, 1,2.

Значения всех коэффициентов взяты в СНиП 23.05.-95 [37].

В результате расчета получаем: требуемая площадь световых проемов окон S0 = 3,4м2. Реальная площадь проемов равна 10м2, что превышает минимальную допустимую площадь световых проемов для помещений такого типа и является достаточным в светлое время суток.

Расчет искусственного освещения для комнаты, освещаемой 15 люминесцентными лампами типа ЛДЦ-60 мощностью по 60Вт каждая.

Согласно СНиП 23.05-95 [37], величина освещенности люминесцентными лампами должна быть в горизонтальной плоскости не ниже 300лм – для системы общего освещения. С учетом зрительной работы высокой точности величина освещенности может быть увеличена до 1000лм.

Световой поток люминесцентной лампы рассчитывается по формуле из СНиП 23.05.-95 [37]:

Фи = Ен * S * Z * K / N * η  (7.3)

где Ен – нормированная освещенность помещения, лк, 200;

 S – площадь пола помещения, м2, 60;

Z – коэффициент, учитывающий отношение средней освещенности к минимальной, 1,1;

К – коэффициент запаса с учетом загрязнения воздуха, 1,3;

N – количество светильников, 15;

η – коэффициент использования светового потока, 0,8.

В результате получаем Фи = 1340лм, суммарный световой поток всех ламп равен 3740лм [52], следовательно, освещенность лаборатории выше минимально допустимой.

7.4 Эргономика рабочего места

7.4.1 Организация рабочего места

В соответствии с СанПиН 2.2.2/4.2.1340-03 [38], ВДТ (видеодисплейный терминал) должен отвечать следующим техническим требованиям:

  •  яркость освещения не менее 100кд/м2;
  •  минимальный размер световой точки не более 0,1 мм для цветного дисплея;
  •  контрастность изображения знака не менее 0,8;
  •  частота кадровой развертки не менее 7кГц
  •  количество точек не менее 640;
  •  антибликовое покрытие экрана;
  •  размер экрана не менее 31см по диагонали;
  •  высота символов на экране не менее 3,8мм;
  •  расстояние от глаз оператора до экрана должно быть порядка 40-80см;

ВДТ должен оборудован поворотной площадкой, позволяющей перемещать его в горизонтальной и вертикальной плоскостях в пределах 130-220мм и изменять угол наклона экрана на 10-15градусов.

Дипломный проект выполнялся на компьютере с ВДТ ViewSonic диагональю 39см. Данный монитор выполнен в соответствии с мировыми стандартами и отвечаем всем вышеперечисленным техническим требованиям.

К клавиатуре предъявляются следующие требования:

  •  окраска корпуса в спокойные мягкие тона с диффузным рассеиванием света;
  •  матовая поверхность с коэффициентом отражения 0,4 - 0,6 и не имеющая блестящих деталей, способных создавать блики;

Проект выполнялся на клавиатуре марки Logitech, которая соответствует всем вышеперечисленным требованиям.

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

Соединительные кабели прокладываются в специальных каналах. Устройство каналов должно такое, что соединительные разъемы не препятствуют извлечению кабелей.

Для манипулятора типа «мышь» справа от пользователя на столешнице предусмотрена свободная площадка, которая по форме и размеру должна идентична поверхности экрана.

Рабочее место оператора соответствует требованиям ГОСТ 12.2.032-78 ССБТ [43].

Пространственная организация рабочего места обеспечивает оптимальную рабочую позу:

  •  голова наклонена вперед на 10 – 20 градусов;
  •  спина имеет упор, соотношение между плечом и предплечьем, а также между бедром и голенью – прямой угол.

Основные параметры рабочего места должны регулируемые. Этим обеспечивается возможность создания благоприятных условий труда отдельному человеку с учетом геоантропометрических характеристик.

Основные параметры рабочего места и мебели, оснащенного персональным компьютером (рис. 7.1):

Рис. 7.1 – Рабочее место оператора ЭВМ

  •  высота сидения 42 - 45 см;
  •  высота клавиатуры от пола 70 – 85см;
  •  угол наклона клавиатуры от горизонтали 7 – 15градусов;
  •  удаленность клавиатуры от края стола 10 – 26см;
  •  расстояние от центра экрана до пола 90 – 115см;
  •  угол наклона экрана от вертикали 0 – 30градусов (оптимальный 15);
  •  удаленность экрана от края стола 50 – 75см;
  •  высота рабочей поверхности для записей 74 - 78см;

На рабочем месте предусмотрена подставка для ног, рекомендуемую для всех видов работ, связанных с длительным сохранением в положении сидя

7.4.2 Режим труда и отдыха

По СанПиН 2.2.2.542-96 [39] характер труда оператора ЭВМ считается легким и относится к категории 1А.

Установлены перерывы через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый. Во время регламентированных перерывов с целью снижения нервно-эмоционального напряжения, утомления, устранения влияния гиподинамии выполняются комплексы упражнений.

7.5 Пожарная безопасность

Помещение, где производилась работа над данным проектом, установлена категория пожарной опасности В НПБ 105-03 [40] – горючие и негорючие жидкости, твердые горючие и негорючие вещества и материалы, в том числе пыли и волокна, вещества и материалы, способные при взаимодействии с водой, кислородом воздуха или друг с другом только гореть при условии, что помещения, в которых они имеются в наличии или образуются, не относятся к категориям А или Б. Здание для помещения I степени огнестойкости по СНиП 21-01-97 [41].

В производственном помещении соблюдены следующие правила безопасности:

  •  проходы, выходы из помещения, доступы к средствам пожаротушения свободны;
  •  оборудование, находящееся в эксплуатации, исправно и проверяется каждый раз перед началом работы;
  •  по окончании работ помещение осматривается, обесточивается электросеть, закрывается помещение.

Число эвакуационных выходов из зданий из помещения два. Ширина эвакуационного выхода (двери) составляет 2м. На путях эвакуации используются обычные лестницы и распашные двери. На лестничных клетках  отсутствуют какие-либо помещения, технологические коммуникации, выходы подъемников и грузовых лифтов. На эвакуационных путях устроено как естественное, так и искусственное аварийное освещение.

В качестве первичных средств пожаротушения в помещении находятся ручные углекислотные огнетушители в количестве двух в помещении.

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

Объекты ВЦ кроме АПС необходимо оборудовано установками стационарного автопожаротушения. Примены установки газового тушения пожаров, действие которых основано на быстром заполнении помещения огнетушащим газовым веществом, в результате чего снижается содержание кислорода в воздухе.

7.6 Чрезвычайные ситуации

В условиях данного помещения наиболее вероятной чрезвычайной ситуацией может быть пожар. При возникновении пожара необходимо эвакуировать персонал и сообщить о случившемся в службу пожарной охраны. План эвакуации представлен на рисунке 7.2.

Рис. 7.2 – План эвакуации при пожаре.


8 ЭКОНОМИЧЕСКАЯ ЧАСТЬ

В этом разделе рассматриваются затраты на разработку системы сетевого мониторинга, её внедрение и сопровождение, а также сопутствующие материалы и оборудование.

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

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

С ростом клиентской базы, а как следствие и числа активного оборудования, возникла необходимость оперативного отслеживания состояния сети в целом и отдельных её элементов в подробности. До внедрения системы сетевого мониторинга сетевому администратору приходилось подключаться посредствам протоколов telnet, http, snmp, ssh и т.п. к каждому интересующему узлу сети и пользоваться встроенными средствами мониторинга и диагностики. На данный момент емкость сети составляет 5000 портов, 300 коммутаторов 2-го уровня, 15 маршрутизаторов и 20 серверов внутреннего пользования.

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

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

В соответствии со сложившейся ситуацией, было решено разработать и внедрить систему сетевого мониторинга, которая решала бы все вышеизложенные проблемы, которые, обобщив можно выразить следующим образом:

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

Система должна удовлетворять следующим требованиям в экономическом плане:

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

В целом разработка проекта заняла 112 часов (2 недели). На внедрение этого проекта потребуется 56 часов (1 неделя).

8.1 Расчет затрат на разработку проекта

Затраты на разработку проекта складываются из:

  •  затрат на заработную плату;
  •  затрат на амортизацию оборудования и программных продуктов;
  •  затрат на оплату электроэнергии;
  •  накладных расходов.

Расходы на заработную плату.

При расчете затрат на заработную плату учитываем, что данный проект разрабатывал один человек: системный инженер.

Среднерыночная заработная плата системного инженера требуемого уровня по региону составляет 30000 руб. [53]

Рассчитаем стоимость 1 часа работы инженера, опираясь на следующие данные:

  •  премия 25%;
  •  районный коэффициент 15%;
  •  фонд рабочего времени в 2010 году, в соответствии с производственным календарем, составляет 1988 час;

Таким образом, расценка с учетом районного коэффициента составит:

РЧ = 30000*1,25*1,15*12/1988 = 260 руб

В расчете затрат на заработную плату учитываются отчисления, выплачиваемые с начисленной заработной платы, то есть общая величина тарифа страховых взносов будет равна максимальной ставке ЕСН – 26%, в том числе:

  •  ПФР – 20%;
  •  ФССР – 2,9%
  •  ФФОМС – 1,1%;
  •  ГФОМС – 2%;
  •  Обязательное социальное страхование от несчастных случаев - 0,2%.

В сумме отчисления составят:

СО = РЧ * 0,262 = 260 * 0,262 = 68 руб

С учетом времени работы инженера (112 часов на разработку и 56 часов на внедрение), рассчитаем расходы на заработную плату:

ЗП = (112 + 56) * (РЧ + СО) = 168 * 328 = 55104 руб

Расходы на амортизацию оборудования и программных продуктов.

В качестве основного оборудования на этапе разработки проекта сети использовались персональный компьютер и сервер AQUARIUS SERVER T40 S41. Стоимость компьютера на данный момент составляет примерно 17000 руб, тогда как сервера 30000 руб [54].

Таким образом стоимость разовых вложений в аппаратуру составит:

РВА = 47000 руб

В течение срока эксплуатации компьютера и сервера допускается их модернизация, данный вид затрат также учитывается при расчете. Закладываем 50% от РВ на модернизацию:

РМА = РВ * 0,5 = 23500 руб

Компьютер использовался на следующих этапах:

  •  поиск литературы;
  •  поиск решений проектирования системы сетевого мониторинга;
  •  разработка структур и подсистем;
  •  проектирование системы сетевого мониторинга;
  •  оформление документа.

Сервер использовался во время внедрения системы и непосредственной работы с системой.

Используемые в разработке программные продукты получены по свободным лицензиям, что  говорит о нулевой их стоимости и отсутствии необходимости их амортизации.

Таким образом общие затраты на аппаратуру с учетом амортизации составят:

ОЗА = РВА + РМА = 47000 + 23500 = 70500 руб

Срок полезного использования принимаем 2 года. Стоимость одного часа работы составляет (приняв число рабочих дней в месяце 22 и при 8-часовом рабочем дне):

СОЧР = ОЗА / ВР = 70500 / 4224 = 16,69 руб

На время разработки и внедрения стоимость амортизационных отчислений соответственно составит:

САЧРВ = СОЧР * ТРВ = 16,69 * 168 = 2803,92 руб

Расходы на электроэнергию.

Расходы на электроэнергию складываются из потребляемой компьютером и затрачиваемой на освещение. Стоимость электроэнергии:

СЭН = 0,80 руб/кВт * ч (По договору с собственником помещения)

Рк,с = 200 Вт – мощность, потребляемая компьютером или сервером.

Трк = 168 ч – время работы компьютера на этапе разработки и внедрения системы.

Трс = 52 ч – время работы сервера на этапе разработки и внедрения системы.

Таким образом стоимость электроэнергии на этапе разработки и внедрения проекта составит:

СЭНП = Рк * Трк * СЭН + Рк * Трс * СЭН = (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 = (26880 + 8320) / 1000 = 35,2 руб

Рабочее место, на котором производилась данная работа, оснащено светильником мощностью 100 Вт. Рассчитаем стоимость электроэнергии, затраченной осветительным прибором на время разработки и внедрения системы:

СЭНО = 100 * Трк * СЭН = (100 * 168 * 0,80) / 1000 = 13,44 руб

Общие затраты на электроэнергию составили:

ОЗЭН = СЭНП + СЭНО = 35,2 + 13,44 = 48,64 руб

8.2 Расчет накладных расходов

Данный пункт затрат охватывает затраты на прочее оборудование и расходные материалы, также непредвиденные расходы.

Накладные расходы в бюджете предприятия составляют 400% от начисленной заработной платы:

НР = ЗП * 4 = 55104 * 4 = 220416 руб.

Таким образом затраты на разработку и внедрение проекта составили:

СРВ = ЗП + САЧРВ + ОЗЭН + НР = 55104 + 2803,92 + 48,64 + 220416 = 278372,56 руб

8.3 Эффективность

В результате выполнения экономических расчетов была назначена минимальная цена разработки и внедрения системы сетевого мониторинга 278372,56 руб.

Как видно из расчетов, подавляющая часть стоимости расходов приходится на материалы и оборудование. Это объясняется тем, что производители основного оборудования это зарубежные компании и соответственно цены на данную продукцию приводятся в американских долларах по курсу ЦБРФ + 3%. А повышение таможенных пошлин на ввозимую продукцию также негативно сказывается на цене для конечных заказчиков.

Для обоснования самостоятельной разработки системы сравним ее стоимость с готовыми решениями, присутствующими на рынке [55]:

  •  D-Link D-View – 360 000 руб
  •  HP OpenView – 750 000 руб

Учитывая, что эти решения также требуют наличие опытного системного инженера, выделенного сервера и компьютера, то получаем экономию только за счет сокращения времени на разработку системы, то есть для расчета стоимости внедрения коммерческой системы, необходимо из полученной минимальной цены разработки и внедрения системы вычесть затраты на заработную плату и электричество в процессе разработки системы:

СВКС = СЛ + МЦРВС – ВР * (РЧ + СО) – СЭНР - СЭНОР = 360 000 + 278372,56 – 112 * 328 – 26,88 – 9,44 = 670032,24 руб.

Как видно из расчета, стоимость внедрения самой недорогостоящей коммерческой системы сетевого мониторинга стоит почти в два раза дороже, чем разработка и внедрение собственной системы.

В заключение подсчитаем потенциальную экономию от внедрения системы. Как было сказано в обосновании необходимости внедрения системы, она позволяет предсказывать перегрузки сети и планировать модернизацию её отдельных участков до того, как произойдет сбой в работе оборудования и поступят первые жалобы от клиентов, что повлечет за собой необходимость перерасчетов и возврата части вложенных средств на счета абонентов.

Расчет будем производить на основе статистических данных, собранных с биллинговой системы учета и регистрации платежей и подключений, используемой внутри предприятия, с расчетом на один год работы системы. Имеем следующие данные:

Сеть работает в 15 районах города Верхняя Пышма, поделена на 15 независимых сегментов, которые обслуживаются 15 центральными маршрутизаторами.

Среднестатистический месячный платеж одного пользователя 700 руб, из чего получаем стоимость 1 дня простоя сети 700 / 30 = 23 руб.

В каждом районе в среднем по 20 домов, в каждом доме усреднено 50 абонентов, имеем общее число абонентов в районе 1000.

При неожиданном отказе оборудования получаем произойдет следующая ситуация – часть абонентов (как правило 75% от общего числа в районе) не сможет получит заказанные услуги в течение времени, пока будет заказано новое оборудование, настроено и установлено. Как правило это время составляет от 1 до 2 недель. То есть эти пользователи потребуют возврата денег за неполученные услуги. Происходит такая ситуация как правило 3 раза в год, проведем расчет недополученной выручки при данных условиях:

НВ = 23 * 1000 * 0,75 * 14 * 3 = 724500 руб.

Таким образом, разработанная и внедренная система полностью окупается менее, чем за год, что говорит об экономической целесообразности её разработки.


ЗАКЛЮЧЕНИЕ

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

Система удовлетворяет всем требованиям уточненного технического задания:

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

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

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


БИБЛИОГРАФИЧЕСКИЙ СПИСОК

  1.  Бойченко Е.В. Кальфа В. Овчинников В.В. Локальные вычислительные сети / Бойченко Е.В. Кальфа В. Овчинников В.В. - М.: Радио и связь 2000. – 500 с.
  2.  Бройдо В. Л. Вычислительные системы, сети и телекоммуникации: Учебник для вузов / В.Л. Бройдо. - Спб.: Питер, 2003. - 688 с.
  3.  Гусева А.И. Работа в локальных сетях: Учебник / А. И. Гусева. – М.: Диалог – МИФИ, 2001. – 344 с.
  4.  Камалян А.К., Кулев С.А., Назаренко К.Н. и др. Компьютерные сети и средства защиты информации: Учебное пособие /Камалян А.К., Кулев С.А., Назаренко К.Н. и др. - Воронеж: ВГАУ, 2003.-119с.
  5.  Курносов А.П.  Практикум по информатике/Под ред. Курносова А.П. Воронеж: ВГАУ, 2001.- 173 с.
  6.  Малышев Р.А. Локальные вычислительные сети: Учебное пособие/ РГАТА. – Рыбинск, 2005. – 83 с.
  7.  Новиков Ю. В. Локальные сети: архитектура, алгоритмы, проектирование. / Ю. В. Новиков. - М.: ЭКОМ, 2000. – 312 с.
  8.  Новиков Ю. В. Основы локальных сетей / Ю. В. Новиков. - М.: ЭКОМ, 2005. – 360 с.
  9.  Олифер В.Г, Олифер Н.А.  Сетевые операционные системы/ В.Г. Олифер, Н.А. Олифер. – СПб.: Питер, 2002. – 544 с.: ил.
  10.  Олифер В.Г., Олифер Н.А.  Компьютерные сети. Принципы, технологии, протоколы /В.Г. Олифер, Н.А. Олифер. - СПб.: Питер, 2002. - 672 с.
  11.  Флинт Д. Локальные сети ПК: принципы построения, реализация / Д. Флинт. - М.: Финансы и статистика, 2001. – 359 с.
  12.  Фридман А.Л. Основы объектно-ориентированной разработки программных систем. / А. Л. Фридман. – М.: Финансы и статистика, 2000. – 192 с.
  13.  Шафрин Ю.А. Основы компьютерной технологии / Ю.А. Шафрин. - М.: АБФ, 2001. – 560 с.
  14.  Яковлев В.А. Компьютерные сети / В.А. Яковлев. -  М.: ИНФРА-М. 2001. – 244 с.
  15.  www.informika.ru - Интернет-учебник по информатике.
  16.  www.ito.edu.ru – Виртуальный университет информационных технологий.
  17.  www.ietf.org – Портал технических стандартов.
  18.  www.nagios.org – Сайт проекта Nagios.
  19.  www.debian.org – Сайт операционной системы Debian.
  20.  www.linux.org – Сайт ядра Linux.
  21.  www.habrahabr.ru – Русский блог-портал специалистов по информационным технологиям.
  22.  http://en.wikipedia.org/wiki/Wiki - Англоязычная свободная энциклопедия.
  23.  Храмцов П.Б.Информационные сети / Московская финансово-промышленная академия. - М., - 2004. - 290 с
  24.  Тулябаев Ф.А. Компьютерные сети и телекоммуникации 171 стр.
  25.  Столлингс В. Современные компьютерные сети. 2-е изд СПб.: Питер, 2003. - 783 с.: ил.
  26.  Паркер Т., Сиян К. TCP/IP. Для профессионалов 3-е изд. СПб.: Питер, 2004. - 859 с.: ил.
  27.  Вишневский В.М. Теоретические основы проектирования компьютерных сетей Техносфера, 2003 г.
  28.  Casad J. Sams teach yourself TCP-IP in 24 hours
  29.  Hunt C. TCP-IP network administration
  30.  James Turnbull. Pro Nagios 2.0
  31.  Бейли Д., Райт Э. Волоконная оптика: теория и практика Волоконная оптика: теория и практика/Пер. с англ. - М: КУДИЦ-ПРЕСС, 2008 г. , 320 с.
  32.  Руководство пользователя. Коммутаторы локальных сетей D-Link. Учебное пособие 2004 г. 89 стр.
  33.  Таненбаум Э. Компьютерные сети 4-е изд.
  34.  Feit S. TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security — 2nd ed. Dr. Sidnie Feit Copyright 1997, 1993 All rights reserved Фейт С. TCP/IP: Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) — 2-е изд. Copyright © 1997, 1993 by The McGraw-Hill Companies, Inc. ISBN 0-07-021389-5 McGraw-Hill Издательство "Лори", 2000 , 450 стр
  35.  Уилсон Эд. Мониторинг и анализ сетей. Методы выявления неисправностей
  36.  ГОСТ 12.1.005-88 ССБТ. Общие санитарно-гигиенические требования к воздуху рабочей зоны.
  37.  СНиП 23.05-95. Естественное и искусственное освещение.
  38.  СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.
  39.  СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам, персональным ЭВМ и организации работы.
  40.  НПБ 105-03. «Пожарная безопасность».
  41.  СНиП 21-01-97. Пожарная безопасность зданий и сооружений.
  42.  ГОСТ 12.1.003-83 ССБТ. Шум. Общие требования безопасности.
  43.  ГОСТ 12.1.006-84 ССБТ. Электромагнитные поля радиочастот. Общие требования безопасности.
  44.  ГОСТ 12.2.032-78 ССБТ. Рабочее место при выполнении работ сидя. Общие требования.
  45.  http://ru.wikipedia.org/wiki/ - Русскоязычная свободная интернет-энциклопедия.
  46.  http://www.goural.ru/svregion/407 - Официальный туристический сайт Свердловской области
  47.  http://www.ugmk.com – Сайт компании УГМК-холдинг.
  48.  СН 2.2.4/2.1.8.562-96. Шум на рабочих местах, в помещениях жилых, общественных зданий и на территории жилой застройки.
  49.  www.nix.ru – Сайт поставщика компьютерных комплектующих.
  50.  http://www.mprso.ru/a_2001.htm - Сайт министерства природных ресурсов Свердловской области.
  51.  СанПиН 2.1.4.1074-01. Питьевая вода и водоснабжение населенных мест питьевая вода. Гигиенические требования к качеству воды централизованных систем питьевого водоснабжения. Контроль качества санитарно-эпидемиологические правила и нормативы.
  52.  Технический паспорт ламп ЛДЦ60.
  53.  www.e1.ru – Интернет-портал города Екатеринбург.
  54.  www.price.ru – Справочник по ценам.
  55.  www.opennet.org – Форум специалистов по информационным технологиям.


Приложение А

Рис. А.1 - Структура предприятия


Приложение Б

Таблица Б.1 – Сравнительная таблица систем сетевого мониторинга

Назв.

Диаграммы

SLA Отчеты

Логическое группирование

Тренды

Прогнозирование трендов

Автоматическое обнаружение

Агент [1]

SNMP

Syslog

Внешние скрипты [2]

Плагины [3]

Сложность создания плагинов [4]

Триггеры/события [5]

Веб-интерфейс [6]

Распределенный мониторинг

Инвентаризация

Метод хранения данных

Лицензия

Карты[7]

Управление доступом[8]

События [9]

Язык

Отслеживание пользователей

AdRem NetCrunch

Д

Н

Д

Д

Н

Д

Н

Д

Д

Д

Д

Н/Д

Д

Только просмотр

Н

Н

SQL

Коммерч.

Динамические, статические, полностью настраиваемые

Д

Д

Argus

Д

Д

Д

Н

Н

Н

Д

Д

Н

Д

Д

Легко

Д

Только просмотр

Частично

Неизвестно

Berkeley DB

Своя

Н

Градация

Д

Cacti

Д

Д

Д

Д

Д

Через плагин

Н

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

RRDtool, MySQL

GPL

Через плагин (weathermap)

Неизвестно

Неизвестно

PHP (требуется)

CiscoWorks LMS

Д

Д

Д

Неизвестно

Н

Д

Н

Д

Д

Неизвестно

Неизвестно

Неизвестно

Д

Полный кнтроль (без обн.)

Д

Д

Неизвестно

Коммерч.

Динамические и настраиваемые

Д

Д

Д

collectd

Внешний скрипт

Н

Н

Н

Н

Модель добавления, возможен multicast

Д

Д

Д

Д

Д (C или Perl)

Легко - Сложно (зависит от метода)

Д

Внешний скрипт

Д

Н

RRDtool, CSV, в памяти, плагины

GPLv2

Н

Apache ACLfla

Н

C

FreeNATS

Д

Д

Д

Н

Н

Д

Д

Н

Через плагин

Через плагин

Д

Средне

На PHP

Полный контроль

Н

Н

MySQL

GPL

Н

Градация

Д

PHP

Ganglia

Д

Н

Д

Д

Н

Через gmond проверку

Д

Через плагин

Н

Д

Д

Средне

Н

Тольско просмотр

Д

Неизвестно

RRDtool, в памяти

BSD

Д

Н

Н

C

Intellipool Network Monitor

Д

Д

Д

Н

Н

Д

Н

Д

Д

Д

Д

Д

Н

Д

Д

Д

FirebirdSQL

Коммерч.

Д

Градация

Д

C++

IPHost Network Monitor

Д

Д

Д

Д

Н

Д

Н

Д

Н

Д

Д

Легко

Д

Просмотр, Отчетность, Подтверждение

Н

Н

FirebirdSQL

Коммерч.

Н

Н

Д

Munin

Д

Н

Н

Д

Неизвестно

Н

Д

Д

Н

Д

Д

Средне

Частично

Только просмотр, привитив

Неизвестно

Неизвестно

RRDtool

GPL

Неизвестно

Неизвестно

Неизвестно

Perl

Nagios

Д

Через плагин

Д

Д

Д

Через плагин

Д

Через плагин

Через плагин

Д

Д

Легко

Д

Просмотр, отчетность, контроль

Д

Через плагин

Файл, SQL

GPL

Динамические и настраиваемые

Д

Д

C

Д

NetMRI

Д

Н

Д

Д

Н

Д

Н

Д

Д

Д

Д

Средне

Д

Н

Д

Д

MySQL

Коммерч.

Д

Д

Д

NetQoS Performance Center

Д

Д

Д

Д

Д

Д

Н

Д

Д

Д

Д

Д

Д

Д

Д

Д

Д

Коммерч.

Д

Д

Д

C, .NET

Д

OpenNMS

Д

Д

Д

Д

Неизвестно

Д

Поддерж

Д

Д

Д

Д

Легко - Сложно (зависит от метода)

Д

Полный контроль

Д

Limited

JRobin, PostgreSQL [1]

GPL

Д

Д

Д

Java

Д

OPNET ACE Live

Д

Д

Д

Д

Д

Д

Н

Д

Н

Д

Д

Легко

Д

Д

Д

Н

Д

Коммерч.

Д

Д

Д

C, Java

Д

Opsview

Д

Д

Д

Д

Н

Д

Д

Д

Д

Д

Д

Д

Д

Д

Д

Н

SQL

GPL

Динамические и настраиваемые

Градация

Д

Perl, C

PacketTrap

Д

Н

Д

Д

Неизвестно

Д

Д

Д

Д

Д

Д

Средне

Д

Просмотр и отчетность

Д

Неизвестно

SQL

Коммерч.

Неизвестно

Неизвестно

Неизвестно

Pandora FMS

Д

Д

Д

Д

Д

Д

Поддерж.

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

MySQL

GPLv2; (доступна коммперч. подписка)

Автоматическое построение

Градация

Д

Perl, PHP

Performance Co-Pilot

Д

Н

Д

Д

Н

Н

Д

Н

Н

Д

Д

Средне

Д

Н

Д

Н

Файл

GPL, LGPL

Н

Н

Н

C, Perl, Python

Scrutinizer

Д

Д

Д

Д

Н

Н

Н

Д

Д

Д

Д

Легко

Д

Д

Д

Д

MySQL

Коммерч.

Динамические, статические, полностью настраиваемые

Д

Д

Perl

Д

ServersCheck

Д

Д

Д

Д

Н

Д

Поддерж

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Н

Flat file, ODBC

Коммерч.

Динамические, статические, полностью настраиваемые

Д

Д

SevOne

Д

Д

Д

Д

Неизвестно

Д

Н

Д

Н

Д

Д

Легко

Д

Полный контроль

Д

Неизвестно

MySQL

Коммерч.

Неизвестно

Д

Д

Orion

Д

Д

Д

Д

Д

Д

Д

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

SQL

Коммерч.

Д

Д

Д

C

Н

Shinken

Д

Через плагин

Д

Д

Н

Через плагин

Д

Через плагин

Через плагин

Д

Д

Легко

Д

Просмотр, отчетность, контроль

Д

Через плагин

Файл, MySQL, Oracle, CouchDB, Sqlite

AGPL

Динамические, статические, настраиваемые

Н

Д

Python

Н

Spiceworks

Д

Д

Д

Н

Н

Д

Поддерж

Д

Н

Д

Д

Средне

Д

Д

Д

Д

Sqlite

Free Коммерч.

Динамические, статические, настраиваемые

Админ и польз. отчетность, больше через плагин

Д

Ruby

Д

TclMon

Contributed standalone client

Д

Д

Д

Н

Д

Поддерж

Д

Д

Д

Д

Легко - Сложно (зависит от метода)

Д

Внешний скрипт

Н

Н

RRDTool, в памяти, плагины

BSD

Внешний отдельно стоящий клиент

Д

Н

Tcl

Zabbix

Д

Д

Д

Д

Д

Д

Поддерж

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

Oracle, MySQL, PostgreSQL, SQLite

GPL

Д

Д

Д

C, PHP

ZeНss

Д

Д

Д

Д

Д

Д

Н

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

ZODB, MySQL, RRDtool

GPL ZeНss Core; платная Pro и Enterprise подписки

Д

Д

Д

Python, Zope

Zyrion Traverse

Д

Real-time or Scheduled

Д

Д

Д

Д

Поддерж

Д

Д

Д

Д

Легко

Д

Полный контроль

Д

Д

SQL

Коммерч.

Настраиваемые

Многозвенный

Д

Java, C

Примечения к Таблице:

1. Агент – это программа, запускаемая на хосте, мониторинг которого необходимо проводить. "Поддерж" означает, что агент может использоваться, но не обязательно. Служба SNMP не считается в данном случае агентом.

2. Возможность выполнения действия запущенного скрипта, написанного пользователем.

3. Официальные или написанные пользователями расширения, которые позволяют получать дополнительную информацию с контролируемых хостов.

4. Написание новых плагинов может быть обычной задачей, если пользователь хочет расширить функционал продукта.

5. Триггеры это правила, определяющие совпадение статуса системы с заданным пользователем.

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

7. Карты это графическое представления контролируемых компонентов.

8. Контроль доступа это возможность обезопасить данные мониторинга через использование нескольких уровней привилегий пользователей через пароли или другие способы. Следует заметить, что даже если поддержка контроля доступа отсутствует, современные веб-сервера могут осуществлять её независимо от службы мониторинга, блокируя определенные страницы.

9. События это возможность подтверждать и записывать определенные действия.


Приложение В

Таблица В.1 – Перечень оборудования сети

Наименован.

Марка, характеристики, номер.

Назначение.

№ сертификата соответствия.

1

Модемный пул

Robotics MP/16 v/34 S/n:000930014196552

Коммутируемое соединение

ОС/1-СПД-105

2

Модем

Robotics Courier v/34 S/n:310ZB2D812TC

Коммутируемое соединение

ОС/1-ТФ-439

3

Модем

Robotics Courier v/34 S/n:310ZB2A79E6X

Коммутируемое соединение

ОС/1-ТФ-439

4

Модем

Robotics Courier v/34 S/n:310ZB2979AC9

Коммутируемое соединение

ОС/1-ТФ-439

5

Модем

Robotics Courier v/34 S/n:310ZB2A79IV2

Коммутируемое соединение

ОС/1-ТФ-439

6

Модем

Robotics Courier v/34 S/n:310ZB2A79J1E

Коммутируемое соединение

ОС/1-ТФ-439

7

ISP- сервер

(WEB, Mail)

AQUARIUS SERVER T40 S41, Linux Debian.

Электронная почта,  WEB сервер.

ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

8

Диалап – сервер

AQUARIUS SERVER E40 S20, Linux Debian

Мультеплексирование РРР соединений

ГОСТ Р 51318.22-99 (класс В),ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

9

Маршрутизатор входной.

AQUARIUS SERVER T40 S41, Linux Debian.

Fire Wall Маршрутизация сетей провайдеров.

ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002, СанПиН 2.2.2/2.4.1340-03

10

Резерв.

PC Pentium 466 mHz, 2,4HDD, 128 mBit RAM, Linux Debian.

Fire Wall

11

Концентратор (хаб)

AT – FS708LE s/n:LITA419B

Коммутация серверов

ОС/1-СПД-791

12

DB - сервер

AQUARIUS SERVER T50 D60, Linux Debian

Сервер баз данных

ГОСТ Р 51318.22-99 (класс В), ГОСТ 26329-84, ГОСТ Р 51318.24-99, ГОСТ Р МЭК 60950-2002,СанПиН 2.2.2/2.4.1340-03

13

Центральный коммутатор с функцией биллинга.

AT-9924T S/n: 64691073

Коммутация серверов, учет трафика, система авторизации клиентов

ОС/3-СПД-0208

14

Оптический модем

FE-C120S5.S20

S/n:94H3D4121099

Вход внешнего канала ГТ

ОС/1-СПД-0031

15

Модем

D-Link DSL-300T

S/n: DR9U151006045

Вход внешнего канала УСИ

ОС/1-ТМ-318

16

Коммутатор

D-Link DES-2108

Коммутация абонентских линий

ОС/3-СПД-0208

17

Коммутатор

D-Link DES-3018

Коммутация абонентских линий

ОС/3-СПД-0208

18

Коммутатор

D-Link DES-3028

Коммутация абонентских линий

ОС/3-СПД-0208

19

Коммутатор

D-Link DES-3526

Коммутация абонентских линий

ОС/3-СПД-0208

20

Коммутатор

D-Link DES-1228

Коммутация абонентских линий

ОС/3-СПД-0208

21

Коммутатор

D-Link DES-1226

Коммутация абонентских линий

ОС/3-СПД-0208

22

Коммутатор

Allied Telesyn Rapier-24i

Коммутация абонентских линий

ОС/3-СПД-0208

23

Маршрутизатор

D-Link DGS-3627

Коммутация оптических магистралей

ОС/3-СПД-0208

24

Коммутатор

Allied Telesyn AT-8024

Коммутация абонентских линий

ОС/3-СПД-0208

25

Коммутатор

Allied Telesyn AT-8012M

Коммутация абонентских линий

ОС/3-СПД-0208

26

Коммутатор

Allied Telesyn Rapier_6G

Коммутация абонентских линий

ОС/3-СПД-0208

27

WiFi точка доступа

D-Link DWL-1000 AP

Организация WiFi сети

ГОСТ 26329-84

28

WiFi точка доступа

D-Link 2000 AP+

Организация WiFi сети

ГОСТ 26329-84

29

WiFi точка доступа

D-Link 900 AP+

Организация WiFi сети

ГОСТ 26329-84


Приложение Г

Конфигурация почтового модуля postfix

/etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first

# line of that file to be used as the name.  The Debian default

# is /etc/mailname.

#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

biff = no

# appending .domain is the MUA's job.

append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings

#delay_warning_time = 4h

readme_directory = no

# TLS parameters

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem

smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

smtpd_use_tls=yes

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for

# information on enabling SSL in the smtp client.

myhostname = monitoring.vpcit.ru

alias_maps = hash:/etc/aliases

alias_database = hash:/etc/aliases

myorigin = /etc/mailname

mydestination = monitoring.vpcit.ru, localhost.vpcit.ru, , localhost

relayhost =

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

mailbox_size_limit = 0

recipient_delimiter = +

inet_interfaces = all

inet_protocols = ipv4


Приложение Д

Рис. Д.1 - Диаграмма работы ядра сетевого мониторинга


Приложение Е

Структура конфигурационных файлов ядра системы

/etc/nagios3

├── apache2.conf

├── cgi.cfg

├── commands.cfg

├── commands.cfg.dpkg-dist

├── conf.d

│   ├── contacts_nagios2.cfg

│   ├── extinfo_nagios2.cfg

│   ├── generic-host_nagios2.cfg

│   ├── generic-service_nagios2.cfg

│   ├── host-gateway_nagios3.cfg

│   ├── host-gateway_nagios3.cfg.ucf-dist

│   ├── hostgroups_nagios2.cfg

│   ├── localhost_nagios2.cfg

│   ├── services_nagios2.cfg

│   └── timeperiods_nagios2.cfg

├── htpasswd.users

├── nagios.cfg

├── nagios.cfg.dpkg-dist

├── objects

│   ├── contacts.cfg

│   ├── extinfo.cfg

│   ├── hostgroups.cfg

│   ├── routers

│   │   ├── at9924.cfg

│   │   ├── des3627g.cfg

│   │   ├── rapier24i.cfg

│   │   └── router_len58a.cfg

│   ├── servers

│   │   ├── 1c.cfg

│   │   ├── db.cfg

│   │   ├── for.cfg

│   │   ├── host_mail.cfg

│   │   ├── isp.cfg

│   │   └── localhost.cfg

│   ├── servicegroups.cfg

│   ├── switches

│   ├── templates.cfg

│   └── timeperiods.cfg

├── pnp

├── resource.cfg

└── stylesheets

   ├── avail.css

   ├── checksanity.css

   ├── cmd.css

   ├── common.css

   ├── config.css

   ├── extinfo.css

   ├── histogram.css

   ├── history.css

   ├── ministatus.css

   ├── notifications.css

   ├── outages.css

   ├── showlog.css

   ├── status.css

   ├── statusmap.css

   ├── summary.css

   ├── tac.css

   └── trends.css


Приложение Ж

Рис. Ж.1 - Схема взаимодействия конфигурационных файлов Nagios


Приложение З

Файлы описания хостов и служб.

/etc/nagios3/objects/contacts.cfg

define contact{

       contact_name                    nagiosadmin             ; Short name of user

       use                             generic-contact         ; Inherit default values from generic-contact template (defined above)

       alias                           Voynovich Andrey                ; Full name of user

       email                           admin@vpcit.ru          

  host_notifications_enabled 1

       service_notifications_enabled 1

       service_notification_period 24x7

       host_notification_period 24x7

       service_notification_options w,u,c,r

       host_notification_options d,u,r

       service_notification_commands notify-service-by-email

       host_notification_commands notify-host-by-email

       can_submit_commands 1

       }

define contact{

       contact_name                    mainadmin               ; Short name of user

       use                             generic-contact         ; Inherit default values from generic-contact template (defined above)

       alias                           Demidoff Alexander              ; Full name of user

email                           demidoff@vpcit.ru                   host_notifications_enabled 1

       service_notifications_enabled 1

       service_notification_period 24x7

       host_notification_period 24x7

       service_notification_options w,u,c,r

       host_notification_options d,u,r

       service_notification_commands notify-service-by-email

       host_notification_commands notify-host-by-email

       can_submit_commands 0

       }

define contact{

       contact_name                    maincoder               ; Short name of user

       use                             generic-contact         ; Inherit default values from generic-contact template (defined above)

       alias                           Don Yura                ; Full name of user

       email                           yura@vpcit.ru   

       host_notifications_enabled 1

       service_notifications_enabled 1

       service_notification_period 24x7

       host_notification_period 24x7

       service_notification_options w,u,c,r

       host_notification_options d,u,r

       service_notification_commands notify-service-by-email

       host_notification_commands notify-host-by-email

       can_submit_commands 0

       }

/etc/nagios3/objects/extinfo.cfg

define hostextinfo{

       hostgroup_name   debian-servers

       notes            Debian GNU/Linux servers

       icon_image       base/debian.png

       icon_image_alt   Debian GNU/Linux

       vrml_image       debian.png

       statusmap_image  base/debian.gd2

       }

define hostextinfo{

       hostgroup_name   windows-servers

       notes            Microsoft Windows servers

       icon_image       base/win40.png

       icon_image_alt   Microsoft Windows

       vrml_image       win40.png

       statusmap_image  base/win40.gd2

       }

define hostextinfo{

       hostgroup_name   routers

       notes            Network Routers

       icon_image       base/router40.png

       icon_image_alt   Router

       vrml_image       router40.png

       statusmap_image  base/router40.gd2

       }

/etc/nagios3/objects/hostgroups.cfg

# Define an optional hostgroup for Linux machines

define hostgroup{

       hostgroup_name  linux-servers ; The name of the hostgroup

       alias           Linux Servers ; Long name of the group

       members         localhost,host_mail,db,isp,for     ; Comma separated list of hosts that belong to this group

       }

# A list of your Debian GNU/Linux servers

define hostgroup {

       hostgroup_name  debian-servers

       alias           Debian GNU/Linux Servers

       members         localhost,host_mail,db,isp,for,router_len58a

       }

# Define a hostgroup for Windows machines

# All hosts that use the windows-server template will automatically be a member of this group

define hostgroup{

       hostgroup_name  windows-servers ; The name of the hostgroup

       alias           Windows Servers ; Long name of the group

       }

# Create a new hostgroup for switches

define hostgroup{

       hostgroup_name  routers ; The name of the hostgroup

       alias   Network Routers ; Long name of the group

       }

/etc/nagios3/objects/templates.cfg

# CONTACT TEMPLATES

# Generic contact definition template - This is NOT a real contact, just a template!

define contact{

       name                            generic-contact         ; The name of this contact template

       service_notification_period     24x7                    ; service notifications can be sent anytime

       host_notification_period        24x7                    ; host notifications can be sent anytime

       service_notification_options    w,u,c,r,f,s             ; send notifications for all service states, flapping events, and scheduled downtime events

       host_notification_options       d,u,r,f,s               ; send notifications for all host states, flapping events, and scheduled downtime events

       service_notification_commands   notify-service-by-email ; send service notifications via email

       host_notification_commands      notify-host-by-email    ; send host notifications via email

       register                        0                       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL CONTACT, JUST A TEMPLATE!

       }

# HOST TEMPLATES

# Generic host definition template - This is NOT a real host, just a template!

define host{

       name                            generic-host    ; The name of this host template

       notifications_enabled           1               ; Host notifications are enabled

       event_handler_enabled           1               ; Host event handler is enabled

       flap_detection_enabled          1               ; Flap detection is enabled

       failure_prediction_enabled      1               ; Failure prediction is enabled

       process_perf_data               1               ; Process performance data

       retain_status_information       1               ; Retain status information across program restarts

       retain_nonstatus_information    1               ; Retain non-status information across program restarts

       notification_period             24x7            ; Send host notifications at any time

       register                        0               ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!

       }

# Linux host definition template - This is NOT a real host, just a template!

define host{

       name                            linux-server    ; The name of this host template

       use                             generic-host    ; This template inherits other values from the generic-host template

       check_period                    24x7            ; By default, Linux hosts are checked round the clock

       check_interval                  5               ; Actively check the host every 5 minutes

       retry_interval                  1               ; Schedule host check retries at 1 minute intervals

       max_check_attempts              10              ; Check each Linux host 10 times (max)

       check_command                   check-host-alive ; Default command to check Linux hosts

       notification_period             workhours       ; Linux admins hate to be woken up, so we only notify during the day

                                                       ; Note that the notification_period variable is being overridden from

                                                       ; the value that is inherited from the generic-host template!

       notification_interval           120             ; Resend notifications every 2 hours

       notification_options            d,u,r           ; Only send notifications for specific host states

       contact_groups                  admins          ; Notifications get sent to the admins by default

       register                        0               ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!

       }

# Windows host definition template - This is NOT a real host, just a template!

define host{

       name                    windows-server  ; The name of this host template

       use                     generic-host    ; Inherit default values from the generic-host template

       check_period            24x7            ; By default, Windows servers are monitored round the clock

       check_interval          5               ; Actively check the server every 5 minutes

       retry_interval          1               ; Schedule host check retries at 1 minute intervals

       max_check_attempts      10              ; Check each server 10 times (max)

       check_command           check-host-alive        ; Default command to check if servers are "alive"

       notification_period     24x7            ; Send notification out at any time - day or night

       notification_interval   30              ; Resend notifications every 30 minutes

       notification_options    d,r             ; Only send notifications for specific host states

       contact_groups          admins          ; Notifications get sent to the admins by default

       hostgroups              windows-servers ; Host groups that Windows servers should be a member of

       register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE

       }

# We define a generic printer template that can be used for most printers we monitor

define host{

       name                    generic-printer ; The name of this host template

       use                     generic-host    ; Inherit default values from the generic-host template

       check_period            24x7            ; By default, printers are monitored round the clock

       check_interval          5               ; Actively check the printer every 5 minutes

       retry_interval          1               ; Schedule host check retries at 1 minute intervals

       max_check_attempts      10              ; Check each printer 10 times (max)

       check_command           check-host-alive        ; Default command to check if printers are "alive"

       notification_period     workhours               ; Printers are only used during the workday

       notification_interval   30              ; Resend notifications every 30 minutes

       notification_options    d,r             ; Only send notifications for specific host states

       contact_groups          admins          ; Notifications get sent to the admins by default

       register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE

       }

# Define a template for switches that we can reuse

define host{

       name                    generic-switch  ; The name of this host template

       use                     generic-host    ; Inherit default values from the generic-host template

       check_period            24x7            ; By default, switches are monitored round the clock

       check_interval          5               ; Switches are checked every 5 minutes

       retry_interval          1               ; Schedule host check retries at 1 minute intervals

       max_check_attempts      10              ; Check each switch 10 times (max)

       check_command           check-host-alive        ; Default command to check if routers are "alive"

       notification_period     24x7            ; Send notifications at any time

       notification_interval   30              ; Resend notifications every 30 minutes

       notification_options    d,r             ; Only send notifications for specific host states

       contact_groups          admins          ; Notifications get sent to the admins by default

       register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE

       }

# SERVICE TEMPLATES

# Generic service definition template - This is NOT a real service, just a template!

define service{

       name                            generic-service         ; The 'name' of this service template

       active_checks_enabled           1                       ; Active service checks are enabled

       passive_checks_enabled          1                       ; Passive service checks are enabled/accepted

       parallelize_check               1                       ; Active service checks should be parallelized (disabling this can lead to major performance problems)

       obsess_over_service             1                       ; We should obsess over this service (if necessary)

       check_freshness                 0                       ; Default is to NOT check service 'freshness'

       notifications_enabled           1                       ; Service notifications are enabled

       event_handler_enabled           1                       ; Service event handler is enabled

       flap_detection_enabled          1                       ; Flap detection is enabled

       failure_prediction_enabled      1                       ; Failure prediction is enabled

       process_perf_data               1                       ; Process performance data

       retain_status_information       1                       ; Retain status information across program restarts

       retain_nonstatus_information    1                       ; Retain non-status information across program restarts

       is_volatile                     0                       ; The service is not volatile

       check_period                    24x7                    ; The service can be checked at any time of the day

       max_check_attempts              3                       ; Re-check the service up to 3 times in order to determine its final (hard) state

       normal_check_interval           10                      ; Check the service every 10 minutes under normal conditions

       retry_check_interval            2                       ; Re-check the service every two minutes until a hard state can be determined

       contact_groups                  admins                  ; Notifications get sent out to everyone in the 'admins' group

       notification_options            w,u,c,r                 ; Send notifications about warning, unknown, critical, and recovery events

       notification_interval           60                      ; Re-notify about service problems every hour

       notification_period             24x7                    ; Notifications can be sent out at any time

        register                        0                      ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!

       }

# Local service definition template - This is NOT a real service, just a template!

define service{

       name                            local-service           ; The name of this service template

       use                             generic-service         ; Inherit default values from the generic-service definition

       max_check_attempts              4                       ; Re-check the service up to 4 times in order to determine its final (hard) state

       normal_check_interval           5                       ; Check the service every 5 minutes under normal conditions

       retry_check_interval            1                       ; Re-check the service every minute until a hard state can be determined

       register                        0                       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!

       }

/etc/nagios3/objects/timeperiods.cfg

# This defines a timeperiod where all times are valid for checks,

# notifications, etc.  The classic "24x7" support nightmare. :-)

define timeperiod{

       timeperiod_name 24x7

       alias           24 Hours A Day, 7 Days A Week

       sunday          00:00-24:00

       monday          00:00-24:00

       tuesday         00:00-24:00

       wednesday       00:00-24:00

       thursday        00:00-24:00

       friday          00:00-24:00

       saturday        00:00-24:00

       }

# 'workhours' timeperiod definition

define timeperiod{

       timeperiod_name workhours

       alias           Normal Work Hours

       monday          09:00-18:00

       tuesday         09:00-18:00

       wednesday       09:00-18:00

       thursday        09:00-18:00

       friday          09:00-18:00

       }

# 'none' timeperiod definition

define timeperiod{

       timeperiod_name none

       alias           No Time Is A Good Time

       }

# Some U.S. holidays

# Note: The timeranges for each holiday are meant to *exclude* the holidays from being

# treated as a valid time for notifications, etc.  You probably don't want your pager

# going off on New Year's.  Although you're employer might... :-)

define timeperiod{

       name                    us-holidays

       timeperiod_name         us-holidays

       alias                   U.S. Holidays

       january 1               00:00-00:00     ; New Years

       monday -1 may           00:00-00:00     ; Memorial Day (last Monday in May)

       july 4                  00:00-00:00     ; Independence Day

       monday 1 september      00:00-00:00     ; Labor Day (first Monday in September)

       thursday -1 november    00:00-00:00     ; Thanksgiving (last Thursday in November)

       december 25             00:00-00:00     ; Christmas

       }

# This defines a modified "24x7" timeperiod that covers every day of the

# year, except for U.S. holidays (defined in the timeperiod above).

define timeperiod{

       timeperiod_name 24x7_sans_holidays

       alias           24x7 Sans Holidays

       use             us-holidays             ; Get holiday exceptions from other timeperiod

       sunday          00:00-24:00

       monday          00:00-24:00

       tuesday         00:00-24:00

       wednesday       00:00-24:00

       thursday        00:00-24:00

       friday          00:00-24:00

       saturday        00:00-24:00

       }

/etc/nagios3/objects/servers/localhost.cfg

define host{

       use                     linux-server

       host_name               localhost

       alias                   localhost

       address                 127.0.0.1

       check_interval          0.12

       notification_period     24x7

       notification_options    d,u,f,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             PING

       check_command                   check_ping!100.0,20%!500.0,60%

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             Root Partition

       check_command                   check_local_disk!20%!10%!/

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             var Partition

       check_command                   check_local_disk!20%!10%!/var

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             Current Users

       check_command                   check_local_users!20!50

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             Total Processes

       check_command                   check_local_procs!250!400!RSZDT

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             Current Load

       check_command                   check_local_load!5.0,4.0,3.0!10.0,6.0,4.0

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       localhost

       service_description             Swap Usage

       check_command                   check_local_swap!20!10

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Define a service to check SSH on the local machine.

# Disable notifications for this service by default, as not all users may have SSH enabled.

define service{

       use                             local-service         ; Name of service template to use

       host_name                       localhost

       service_description             SSH

       check_command                   check_ssh

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Define a service to check HTTP on the local machine.

# Disable notifications for this service by default, as not all users may have HTTP enabled.

define service{

       use                             local-service         ; Name of service template to use

       host_name                       localhost

       service_description             HTTP

       check_command                   check_http

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service; Inherit values from a template

       host_name               localhost

       service_description     Uptime

       check_command           check_netapp_uptime

       }

define service{

       use             generic-service; Inherit values from a template

       host_name       localhost

       service_description     eth0 System Link Status on hosting

       check_command           check_snmp!public!ifOperStatus.2! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service; Inherit values from a template

       host_name       localhost

       service_description     eth0.1001 Management Link Status on hosting

       check_command           check_snmp!public!ifOperStatus.3! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Monitor bandwidth via MRTG logs

define service{

       use             generic-service; Inherit values from a template

       host_name       localhost

       service_description     eth0 System Link Bandwidth Usage on hosting

       check_command           traffic_average!/var/www/mrtg/monitoring/127.0.0.1_2.log!AVG!1000000,2000000!5000000,5000000!10

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service; Inherit values from a template

       host_name       localhost

       service_description     eth0.1001 Management Link Usage on hosting

       check_command           traffic_average!/var/www/mrtg/monitoring/127.0.0.1_3.log!AVG!1000000,2000000!5000000,5000000!10

#        servicegroups  bandwidth_services

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               localhost

       service_description     Memory Usage

       check_command           check_snmp_mem_v1!public!70,70!90,90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

/etc/nagios3/objects/servers/1c.cfg

# Define a host for the Windows machine we'll be monitoring

# Change the host_name, alias, and address to fit your situation

define host{

       use             windows-server  ; Inherit default values from a template

       host_name       1c      ; The name we're giving to this host

       alias           1c terminal server      ; A longer name associated with the host

       address         10.10.80.33     ; IP address of the host

       notification_period     24x7

       notification_options    d,u,f,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Create a service for monitoring the version of NSCLient++ that is installed

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     NSClient++ Version

       check_command           check_nt!CLIENTVERSION

       }

# Create a service for monitoring the uptime of the server

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     Uptime

       check_command           check_nt!UPTIME

       }

# Create a service for monitoring CPU load

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     CPU Load

       check_command           check_nt!CPULOAD!-l 5,80,90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Create a service for monitoring

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     Memory Usage

       check_command           check_nt!MEMUSE!-w 80 -c 90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Create a service for monitoring C:\ disk usage

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     C:\ System Space

       check_command           check_nt!USEDDISKSPACE!-l c -w 80 -c 90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               1c

       service_description     D:\ Data Space

       check_command           check_nt!USEDDISKSPACE!-l d -w 80 -c 90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               1c

       service_description     E:\ Swap Usage

       check_command           check_nt!USEDDISKSPACE!-l e -w 80 -c 90

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Create a service for monitoring the Explorer.exe process

# Change the host_name to match the name of the host you defined above

define service{

       use                     generic-service

       host_name               1c

       service_description     Explorer

       check_command           check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

/etc/nagios3/objects/servers/db.cfg

define host{

       use                     linux-server

       host_name               db

       alias                   Database and DNS

       address                 192.168.10.215

       parents                 at9924

       notification_period     24x7

       notification_options    d,u,r,f

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service         ; Name of service template to use

       host_name                       db

       service_description             PING

       check_command                   check_ping!100.0,20%!500.0,60%

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service; Inherit values from a template

       host_name               db

       service_description     Uptime

       check_command           check_netapp_uptime

       }

define service{

       use                 generic-service

       host_name           db

       service_description CPU Load

       check_command       check_nrpe_1arg!check_load

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description / Free Space

       check_command       check_nrpe_1arg!check_disk1

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description /var Free Space

       check_command       check_nrpe_1arg!check_disk2

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description Raid State md0

       check_command       check_nrpe_1arg!check_raid

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description Total Processes

       check_command       check_nrpe_1arg!check_total_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description Zombie Processes

       check_command       check_nrpe_1arg!check_zombie_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           db

       service_description Swap Usage

       check_command       check_nrpe_1arg!check_swap

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               db

       service_description     Memory Usage

       check_command           check_snmp_mem_v1!public!85,70!90,90

       notification_period     24x7

       notification_options    w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service; Inherit values from a template

       host_name               db

       service_description     DNS

       check_command           check_dns

       }

/etc/nagios3/objects/servers/for.cfg

define host{

       use                     linux-server

       host_name               for

       alias                   Fortochka

       address                 192.168.10.3

       notification_period     24x7

       notification_options    d,u,r,f

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# SERVICE DEFINITIONS

# Define a service to "ping" the machine

define service{

       use                             local-service

       host_name                       for

       service_description             PING

       check_command                   check_ping!100.0,20%!500.0,60%

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Monitor uptime via SNMP

define service{

       use                     generic-service

       host_name               for

       service_description     Uptime

       check_command           check_netapp_uptime

       }

define service{

       use                 generic-service

       host_name           for

       service_description CPU Load

       check_command       check_nrpe_1arg!check_load

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           for

       service_description / Free Space

       check_command       check_nrpe_1arg!check_disk1

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           for

       service_description Total Processes

       check_command       check_nrpe_1arg!check_total_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           for

       service_description Zombie Processes

       check_command       check_nrpe_1arg!check_zombie_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           for

       service_description Swap Usage

       check_command       check_nrpe_1arg!check_swap

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       for

       service_description     eth0 External Link Status

       check_command           check_snmp!public!ifOperStatus.2! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               for

       service_description     Memory Usage

       check_command           check_snmp_mem_v1!public!85,70!90,90

       notification_period     24x7

       notification_options    w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use     generic-service

       host_name       for

       service_description     HTTP

       check_command   check_http

       }

/etc/nagios3/objects/servers/host_mail.cfg

define host{

       use                     linux-server

       host_name               host_mail

       alias                   Hosting and Mail

       address                 192.168.10.214

       notification_period     24x7

       notification_options    d,u,r,f

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                             local-service

       host_name                       host_mail

       service_description             PING

       check_command                   check_ping!100.0,20%!500.0,60%

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Monitor uptime via SNMP

define service{

       use                     generic-service

       host_name               host_mail

       service_description     Uptime

       check_command           check_netapp_uptime

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description CPU Load

       check_command       check_nrpe_1arg!check_load

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description /var/ Free Space

       check_command       check_nrpe_1arg!check_disk1

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description Total Processes

       check_command       check_nrpe_1arg!check_total_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description Zombie Processes

       check_command       check_nrpe_1arg!check_zombie_procs

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description Swap Usage

       check_command       check_nrpe_1arg!check_swap

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth0 External Link Status on hosting

       check_command           check_snmp!public!ifOperStatus.2! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth1 System Link Status on hosting

       check_command           check_snmp!public!ifOperStatus.3! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth1.80 Internal Link Status on hosting

       check_command           check_snmp!public!ifOperStatus.4! -m RFC1213-MIB

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

# Monitor bandwidth via MRTG logs

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth0 Bandwidth Usage on hosting

       check_command           traffic_average!/var/www/mrtg/host_mail/192.168.10.214_2.log!AVG!1000000,2000000!5000000,5000000!10

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth1 Bandwidth Usage on hosting

       check_command           traffic_average!/var/www/mrtg/host_mail/192.168.10.214_3.log!AVG!1000000,2000000!5000000,5000000!10

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use             generic-service

       host_name       host_mail

       service_description     eth1.80 Bandwidth Usage on hosting

       check_command           traffic_average!/var/www/mrtg/host_mail/192.168.10.214_5.log!AVG!1000000,2000000!5000000,5000000!10

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               host_mail

       service_description     SMTP

       check_command           check_smtp

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               host_mail

       service_description     POP3

       check_command           check_pop

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               host_mail

       service_description     IMAP

       check_command           check_imap

       notification_period     24x7

       notification_options    w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                     generic-service

       host_name               host_mail

       service_description     Memory Usage

       check_command           check_snmp_mem_v1!public!85,70!90,90

       notification_period     24x7

       notification_options    w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{

       use                 generic-service

       host_name           host_mail

       service_description Raid State md1

       check_command       check_nrpe_1arg!check_raid

       notification_period     24x7

       notification_options w,c,r

       notification_interval   30

       contact_groups          admins

       notifications_enabled   1

       }

define service{