Характеристика мониторинга сети

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Мониторинг сети с помощью функционала Dude

2. Мониторинг загрузки сети

3. Программное обеспечение защиты сети и учета расхода трафика

Заключение

Список используемой литературы



Введение

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

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

Например, для того, чтобы определить состояние веб-сервера, программа, выполняющая мониторинг, может периодически отправлять запрос HTTP на получение страницы; для почтовых серверов можно отправить тестовое сообщение по SMTP и получить по IMAP или POP3.

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

отправлен сигнал тревоги системному администратору;

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

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



1. Мониторинг сети с помощью функционала Dude

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

Мониторинг состояния системы, как правило, осуществляется одной или несколькими рабочими станциями или серверами. Система, проводящая мониторинг, называется Network Management Station (NMS) - станция управления сетью. Далее система, на которой установлен Dude, может называться NMS. Dude поддерживает как активный, так и пассивный тип мониторинга.

Поддерживаемые типы мониторинга

Существует два типа мониторинга: активный и пассивный.

Активный мониторинг подразумевает опрос устройств с определённой периодичностью с целью определения доступности самих устройств и сервисов, которые они предоставляют, а также проверки текущего состояния устройств, например, процент загрузки процессора, дисков, температуры на шасси и прочих. С помощью Dude можно осуществлять такой мониторинг. Более того, в Dude, в основном, весь мониторинг осуществляется в таком режиме.

Пассивный мониторинг подразумевает ожидание от устройств сообщений о событиях, происходящих в системе. Обычно такие сообщения присылаются устройствами по протоколу syslog, либо с помощью SNMP Trap'ов. Что касается работы с SNMP Trap'ами, то Dude, несмотря на отличную поддержку SNMP, НЕ поддерживает работу с ними. Однако в данном программном продукте неплохо реализована работа с syslog сообщениями.

Активный мониторинг, поддерживаемые типы опросов и предоставление информации

О том, что умеет делать Dude в активном режиме мониторинга, написано на его страничке:

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

обнаружение типа устройств и определение производителя;

мониторинг устройств и связей между ними и оповещения о сбоях;

отображение устройств в графическом виде с возможностью добавления своих изображений;

простая установка и использование;

можно строить свои карты сетей с добавлением нестандартных устройств;

поддерживает мониторинг по SNMP, ICMP, DNS, UDP и TCP для устройств, поддерживающих данные протоколы;

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

запускать напрямую с консоли средства удалённого администрирования;

работает под клиент-серверной архитектурой;

запускается и работает под Linux и FreeBSD в Wine, MacOS в Darwine, Windows;

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



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

Объём подгружаемых клиентом данных сравнительно высок - он может достигать нескольких десятков мегабайт. Если Вы подключаетесь к серверу локально или по локальной сети, то задержек при загрузке клиента заметно не будет. Однако, когда Вы подключаетесь через интернет-каналы, задержки могут быть вполне ощутимыми. В целом, если Ваша скорость доступа к серверу больше 10 Мбит/с, задержки получаются приемлемыми, но, если Ваша скорость доступа значительно ниже этого значения, то загрузка клиента может занять несколько минут.

После загрузки конфигурации на клиент сервер постоянно с ним общается, передавая ему только изменения. Данный процесс потребляет небольшую ёмкость интернет-канала - порядка 30-50 Кбит/с. При этом сервер общается со всеми клиентами одновременно, т.е. любые изменения в конфигурации или в статусе зондирования незамедлительно становятся доступны всем клиентам. Если, например, на одном из клиентов изменить местоположение изображения устройства на карте, то на других клиентах изображение тут же сместится. Поэтому одним из критериев выбора местоположения сервера является пропускная способность канала до него.

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

Рассмотрим пример из практики.

2. Мониторинг загрузки сети

Zabbix - мониторинг загрузки сети и Интернет-канала.

Подключение сервера.

Конфигурирование начнем с создания новой группы серверов. Идем в Configurations>Host groups и нажимаем на кнопку вверху справа Create host group. Я назову группу DemoServers.

Creategroup

После создания группы,- необходимо создать сам хост. Переходим в раздел Configurations > Hosts. Жмем кнопку Create host. В поле IP address или DNS определите внешний IP или DNS-имя по которому Zabbix Server подключится к хосту для получения данных.

В этом же окне откройте вкладку Templates, чтобы подключить к хосту шаблон, по которому для него автоматически создадутся приложения, триггеры, графики и пр. В моем случае, поскольку на хосте стоит ОС Linux, я выберу шаблон Template OS Linux.



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

