Система мониторинга ресурсов и сервисов локальной вычислительной сети

РЕФЕРАТ

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

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

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

§ Полное описание всех этапов проектирования, разработки и внедрения системы;

§  Руководство системного администратора, включающее описание пользовательского интерфейса системы.

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

ПЕРЕЧЕНЬ ЛИСТОВ ГРАФИЧЕСКИХ ДОКУМЕНТОВ

Таблица 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.

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

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

LAN - Local Area Network - локальная сеть, ЛВС. адрес - Media Access Control - идентификационный номер сетевого устройства, определяемый, как правило, производителем.

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

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

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

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

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

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

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

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

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

Предприятие

Преддипломная практика проходила на предприятии ООО «Геркон» в отделе сопровождения в должности системного администратора. Предприятие предлагает услуги доступа в Интернет в городах Верхняя Пышма и Среднеуральск по технологии 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) выполняют функции, аналогичные функциям систем управления, но по отношению к коммуникационному оборудованию. Вместе с тем, некоторые функции этих двух видов систем управления могут дублироваться, например, средства управления системой могут выполнять простейший анализ сетевого трафика.

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

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

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

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

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

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

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

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

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

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

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

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

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

. Захват данных.

. Просмотр захваченных данных.

. Анализ данных.

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

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

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

