cовместное использование MRTG и RRDtool для мониторинга объектов ЛВС

введение

Прежде чем начать свой рассказ о мониторинге состояния сети, я хотел бы рассказать о том, зачем же он нужен.
Допустим у нас есть небольшая сеть, состоящая из одного хаба, небольшого файл-сервера и десятка персоналок. Все это предназначено для обмена файлами между персоналками и работы с общими документами, находящимися на сервере. Тут все просто: ежели что-то выдет из строя или нерадивый пользователь решит посмотреть фильм с компьютера своего коллеги, что незамедлительно скажется на производительности всей сети, то выяснить причину будет нетрудно. Благо сеть небольшая и все находится под боком.
А если у нас в сети несколько серверов (да еще на разных платформах), несколько свичей, и все это расположено на достаточно большой площади? Ждать, когда к вам прибегут с жалобой?
Один из выходов – использование программ для мониторинга работы всех этих элементов сети в реальном времени. Один из таких пакетов – это широко распространенный пакет MRTG (Multi Router Traffic Grapher,http://people.ee.ethz.ch/~oetiker/webtools/mrtg/), написанный Тобиасом Утикером (Tobias Oetiker). Данный пакет основан на протоколе SNMP (Simple Network Management Protocol). Принцип действия программы прост: MRTG периодически опрашивает по протоколу SNMP наблюдаемые объекты и выводит полученную информацию в виде графиков. Поэтому MRTG можно применять для работы с любым оборудованием, имеющим SNMP-агент. Также MRTG можно применять для мониторинга серверов Netware с помощью специального модуля расширения MRTGEXT (http://forge.novell.com/modules/xfmod/project/?mrtgext).
Однако существует еще и пакет RRDtool, (http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/), написанный тем же автором и предназначенный для статистической обработки и визуализации числовых рядов. Как написал сам Тобиас в документации к MRTG, в будущем он планирует объединить оба пакета в один. Однако уже в версиях, существующих сегодня, предусмотрена возможность интеграции обоих пакетов: MRTG может собирать статистическую информацию и сохранять ее в формате RRDtool. А визуализация данных (построение графиков) выполняется уже средствами RRDtool.
В ходе поиска приемлемого решения задачи мониторинга разнородных объектов сети, я редко наталкивался на тематических форумах на упоминания о подобной связке: большинство администраторов ограничиваются использованием MRTG, либо используют для мониторинга софт, поставляемый вместе с сетевым оборудованием, что принуждает их использовать большое число различных программ, для решения одной задачи. А между тем использование связки MRTG+RRdtool, на мой взгляд, достаточно эффективно. Поэтому я и решил поделиться в этой статье своим опытом с читателями.

немного теории

Название RRDtool произошло от термина Round Robin Database, что означает “круговая база данных”. Данная база имеет фиксированный размер. При помещении в нее новых данных, старые данные начинают удаляться, как только заполняется отведенное для них число ячеек. Помещаемые в базу данные – это значения параметров и моменты времени, в которые данные значения наблюдались. Давайте рассмотрим команду создания базы более подробно, так как проектирование структуры базы – это самая важная операция при работе с RRDtool. Именно на этой стадии определяется то, какие данные и как вы сможете накапливать в базе для их последующего просмотра. Команда создания базы имеет формат:

Rrdtool create <имя файла базы> \
[--start start time] [--step step] \
DS:ds-name:DST:heartbeat:min:max \
RRA:cf:xff:step:rows

Здесь start time – это предполагаемое время, когда наблюдалось первое значение отслеживаемого параметра. Почему предполагаемое? Потому что база RRD позволяет заносить в нее значения не только в реальном времени.То есть данные за некоторый период времени можно собирать, например, в лог-файле и лишь затем занести их в базу. Step – это временной интервал между соседними отсчетами. Start time задается в секундах, с момент начала эпохи. Если параметр не указан, то предполагается его значение равное текущему времени минус 10 секунд. Если шаг (step) не задан, то предполагается его значение 300 секунд.
Далее описывается источник данных. Источник данных определяет, как следует интерпретировать числа, помещаемые в базу. Значения, полученные в результате такой интерпретации, называются primary data points (PDP). Ds-name – имя источника базы. DST – тип источника данных. Это один из ключевых параметров базы. Он может принимать несколько значений. О всех возможных значениях этого параметра можно прочесть в соответствующих manpages, я лишь упомяну о двух наиболее интересных для нас. Это значения GAUGE и COUNTER. Первый тип, GAUGE, означает, что все подаваемые значения интерпретируются как есть. Этот тип можно применить, например, если подаваемые значения – это значения утилизации процессора сервера. Второй тип, COUNTER, означает, что при подаче значений будет вычисляться разность между двумя соседними значениями, деленная на значение step. Таким образом, при использовании данного типа источника, будет вычисляться скорость изменения параметра. Этот тип следует использовать в случае, если анализируемый параметр – это счетчик переданных данных (октетов или пакетов). Его можно использовать, если нужно оценить скорость передачи данных. Heartbeat – это максимальное время, на которое могут отстоять друг от друга соседние отсчеты. Если это время превышено, то пропущенные отсчеты будут добавлены автоматически, а их значение будет считаться неопределенными. Min и max – задают диапазон, в котором могут находиться подаваемые в базу значения. Если они не известны, то можно указать U – unknown.
Другая неотъемлемая часть базы – это Round Robin Archive, RRA. RRA хранит числовые ряды, полученные путем консолидации значений PDP. Cf – это функция консолидации. Существует 4 функции консолидации: AVERAGE, MIN, MAX, LAST. Функция консолидации определяет операцию, которую следует выполнить с набором PDP, чтобы получить результат, который и будет храниться в RRA. Результат, получаемый после применения функции консолидации, называется consolidated data point (CDP). Step – это количество PDP, используемых для получения одного CDP. Его не следует путать с одноименным параметром источника данных. То есть, если step=6, cf=AVERAGE, то будет выбрано 6 значений PDP и вычислено их среднее арифметическое. Это и есть искомое значение CDP. Xff – это коэффициент, указывающий, какая часть PDP из интервала консолидации может быть неопределена, чтобы CDP мог быть вычислен. Rows – это количество значений CDP, хранимых в данном RRA. С помощью этого параметра можно задать период, за который мы хотим хранить данные. База может содержать несколько источников данных, а также несколько архивов RRA. Если RRA будут иметь интервалы консолидации разной длины, то такая база сможет хранить данные за достаточно большой период времени, имея при этом небольшой размер (храниться будут не значения отслеживаемого параметра, а наборы значений функции консолидации, которые не требуют большого объема памяти).
Рассмотрим пример:

rrdtool create cpu.rrd -s 60 DS:ds0:GAUGE:600:0:100 RRA:AVERAGE:0.5:1:10080

В этом примере создается база cpu.rrd. Предполагается, что она будет содержать значения утилизации процессора, получаемые с интервалом в 60 секунд. База содержит один источник данных ds0, типа GAUGE, что значит, что PDP будут равны подаваемым в базу значениям утилизации. Если интервал между двумя соседними значениями превысит 600 секунд, то пропущенные значения (а мы предполагали, что данные будут собираться раз в минуту) будут считаться неопределенными (unknown). Утилизация измеряется в процентах, следовательно может лежать в пределах от 0 до 100. База содержит один RRA, длина интервала консолидации = 1, значит, все CDP будут равны соответствующим PDP (функция консолидации, взятая от одного аргумента, всегда вернет значение, равное значению этого аргумента). RRA может хранить до 1080 значений CDP. Учитывая, что данные собираются раз в 60 секунд, а длина интервала консолидации = 1, 10080 значений CDP позволят хранить данные об утилизации процессора, собранные в течение последних 7 суток.

прикручиваем RRDtool к MRTG

Для того чтобы использовать MRTG в режиме интеграции с RRDtool, необходимо в файле конфигурации MRTG указать параметр “LogFormat: rrdtool” и, при необходимости, путь к модулю “RRDs.pm” и исполнимому файлу RRDtool с помощью ключевых слов “LibAdd” и “PathAdd”. После этого MRTG начнет сохранять собираемые данные не в обычные лог-файлы, а в базы RRD. При этом более не будут прорисовываться графики, что снизит нагрузку на сервер, на котором выполняется MRTG. Кстати, в этом режиме минимальный интервал сбора данных составляет уже не 5, а одну минуту!
Имена создаваемых баз, будут совпадать с именами целей, описанных в файле конфигурации MRTG: если цель описана строкой

Target[192.168.1.1_2]: 2:public@192.168.1.1:

то база будет называться 192.168.1.1_2.rrd.
У пытливого читателя наверняка возникнет вопрос: а как быть со структурой базы? Ведь в предыдущей части статьи мы подробно рассмотрели структуру базы.
В этом случае MRTG всю работу по созданию базы выполнит автоматически. Узнать, что получилось, можно с помощью команды

rrdtool info <имя базы>

filename = "192.168.1.1_2.rrd"
rrd_version = "0001"
step = 60
last_update = 1080555390
ds[ds0].type = "COUNTER"
ds[ds0].minimal_heartbeat = 600
ds[ds0].min = 0.0000000000e+00
ds[ds0].max = 1.2500000000e+07
ds[ds0].last_ds = "39793687"
ds[ds0].value = 1.1816100000e+05
ds[ds0].unknown_sec = 0
ds[ds1].type = "COUNTER"
ds[ds1].minimal_heartbeat = 600
ds[ds1].min = 0.0000000000e+00
ds[ds1].max = 1.2500000000e+07
ds[ds1].last_ds = "1935209532"
ds[ds1].value = 8.9708000000e+05
ds[ds1].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 4000
rra[0].pdp_per_row = 1
rra[0].xff = 5.0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[0].cdp_prep[1].value = NaN
rra[0].cdp_prep[1].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 800
rra[1].pdp_per_row = 30
rra[1].xff = 5.0000000000e-01
rra[1].cdp_prep[0].value = 1.5684095833e+05
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[1].cdp_prep[1].value = 4.6094026667e+06
rra[1].cdp_prep[1].unknown_datapoints = 0
…
…
…
rra[6].cf = "MAX"
rra[6].rows = 800
rra[6].pdp_per_row = 120
rra[6].xff = 5.0000000000e-01
rra[6].cdp_prep[0].value = 4.6128083333e+04
rra[6].cdp_prep[0].unknown_datapoints = 0
rra[6].cdp_prep[1].value = 1.1142262917e+06
rra[6].cdp_prep[1].unknown_datapoints = 0
rra[7].cf = "MAX"
rra[7].rows = 800
rra[7].pdp_per_row = 1440
rra[7].xff = 5.0000000000e-01
rra[7].cdp_prep[0].value = 2.0685374167e+05
rra[7].cdp_prep[0].unknown_datapoints = 0
rra[7].cdp_prep[1].value = 1.1682287500e+06
rra[7].cdp_prep[1].unknown_datapoints = 0

Данная база содержит 2 источника данных: ds0 для записи входящего трафика и ds1 для записи исходящего. Одни RRA позволяют отслеживать среднее значение скорости на интервале консолидации, а другие – максимальные значения. Разные RRA имеют разные длины интервалов консолидации и разное число рядов. Это позволяет каждому RRA хранить данные за разные периоды времени. При этом те RRA, которые имеют больший охват, также имеют более низкое разрешение. Например, RRA, имеющий длину интервала консолидации 1, позволит при периоде сбора данных в одну минуту выводить среднее за минуту значение, а RRA с длиной интервала консолидации 30 – среднее значение за полчаса. Если в базе присутствуют несколько RRA, то при выводе графиков RRDtool автоматически выбирает из них тот, который имеет лучшее разрешение.
Как быть, если вас не устраивает набор RRA, сформированный по умолчанию? Тут есть 2 выхода: изменить параметры уже существующих RRA с помощью команды “rrdtool resize” либо создать самим базу с таким же именем, содержащую 2 источника данных - ds0 и ds1 - и самостоятельно спроектированный набор RRA. Заменить старую базу на новую можно при остановленном сервисе MRTG.
После того, как началось сохранение данных в базу, построение графика можно осуществить скриптом вида:

begin=$1
end=$2
step=$3
rrdtool graph speed.png \
--start $begin --end $end --step $step --title "Speed of eth0 at 192.168.1.1" --imgformat PNG \
--height 200 --width 650 \
DEF:var1=192.168.1.1_2.rrd:ds0:AVERAGE \
DEF:var2=192.168.1.1_2.rrd:ds1:AVERAGE \
CDEF:new_var1=var1,8,* \
CDEF:new_var2=var2,8,* \
LINE2:new_var1#33CC33 \
LINE1:new_var2#0000FF

В данном примере командой “rrdtool graph” из базы 192.168.2.2_2.rrd формируется графический файл speed.png, содержащий график размером 650x200 пикселей, на котором отображены входящая и исходящая скорости передачи данных через интерфейс (виртуальные источники данных var1 и var2). Значения скоростей, содержащиеся в базе перед выводом на график, умножаются на 8, т.к RRDtool хранит скорость, измеряемую в байтах за секунду, а мы обычно оперируем данными, представленными в битах за секунду. Параметры $begin и $end – это начальный и конечный временной отсчеты, отображаемые на графике. Параметр $step – это расстояние между отсчетами на графике, задаваемое в секундах. Самое высокое разрешение графика можно получить, если задать значение $step равным длине интервала консолидации одного из RRA. Однако, если использовать значение кратное длине интервала консолидации, то при построении графика будет выполнена дальнейшая консолидация значений CDP с помощью соответствующей функции cf. Это позволяет выводить данные с различными разрешениями, опираясь всего на один RRA! Манипулируя всеми тремя параметрами, можно легко получать графики за любой интервал времени и с любым разрешением в пределах периода, охваченного имеющимися RRA. На приведенных скриншотах показаны примеры графиков загрузки процессора (рис. 1) и сетевого интерфейса (рис. 2).

заключение

В заключении я хотел бы немного упомянуть способах автоматизации создания графиков. Поскольку вышеописанная связка MRTG и RRDtool не подразумевает автоматического пострения графиков, это следует делать с помощью скрипта, подобного рассмотренному нами. Один из самых простых способов – это запуск такого скрипта с помощью планировщика cron в заданные моменты времени. Полученные графики можно свести в веб-страницу, подобную той, которую использует MRTG в своем обычном режиме работы. А более продвинутый вариант – это использование cgi-скрипта, который позволит не только инициировать построение графиков по требованию администратора, но и задавать параметры построения (начальную и конечные точки, а также шаг построения) непосредственно на веб-странице, на которой и размещаются графики. Одним словом – немного фантазии и у вас в руках веб-консоль со статистикой о работе всей сети.

Юрий Левин,yl@tut.by.
обсуждение статьи