Но нас ведь не просто графики интересуют, а оповещение в случае загрузки канала. Для начала определимся с тем, что именно будем мониторить. Поскольку, хост отдает контент - критичным для нас будет отдача трафика на интерфейсе. Если же вы мониторите офисный шлюз, то критичным будет исходящий трафик на интерфейсе(для шлюза он будет входящим), который смотрит в локальную сеть. Для того, чтобы научить наш Zabbix слать оповещения в случае “проседания канала”, нам необходимо создать триггер. Открываем раздел Configuration>Hosts и напротив нашего SuperServer выбираем Triggers. В открывшемся окне жмем Create trigger и заполняем

Name: Inet Channel Overload Out eth0

Expression: {DemoServers.SuperServer:net.if.out[eth0].last(0)}>9437184

Severity: Disaster

Число 9437184 это 9 Мбит/c. (9437184 = 1024*1024*9)

Вот и все, что требовалось сделать. Теперь если загрузка исходящего трафика на интерфейсе eth0 будет больше 9 Мбит/с - нам придет оповещение. А прочитать, как подключить СМС-оповещение к Zabbix можно тут.

10-Страйк: Мониторинг Сети" - программа проверки состояния серверов и сетевого оборудования

ТРЕБОВАНИЯ

RRDTool - установка и настройка см. здесь и здесь (англ.).

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

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

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

БРАНДМАУЭР

Итак, нам необходимы правила брандмауэра, которые будут считать трафик www (входящий), pop3 (входящий), smtp (исходящий), imap (входящий) и общий входящий. Вот они:

pif="xl0" # внешний интерфейс

cmd="ipfw -q add"

# Считаем трафик

# SMTP, SMTPS

$cmd 0020 count tcp from any to any 25,465 out via $pif

# POP3, POP3S

$cmd 0021 count tcp from any 110,995 to any in via $pif

# WWW

$cmd 0022 count tcp from any 80,443,8080 to any in via $pif

# ALL

$cmd 0023 count all from any to any in via $pif

# IMAP, IMAPS

$cmd 0024 count tcp from any 143,993 to any in via $pif

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

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

freebsd-host# ipfw show 23

Выдает нам нечто похожее:

00013 146322 109248471 count ip from any to any in via xl0

Нас будет интересовать третья цифра - 109248471 - количество байт, сосчитанное правилом 23, которое в нашем случае считает общий входящий трафик.

RRDTOOL

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

Расположение файлов в моем примере:

База RRDTool: /var/rrdtool/db/network_usage.rrd

Скрипты: /var/rrdtool/scripts/

СКРИПТЫ

Нам будет необходимы следующий скрипты:

network_usage_create.sh - создает базу данных для хранения значений счетчиков, описанных выше. Запускается один раз.

network_usage.sh - обновляет базу. Запускается периодиески. Для нашего примера, один раз в минуту.

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

network_usage_update_rrdtool.sh - фактически, этот скрипт просто запускает раз в пять минут network_usage.sh иnetwork_usage_graph.sh. Его содержимое самое очевидное.

Вот их содержимое:

Создаем базу данных RRDTool

network_usage_create.sh

#!/bin/sh

rrdtool create /var/rrdtool/db/network_usage.rrd \

--start 1176595200 \

--step 60 \

DS:input_pop3:COUNTER:120:U:U \

DS:input_imap:COUNTER:120:U:U \

DS:output_smtp:COUNTER:120:U:U \

DS:input_www:COUNTER:120:U:U \

DS:input_all:COUNTER:120:U:U \

RRA:AVERAGE:0.5:1:1200 \

RRA:MAX:0.5:1:1200 \

Этим скриптом создаем файл (базу данных) RRDTool "network_usage.rrd". Прокомментирую команды:

--step 60 - наша база расчитана на прием значений каждые 60 секунд.

число 120 в строках DS - т.н. heartbeat, обычно ставится как step*2.

U:U - минимальные и максимальные значения. В нашем случае не определены.

строки RRA:AVERAGE и RRA:MAX содержат значения 0.5:1:1200 - это означает, что наша база содержит 1200 ячеек для хранения значений счетчиков через каждый 1 step (грубо: 1200 * (1*60 сек) = 50 часов). Параметр 0.5 имеет хитрое определение, я даже приводить его не буду.

Проверяем, появился ли файл /var/rrdtool/db/network_usage.rrd. Если появился, переходим к следующему шагу. Если нет, то проверяем пути запуска rrdtool (возможно, у вас rrdtool запускается не такой командой /usr/local/bin/rrdtool, а как-нибудь иначе). В любом случае, пока база rrdtool не будет создана, дальше идти нельзя.

Заносим новые данные в базу RRDTool

network_usage.sh