Обычно процесс анализа протоколов занимает относительно немного времени - 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(англ. 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.- протокол мониторинга компьютерных сетей, расширение 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. ПРЕДЛАГАЕМАЯ СИСТЕМА

 

.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, что говорит о её бесплатности и открытости исходных кодов, что соответствует уточненному техническому заданию на проектирование системы сетевого мониторинга.(полное название GNU/Linux, произносится «гну слэш ли́нукс», также в некоторых языках «GNU+Linux», «GNU-Linux» и др.) - общее название UNIX-подобных операционных систем на основе одноимённого ядра и собранных для него библиотек и системных программ, разработанных в рамках проекта 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 используют дистрибутивы. Дистрибутив - это не просто набор программ, а ряд решений для разных задач пользователей, объединённых едиными системами установки, управления и обновления пакетов, настройки и поддержки.

Самые распространённые в мире дистрибутивы:- быстро завоевавший популярность дистрибутив, ориентированный на лёгкость в освоении и использовании.- бесплатно распространяемая версия дистрибутива SuSE, принадлежащая компании Novell. Отличается удобством в настройке и обслуживании благодаря использованию утилиты YaST.- поддерживается сообществом и корпорацией RedHat, предшествует выпускам коммерческой версии RHEL.GNU/Linux - международный дистрибутив, разрабатываемый обширным сообществом разработчиков в некоммерческих целях. Послужил основой для создания множества других дистрибутивов. Отличается строгим подходом к включению несвободного ПО.- французско-бразильский дистрибутив, объединение бывших Mandrake и Conectiva (англ.).- один из старейших дистрибутивов, отличается консервативным подходом в разработке и использовании.- дистрибутив, собираемый из исходных кодов. Позволяет очень гибко настраивать конечную систему и оптимизировать производительность, поэтому часто называет себя мета-дистрибутивом. Ориентирован на экспертов и опытных пользователей.- ориентированный на применение самых последних версий программ и постоянно обновляемый, поддерживающий одинаково как бинарную, так и установку из исходных кодов и построенный на философии простоты 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. Можно это делать и из-под учетной записи суперпользователя, что создаст серьезную угрозу для безопасности системы.

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

% sudo -s

Создадим новую учетную запись пользователя 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 и его плагинов (#"785441.files/image003.gif">

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

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

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

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

.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 и NSClient’a, поставляемого с Nagios. Ниже представлена схема его работы

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

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

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

 

.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. Библиотека, ответственная за формирование графики (#"785441.files/image008.gif">

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

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

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

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

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

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

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

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

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

 

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

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

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

·        шум;

·        электромагнитное излучение;

·        электростатическое поле.

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

 

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

 

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

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

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

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

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

·        защитное заземление;

·        защитное зануление;

·        защитное отключение.

 

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

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

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

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

·    применение бесшумных охлаждающих механизмов;

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

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

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

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

·        принтер (49дБ) [49].

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

                                                                                  (7.1)

где Li - уровень шума одного устройства, дБ= 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 Условия труда

 

.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

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

 

.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 Эргономика рабочего места

 

.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 неделя).

 

.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 руб

 

.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 с.

.        Бройдо В. Л. Вычислительные системы, сети и телекоммуникации: Учебник для вузов / В.Л. Бройдо. - Спб.: Питер, 2003. - 688 с.

.        Гусева А.И. Работа в локальных сетях: Учебник / А. И. Гусева. - М.: Диалог - МИФИ, 2001. - 344 с.

.        Камалян А.К., Кулев С.А., Назаренко К.Н. и др. Компьютерные сети и средства защиты информации: Учебное пособие /Камалян А.К., Кулев С.А., Назаренко К.Н. и др. - Воронеж: ВГАУ, 2003.-119с.

.        Курносов А.П. Практикум по информатике/Под ред. Курносова А.П. Воронеж: ВГАУ, 2001.- 173 с.

.        Малышев Р.А. Локальные вычислительные сети: Учебное пособие/ РГАТА. - Рыбинск, 2005. - 83 с.

.        Новиков Ю. В. Локальные сети: архитектура, алгоритмы, проектирование. / Ю. В. Новиков. - М.: ЭКОМ, 2000. - 312 с.

.        Новиков Ю. В. Основы локальных сетей / Ю. В. Новиков. - М.: ЭКОМ, 2005. - 360 с.

.        Олифер В.Г, Олифер Н.А. Сетевые операционные системы/ В.Г. Олифер, Н.А. Олифер. - СПб.: Питер, 2002. - 544 с.: ил.

.        Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы /В.Г. Олифер, Н.А. Олифер. - СПб.: Питер, 2002. - 672 с.

.        Флинт Д. Локальные сети ПК: принципы построения, реализация / Д. Флинт. - М.: Финансы и статистика, 2001. - 359 с.

.        Фридман А.Л. Основы объектно-ориентированной разработки программных систем. / А. Л. Фридман. - М.: Финансы и статистика, 2000. - 192 с.

.        Шафрин Ю.А. Основы компьютерной технологии / Ю.А. Шафрин. - М.: АБФ, 2001. - 560 с.

.        Яковлев В.А. Компьютерные сети / В.А. Яковлев. - М.: ИНФРА-М. 2001. - 244 с.

.        www.informika.ru - Интернет-учебник по информатике.

.        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 - Русский блог-портал специалистов по информационным технологиям.

.        #"785441.files/image030.gif">

Приложение Б

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

Назв.

Диаграммы

SLA <#"785441.files/image031.gif"> Рис. Д.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 contact{_name nagiosadmin ; Short name of usergeneric-contact ; Inherit default values from generic-contact template (defined above)Voynovich Andrey ; Full name of useradmin@vpcit.ru_notifications_enabled 1_notifications_enabled 1_notification_period 24x7_notification_period 24x7_notification_options w,u,c,r_notification_options d,u,r_notification_commands notify-service-by-email_notification_commands notify-host-by-email_submit_commands 1 } contact{_name mainadmin ; Short name of usergeneric-contact ; Inherit default values from generic-contact template (defined above)Demidoff Alexander ; Full name of userdemidoff@vpcit.ru host_notifications_enabled 1_notifications_enabled 1_notification_period 24x7_notification_period 24x7_notification_options w,u,c,r_notification_options d,u,r_notification_commands notify-service-by-email_notification_commands notify-host-by-email_submit_commands 0 } contact{_name maincoder ; Short name of usergeneric-contact ; Inherit default values from generic-contact template (defined above)Don Yura ; Full name of useryura@vpcit.ru_notifications_enabled 1_notifications_enabled 1_notification_period 24x7_notification_period 24x7_notification_options w,u,c,r_notification_options d,u,r_notification_commands notify-service-by-email_notification_commands notify-host-by-email_submit_commands 0 } /etc/nagios3/objects/extinfo.cfg hostextinfo{_name debian-serversDebian GNU/Linux servers_image base/debian.png_image_alt Debian GNU/Linux_image debian.png_image base/debian.gd2 } hostextinfo{_name windows-serversMicrosoft Windows servers_image base/win40.png_image_alt Microsoft Windows_image win40.png_image base/win40.gd2 } hostextinfo{_name routersNetwork Routers_image base/router40.png_image_alt Router_image router40.png_image base/router40.gd2 } /etc/nagios3/objects/hostgroups.cfg # Define an optional hostgroup for Linux machineshostgroup{_name linux-servers ; The name of the hostgroupLinux Servers ; Long name of the grouplocalhost,host_mail,db,isp,for ; Comma separated list of hosts that belong to this group } # A list of your Debian GNU/Linux servershostgroup {_name debian-serversDebian GNU/Linux Serverslocalhost,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 hostgroup{_name windows-servers ; The name of the hostgroupWindows Servers ; Long name of the group } # Create a new hostgroup for switches hostgroup{_name routers ; The name of the hostgroupNetwork 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! contact{generic-contact ; The name of this contact template_notification_period 24x7 ; service notifications can be sent anytime_notification_period 24x7 ; host notifications can be sent anytime_notification_options w,u,c,r,f,s ; send notifications for all service states, flapping events, and scheduled downtime events_notification_options d,u,r,f,s ; send notifications for all host states, flapping events, and scheduled downtime events_notification_commands notify-service-by-email ; send service notifications via email_notification_commands notify-host-by-email ; send host notifications via email0 ; 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! host{generic-host ; The name of this host template_enabled 1 ; Host notifications are enabled_handler_enabled 1 ; Host event handler is enabled_detection_enabled 1 ; Flap detection is enabled_prediction_enabled 1 ; Failure prediction is enabled_perf_data 1 ; Process performance data_status_information 1 ; Retain status information across program restarts_nonstatus_information 1 ; Retain non-status information across program restarts_period 24x7 ; Send host notifications at any time0 ; 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! host{linux-server ; The name of this host templategeneric-host ; This template inherits other values from the generic-host template_period 24x7 ; By default, Linux hosts are checked round the clock_interval 5 ; Actively check the host every 5 minutes_interval 1 ; Schedule host check retries at 1 minute intervals_check_attempts 10 ; Check each Linux host 10 times (max)_command check-host-alive ; Default command to check Linux hosts_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!_interval 120 ; Resend notifications every 2 hours_options d,u,r ; Only send notifications for specific host states_groups admins ; Notifications get sent to the admins by default0 ; 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! host{windows-server ; The name of this host templategeneric-host ; Inherit default values from the generic-host template_period 24x7 ; By default, Windows servers are monitored round the clock_interval 5 ; Actively check the server every 5 minutes_interval 1 ; Schedule host check retries at 1 minute intervals_check_attempts 10 ; Check each server 10 times (max)_command check-host-alive ; Default command to check if servers are "alive"_period 24x7 ; Send notification out at any time - day or night_interval 30 ; Resend notifications every 30 minutes_options d,r ; Only send notifications for specific host states_groups admins ; Notifications get sent to the admins by defaultwindows-servers ; Host groups that Windows servers should be a member of0 ; DONT REGISTER THIS - ITS JUST A TEMPLATE } # We define a generic printer template that can be used for most printers we monitor host{generic-printer ; The name of this host templategeneric-host ; Inherit default values from the generic-host template_period 24x7 ; By default, printers are monitored round the clock_interval 5 ; Actively check the printer every 5 minutes_interval 1 ; Schedule host check retries at 1 minute intervals_check_attempts 10 ; Check each printer 10 times (max)_command check-host-alive ; Default command to check if printers are "alive"_period workhours ; Printers are only used during the workday_interval 30 ; Resend notifications every 30 minutes_options d,r ; Only send notifications for specific host states_groups admins ; Notifications get sent to the admins by default0 ; DONT REGISTER THIS - ITS JUST A TEMPLATE } # Define a template for switches that we can reusehost{generic-switch ; The name of this host templategeneric-host ; Inherit default values from the generic-host template_period 24x7 ; By default, switches are monitored round the clock_interval 5 ; Switches are checked every 5 minutes_interval 1 ; Schedule host check retries at 1 minute intervals_check_attempts 10 ; Check each switch 10 times (max)_command check-host-alive ; Default command to check if routers are "alive"_period 24x7 ; Send notifications at any time_interval 30 ; Resend notifications every 30 minutes_options d,r ; Only send notifications for specific host states_groups admins ; Notifications get sent to the admins by default0 ; DONT REGISTER THIS - ITS JUST A TEMPLATE } # SERVICE TEMPLATES # Generic service definition template - This is NOT a real service, just a template! service{generic-service ; The 'name' of this service template_checks_enabled 1 ; Active service checks are enabled_checks_enabled 1 ; Passive service checks are enabled/accepted_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)_over_service 1 ; We should obsess over this service (if necessary)_freshness 0 ; Default is to NOT check service 'freshness'_enabled 1 ; Service notifications are enabled_handler_enabled 1 ; Service event handler is enabled_detection_enabled 1 ; Flap detection is enabled_prediction_enabled 1 ; Failure prediction is enabled_perf_data 1 ; Process performance data_status_information 1 ; Retain status information across program restarts_nonstatus_information 1 ; Retain non-status information across program restarts_volatile 0 ; The service is not volatile_period 24x7 ; The service can be checked at any time of the day_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state_check_interval 10 ; Check the service every 10 minutes under normal conditions_check_interval 2 ; Re-check the service every two minutes until a hard state can be determined_groups admins ; Notifications get sent out to everyone in the 'admins' group_options w,u,c,r ; Send notifications about warning, unknown, critical, and recovery events_interval 60 ; Re-notify about service problems every hour_period 24x7 ; Notifications can be sent out at any time0 ; 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! service{local-service ; The name of this service templategeneric-service ; Inherit default values from the generic-service definition_check_attempts 4 ; Re-check the service up to 4 times in order to determine its final (hard) state_check_interval 5 ; Check the service every 5 minutes under normal conditions_check_interval 1 ; Re-check the service every minute until a hard state can be determined0 ; 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. :-)timeperiod{_name 24x724 Hours A Day, 7 Days A Week00:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:00 } # 'workhours' timeperiod definitiontimeperiod{_name workhoursNormal Work Hours09:00-18:0009:00-18:0009:00-18:0009:00-18:0009:00-18:00 } # 'none' timeperiod definitiontimeperiod{_name noneNo 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... :-)timeperiod{us-holidays_name us-holidaysU.S. Holidays 1 00:00-00:00 ; New Years-1 may 00:00-00:00 ; Memorial Day (last Monday in May)4 00:00-00:00 ; Independence Day1 september 00:00-00:00 ; Labor Day (first Monday in September)-1 november 00:00-00:00 ; Thanksgiving (last Thursday in November)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).timeperiod{_name 24x7_sans_holidays24x7 Sans Holidays us-holidays ; Get holiday exceptions from other timeperiod 00:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:0000:00-24:00 } /etc/nagios3/objects/servers/localhost.cfg host{linux-server_name localhostlocalhost127.0.0.1_interval 0.12_period 24x7_options d,u,f,r_interval 30_groups admins_enabled 1 } service{local-service_name localhost_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{local-service_name localhost_description Root Partition_command check_local_disk!20%!10%!/_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{local-service_name localhost_description var Partition_command check_local_disk!20%!10%!/var_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{local-service_name localhost_description Current Users_command check_local_users!20!50_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{local-service_name localhost_description Total Processes_command check_local_procs!250!400!RSZDT_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{local-service_name localhost_description Current Load_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{local-service_name localhost_description Swap Usage_command check_local_swap!20!10_period 24x7_options w,c,r_interval 30_groups admins_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. service{local-service ; Name of service template to use_name localhost_description SSH_command check_ssh_period 24x7_options w,c,r_interval 30_groups admins_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.service{local-service ; Name of service template to use_name localhost_description HTTP_command check_http_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name localhost_description Uptime_command check_netapp_uptime } service{generic-service; Inherit values from a template_name localhost_description eth0 System Link Status on hosting_command check_snmp!public!ifOperStatus.2! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service; Inherit values from a template_name localhost_description eth0.1001 Management Link Status on hosting_command check_snmp!public!ifOperStatus.3! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor bandwidth via MRTG logs service{generic-service; Inherit values from a template_name localhost_description eth0 System Link Bandwidth Usage on hosting_command traffic_average!/var/www/mrtg/monitoring/127.0.0.1_2.log!AVG!1000000,2000000!5000000,5000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name localhost_description eth0.1001 Management Link Usage on hosting_command traffic_average!/var/www/mrtg/monitoring/127.0.0.1_3.log!AVG!1000000,2000000!5000000,5000000!10 # servicegroups bandwidth_services_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name localhost_description Memory Usage_command check_snmp_mem_v1!public!70,70!90,90_period 24x7_options w,c,r_interval 30_groups admins_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 situationhost{windows-server ; Inherit default values from a template_name 1c ; The name we're giving to this host1c terminal server ; A longer name associated with the host10.10.80.33 ; IP address of the host_period 24x7_options d,u,f,r_interval 30_groups admins_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 service{generic-service_name 1c_description NSClient++ Version_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 service{generic-service_name 1c_description Uptime_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 service{generic-service_name 1c_description CPU Load_command check_nt!CPULOAD!-l 5,80,90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Create a service for monitoring # Change the host_name to match the name of the host you defined above service{generic-service_name 1c_description Memory Usage_command check_nt!MEMUSE!-w 80 -c 90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Create a service for monitoring C:\ disk usage # Change the host_name to match the name of the host you defined above service{generic-service_name 1c_description C:\ System Space_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name 1c_description D:\ Data Space_command check_nt!USEDDISKSPACE!-l d -w 80 -c 90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name 1c_description E:\ Swap Usage_command check_nt!USEDDISKSPACE!-l e -w 80 -c 90_period 24x7_options w,c,r_interval 30_groups admins_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 service{generic-service_name 1c_description Explorer_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } /etc/nagios3/objects/servers/db.cfg host{linux-server_name dbDatabase and DNS192.168.10.215at9924_period 24x7_options d,u,r,f_interval 30_groups admins_enabled 1 } service{local-service ; Name of service template to use_name db_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name db_description Uptime_command check_netapp_uptime } service{generic-service_name db_description CPU Load_command check_nrpe_1arg!check_load_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description / Free Space_command check_nrpe_1arg!check_disk1_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description /var Free Space_command check_nrpe_1arg!check_disk2_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description Raid State md0_command check_nrpe_1arg!check_raid_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description Total Processes_command check_nrpe_1arg!check_total_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description Zombie Processes_command check_nrpe_1arg!check_zombie_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description Swap Usage_command check_nrpe_1arg!check_swap_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name db_description Memory Usage_command check_snmp_mem_v1!public!85,70!90,90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name db_description DNS_command check_dns } /etc/nagios3/objects/servers/for.cfg host{linux-server_name forFortochka192.168.10.3_period 24x7_options d,u,r,f_interval 30_groups admins_enabled 1 } # SERVICE DEFINITIONS # Define a service to "ping" the machine service{local-service_name for_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor uptime via SNMP service{generic-service_name for_description Uptime_command check_netapp_uptime } service{generic-service_name for_description CPU Load_command check_nrpe_1arg!check_load_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service_name for_description / Free Space_command check_nrpe_1arg!check_disk1_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name for_description Total Processes_command check_nrpe_1arg!check_total_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name for_description Zombie Processes_command check_nrpe_1arg!check_zombie_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name for_description Swap Usage_command check_nrpe_1arg!check_swap_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name for_description eth0 External Link Status_command check_snmp!public!ifOperStatus.2! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service_name for_description Memory Usage_command check_snmp_mem_v1!public!85,70!90,90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name for_description HTTP_command check_http } /etc/nagios3/objects/servers/host_mail.cfg host{linux-server_name host_mailHosting and Mail192.168.10.214_period 24x7_options d,u,r,f_interval 30_groups admins_enabled 1 } service{local-service_name host_mail_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor uptime via SNMP service{generic-service_name host_mail_description Uptime_command check_netapp_uptime } service{generic-service_name host_mail_description CPU Load_command check_nrpe_1arg!check_load_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description /var/ Free Space_command check_nrpe_1arg!check_disk1_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description Total Processes_command check_nrpe_1arg!check_total_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description Zombie Processes_command check_nrpe_1arg!check_zombie_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description Swap Usage_command check_nrpe_1arg!check_swap_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description eth0 External Link Status on hosting_command check_snmp!public!ifOperStatus.2! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description eth1 System Link Status on hosting_command check_snmp!public!ifOperStatus.3! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description eth1.80 Internal Link Status on hosting_command check_snmp!public!ifOperStatus.4! -m RFC1213-MIB_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor bandwidth via MRTG logsservice{generic-service_name host_mail_description eth0 Bandwidth Usage on hosting_command traffic_average!/var/www/mrtg/host_mail/192.168.10.214_2.log!AVG!1000000,2000000!5000000,5000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description eth1 Bandwidth Usage on hosting_command traffic_average!/var/www/mrtg/host_mail/192.168.10.214_3.log!AVG!1000000,2000000!5000000,5000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description eth1.80 Bandwidth Usage on hosting_command traffic_average!/var/www/mrtg/host_mail/192.168.10.214_5.log!AVG!1000000,2000000!5000000,5000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description SMTP_command check_smtp_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description POP3_command check_pop_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description IMAP_command check_imap_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description Memory Usage_command check_snmp_mem_v1!public!85,70!90,90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service_name host_mail_description Raid State md1_command check_nrpe_1arg!check_raid_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name host_mail_description HTTP_command check_http } /etc/nagios3/objects/servers/isp.cfg host{linux-server_name ispDatabase and DNS192.168.10.217at9924_period 24x7_options d,u,r,f_interval 30_groups admins_enabled 1 } service{local-service_name isp_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name isp_description DNS_command check_dns } /etc/nagios3/objects/routers/at9924.cfg host{generic-switch ; Inherit default values from a template_name at9924 ; The name we're giving to this switchAllied Telesyn AT-9924 ; A longer name associated with the switch192.168.10.101 ; IP address of the switchrouters ; Host groups this switch is associated with_period 24x7_options d,u,f,r_interval 30_groups admins_enabled 1 } # Create a service to PING to switch service{generic-service ; Inherit values from a template_name at9924 ; The name of the host the service is associated with_description PING ; The service description_command check_ping!200.0,20%!600.0,60% ; The command used to monitor the service_check_interval 5 ; Check the service every 5 minutes under normal conditions_check_interval 1 ; Re-check the service every minute until its final/hard state is determined_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor uptime via SNMP service{generic-service ; Inherit values from a template_name at9924_description Uptime_command check_netapp_uptime } # Monitor Ports status via SNMP service{generic-service ; Inherit values from a template_name at9924_description Port 1 Link Status ub13_command check_snmp!public!ifOperStatus.1! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name at9924_description Port 2 Link Status Lenina-105B_command check_snmp!public!ifOperStatus.2! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name at9924_description Port 3 Link Status krivousova36b_command check_snmp!public!ifOperStatus.3! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name at9924_description Port 4 Link Status ur39a_command check_snmp!public!ifOperStatus.4! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name at9924_description Port 5 Link Status ISP-concentrator_command check_snmp!public!ifOperStatus.5! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name at9924_description Port 6 Link Status isp-server_command check_snmp!public!ifOperStatus.6! -m RFC1213-MIB } <…> # Monitor bandwidth via MRTG logs service{generic-service ; Inherit values from a template_name at9924_description Port 1 Bandwidth Usage ub13_command traffic_average!/var/www/mrtg/AT-9924/192.168.10.101_1.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name at9924_description Port 2 Bandwidth Usage Lenina-105B_command traffic_average!/var/www/mrtg/AT-9924/192.168.10.101_2.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name at9924_description Port 3 Bandwidth Usage krivousova36b_command traffic_average!/var/www/mrtg/AT-9924/192.168.10.101_3.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service ; Inherit values from a template_name at9924_description Port 4 Bandwidth Usage ur39a_command traffic_average!/var/www/mrtg/AT-9924/192.168.10.101_4.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } <…> /etc/nagios3/objects/routers/router_len58a.cfg host{linux-server_name router_len58aLenina 58a Router192.168.10.158des3627g_period 24x7_options d,u,r,f_interval 30_groups admins_enabled 1 }service{local-service ; Name of service template to use_name router_len58a_description PING_command check_ping!100.0,20%!500.0,60%_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name router_len58a_description Uptime_command check_netapp_uptime } service{generic-service_name router_len58a_description CPU Load_command check_nrpe_1arg!check_load_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service_name router_len58a_description / Free Space_command check_nrpe_1arg!check_disk1_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 service{generic-service_name router_len58a_description Total Processes_command check_nrpe_1arg!check_total_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name router_len58a_description Zombie Processes_command check_nrpe_1arg!check_zombie_procs_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service_name router_len58a_description Memory Usage_command check_snmp_mem_v1!public!85,70!90,90_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service; Inherit values from a template_name router_len58a_description DNS_command check_dns } /etc/nagios3/objects/routers/des3627g.cfg host{generic-switch ; Inherit default values from a template_name des3627g ; The name we're giving to this switchD-Link DES-3627G ; A longer name associated with the switch192.168.10.111 ; IP address of the switchrouters ; Host groups this switch is associated with_period 24x7_options d,u,f,r_interval 30_groups admins_enabled 1 } # Create a service to PING to switch service{generic-service ; Inherit values from a template_name des3627g ; The name of the host the service is associated with_description PING ; The service description_command check_ping!200.0,20%!600.0,60% ; The command used to monitor the service_check_interval 5 ; Check the service every 5 minutes under normal conditions_check_interval 1 ; Re-check the service every minute until its final/hard state is determined_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } # Monitor uptime via SNMPservice{generic-service ; Inherit values from a template_name des3627g_description Uptime_command check_netapp_uptime } # Monitor Ports status via SNMP service{generic-service ; Inherit values from a template_name des3627g_description Port 1 Link Status_command check_snmp!public!ifOperStatus.1! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 2 Link Status_command check_snmp!public!ifOperStatus.2! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 3 Link Status_command check_snmp!public!ifOperStatus.3! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 4 Link Status_command check_snmp!public!ifOperStatus.4! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 5 Link Status_command check_snmp!public!ifOperStatus.5! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 6 Link Status_command check_snmp!public!ifOperStatus.6! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 7 Link Status_command check_snmp!public!ifOperStatus.7! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 8 Link Status_command check_snmp!public!ifOperStatus.8! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 9 Link Status_command check_snmp!public!ifOperStatus.9! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 10 Link Status_command check_snmp!public!ifOperStatus.10! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 11 Link Status_command check_snmp!public!ifOperStatus.11! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 12 Link Status ugmk-router_command check_snmp!public!ifOperStatus.12! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 21 Link Status_command check_snmp!public!ifOperStatus.21! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 22 Link Status_command check_snmp!public!ifOperStatus.22! -m RFC1213-MIB } service{generic-service ; Inherit values from a template_name des3627g_description Port 23 Link Status_command check_snmp!public!ifOperStatus.23! -m RFC1213-MIB } # Monitor bandwidth via MRTG logs service{generic-service ; Inherit values from a template_name des3627g_description Port 1 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_1.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 2 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_2.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 3 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_3.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 4 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_4.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 5 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_5.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 6 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_6.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 8 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_8.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 9 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_9.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 10 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_10.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 }service{generic-service ; Inherit values from a template_name des3627g_description Port 11 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_11.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 12 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_12.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 21 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_21.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 22 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_22.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } service{generic-service ; Inherit values from a template_name des3627g_description Port 23 Bandwidth Usage_command traffic_average!/var/www/mrtg/DES-3627G/192.168.10.111_23.log!AVG!80000000,90000000!100000000,120000000!10_period 24x7_options w,c,r_interval 30_groups admins_enabled 1 } /etc/nagios/nrpe.cfg ############################################################################# # This is configuration file for the NRPE daemon. It needs to be # located on the remote host that is running the NRPE daemon, not the host # from which the check_nrpe client is being executed. ############################################################################# # PID FILE # The name of the file in which the NRPE daemon should write it's process ID # number. The file is only written if the NRPE daemon is started by the root # user and is running in standalone mode. _file=/var/run/nrpe.pid # PORT NUMBER # Port number we should wait for connections on. # NOTE: This must be a non-priviledged port (i.e. > 1024). # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _port=5666 # SERVER ADDRESS # Address that nrpe should bind to in case there are more than one interface # and you do not want nrpe to bind on all interfaces. # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _address=192.168.10.214 # NRPE USER # This determines the effective user that the NRPE daemon should run as. # You can either supply a username or a UID. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _user=nagios # NRPE GROUP # This determines the effective group that the NRPE daemon should run as. # You can either supply a group name or a GID. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd_group=nagios # ALLOWED HOST ADDRESSES # This is an optional comma-delimited list of IP address or hostnames # that are allowed to talk to the NRPE daemon. # # Note: The daemon only does rudimentary checking of the client's IP # address. I would highly recommend adding entries in your /etc/hosts.allow # file to allow only the specified host to connect to the port # you are running this daemon on. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _hosts=127.0.0.1,192.168.10.2 # COMMAND ARGUMENT PROCESSING # This option determines whether or not the NRPE daemon will allow clients # to specify arguments to commands that are executed. This option only works # if the daemon was configured with the --enable-command-args configure script # option. # # *** ENABLING THIS OPTION IS A SECURITY RISK! *** # Read the SECURITY file for information on some of the security implications # of enabling this variable. # # Values: 0=do not allow arguments, 1=allow command arguments_blame_nrpe=0 # COMMAND PREFIX # This option allows you to prefix all commands with a user-defined string. # A space is automatically added between the specified prefix string and the # command line from the command definition. # # *** THIS EXAMPLE MAY POSE A POTENTIAL SECURITY RISK, SO USE WITH CAUTION! *** # Usage scenario: # Execute restricted commmands using sudo. For this to work, you need to add # the nagios user to your /etc/sudoers. An example entry for alllowing # execution of the plugins from might be: # # nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/ # # This lets the nagios user run all commands in that directory (and only them) # without asking for a password. If you do this, make sure you don't give # random users write access to that directory or its contents! # command_prefix=/usr/bin/sudo # DEBUGGING OPTION # This option determines whether or not debugging messages are logged to the # syslog facility. # Values: 0=debugging off, 1=debugging on =0 # COMMAND TIMEOUT # This specifies the maximum number of seconds that the NRPE daemon will # allow plugins to finish executing before killing them off. _timeout=60 # WEEK RANDOM SEED OPTION # This directive allows you to use SSL even if your system does not have # a /dev/random or /dev/urandom (on purpose or because the necessary patches # were not applied). The random number generator will be seeded from a file # which is either a file pointed to by the environment valiable $RANDFILE # or $HOME/.rnd. If neither exists, the pseudo random number generator will # be initialized and a warning will be issued. # Values: 0=only seed from /dev/[u]random, 1=also seed from weak randomness #allow_weak_random_seed=1 # INCLUDE CONFIG FILE # This directive allows you to include definitions from an external config file. #include=<somefile.cfg> # INCLUDE CONFIG DIRECTORY # This directive allows you to include definitions from config files (with a # .cfg extension) in one or more directories (with recursion). #include_dir=<somedirectory> #include_dir=<someotherdirectory> # COMMAND DEFINITIONS # Command definitions that this daemon will run. Definitions # are in the following format: # # command[<command_name>]=<command_line> # # When the daemon receives a request to return the results of <command_name> # it will execute the command specified by the <command_line> argument. # # Unlike Nagios, the command line cannot contain macros - it must be # typed exactly as it should be executed. # # Note: Any plugins that are used in the command lines must reside # on the machine that this daemon is running on! The examples below # assume that you have plugins installed in a /usr/local/nagios/libexec # directory. Also note that you will have to modify the definitions below # to match the argument format the plugins expect. Remember, these are # examples only! # The following examples use hardcoded command arguments... [check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/md1[check_disk2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/md3[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 17000 -c 18000 -s Z[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 17000 -c 20000[check_swap]=/usr/lib/nagios/plugins/check_swap -w 20 -c 10[check_raid]=/usr/lib/nagios/plugins/check_linux_raid md1 # The following examples allow user-supplied arguments and can # only be used if the NRPE daemon was compiled with support for # command arguments *AND* the dont_blame_nrpe directive in this # config file is set to '1'... #command[check_users]=/usr/lib/nagios/plugins/check_users -w $ARG1$ -c $ARG2$ #command[check_load]=/usr/lib/nagios/plugins/check_load -w $ARG1$ -c $ARG2$ #command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ #command[check_procs]=/usr/lib/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$ # # local configuration: # if you'd prefer, you can instead place directives here=/etc/nagios/nrpe_local.cfg Приложение И Исходные тексты плагинов, не идущих в поставке с пакетом ядра системы. /usr/lib/nagios/plugins/check_snmp_load.pl #!/usr/bin/perl -w # nagios: -epn ############################## check_snmp_load #################$Version='1.12'; # # Help : ./check_snmp_load.pl -h # strict;Net::SNMP;Getopt::Long; # Nagios specific $TIMEOUT = 15;%ERRORS=('OK'=>0,'WARNING'=>1,'CRITICAL'=>2,'UNKNOWN'=>3,'DEPENDENT'=>4); # SNMP Datas # Generic with host-ressource-mib$base_proc = "1.3.6.1.2.1.25.3.3.1"; # oid for all proc info$proc_id = "1.3.6.1.2.1.25.3.3.1.1"; # list of processors (product ID)$proc_load = "1.3.6.1.2.1.25.3.3.1.2"; # %time the proc was not idle over last minute # Linux load $linload_table= "1.3.6.1.4.1.2021.10.1"; # net-snmp load table$linload_name = "1.3.6.1.4.1.2021.10.1.2"; # text 'Load-1','Load-5', 'Load-15'$linload_load = "1.3.6.1.4.1.2021.10.1.3"; # effective load table # Cisco cpu/load $cisco_cpu_5m = "1.3.6.1.4.1.9.2.1.58.0"; # Cisco CPU load (5min %)$cisco_cpu_1m = "1.3.6.1.4.1.9.2.1.57.0"; # Cisco CPU load (1min %)$cisco_cpu_5s = "1.3.6.1.4.1.9.2.1.56.0"; # Cisco CPU load (5sec %) # Cisco catalyst cpu/load $ciscocata_cpu_5m = ".1.3.6.1.4.1.9.9.109.1.1.1.1.5.9"; # Cisco CPU load (5min %)$ciscocata_cpu_1m = ".1.3.6.1.4.1.9.9.109.1.1.1.1.3.9"; # Cisco CPU load (1min %)$ciscocata_cpu_5s = ".1.3.6.1.4.1.9.9.109.1.1.1.1.4.9"; # Cisco CPU load (5sec %) # Netscreen cpu/load $nsc_cpu_5m = "1.3.6.1.4.1.3224.16.1.4.0"; # NS CPU load (5min %)$nsc_cpu_1m = "1.3.6.1.4.1.3224.16.1.2.0"; # NS CPU load (1min %)$nsc_cpu_5s = "1.3.6.1.4.1.3224.16.1.3.0"; # NS CPU load (5sec %) # AS/400 CPU $as400_cpu = "1.3.6.1.4.1.2.6.4.5.1.0"; # AS400 CPU load (10000=100%); # Net-SNMP CPU $ns_cpu_idle = "1.3.6.1.4.1.2021.11.11.0"; # Net-snmp cpu idle$ns_cpu_user = "1.3.6.1.4.1.2021.11.9.0"; # Net-snmp user cpu usage$ns_cpu_system = "1.3.6.1.4.1.2021.11.10.0"; # Net-snmp system cpu usage # Procurve CPU$procurve_cpu = "1.3.6.1.4.1.11.2.14.11.5.1.9.6.1.0"; # Procurve CPU Counter # Nokia CPU$nokia_cpu = "1.3.6.1.4.1.94.1.21.1.7.1.0"; # Nokia CPU % usage # Bluecoat Appliance$bluecoat_cpu = "1.3.6.1.4.1.3417.2.4.1.1.1.4.1"; # Bluecoat %cpu usage. # Fortigate CPU$fortigate_cpu = ".1.3.6.1.4.1.12356.1.8.0"; # Fortigate CPU % usage # Linkproof Appliance$linkproof_cpu= "1.3.6.1.4.1.89.35.1.55.0"; # CPU RE (Routing Engine Tasks) # 1.3.6.1.4.1.89.35.1.53.0 : Ressource utilisation (%) Considers network utilization and internal CPU utilization # 1.3.6.1.4.1.89.35.1.54 : CPU only (%) # 1.3.6.1.4.1.89.35.1.55 : network only (%) # HP-UX cpu usage (thanks to krizb for the OIDs).$hpux_load_1_min="1.3.6.1.4.1.11.2.3.1.1.3.0";$hpux_load_5_min="1.3.6.1.4.1.11.2.3.1.1.4.0";$hpux_load_15_min="1.3.6.1.4.1.11.2.3.1.1.5.0"; # valid values@valid_types = ("stand","netsc","netsl","as400","cisco","cata","nsc","fg","bc","nokia","hp","lp","hpux"); # CPU OID array%cpu_oid = ("netsc",$ns_cpu_idle,"as400",$as400_cpu,"bc",$bluecoat_cpu,"nokia",$nokia_cpu,"hp",$procurve_cpu,"lp",$linkproof_cpu,"fg",$fortigate_cpu); # Globals $o_host = undef; # hostname$o_community = undef; # community$o_port = 161; # port$o_help= undef; # wan't some help ?$o_verb= undef; # verbose mode$o_version= undef; # print version # check type : stand | netsc | netsl | as400 | cisco | cata | nsc | fg | bc | nokia | hp | lp | hpux$o_check_type= "stand"; # End compatibility$o_warn= undef; # warning level@o_warnL= undef; # warning levels for Linux Load or Cisco CPU$o_crit= undef; # critical level@o_critL= undef; # critical level for Linux Load or Cisco CPU$o_timeout= undef; # Timeout (Default 5)$o_perf= undef; # Output performance data$o_version2= undef; # use snmp v2c # SNMPv3 specific$o_login= undef; # Login for snmpv3$o_passwd= undef; # Pass for snmpv3$v3protocols=undef; # V3 protocol list.$o_authproto='md5'; # Auth protocol$o_privproto='des'; # Priv protocol$o_privpass= undef; # priv password # functions p_version { print "check_snmp_load version : $Version\n"; } print_usage {"Usage: $0 [-v] -H <host> -C <snmp_community> [-2] | (-l login -x passwd [-X pass -L <authp>,<privp>]) [-p <port>] -w <warn level> -c <crit level> -T=[stand|netsl|netsc|as400|cisco|cata|nsc|fg|bc|nokia|hp|lp|hpux] [-f] [-t <timeout>] [-V]\n"; } isnnum { # Return true if arg is not a number$num = shift;( $num =~ /^(\d+\.?\d*)|(^\.\d+)$/ ) { return 0 ;}1; } help {"\nSNMP Load & CPU Monitor for Nagios version ",$Version,"\n";"GPL licence, (c)2004-2007 Patrick Proy\n\n";_usage();<<EOT; v, --verboseextra debugging information h, --helpthis help message H, --hostname=HOSTor IP address of host to check C, --community=COMMUNITY NAMEname for the host's SNMP agent (implies v1 protocol) , --v2csnmp v2c l, --login=LOGIN ; -x, --passwd=PASSWDand auth password for snmpv3 authenticationno priv password exists, implies AuthNoPriv X, --privpass=PASSWDpassword for snmpv3 (AuthPriv protocol) L, --protocols=<authproto>,<privproto> <authproto> : Authentication protocol (md5|sha : default md5) <privproto> : Priv protocole (des|aes : default des) P, --port=PORTport (Default 161) w, --warn=INTEGER | INT,INT,INT value check : warning level for cpu in percent (on one minute) value check : comma separated level for load or cpu for 1min, 5min, 15min c, --crit=INTEGER | INT,INT,INTlevel for cpu in percent (on one minute) value check : critical level for cpu in percent (on one minute) value check : comma separated level for load or cpu for 1min, 5min, 15min T, --type=stand|netsl|netsc|as400|cisco|bc|nokia|hp|lpcheck :: standard MIBII (works with Windows),handle multiple CPU.: linux load provided by Net SNMP (1,5 & 15 minutes values): cpu usage given by net-snmp (100-idle): as400 CPU usage: Cisco CPU usage: Cisco catalyst CPU usage: NetScreen CPU usage: Fortigate CPU usage: Bluecoat CPU usage: Nokia CPU usage: HP procurve switch CPU usage: Linkproof CPU usage: HP-UX load (1,5 & 15 minutes values) f, --perfparsecompatible output t, --timeout=INTEGERfor SNMP in seconds (Default: 5) V, --versionversion number } # For verbose outputverb { my $t=shift; print $t,"\n" if defined($o_verb) ; } check_options {::Long::Configure ("bundling");( 'v' => \$o_verb, 'verbose' => \$o_verb, 'h' => \$o_help, 'help' => \$o_help, 'H:s' => \$o_host, 'hostname:s' => \$o_host, 'p:i' => \$o_port, 'port:i' => \$o_port, 'C:s' => \$o_community, 'community:s' => \$o_community, 'l:s' => \$o_login, 'login:s' => \$o_login, 'x:s' => \$o_passwd, 'passwd:s' => \$o_passwd, 'X:s' => \$o_privpass, 'privpass:s' => \$o_privpass, 'L:s' => \$v3protocols, 'protocols:s' => \$v3protocols, 't:i' => \$o_timeout, 'timeout:i' => \$o_timeout, 'V' => \$o_version, 'version' => \$o_version, '2' => \$o_version2, 'v2c' => \$o_version2, 'c:s' => \$o_crit, 'critical:s' => \$o_crit, 'w:s' => \$o_warn, 'warn:s' => \$o_warn, 'f' => \$o_perf, 'perfparse' => \$o_perf, 'T:s' => \$o_check_type, 'type:s' => \$o_check_type ); # check the -T option$T_option_valid=0;(@valid_types) { if ($_ eq $o_check_type) {$T_option_valid=1} };( $T_option_valid == 0 ) {print "Invalid check type (-T)!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}} # Basic checks(defined($o_timeout) && (isnnum($o_timeout) || ($o_timeout < 2) || ($o_timeout > 60))) { print "Timeout must be >1 and <60 !\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}(!defined($o_timeout)) {$o_timeout=5;}(defined ($o_help) ) { help(); exit $ERRORS{"UNKNOWN"}};(defined($o_version)) { p_version(); exit $ERRORS{"UNKNOWN"}};( ! defined($o_host) ) # check host and filter { print_usage(); exit $ERRORS{"UNKNOWN"}} # check snmp information( !defined($o_community) && (!defined($o_login) || !defined($o_passwd)) ) { print "Put snmp login info!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}((defined($o_login) || defined($o_passwd)) && (defined($o_community) || defined($o_version2)) ) { print "Can't mix snmp v1,2c,3 protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}(defined ($v3protocols)) {(!defined($o_login)) { print "Put snmp V3 login info with protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}@v3proto=split(/,/,$v3protocols);((defined ($v3proto[0])) && ($v3proto[0] ne "")) {$o_authproto=$v3proto[0]; } # Auth protocol(defined ($v3proto[1])) {$o_privproto=$v3proto[1]; } # Priv protocol((defined ($v3proto[1])) && (!defined($o_privpass))) {"Put snmp V3 priv login info with priv protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}} } # Check warnings and critical(!defined($o_warn) || !defined($o_crit)) { print "put warning and critical info!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}} # Get rid of % sign $o_warn =~ s/\%//g; $o_crit =~ s/\%//g; # Check for multiple warning and crit in case of -L(($o_check_type eq "netsl") || ($o_check_type eq "cisco") || ($o_check_type eq "cata") || ($o_check_type eq "nsc") || ($o_check_type eq "hpux")) { @o_warnL=split(/,/ , $o_warn); @o_critL=split(/,/ , $o_crit);(($#o_warnL != 2) || ($#o_critL != 2)) { print "3 warnings and critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"}}(my $i=0;$i<3;$i++) {( isnnum($o_warnL[$i]) || isnnum($o_critL[$i])) { print "Numeric value for warning or critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"}}($o_warnL[$i] > $o_critL[$i]) { print "warning <= critical ! \n";print_usage(); exit $ERRORS{"UNKNOWN"}} } } else {(($o_warn =~ /,/) || ($o_crit =~ /,/)) { { print "Multiple warning/critical levels not available for this check\n";print_usage(); exit $ERRORS{"UNKNOWN"}} }( isnnum($o_warn) || isnnum($o_crit) ) { print "Numeric value for warning or critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"}}($o_warn > $o_crit) { print "warning <= critical ! \n";print_usage(); exit $ERRORS{"UNKNOWN"}} } } ########## MAIN ####### _options(); # Check gobal timeout if snmp screws up(defined($TIMEOUT)) {("Alarm at $TIMEOUT + 5");($TIMEOUT+5); } else {("no global timeout defined : $o_timeout + 10");($o_timeout+10); } $SIG{'ALRM'} = sub {"No answer from host\n";$ERRORS{"UNKNOWN"}; }; # Connect to host($session,$error);( defined($o_login) && defined($o_passwd)) { # SNMPv3 login("SNMPv3 login");(!defined ($o_privpass)) {("SNMPv3 AuthNoPriv login : $o_login, $o_authproto"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => '3', username => $o_login, authpassword => $o_passwd, authprotocol => $o_authproto, timeout => $o_timeout ); } else {("SNMPv3 AuthPriv login : $o_login, $o_authproto, $o_privproto"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => '3', username => $o_login, authpassword => $o_passwd, authprotocol => $o_authproto, privpassword => $o_privpass, privprotocol => $o_privproto, timeout => $o_timeout ); } else {(defined ($o_version2)) { # SNMPv2 Login("SNMP v2c login"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => 2, community => $o_community, port => $o_port, timeout => $o_timeout ); } else { # SNMPV1 login("SNMP v1 login"); ($session, $error) = Net::SNMP->session( hostname => $o_host, community => $o_community, port => $o_port, timeout => $o_timeout ); } }(!defined($session)) {("ERROR opening session: %s.\n", $error);$ERRORS{"UNKNOWN"}; } $exit_val=undef; ########### Linux load check ############## ($o_check_type eq "netsl") { ("Checking linux load"); # Get load table$resultat = (Net::SNMP->VERSION < 4) ? $session->get_table($linload_table) : $session->get_table(Baseoid => $linload_table); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; @load = undef;@iload = undef;@oid=undef;$exist=0;my $key ( keys %$resultat) {("OID : $key, Desc : $$resultat{$key}");( $key =~ /$linload_name/ ) { @oid=split (/\./,$key); $iload[0]= pop(@oid) if ($$resultat{$key} eq "Load-1"); $iload[1]= pop(@oid) if ($$resultat{$key} eq "Load-5"); $iload[2]= pop(@oid) if ($$resultat{$key} eq "Load-15"); $exist=1 } } ($exist == 0) {"Can't find snmp information on load : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } (my $i=0;$i<3;$i++) { $load[$i] = $$resultat{$linload_load . "." . $iload[$i]}}; "Load : $load[0] $load[1] $load[2] :"; $exit_val=$ERRORS{"OK"};(my $i=0;$i<3;$i++) {( $load[$i] > $o_critL[$i] ) {" $load[$i] > $o_critL[$i] : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; }( $load[$i] > $o_warnL[$i] ) { # output warn error only if no critical was found($exit_val eq $ERRORS{"OK"}) {" $load[$i] > $o_warnL[$i] : WARNING"; $exit_val=$ERRORS{"WARNING"}; } } }" OK" if ($exit_val eq $ERRORS{"OK"});(defined($o_perf)) {" | load_1_min=$load[0];$o_warnL[0];$o_critL[0] ";"load_5_min=$load[1];$o_warnL[1];$o_critL[1] ";"load_15_min=$load[2];$o_warnL[2];$o_critL[2]\n"; } else {"\n"; }$exit_val; } ############## Cisco CPU check ################ ($o_check_type eq "cisco") {@oidlists = ($cisco_cpu_5m, $cisco_cpu_1m, $cisco_cpu_5s);$resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@oidlists) : $session->get_request(-varbindlist => \@oidlists); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; (!defined ($$resultat{$cisco_cpu_5s})) {"No CPU information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } @load = undef; $load[0]=$$resultat{$cisco_cpu_5s}; $load[1]=$$resultat{$cisco_cpu_1m}; $load[2]=$$resultat{$cisco_cpu_5m}; "CPU : $load[0] $load[1] $load[2] :"; $exit_val=$ERRORS{"OK"};(my $i=0;$i<3;$i++) {( $load[$i] > $o_critL[$i] ) {" $load[$i] > $o_critL[$i] : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; }( $load[$i] > $o_warnL[$i] ) { # output warn error only if no critical was found($exit_val eq $ERRORS{"OK"}) {" $load[$i] > $o_warnL[$i] : WARNING"; $exit_val=$ERRORS{"WARNING"}; } } }" OK" if ($exit_val eq $ERRORS{"OK"});(defined($o_perf)) {" | load_5_sec=$load[0]%;$o_warnL[0];$o_critL[0] ";"load_1_min=$load[1]%;$o_warnL[1];$o_critL[1] ";"load_5_min=$load[2]%;$o_warnL[2];$o_critL[2]\n"; } else {"\n"; } $exit_val; } ############## Cisco Catalyst CPU check ################ ($o_check_type eq "cata") {@oidlists = ($ciscocata_cpu_5m, $ciscocata_cpu_1m, $ciscocata_cpu_5s);$resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@oidlists) : $session->get_request(-varbindlist => \@oidlists); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; (!defined ($$resultat{$ciscocata_cpu_5s})) {"No CPU information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } @load = undef; $load[0]=$$resultat{$ciscocata_cpu_5s}; $load[1]=$$resultat{$ciscocata_cpu_1m}; $load[2]=$$resultat{$ciscocata_cpu_5m}; "CPU : $load[0] $load[1] $load[2] :"; $exit_val=$ERRORS{"OK"};(my $i=0;$i<3;$i++) {( $load[$i] > $o_critL[$i] ) {" $load[$i] > $o_critL[$i] : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; }( $load[$i] > $o_warnL[$i] ) { # output warn error only if no critical was found($exit_val eq $ERRORS{"OK"}) {" $load[$i] > $o_warnL[$i] : WARNING"; $exit_val=$ERRORS{"WARNING"}; } } }" OK" if ($exit_val eq $ERRORS{"OK"});(defined($o_perf)) {" | load_5_sec=$load[0]%;$o_warnL[0];$o_critL[0] ";"load_1_min=$load[1]%;$o_warnL[1];$o_critL[1] ";"load_5_min=$load[2]%;$o_warnL[2];$o_critL[2]\n"; } else {"\n"; } $exit_val; } ############## Netscreen CPU check ################ ($o_check_type eq "nsc") {@oidlists = ($nsc_cpu_5m, $nsc_cpu_1m, $nsc_cpu_5s);$resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@oidlists) : $session->get_request(-varbindlist => \@oidlists);(!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; (!defined ($$resultat{$nsc_cpu_5s})) {"No CPU information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } @load = undef; $load[0]=$$resultat{$nsc_cpu_5s}; $load[1]=$$resultat{$nsc_cpu_1m}; $load[2]=$$resultat{$nsc_cpu_5m}; "CPU : $load[0] $load[1] $load[2] :"; $exit_val=$ERRORS{"OK"};(my $i=0;$i<3;$i++) {( $load[$i] > $o_critL[$i] ) {" $load[$i] > $o_critL[$i] : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; }( $load[$i] > $o_warnL[$i] ) { # output warn error only if no critical was found($exit_val eq $ERRORS{"OK"}) {" $load[$i] > $o_warnL[$i] : WARNING"; $exit_val=$ERRORS{"WARNING"}; } } }" OK" if ($exit_val eq $ERRORS{"OK"});(defined($o_perf)) {" | cpu_5_sec=$load[0]%;$o_warnL[0];$o_critL[0] ";"cpu_1_min=$load[1]%;$o_warnL[1];$o_critL[1] ";"cpu_5_min=$load[2]%;$o_warnL[2];$o_critL[2]\n"; } else {"\n"; } $exit_val; } ################## CPU for : AS/400 , Netsnmp, HP, Bluecoat, linkproof, fortigate ###########( $o_check_type =~ /netsc|as400|bc|nokia|^hp$|lp|fg/ ) { # Get load table@oidlist = $cpu_oid{$o_check_type};("Checking OID : @oidlist");$resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@oidlist) : $session->get_request(-varbindlist => \@oidlist);(!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; (!defined ($$resultat{$cpu_oid{$o_check_type}})) {"No CPU information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } $load=$$resultat{$cpu_oid{$o_check_type}};("OID returned $load"); # for AS400, divide by 100($o_check_type eq "as400") {$load /= 100; }; # for Net-snmp : oid returned idle time so load = 100-idle.($o_check_type eq "netsc") {$load = 100 - $load; }; ("CPU used %.1f%% (",$load); $exit_val=$ERRORS{"OK"};($load > $o_crit) {">$o_crit) : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; } else {($load > $o_warn) {">$o_warn) : WARNING"; $exit_val=$ERRORS{"WARNING"}; } }"<$o_warn) : OK" if ($exit_val eq $ERRORS{"OK"}); (defined($o_perf)) ?" | cpu_prct_used=$load%;$o_warn;$o_crit\n" : print "\n";$exit_val; } ##### Checking hpux load($o_check_type eq "hpux") { ("Checking hpux load"); @oidlists = ($hpux_load_1_min, $hpux_load_5_min, $hpux_load_15_min);$resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@oidlists) : $session->get_request(-varbindlist => \@oidlists); (!defined($resultat)) {("ERROR: Load table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; (!defined ($$resultat{$hpux_load_1_min})) {"No Load information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } @load = undef; $load[0]=$$resultat{$hpux_load_1_min}/100; $load[1]=$$resultat{$hpux_load_5_min}/100; $load[2]=$$resultat{$hpux_load_15_min}/100; "Load : $load[0] $load[1] $load[2] :"; $exit_val=$ERRORS{"OK"};(my $i=0;$i<3;$i++) {( $load[$i] > $o_critL[$i] ) {" $load[$i] > $o_critL[$i] : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; }( $load[$i] > $o_warnL[$i] ) { # output warn error only if no critical was found($exit_val eq $ERRORS{"OK"}) {" $load[$i] > $o_warnL[$i] : WARNING"; $exit_val=$ERRORS{"WARNING"}; } } }" OK" if ($exit_val eq $ERRORS{"OK"});(defined($o_perf)) {" | load_1_min=$load[0]%;$o_warnL[0];$o_critL[0] ";"load_5_min=$load[1]%;$o_warnL[1];$o_critL[1] ";"load_15_min=$load[2]%;$o_warnL[2];$o_critL[2]\n"; } else {"\n"; } $exit_val; } ########## Standard cpu usage check ############ # Get desctiption table$resultat = (Net::SNMP->VERSION < 4) ? $session->get_table($base_proc) : $session->get_table(Baseoid => $base_proc); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } $session->close; ($cpu_used,$ncpu)=(0,0);my $key ( keys %$resultat) {("OID : $key, Desc : $$resultat{$key}");( $key =~ /$proc_load/) { $cpu_used += $$resultat{$key}; $ncpu++; } } ($ncpu==0) {"Can't find CPU usage information : UNKNOWN\n";$ERRORS{"UNKNOWN"}; } $cpu_used /= $ncpu;"$ncpu CPU, ", $ncpu==1 ? "load" : "average load";(" %.1f%%",$cpu_used); $exit_val=$ERRORS{"OK"}; ($cpu_used > $o_crit) {" > $o_crit% : CRITICAL"; $exit_val=$ERRORS{"CRITICAL"}; } else {($cpu_used > $o_warn) {" > $o_warn% : WARNING"; $exit_val=$ERRORS{"WARNING"}; } }" < $o_warn% : OK" if ($exit_val eq $ERRORS{"OK"}); (defined($o_perf)) ?" | cpu_prct_used=$cpu_used%;$o_warn;$o_crit\n" : print "\n";$exit_val; /usr/lib/nagios/plugins/check_snmp_mem.pl #!/usr/bin/perl -w # nagios: -epn ############################## check_snmp_mem ############## # # Help : ./check_snmp_mem.pl -h # strict;Net::SNMP;Getopt::Long; # Nagios specific lib "/usr/lib/nagios/plugins";utils qw(%ERRORS $TIMEOUT); #my $TIMEOUT = 15; #my %ERRORS=('OK'=>0,'WARNING'=>1,'CRITICAL'=>2,'UNKNOWN'=>3,'DEPENDENT'=>4); # SNMP Datas # Net-snmp memory $nets_ram_free = "1.3.6.1.4.1.2021.4.6.0"; # Real memory free$nets_ram_total = "1.3.6.1.4.1.2021.4.5.0"; # Real memory total$nets_ram_cache = "1.3.6.1.4.1.2021.4.15.0"; # Real memory cached$nets_swap_free = "1.3.6.1.4.1.2021.4.4.0"; # swap memory free$nets_swap_total = "1.3.6.1.4.1.2021.4.3.0"; # Swap memory total@nets_oids = ($nets_ram_free,$nets_ram_total,$nets_swap_free,$nets_swap_total,$nets_ram_cache); # Cisco $cisco_mem_pool = "1.3.6.1.4.1.9.9.48.1.1.1"; # Cisco memory pool$cisco_index = "1.3.6.1.4.1.9.9.48.1.1.1.2"; # memory pool name and index$cisco_valid = "1.3.6.1.4.1.9.9.48.1.1.1.4"; # Valid memory if 1$cisco_used = "1.3.6.1.4.1.9.9.48.1.1.1.5"; # Used memory$cisco_free = "1.3.6.1.4.1.9.9.48.1.1.1.6"; # Free memory # .1 : type, .2 : name, .3 : alternate, .4 : valid, .5 : used, .6 : free, .7 : max free # HP Procurve $hp_mem_pool = "1.3.6.1.4.1.11.2.14.11.5.1.1.2.2.1.1"; # HP memory pool$hp_mem_index = "1.3.6.1.4.1.11.2.14.11.5.1.1.2.2.1.1.1"; # memory slot index$hp_mem_total = "1.3.6.1.4.1.11.2.14.11.5.1.1.2.2.1.1.5"; # Total Bytes$hp_mem_free = "1.3.6.1.4.1.11.2.14.11.5.1.1.2.2.1.1.6"; # Free Bytes$hp_mem_free_seg = "1.3.6.1.4.1.11.2.14.11.5.1.1.2.2.1.1.3"; # Free segments # AS/400 # Windows NT/2K/(XP?) # check_snmp_storage.pl -C <community> -H <hostIP> -m "^Virtual Memory$" -w <warn %> -c <crit %> # Globals $Version='1.1'; $o_host = undef; # hostname$o_community = undef; # community$o_port = 161; # port$o_help= undef; # wan't some help ?$o_verb= undef; # verbose mode$o_version= undef; # print version$o_netsnmp= 1; # Check with netsnmp (default)$o_cisco= undef; # Check cisco router mem$o_hp= undef; # Check hp procurve mem$o_warn= undef; # warning level option$o_warnR= undef; # warning level for Real memory$o_warnS= undef; # warning levels for swap$o_crit= undef; # Critical level option$o_critR= undef; # critical level for Real memory$o_critS= undef; # critical level for swap$o_perf= undef; # Performance data option$o_cache= undef; # Include cached memory as used memory$o_timeout= undef; # Timeout (Default 5)$o_version2= undef; # use snmp v2c # SNMPv3 specific$o_login= undef; # Login for snmpv3$o_passwd= undef; # Pass for snmpv3$v3protocols=undef; # V3 protocol list.$o_authproto='md5'; # Auth protocol$o_privproto='des'; # Priv protocol$o_privpass= undef; # priv password # functions p_version { print "check_snmp_mem version : $Version\n"; } print_usage {"Usage: $0 [-v] -H <host> -C <snmp_community> [-2] | (-l login -x passwd [-X pass -L <authp>,<privp>]) [-p <port>] -w <warn level> -c <crit level> [-I|-N|-E] [-f] [-m] [-t <timeout>] [-V]\n"; } isnnum { # Return true if arg is not a number$num = shift;( $num =~ /^(\d+\.?\d*)|(^\.\d+)$/ ) { return 0 ;}1; } round ($$) {"%.$_[1]f", $_[0]; } help {"\nSNMP Memory Monitor for Nagios version ",$Version,"\n";"(c)2004-2006 to my cat Ratoune - Author: Patrick Proy\n\n";_usage();<<EOT; v, --verboseextra debugging information (including interface list on the system) h, --helpthis help message H, --hostname=HOSTor IP address of host to check C, --community=COMMUNITY NAMEname for the host's SNMP agent (implies SNMP v1 or v2c with option) , --v2csnmp v2c l, --login=LOGIN ; -x, --passwd=PASSWDand auth password for snmpv3 authenticationno priv password exists, implies AuthNoPriv X, --privpass=PASSWDpassword for snmpv3 (AuthPriv protocol) L, --protocols=<authproto>,<privproto> <authproto> : Authentication protocol (md5|sha : default md5) <privproto> : Priv protocole (des|aes : default des) P, --port=PORTport (Default 161) w, --warn=INTEGER | INT,INTlevel for memory in percent (0 for no checks)(-N switch) : comma separated level for Real Memory and Swap I switch : warning level c, --crit=INTEGER | INT,INTlevel for memory in percent (0 for no checks)(-N switch) : comma separated level for Real Memory and Swap I switch : critical level N, --netsnmp (default)linux memory & swap provided by Net SNMP m, --memcachecached memory in used memory (only with Net-SNMP) I, --ciscocisco memory (sum of all memory pools) E, --hpHP proccurve memory f, --perfdatadata output t, --timeout=INTEGERfor SNMP in seconds (Default: 5) V, --versionversion number } # For verbose outputverb { my $t=shift; print $t,"\n" if defined($o_verb) ; } # Get the alarm signal (just in case snmp timout screws up) $SIG{'ALRM'} = sub {("ERROR: Alarm signal (Nagios time-out)\n");$ERRORS{"UNKNOWN"}; }; check_options {::Long::Configure ("bundling");( 'v' => \$o_verb, 'verbose' => \$o_verb, 'h' => \$o_help, 'help' => \$o_help, 'H:s' => \$o_host, 'hostname:s' => \$o_host, 'p:i' => \$o_port, 'port:i' => \$o_port, 'C:s' => \$o_community, 'community:s' => \$o_community, 'l:s' => \$o_login, 'login:s' => \$o_login, 'x:s' => \$o_passwd, 'passwd:s' => \$o_passwd, 'X:s' => \$o_privpass, 'privpass:s' => \$o_privpass, 'L:s' => \$v3protocols, 'protocols:s' => \$v3protocols, 't:i' => \$o_timeout, 'timeout:i' => \$o_timeout, 'V' => \$o_version, 'version' => \$o_version, 'I' => \$o_cisco, 'cisco' => \$o_cisco, 'N' => \$o_netsnmp, 'netsnmp' => \$o_netsnmp, 'E' => \$o_hp, 'hp' => \$o_hp, '2' => \$o_version2, 'v2c' => \$o_version2, 'c:s' => \$o_crit, 'critical:s' => \$o_crit, 'w:s' => \$o_warn, 'warn:s' => \$o_warn, 'm' => \$o_cache, 'memcache' => \$o_cache, 'f' => \$o_perf, 'perfdata' => \$o_perf );(defined ($o_help) ) { help(); exit $ERRORS{"UNKNOWN"}};(defined($o_version)) { p_version(); exit $ERRORS{"UNKNOWN"}};( ! defined($o_host) ) # check host and filter { print "No host defined!\n";print_usage(); exit $ERRORS{"UNKNOWN"}} # check snmp information( !defined($o_community) && (!defined($o_login) || !defined($o_passwd)) ) { print "Put snmp login info!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}((defined($o_login) || defined($o_passwd)) && (defined($o_community) || defined($o_version2)) ) { print "Can't mix snmp v1,2c,3 protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}(defined ($v3protocols)) {(!defined($o_login)) { print "Put snmp V3 login info with protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}@v3proto=split(/,/,$v3protocols);((defined ($v3proto[0])) && ($v3proto[0] ne "")) {$o_authproto=$v3proto[0]; } # Auth protocol(defined ($v3proto[1])) {$o_privproto=$v3proto[1]; } # Priv protocol((defined ($v3proto[1])) && (!defined($o_privpass))) {"Put snmp V3 priv login info with priv protocols!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}} }(defined($o_timeout) && (isnnum($o_timeout) || ($o_timeout < 2) || ($o_timeout > 60))) { print "Timeout must be >1 and <60 !\n"; print_usage(); exit $ERRORS{"UNKNOWN"}}(!defined($o_timeout)) {$o_timeout=5;} #Check Warning and crit are present( ! defined($o_warn) || ! defined($o_crit)) { print "Put warning and critical values!\n"; print_usage(); exit $ERRORS{"UNKNOWN"}} # Get rid of % sign $o_warn =~ s/\%//g; $o_crit =~ s/\%//g; # if -N or -E switch , undef $o_netsnmp(defined($o_cisco) || defined($o_hp) ) { $o_netsnmp=undef;( isnnum($o_warn) || isnnum($o_crit)) { print "Numeric value for warning or critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"} }( ($o_crit != 0) && ($o_warn > $o_crit) ) { print "warning <= critical ! \n";print_usage(); exit $ERRORS{"UNKNOWN"}} }(defined($o_netsnmp)) {@o_warnL=split(/,/ , $o_warn);@o_critL=split(/,/ , $o_crit);(($#o_warnL != 1) || ($#o_critL != 1)) { print "2 warnings and critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"}}(my $i=0;$i<2;$i++) {( isnnum($o_warnL[$i]) || isnnum($o_critL[$i])) { print "Numeric value for warning or critical !\n";print_usage(); exit $ERRORS{"UNKNOWN"} }(($o_critL[$i]!= 0) && ($o_warnL[$i] > $o_critL[$i])) { print "warning <= critical ! \n";print_usage(); exit $ERRORS{"UNKNOWN"}}( $o_critL[$i] > 100) { print "critical percent must be < 100 !\n";print_usage(); exit $ERRORS{"UNKNOWN"}} } $o_warnR=$o_warnL[0];$o_warnS=$o_warnL[1]; $o_critR=$o_critL[0];$o_critS=$o_critL[1]; } } ########## MAIN ####### _options(); # Check gobal timeout if snmp screws up(defined($TIMEOUT)) {("Alarm at $TIMEOUT");($TIMEOUT); } else {("no timeout defined : $o_timeout + 10");($o_timeout+10); } # Connect to host($session,$error);( defined($o_login) && defined($o_passwd)) { # SNMPv3 login(!defined ($o_privpass)) {("SNMPv3 AuthNoPriv login : $o_login, $o_authproto"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => '3', username => $o_login, authpassword => $o_passwd, authprotocol => $o_authproto, timeout => $o_timeout ); } else {("SNMPv3 AuthPriv login : $o_login, $o_authproto, $o_privproto"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => '3', username => $o_login, authpassword => $o_passwd, authprotocol => $o_authproto, privpassword => $o_privpass, privprotocol => $o_privproto, timeout => $o_timeout ); } } else {(defined ($o_version2)) { # SNMPv2 Login("SNMP v2c login"); ($session, $error) = Net::SNMP->session( hostname => $o_host, version => 2, port => $o_port, timeout => $o_timeout ); } else { # SNMPV1 login("SNMP v1 login"); ($session, $error) = Net::SNMP->session( hostname => $o_host, community => $o_community, port => $o_port, timeout => $o_timeout ); } }(!defined($session)) {("ERROR opening session: %s.\n", $error);$ERRORS{"UNKNOWN"}; } # Global variable$resultat=undef; ########### Cisco memory check ############(defined ($o_cisco)) { # Get Cisco memory table $resultat = (Net::SNMP->VERSION < 4) ? $session->get_table($cisco_mem_pool) :$session->get_table(Baseoid => $cisco_mem_pool); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; }(@oid,@index)=(undef,undef);$nindex=0;my $key ( keys %$resultat) {("OID : $key, Desc : $$resultat{$key}");( $key =~ /$cisco_index/ ) { @oid=split (/\./,$key); $index[$nindex++] = pop(@oid); } } # Check if at least 1 memory pool exists($nindex == 0) {("ERROR: No memory pools found"); $session->close;$ERRORS{"UNKNOWN"}; } # Test every memory pool($c_output,$prct_free)=(undef,undef);($warn_s,$crit_s)=(0,0);($used,$free)=(0,0);(@index) { $c_output .="," if defined ($c_output);( $$resultat{$cisco_valid . "." . $_} == 1 ) { $used += $$resultat{$cisco_used . "." . $_}; $free += $$resultat{$cisco_free . "." . $_}; $prct_free=round($$resultat{$cisco_used . "." . $_}*100/($$resultat{$cisco_free . "." . $_}+$$resultat{$cisco_used . "." . $_}) ,0); $c_output .= $$resultat{$cisco_index . "." . $_} . ":" . $prct_free . "%";(($o_crit!=0)&&($o_crit <= $prct_free)) { $crit_s =1; } elsif (($o_warn!=0)&&($o_warn <= $prct_free)) { $warn_s=1; } } else { $c_output .= $$resultat{$cisco_index . "." . $_} . ": INVALID"; $crit_s =1; } }$total=$used+$free; $prct_free=round($used*100/($total),0);("Total used : $used, free: $free, output : $c_output");$c_status="OK"; $c_output .=" : " . $prct_free ."% : ";($crit_s == 1 ) { $c_output .= " > " . $o_crit ; $c_status="CRITICAL"; } else {($warn_s == 1 ) { $c_output.=" > " . $o_warn; $c_status="WARNING"; } } $c_output .= " ; ".$c_status;(defined ($o_perf)) { $c_output .= " | ram_used=" . $used.";"; $c_output .= ($o_warn ==0)? ";" : round($o_warn * $total/100,0).";"; $c_output .= ($o_crit ==0)? ";" : round($o_crit * $total/100,0).";"; $c_output .= "0;" . $total ; } $session->close;"$c_output \n";$ERRORS{$c_status}; } ########### HP Procurve memory check ############(defined ($o_hp)) { # Get hp memory table $resultat = (Net::SNMP->VERSION < 4) ? $session->get_table($hp_mem_pool) :$session->get_table(Baseoid => $hp_mem_pool); (!defined($resultat)) {("ERROR: Description table : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; }(@oid,@index)=(undef,undef);$nindex=0;my $key ( keys %$resultat) {("OID : $key, Desc : $$resultat{$key}");( $key =~ /$hp_mem_index/ ) { @oid=split (/\./,$key); $index[$nindex++] = pop(@oid); } } # Check if at least 1 memory slots exists($nindex == 0) {("ERROR: No memory slots found"); $session->close;$ERRORS{"UNKNOWN"}; } # Consolidate the datas($total,$free)=(0,0);($c_output,$prct_free)=(undef,undef);(@index) { $c_output .="," if defined ($c_output); $total += $$resultat{$hp_mem_total . "." . $_}; $free += $$resultat{$hp_mem_free . "." . $_}; $c_output .= "Slot " . $$resultat{$hp_mem_index . "." . $_} . ":" .round( - ($$resultat{$hp_mem_free . "." . $_} *100 / $$resultat{$hp_mem_total . "." . $_}) ,0) . "%"; }$used = $total - $free; $prct_free=round($used*100/($total),0);("Used : $used, Free: $free, Output : $c_output");$c_status="OK"; $c_output .=" : " . $prct_free ."% : ";(($o_crit!=0)&&($o_crit <= $prct_free)) { $c_output .= " > " . $o_crit ; $c_status="CRITICAL"; } else {(($o_warn!=0)&&($o_warn <= $prct_free)) { $c_output.=" > " . $o_warn; $c_status="WARNING"; } } $c_output .= " ; ".$c_status;(defined ($o_perf)) { $c_output .= " | ram_used=" . $used.";"; $c_output .= ($o_warn ==0)? ";" : round($o_warn * $total/100,0).";"; $c_output .= ($o_crit ==0)? ";" : round($o_crit * $total/100,0).";"; $c_output .= "0;" . $total ; } $session->close;"$c_output \n";$ERRORS{$c_status}; } ########### Net snmp memory check ############(defined ($o_netsnmp)) { # Get NetSNMP memory values $resultat = (Net::SNMP->VERSION < 4) ? $session->get_request(@nets_oids) :$session->get_request(-varbindlist => \@nets_oids);(!defined($resultat)) {("ERROR: netsnmp : %s.\n", $session->error); $session->close;$ERRORS{"UNKNOWN"}; } ($realused,$swapused)=(undef,undef); $realused= defined($o_cache) ? ($$resultat{$nets_ram_total}-$$resultat{$nets_ram_free})/$$resultat{$nets_ram_total} : ($$resultat{$nets_ram_total}-($$resultat{$nets_ram_free}+$$resultat{$nets_ram_cache}))/$$resultat{$nets_ram_total}; ($$resultat{$nets_ram_total} == 0) { $realused = 0; } $swapused= ($$resultat{$nets_swap_total} == 0) ? 0 : ($$resultat{$nets_swap_total}-$$resultat{$nets_swap_free})/$$resultat{$nets_swap_total}; $realused=round($realused*100,0); $swapused=round($swapused*100,0);($o_cache) ?("Ram : $$resultat{$nets_ram_free} / $$resultat{$nets_ram_total} : $realused") :("Ram : $$resultat{$nets_ram_free} ($$resultat{$nets_ram_cache} cached) / $$resultat{$nets_ram_total} : $realused");("Swap : $$resultat{$nets_swap_free} / $$resultat{$nets_swap_total} : $swapused"); $n_status="OK";$n_output="Ram : " . $realused . "%, Swap : " . $swapused . "% :";((($o_critR!=0)&&($o_critR <= $realused)) || (($o_critS!=0)&&($o_critS <= $swapused))) { $n_output .= " > " . $o_critR . ", " . $o_critS; $n_status="CRITICAL"; } else {((($o_warnR!=0)&&($o_warnR <= $realused)) || (($o_warnS!=0)&&($o_warnS <= $swapused))) { $n_output.=" > " . $o_warnR . ", " . $o_warnS; $n_status="WARNING"; } } $n_output .= " ; ".$n_status;(defined ($o_perf)) {(defined ($o_cache)) { $n_output .= " | ram_used=" . ($$resultat{$nets_ram_total}-$$resultat{$nets_ram_free}).";"; }{ $n_output .= " | ram_used=" . ($$resultat{$nets_ram_total}-$$resultat{$nets_ram_free}-$$resultat{$nets_ram_cache}).";"; } $n_output .= ($o_warnR ==0)? ";" : round($o_warnR * $$resultat{$nets_ram_total}/100,0).";"; $n_output .= ($o_critR ==0)? ";" : round($o_critR * $$resultat{$nets_ram_total}/100,0).";"; $n_output .= "0;" . $$resultat{$nets_ram_total}. " "; $n_output .= "swap_used=" . ($$resultat{$nets_swap_total}-$$resultat{$nets_swap_free}).";"; $n_output .= ($o_warnS ==0)? ";" : round($o_warnS * $$resultat{$nets_swap_total}/100,0).";"; $n_output .= ($o_critS ==0)? ";" : round($o_critS * $$resultat{$nets_swap_total}/100,0).";"; $n_output .= "0;" . $$resultat{$nets_swap_total}; } $session->close;"$n_output \n";$ERRORS{$n_status}; } Приложение К Конфигурация протокола SNMP на удаленных хостах # sec.name source community #com2sec paranoid default publicsec readonly default public #com2sec readwrite default private #### # Second, map the security names into group names: # sec.model sec.nameMyROSystem v1 paranoidMyROSystem v2c paranoidMyROSystem usm paranoidMyROGroup v1 readonlyMyROGroup v2c readonlyMyROGroup usm readonlyMyRWGroup v1 readwriteMyRWGroup v2c readwriteMyRWGroup usm readwrite #### # Third, create a view for us to let the groups have rights to: # incl/excl subtree maskall included .1 80system included .iso.org.dod.internet.mgmt.mib-2.system #### # Finally, grant the 2 groups access to the 1 view with different # write permissions: # context sec.model sec.level match read write notifMyROSystem "" any noauth exact system none noneMyROGroup "" any noauth exact all none noneMyRWGroup "" any noauth exact all all none Приложение Л Конфигурация агента ядра сетевого мониторинга на удаленных хостах /etc/nagios/nrpe.cfg # PID FILE # The name of the file in which the NRPE daemon should write it's process ID # number. The file is only written if the NRPE daemon is started by the root # user and is running in standalone mode. _file=/var/run/nrpe.pid # PORT NUMBER # Port number we should wait for connections on. # NOTE: This must be a non-priviledged port (i.e. > 1024). # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _port=5666 # SERVER ADDRESS # Address that nrpe should bind to in case there are more than one interface # and you do not want nrpe to bind on all interfaces. # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _address=192.168.10.158 # NRPE USER # This determines the effective user that the NRPE daemon should run as. # You can either supply a username or a UID. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _user=nagios # NRPE GROUP # This determines the effective group that the NRPE daemon should run as. # You can either supply a group name or a GID. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd _group=nagios # ALLOWED HOST ADDRESSES # This is an optional comma-delimited list of IP address or hostnames # that are allowed to talk to the NRPE daemon. # # Note: The daemon only does rudimentary checking of the client's IP # address. I would highly recommend adding entries in your /etc/hosts.allow # file to allow only the specified host to connect to the port # you are running this daemon on. # # NOTE: This option is ignored if NRPE is running under either inetd or xinetd_hosts=127.0.0.1,192.168.10.2 # COMMAND ARGUMENT PROCESSING # This option determines whether or not the NRPE daemon will allow clients # to specify arguments to commands that are executed. This option only works # if the daemon was configured with the --enable-command-args configure script # option. # # *** ENABLING THIS OPTION IS A SECURITY RISK! *** # Read the SECURITY file for information on some of the security implications # of enabling this variable. # # Values: 0=do not allow arguments, 1=allow command arguments _blame_nrpe=0 # COMMAND PREFIX # This option allows you to prefix all commands with a user-defined string. # A space is automatically added between the specified prefix string and the # command line from the command definition. # # *** THIS EXAMPLE MAY POSE A POTENTIAL SECURITY RISK, SO USE WITH CAUTION! *** # Usage scenario: # Execute restricted commmands using sudo. For this to work, you need to add # the nagios user to your /etc/sudoers. An example entry for alllowing # execution of the plugins from might be: # # nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/ # # This lets the nagios user run all commands in that directory (and only them) # without asking for a password. If you do this, make sure you don't give # random users write access to that directory or its contents! # command_prefix=/usr/bin/sudo # DEBUGGING OPTION # This option determines whether or not debugging messages are logged to the # syslog facility. # Values: 0=debugging off, 1=debugging on =0 # COMMAND TIMEOUT # This specifies the maximum number of seconds that the NRPE daemon will # allow plugins to finish executing before killing them off. _timeout=60 # WEEK RANDOM SEED OPTION # This directive allows you to use SSL even if your system does not have # a /dev/random or /dev/urandom (on purpose or because the necessary patches # were not applied). The random number generator will be seeded from a file # which is either a file pointed to by the environment valiable $RANDFILE # or $HOME/.rnd. If neither exists, the pseudo random number generator will # be initialized and a warning will be issued. # Values: 0=only seed from /dev/[u]random, 1=also seed from weak randomness #allow_weak_random_seed=1 # INCLUDE CONFIG FILE # This directive allows you to include definitions from an external config file. #include=<somefile.cfg> # INCLUDE CONFIG DIRECTORY # This directive allows you to include definitions from config files (with a # .cfg extension) in one or more directories (with recursion). #include_dir=<somedirectory> #include_dir=<someotherdirectory> # COMMAND DEFINITIONS # Command definitions that this daemon will run. Definitions # are in the following format: # # command[<command_name>]=<command_line> # # When the daemon receives a request to return the results of <command_name> # it will execute the command specified by the <command_line> argument. # # Unlike Nagios, the command line cannot contain macros - it must be # typed exactly as it should be executed. # # Note: Any plugins that are used in the command lines must reside # on the machine that this daemon is running on! The examples below # assume that you have plugins installed in a /usr/local/nagios/libexec # directory. Also note that you will have to modify the definitions below # to match the argument format the plugins expect. Remember, these are # examples only! # The following examples use hardcoded command arguments... [check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10[check_load]=/usr/lib/nagios/plugins/check_load -w 15,15,15 -c 30,25,20[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 17000 -c 18000 -s Z[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 17000 -c 20000 # The following examples allow user-supplied arguments and can # only be used if the NRPE daemon was compiled with support for # command arguments *AND* the dont_blame_nrpe directive in this # config file is set to '1'... #command[check_users]=/usr/lib/nagios/plugins/check_users -w $ARG1$ -c $ARG2$ #command[check_load]=/usr/lib/nagios/plugins/check_load -w $ARG1$ -c $ARG2$ #command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ #command[check_procs]=/usr/lib/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$ # # local configuration: # if you'd prefer, you can instead place directives here=/etc/nagios/nrpe_local.cfg Приложение М Пример конфигурационного файла MRTG /etc/mrtg/shaper/mrtg.cfg # Created by # /usr/bin/cfgmaker public@192.168.10.1 ### Global Config Options # for UNIX # WorkDir: /home/http/mrtg # for Debian: /var/www/mrtg/shaper # or for NT # WorkDir: c:\mrtgdata ### Global Defaults # to get bits instead of bytes and graphs growing to the right[_]: growright, bits : no ###################################################################### # System: shaper # Description: Linux shaper 2.6.31-bfs311 #1 SMP Fri Dec 4 10:23:03 YEKT 2009 x86_64 # Contact: Root <root@localhost> (configure /etc/snmp/snmpd.local.conf) # Location: Unknown (configure /etc/snmp/snmpd.local.conf) ###################################################################### ### Interface 1 >> Descr: 'lo' | Name: 'lo' | Ip: '127.0.0.1' | Eth: '' ### ### The following interface is commented out because: ### * it is a Software Loopback interface # # Target[192.168.10.1_1]: 1:public@192.168.10.1: # SetEnv[192.168.10.1_1]: MRTG_INT_IP="127.0.0.1" MRTG_INT_DESCR="lo" # MaxBytes[192.168.10.1_1]: 1250000 # Title[192.168.10.1_1]: Traffic Analysis for 1 -- shaper # PageTop[192.168.10.1_1]: <h1>Traffic Analysis for 1 -- shaper</h1> # <div id="sysdetails"> # <table> # <tr> # <td>System:</td> # <td>shaper in Unknown (configure /etc/snmp/snmpd.local.conf)</td> # </tr> # <tr> # <td>Maintainer:</td> # <td>Root &lt;root@localhost&gt; (configure /etc/snmp/snmpd.local.conf)</td> # </tr> # <tr> # <td>Description:</td> # <td>lo </td> # </tr> # <tr> # <td>ifType:</td> # <td>softwareLoopback (24)</td> # </tr> # <tr> # <td>ifName:</td> # <td>lo</td> # </tr> # <tr> # <td>Max Speed:</td> # <td>1250.0 kBytes/s</td> # </tr> # <tr> # <td>Ip:</td> # <td>127.0.0.1 (localhost)</td> # </tr> # </table> # </div> ### Interface 2 >> Descr: 'eth2' | Name: 'eth2' | Ip: '' | Eth: '30-78-30-30-32-33-35-34-32-35-34-33-30-66' ### ### The following interface is commented out because: ### * it is administratively DOWN # # Target[192.168.10.1_2]: 2:public@192.168.10.1: # SetEnv[192.168.10.1_2]: MRTG_INT_IP="" MRTG_INT_DESCR="eth2" # MaxBytes[192.168.10.1_2]: 1250000 # Title[192.168.10.1_2]: Traffic Analysis for 2 -- shaper # PageTop[192.168.10.1_2]: <h1>Traffic Analysis for 2 -- shaper</h1> # <div id="sysdetails"> # <table> # <tr> # <td>System:</td> # <td>shaper in Unknown (configure /etc/snmp/snmpd.local.conf)</td> # </tr> # <tr> # <td>Maintainer:</td> # <td>Root &lt;root@localhost&gt; (configure /etc/snmp/snmpd.local.conf)</td> # </tr> # <tr> # <td>Description:</td> # <td>eth2 </td> # </tr> # <tr> # <td>ifType:</td> # <td>ethernetCsmacd (6)</td> # </tr> # <tr> # <td>ifName:</td> # <td>eth2</td> # </tr> # <tr> # <td>Max Speed:</td> # <td>1250.0 kBytes/s</td> # </tr> # </table> # </div> ### Interface 3 >> Descr: 'eth0' | Name: 'eth0' | Ip: '192.168.10.1' | Eth: '30-78-30-30-31-62-32-31-32-65-37-62-65-36' ### [192.168.10.1_3]: 3:public@192.168.10.1:[192.168.10.1_3]: MRTG_INT_IP="192.168.10.1" MRTG_INT_DESCR="eth0"[192.168.10.1_3]: 125000000[192.168.10.1_3]: Traffic Analysis for 3 -- shaper[192.168.10.1_3]: <h1>Traffic Analysis for 3 -- shaper</h1> <div id="sysdetails"> <table> <tr> <td>System:</td> <td>shaper in Unknown (configure /etc/snmp/snmpd.local.conf)</td> </tr> <tr> <td>Maintainer:</td> <td>Root &lt;root@localhost&gt; (configure /etc/snmp/snmpd.local.conf)</td> </tr> <tr> <td>Description:</td> <td>eth0 </td> </tr> <tr> <td>ifType:</td> <td>ethernetCsmacd (6)</td> </tr> <tr> <td>ifName:</td> <td>eth0</td> </tr> <tr> <td>Max Speed:</td> <td>1250.0 kBytes/s</td> </tr> <tr> <td>Ip:</td> <td>192.168.10.1 (shaper)</td> </tr> </table> </div> ### Interface 4 >> Descr: 'eth1' | Name: 'eth1' | Ip: '91.192.168.250' | Eth: '30-78-30-30-31-62-32-31-32-65-37-62-63-38' ### [192.168.10.1_4]: 4:public@192.168.10.1:[192.168.10.1_4]: MRTG_INT_IP="91.192.168.250" MRTG_INT_DESCR="eth1"[192.168.10.1_4]: 125000000[192.168.10.1_4]: Traffic Analysis for 4 -- shaper[192.168.10.1_4]: <h1>Traffic Analysis for 4 -- shaper</h1> <div id="sysdetails"> <table> <tr> <td>System:</td> <td>shaper in Unknown (configure /etc/snmp/snmpd.local.conf)</td> </tr> <tr> <td>Maintainer:</td> <td>Root &lt;root@localhost&gt; (configure /etc/snmp/snmpd.local.conf)</td> </tr> <tr> <td>Description:</td> <td>eth1 </td> </tr> <tr> <td>ifType:</td> <td>ethernetCsmacd (6)</td> </tr> <tr> <td>ifName:</td> <td>eth1</td> </tr> <tr> <td>Max Speed:</td> <td>1250.0 kBytes/s</td> </tr> <tr> <td>Ip:</td> <td>91.192.168.250 (shaper.vpcit.ru)</td> </tr> </table> </div> Приложение Н Рис. Н.1 - Пример представления графиков загрузки интерфейсов посредством MRTG Приложение О Параметры crontab /etc/cron.d/mrtg -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/bgp/mrtg.cfg ]; then env LANG=C /usr/bin/mrtg /etc/mrtg/bgp/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi 0-55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/AT-9924/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/AT-9924/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/DES-3627G/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/DES-3627G/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/Rapier_24i/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/Rapier_24i/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/host_mail/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/host_mail/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/monitoring/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/monitoring/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/urrab_39a/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/urrab_39a/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/len_58a/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/len_58a/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/krivous_36b/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/krivous_36b/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/shaper/mrtg.cfg ]; then env/usr/bin/mrtg /etc/mrtg/shaper/mrtg.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi -55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/for/for.cfg ]; then env/usr/bin/mrtg /etc/mrtg/for/for.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi Приложение П Таблица П.1 - Подробное сравнение технических особенностей различных сборщиков системных журналов Параметр/Служба syslogd syslog-ng OSE syslog-ng PE Получение журналов от UNIX domain socket (stream & dgram) Да Да Да UDP Да Да Да UDP использующий IETF-syslog стандартный протокол - Да Да TCP - Да Да TCP использующий IETF-syslog стандартный протокол - Да Да UDP6 Зависит от ОС Да Да TCP6 - Да Да TLS-шифрованные каналы - Да Да TLS использующий IETF-syslog стандартный протокол - Да Да Именованные каналы - Да Да Файл - Да Да Стандартный вывод (stdout) приложения - Да Да Устройство протоколирования ядра на Linux, Solaris, BSD klogd Да Да Файл со звездочками в имени или пути - - Да IBM System i журанл аудита (QAUDJRN) & журнал оператора терминала (QSYSOPR) (через отдельное приложение агента) - - Да Windows EventLog /файлы журналов (через отделное агентское приложение) - - Да Отправка системных журналов к UNIX domain sockets (stream & dgram) - Да Да UDP Да Да Да UDP использующий IETF-syslog стандартный протокол - Да Да TCP - Да Да TCP использующий IETF-syslog стандартный протокол - Да Да UDP6 depends on the OS Да Да TCP6 - Да Да Именованый канал Да Да Да Файл Да Да Да Шифрованый, сжатый, с метками времени и проиндексированный двоичный файл - - Да SQL база данных (MySQL, Microsoft SQL (MSSQL), Oracle, PostgreSQL, SQLite) - Да Да Стандартный ввод любой указанной пользователем программы - Да Да Пользовательский tty Да Да Да Поддержка встроенного TLS шифрования при использовании TCP, TCP6, или IETF-syslog протокола - Да Да Производительность Принятие 75000 сообщений в секунда (измерено с 150-байтовыми сообщениями на серверной платформе низшего уровня) - Да Да Форматы сообщений Поддержка сырых, не формата syslog сообщений - Да Да Поддержка RFC3164 формата сообщений (BSD) Да Да Да Поддержка IETF-syslog формата сообщений - Да Да Поддержка расширенных RFC3339 (ISO 8601) временных меток - Да Да Поддержка некоторых нестандартных формтаов временных меток (Cisco PIX, LinkSys, и др.) - Да Да Поддержка микросекундного определения времени (точность настраивается пользователем) - Да Да Поддержка информации о временных зонах - Да Да Поддержка определения неверных имен хостов (позволяет принимать сообщения от приложений, которые отправляют syslog сообщения в неправильном формате) - Да Да Поддержка сцепленного имени хоста, котороая позволяет определить путь прохождения сообщения через релеи. - Да Да Обработка сообщений/фильтрация Поддержка разрешения имен через DNS Да Да Да Поддержка разрешения имен через файл (локальная карта IP->host) - Да Да Кэширование DNS запросов для предотвращения перегрузки DNS серверов и повышения производительности - Да Да Поддержка нормализации имен хостов (принудительное приведение имен в нижний регистр) - Да Да Сообщения могут назначаться нескольким независимым адресатам (файл, sql, несколько удаленных серверов, и др.) одновременно Да Да Да Одна фильтрующая операция может направлять сообщения по нескольким адресатам - Да Да Сегментирования текстовых сообщений в пары имя=значение с использованием парсеров. - Да Да Использования результатов парсинга как макросов - Да Да Определение значений по умолчанию для макросов - Да Да Замена выбранных частей сообщения - Да Да Установка значения пар имя=значение - Да Да Поддержка преобразования временных меток между временными зонами - Да Да Поддержка контролируемых потоков для путей журналов событий: принятие сообщений со входа приостанавливается, пока адресат заполнен, пока адресам не сможет принимать сообщения. - Да Да Поддержка сложных фильтров с использованием булевой алгебры с операторами И/ИЛИ/НЕ и их выражений - Да Да Поддержка многократно используемых фильтров: возможно единственное определение фильтра и его последующее использование в нескольких путях журналов - Да Да - Да Да Поддержка комбинированных фильтров: фильтры могут быть объединены с использованием булевых операторов - Да Да Поддержка фильтрации по содержимому с использованием регулярных выражений POSIX - Да Да Фильтрация по syslog facility и priority Да Да Да Фильтрация по имени хоста - Да Да Фильтрация по имени приложения - Да Да Фильтрация по содержимому сообщения - Да Да Фильтрация по IP адресу источника - Да Да Фильтрация по любым SD метаданным при использовании IETF-syslog протокола - Да Да Поддержка отклонения сообщений на основе фильтра Да Да Да Поддержка ограничения потока сообщений, отправляемого получателю - Да Да Поддержка сортировка сообщений по разным адресатам, все неотфильтрованный сообщения собираются в резервном адресате - Да Да Сбор статистика по адресатам, источникам и глобальным параметрам - Да Да Стастистика может быть запрошена в любой момент посредствам сокетов unix-domain - Да Да Возможности Автоматическое создание директорий, основанное на содержимом сообщений. - Да Да Автоматическое создание таблиц, колонок и индексов в SQL базах данных, основываясь на содержимом сообщений - Да Да Изменяемый формат сообщений с использованием шаблонов и макросов - Да Да Сегментирование и изменение содержимого сообщений - Да Да Поддержка автоматической ротации журналов добавлением временных меток к лог-файлу и именам таблиц в базе данных - Да Да Перезапуск программ-адресатов, если они завершают работу - Да Да Перезапуск программ-источников, если они завершают работу - Да Да Поддержка буферизации сообщений на жестком диске для предотвращения потери сообщений в случае недоступности адресата - - Да Содержимое дискового буфера остается даже между перезапусками syslog-ng - - Да Поддержка аутентификации, X.509 при использовании TLS - Да Да Поддержка сетевого сжатия при использовании TLS - Да Да Подержка файлов журналов размером более 2GB Да Да Да Поддержка IP спуфинга при перенаправлении сообщений с использованием UDP - Да Да Многопоточность при исопльзовании SQL адресатов - Да Да Поддержка IPv6 Зависит от ОС Да Да Поддержка и получение сообщений от мультивещательных адресов - Да Да Временные метки могут включать доли секунды - Да Да Может работать в режиме клиента, релея или сервера Да Да Да Другие возможности Переносимость: поддерживает широкий спектр UNIX платформ (Linux, BSDs, Solaris, HP-UX, AIX) Да Да Да Живое и готовое помочь комьюнити проекта посредством списка рассылки - Да Да Профессионально составленная документация Да Да Да Коммерческая поддержка Только от некоторых поставщиков ОС Да Да Проверено в боевых условиях (более 10 лет существования и использования) Да Да Да Приложение Р Фильтры и правила модуля сбора системных журналов /etc/syslog-ng/syslog-ng.conf # Configuration file for syslog-ng under Debian # # attempts at reproducing default syslog behavior # the standard syslog levels are (in descending order of priority): # emerg alert crit err warning notice info debug # the aliases "error", "panic", and "warn" are deprecated # the "none" priority found in the original syslogd configuration is # only used in internal messages created by syslogd ###### # options { # disable the chained hostname format in logs # (default is enabled)_hostnames(0); # the time to wait before a died connection is re-established # (default is 60)_reopen(10); # the time to wait before an idle destination file is closed # (default is 60)_reap(360); # the number of lines buffered before written to file # you might want to increase this if your disk isn't catching with # all the log messages you get or if you want less disk activity # (say on a laptop) # (default is 0) #sync(0); # the number of lines fitting in the output queue_fifo_size(2048); # enable or disable directory creation for destination files_dirs(yes); # default owner, group, and permissions for log files # (defaults are 0, 0, 0600) #owner(root);(adm);(0640); # default owner, group, and permissions for created directories # (defaults are 0, 0, 0700) #dir_owner(root); #dir_group(root);_perm(0755); # enable or disable DNS usage # syslog-ng blocks on DNS queries, so enabling DNS may lead to # a Denial of Service attack # (default is yes)_dns(persist_only); _cache_hosts(/etc/hosts); # maximum length of message in bytes # this is only limited by the program listening on the /dev/log Unix # socket, glibc can handle arbitrary length log messages, but -- for # example -- syslogd accepts only 1024 bytes # (default is 2048) #log_msg_size(2048); #Disable statistic log messages._freq(0); # Some program send log messages through a private implementation. # and sometimes that implementation is bad. If this happen syslog-ng # may recognise the program name as hostname. Whit this option # we tell the syslog-ng that if a hostname match this regexp than that # is not a real hostname._hostname("^gconfd$"); #_sleep(20); }; ###### # sources # all known message sourcess_all { # message generated by Syslog-NG(); # standard Linux log source (this is the default place for the syslog() # function to send logs to)stream("/dev/log"); # messages from the kernel("/proc/kmsg" log_prefix("kernel: ")); # use the following line if you want to receive remote UDP logging messages # (this is equivalent to the "-r" syslogd flag)(); }; ###### # destinations # some standard log filesdf_auth { file("/var/log/$HOST/auth.log"); };df_syslog { file("/var/log/$HOST/syslog"); };df_cron { file("/var/log/$HOST/cron.log"); };df_daemon { file("/var/log/$HOST/daemon.log"); };df_kern { file("/var/log/$HOST/kern.log"); };df_lpr { file("/var/log/$HOST/lpr.log"); };df_mail { file("/var/log/$HOST/mail.log"); };df_user { file("/var/log/$HOST/user.log"); };df_uucp { file("/var/log/$HOST/uucp.log"); };df_radius { file("/var/log/$HOST/radius.log"); }; # these files are meant for the mail system log files # and provide re-usable destinations for {mail,cron,...}.info, # {mail,cron,...}.notice, etc.df_facility_dot_info { file("/var/log/$HOST/$FACILITY.info"); };df_facility_dot_notice { file("/var/log/$HOST/$FACILITY.notice"); };df_facility_dot_warn { file("/var/log/$HOST/$FACILITY.warn"); };df_facility_dot_err { file("/var/log/$HOST/$FACILITY.err"); };df_facility_dot_crit { file("/var/log/$HOST/$FACILITY.crit"); }; # these files are meant for the news system, and are kept separated # because they should be owned by "news" instead of "root"df_news_dot_notice { file("/var/log/$HOST/news/news.notice" owner("news")); };df_news_dot_err { file("/var/log/$HOST/news/news.err" owner("news")); };df_news_dot_crit { file("/var/log/$HOST/news/news.crit" owner("news")); }; # some more classical and useful files found in standard syslog configurationsdf_debug { file("/var/log/$HOST/debug"); };df_messages { file("/var/log/$HOST/messages"); }; # pipes # a console to view log messages under Xdp_xconsole { pipe("/dev/xconsole"); }; # consoles # this will send messages to everyone logged indu_all { usertty("*"); }; ###### # filters # all messages from the auth and authpriv facilitiesf_auth { facility(auth, authpriv); }; # all messages except from the auth and authpriv facilitiesf_syslog { not facility(auth, authpriv, mail, local7, local1); }; # respectively: messages from the cron, daemon, kern, lpr, mail, news, user, # and uucp facilitiesf_cron { facility(cron); };f_daemon { facility(daemon); };f_kern { facility(kern); };f_lpr { facility(lpr); };f_mail { facility(mail); };f_news { facility(news); };f_user { facility(user); };f_uucp { facility(uucp); }; # some filters to select messages of priority greater or equal to info, warn, # and err # (equivalents of syslogd's *.info, *.warn, and *.err)f_at_least_info { level(info..emerg); };f_at_least_notice { level(notice..emerg); };f_at_least_warn { level(warn..emerg); };f_at_least_err { level(err..emerg); };f_at_least_crit { level(crit..emerg); }; # all messages of priority debug not coming from the auth, authpriv, news, and # mail facilitiesf_debug { level(debug) and not facility(auth, authpriv, news, mail); }; # all messages of info, notice, or warn priority not coming form the auth, # authpriv, cron, daemon, mail, and news facilitiesf_messages {(info,notice,warn)not facility(auth,authpriv,cron,daemon,mail,news) and facility(local7); }; # messages with priority emergf_emerg { level(emerg); }; # complex filter for messages usually sent to the xconsolef_xconsole {(daemon,mail)level(debug,info,notice,warn)(facility(news)level(crit,err,notice)); }; # filter for radiusf_radius {(local1); }; ###### # logs # order matters if you use "flags(final);" to mark the end of processing in a # "log" statement # these rules provide the same behavior as the commented original syslogd rules # auth,authpriv.* /var/log/auth.log{(s_all);(f_auth);(df_auth); }; # *.*;auth,authpriv.none -/var/log/syslog{(s_all);(f_syslog);(df_syslog); }; # cron.* /var/log/cron.log{(s_all);(f_cron);(df_cron); }; # daemon.* -/var/log/daemon.log{(s_all);(f_daemon);(df_daemon); }; # kern.* -/var/log/kern.log{(s_all);(f_kern);(df_kern); }; # lpr.* -/var/log/lpr.log{(s_all);(f_lpr);(df_lpr); }; # mail.* -/var/log/mail.log{(s_all);(f_mail);(df_mail); }; # user.* -/var/log/user.log{(s_all);(f_user);(df_user); }; # uucp.* /var/log/uucp.log{(s_all);(f_uucp);(df_uucp); }; # mail.info -/var/log/mail.info #log { # source(s_all); # filter(f_mail); # filter(f_at_least_info); # destination(df_facility_dot_info); #}; # mail.warn -/var/log/mail.warn #log { # source(s_all); # filter(f_mail); # filter(f_at_least_warn); # destination(df_facility_dot_warn); #}; # mail.err /var/log/mail.err{(s_all);(f_mail);(f_at_least_err);(df_facility_dot_err); }; # news.crit /var/log/news/news.crit{(s_all);(f_news);(f_at_least_crit);(df_news_dot_crit); }; # news.err /var/log/news/news.err{(s_all);(f_news);(f_at_least_err);(df_news_dot_err); }; # news.notice /var/log/news/news.notice{(s_all);(f_news);(f_at_least_notice);(df_news_dot_notice); }; # *.=debug;\ # auth,authpriv.none;\ # news.none;mail.none -/var/log/debug{(s_all);(f_debug);(df_debug); }; # *.=info;*.=notice;*.=warn;\ # auth,authpriv.none;\ # cron,daemon.none;\ # mail,news.none -/var/log/messages{(s_all);(f_messages);(df_messages); }; # *.emerg *{(s_all);(f_emerg);(du_all); }; # daemon.*;mail.*;\ # news.crit;news.err;news.notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn |/dev/xconsole{(s_all);(f_xconsole);(dp_xconsole); }; # radius log{(s_all);(f_radius); destination(df_radius); }; На удаленных хостах необходимо обновить конфигурацию следующим образом: /etc/syslog.conf # /etc/syslog.conf Configuration file for syslogd. # # For more information see syslog.conf(5) # manpage. # # First some standard logfiles. Log by facility. # ,authpriv.* @log_host *.*;auth,authpriv.none @log_host # |/var/log/syslog.fifo #cron.* @log_host.* @log_host.* @log_host.* @log_host.* @log_host.* @log_host.* @log_host # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. #.info @log_host.warn @log_host.err @log_host # Logging for INN news system #.crit @log_host.err @log_host.notice @log_host # # Some `catch-all' logfiles. # *.=debug;\,authpriv.none;\.none;mail.none @log_host *.=info;*.=notice;*.=warn;\,authpriv.none;\,daemon.none;\,news.none @log_host # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # # $ xconsole -file /dev/xconsole [...] # # busy site.. #.*;mail.*;\.crit;news.err;news.notice;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole # local7.debug /var/log/dhcpd.log Приложение С Скрипт инициализации пакетного фильтра /root/boot/firewall #!/bin/bash # # local variables ="/sbin/iptables" # just head ## clear all rules $I -F INPUT $I -F OUTPUT $I -F FORWARD $I -F POSTROUTING -t mangle $I -F INPUT -t filter ## set default policy to drop all packets $I -P INPUT DROP $I -P OUTPUT DROP $I -P FORWARD DROP ## allow tcp, udp packets for already established tcp, udp connections ## plus tcp, udp packets creating new tcp, udp connections $I -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT $I -A INPUT -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT $I -A OUTPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT $I -A OUTPUT -p udp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT ## allow loopback, for applications using UNIX sockets $I -A INPUT -i lo -j ACCEPT $I -A OUTPUT -o lo -j ACCEPT # Services ## allow to connect via ssh and others wants to connect my PC via ssh $I -A INPUT -p tcp --dport 22 -j ACCEPT -s <source> <…> ## I want to show web face of nagios and mrtg $I -A INPUT -p tcp --dport http -j ACCEPT -s <source> <…> ## Here goes OCS Inventory needs access $I -A INPUT -p tcp --dport http -j ACCEPT -i eth0.92 ## allow icmp $I -A INPUT -p icmp -j ACCEPT $I -A OUTPUT -p icmp -j ACCEPT ## system logging $I -A INPUT -p udp --dport 514 -j ACCEPT -s <source> <…> Похожие работы на - Система мониторинга ресурсов и сервисов локальной вычислительной сети   Модернизация локально - вычислительной сети ГБОУ СПО "ВПТ" СкачатьСкачать документ Информация о работеИнформация о работе Построение корпоративной сети предприятия СкачатьСкачать документ Информация о работеИнформация о работе Разработка проекта корпоративной информационной системы бизнес-центра "Севен" СкачатьСкачать документ Информация о работеИнформация о работе Проект структурированной кабельной системы СкачатьСкачать документ Информация о работеИнформация о работе Грид и облачные вычисления СкачатьСкачать документ Информация о работеИнформация о работе Нужна качественная работа без плагиата? Другие дипломные работы по информационному обеспечению Не нашли материал для своей работы? Поможем написать уникальную работу Без плагиата! Узнайте © 2003 - 2022 «Библиофонд» Обратная связь Пользовательское соглашение Политика конфиденциальности Полная версия Помощь по учебным работам Консультация по курсовой работе Консультация по дипломной работе ВКР Консультация по реферату Консультация по отчетам о практике