#!/bin/sh

input_pop3=`/sbin/ipfw show 0021 | awk '{print $3}'`

input_imap=`/sbin/ipfw show 0024 | awk '{print $3}'`

output_smtp=`/sbin/ipfw show 0020 | awk '{print $3}'`

input_www=`/sbin/ipfw show 0022 | awk '{print $3}'`

input_all=`/sbin/ipfw show 0023 | awk '{print $3}'`

/usr/local/bin/rrdtool update /var/rrdtool/db/network_usage.rrd \

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

Рисуем график интернет-трафика

#!/bin/sh

RRDPREFIX=/var/rrdtool/dbHOUR="`date +%H`"

MINUTE="`date +%M`"

/usr/local/bin/rrdtool graph $WWWPREFIX/network.png \

--width 500 --height 200 --imgformat PNG \

--start -8h \

--end now \

--title "Traffic: last 8 hours ($DATE)" --rigid --color BACK#FAFAFA \

--vertical-label bit/sec \

--base=1024 \

--watermark "(c)2011 BOZZA.RU Ivanov Ilya" \

DEF:tmp_in_pop3=$RRDPREFIX/network_usage.rrd:input_pop3:AVERAGE:step=60 \

DEF:tmp_out_smtp=$RRDPREFIX/network_usage.rrd:output_smtp:AVERAGE:step=60 \

DEF:tmp_in_all=$RRDPREFIX/network_usage.rrd:input_all:AVERAGE:step=60 \

DEF:tmp_in_imap=$RRDPREFIX/network_usage.rrd:input_imap:AVERAGE:step=60 \

CDEF:in_pop3=tmp_in_pop3,8,* \

CDEF:out_smtp=tmp_out_smtp,8,* \

CDEF:in_all=tmp_in_all,8,* \

CDEF:in_imap=tmp_in_imap,8,* \

VDEF:sum_in_pop3=tmp_in_pop3,TOTAL \

VDEF:sum_out_smtp=tmp_out_smtp,TOTAL \

VDEF:sum_in_all=tmp_in_all,TOTAL \

VDEF:sum_in_imap=tmp_in_imap,TOTAL \

VDEF:max_in_pop3=in_pop3,MAXIMUM \

VDEF:max_out_smtp=out_smtp,MAXIMUM \

VDEF:max_in_www=in_www,MAXIMUM \

VDEF:max_in_all=in_all,MAXIMUM \

VDEF:max_in_imap=in_imap,MAXIMUM \

AREA:in_all#CCCCCC:"ALL (in) " \

GPRINT:max_in_all:"Max=%-8.2lf%sbit/s" \

GPRINT:sum_in_all:"Sum=%-8.2lf %sbytes\l" \

LINE1:in_www#0000FF:"WWW (80,443,8080) " \

GPRINT:max_in_www:"Max=%-8.2lf%sbit/s" \

GPRINT:sum_in_www:"Sum=%-8.2lf %sbytes\l" \

LINE1:in_pop3#FF6600:"POP3 (110,995) " \

GPRINT:max_in_pop3:"Max=%-8.2lf%sbit/s" \

GPRINT:sum_in_pop3:"Sum=%-8.2lf %sbytes\l" \

AREA:out_smtp#FF0000:"SMTP (25,465, out)" \

GPRINT:max_out_smtp:"Max=%-8.2lf%sbit/s" \

GPRINT:sum_out_smtp:"Sum=%-8.2lf %sbytes\l" \

LINE1:in_imap#009900:"IMAP (143,993) " \

GPRINT:max_in_imap:"Max=%-8.2lf%sbit/s" \

GPRINT:sum_in_imap:"Sum=%-8.2lf %sbytes\l" \

COMMENT:" \l" \

COMMENT:"Last update\: $HOUR\:$MINUTE $DATE\l" \

WWWPREFIX=/var/www/rrdtool/images - путь до директории, где будет храниться картинка network.png. Отредактируйте этот путь в соответствии с вашим веб-сервером apache или любым другим.

RRDPREFIX=/var/rrdtool/db - путь до директории, где лежит база данных rrdtool.

Наш скрипт отображает загрузку канала за последние 8 часов:

--start -8р - время в часах (символ h после 8).

--base=1024 - мы же страфик считаем, а не килограммы.

В строках DEF:...:step=60 - не забудьте поставить этот параметр для корректного масштабирования. 60 - это уже знакомые нам 60 секунд.

В строках CDEF байты преобразуем в биты. Формат такой: a = b,8,* - т.е. a = b*8.

Обратите внимание на то, что скорость в битах в секунду (bit/s), а сумма трафика - в байтах (bytes). %s указывает порядок - Мега (M), Кило (k) и др. Для того, чтобы понять, откуда ноги растут, внимательно просмотрите создание переменных, а лучше выпишите их на бумагу: tmp_in_all - байты, in_all - биты. Максимумы считают биты (это относится к скорости, бит/сек). Общее (TOTAL) - в байтах. Так нам привычнее. Только и всего.

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

Обновление: ежедневное сохранение статистики в виде изображений
Все здорово - система настроена, рисует график, но есть проблема - статистика исчезнет (точнее говоря, рисунок обновится), как только пройдет 8 часов. А мне надо, чтобы через месяц я мог по дням просмотреть объемы трафика. Это вам не Squid с его логами. Это статистика брандмауэра, тут логи не пишутся. Решение 1: создать отдельные скрипты (и базу данных) для создания не 8-часовой статистики, а, например, за последние 3 месяца. Но мне стало откровенно лень. Решение примитивное - каждый день копировать сгнерированное изображение с именем, например, "01-11-2009.png". Впоследствии можно будет всегда обратиться к нужному изображению и увидеть, какой соотношение почтового трафика было к веб-трафику и пр.

Примечание: мы "рисовали" график для 8 часового отрезка. Чтобы "запечатлеть" сутки, параметр --start в скриптеnetwork_usage_graph.sh надо заменить на --start -24h.

Создаем файл copyTrafStatImage.sh и помещаем его в любую директорию на ваш вкус. Например, в /var/rrdtool/scripts.

Делаем файл исполняемым:

chmod +x /var/rrdtool/scripts/copyTrafStatImage.sh

Далее редактируем файл любым текстовым редактором. Я препочитаю "ee". Например, так:

ee /var/rrdtool/scripts/copyTrafStatImage.sh

Вносим в файл следующее содержимое:

copyTrafStatImage.sh

#!/bin/sh

currentDate=`date "+%d-%m-%Y"`

fileFrom="/var/www/rrdtool/images/network.png"

fileTo="/var/www/rrdtool/images/$currentDate.png"

cp $fileFrom $fileTo

Пояснять синтаксис не буду, все очевидно. Для понимания того, как менять формат имени файла (читай, текущей даты) смотрите "man date" - в самом конце мана несколько очевидных примеров. Данный скрипт будет создавать изображения вида 14-05-2009.png в той же директории, где расположен файл network.png.

Выполнение данного скрипта надо поместить в cron:

# crontab -e

0 */12 * * * /var/rrdtool/scripts/copyTrafStatImage.sh

Каждые 12 часов файл будет скопирован. Вы можете сделать так, чтобы в имени файла была не только дата (ежедневное копирование), а например, еще и час суток. Только чистите периодически директорию веб-сервера, да и просматривать будет муторнее.

3. Программное обеспечение защиты сети и учета расхода трафика

Tor Browser Bundle 5.0.7

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

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

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

Также мониторинг сети включает анализ расхода трафика.

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

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



Заключение

Мониторинг состояния системы, как правило, осуществляется одной или несколькими рабочими станциями или серверами. Система, проводящая мониторинг, называется Network Management Station (NMS) - станция управления сетью. Далее система, на которой установлен Dude, может называться NMS. Dude поддерживает как активный, так и пассивный тип мониторинга.

Поддерживаемые типы мониторинга

Существует два типа мониторинга: активный и пассивный.

Активный мониторинг подразумевает опрос устройств с определённой периодичностью с целью определения доступности самих устройств и сервисов, которые они предоставляют, а также проверки текущего состояния устройств, например, процент загрузки процессора, дисков, температуры на шасси и прочих. С помощью Dude можно осуществлять такой мониторинг. Более того, в Dude, в основном, весь мониторинг осуществляется в таком режиме.

Пассивный мониторинг подразумевает ожидание от устройств сообщений о событиях, происходящих в системе. Обычно такие сообщения присылаются устройствами по протоколу syslog, либо с помощью SNMP Trap'ов. Что касается работы с SNMP Trap'ами, то Dude, несмотря на отличную поддержку SNMP, НЕ поддерживает работу с ними. Однако в данном программном продукте неплохо реализована работа с syslog сообщениями.



Список используемой литературы

1. Осипов И.Е., Mesh-сети: технологии, приложения, оборудование // Технологии и средства связи. - № 4, - 2006г.

2. Lamme Т., Potter D., Chellis J. CCNA: Cisco certified network associate//Network press, 1998, р. 538.

3. Сергей Пахомов. Анатомия беспроводных сетей // Компьютер Пресс. 2002. №7. С.167-175.

Размещено на Allbest.ru

...