MRTG

Перевод документа www.usenix.org/event/lisa98/full_papers/oetiker/oetiker.pdf
Автор: Tobias Oetiker http://oss.oetiker.ch/mrtg/
Переводчик: Зганяйко Дмитрий <zdo.str@gmail.com>

История

Весной 1994 в Монтфортском университете в Лакастере была одна линия с пропускной способностью 64 Кбит, которая обслуживала более чем 1000 компьютеров. В то время не было возможности создать более быструю линию связи, однако было совершенно необходимо иметь возможность мониторить состояние сети в реальном времени. Эта ситуация привела к началу разработку Multi Router Traffic Grapher. Каждые пять минут эта система опрашивала главный шлюзовый роутер университета и генерировала информацию в графическом виде и выдавала ее на веб-странице. Такое визуальное представление позволяло каждому с веб-браузером мониторить состояние соединения.

Как работает MRTG-2

Оригинальный MRTG представлял из себя Perl-скрипт, который использовал внешние утилиты для SNMP запросов и создания GIF-картинок для отображения в HTML страницах (рис. 1). Когда MRTG был впервые опубликован в Интернете весной 1995, это было свежее веяние, и люди стали пользоваться им на своих сайтах.

Вскоре, однако, многочисленные отзывы пользователей указали на две ключевые проблемные зоны: масштабируемость и портируемость. Хотя и MRTG работал прекрасно на 10 линиях связи, большее количество вызывало проблемы с производительностью. Это создавало большую проблему для пользователей. MRTG логировала данные в ASCII-файл, записывая туда информацию каждые пять минут, постоянно поддерживая его целостность и ограничивая размер сверху. Лог содержал в себе немногим больше данных, чем необходимо для отрисовки графиков на веб-странице. Потом графики конвертировались в GIF-формат с помощью использования утилиты pnmtogif, которая конвертировала изображения в формат PNM. Эта опция позволяла MRTG мониторить только до 20 портов роутера с рабочей станции. Другой проблемой для потенциальный пользователей MRTG было обязательное наличие утилиты snmpget из пакета CMU SNMP. Как оказалось, этот пакет оказался сложный для компиляции его на разных платформах. По этой причине на некоторых системах так и не удалось запустить MRTG. Все это изменилось после того, как Дейв Ранд (Dave Rand) заинтересовался MRTG и написал небольшую программу на С rateup. Rateup решала проблему с производительностью MRTG реализовав две наиболее ресурсоемких задач на С, убрав из скриптов на Perl. Rateup выполнял перезапись логов и генерацию графиков. Rateup инициировал разработку MRTG-2.x. Во-первых, Тобиас Оэтикер (Tobias Oetiker) модифицировал rateup для использования библиотеки GD, написанную Томасом Боутеллом (Thomas Boutell), которая позволяла генерировать GIF файлы гораздо быстрее, чем pnmtogif. Во-вторых, проблема портабельности SNMP была решена с помощью перехода с утилиты snmpget из пакета CMU на модуль, написанный Симоном Лайненом (Simon Leinen) и реализующий функционал SNMP на чистом Perl и этим делая его виртуально платформо-независимым. После почти года бета-тестирования и реализации многих частей по запросам пользователей, результатом этих стараний был релиз MRTG-2.0 в январе 1997 года. MRTG-2 был не только быстрее предыдущей версии, но и гораздо дружественней к пользователю. Утилита cfgmaker, которая входила в состав дистрибутива MRTG, могла генерировать каркас для конфигурационного файла для роутера, читая таблицу интерфейсов по SNMP. Эта возможность позволила многим людям конфигурировать MRTG, даже когда они не обладали достаточными знаниями по его архитектуре и настройке или информацией о том, как найти физический интерфейс роутера, который соответствовал той или иной переменной SNMP. MRTG-2 больше не требовал каких-либо внешних зависимостей, и это сделало портирование всего пакета очень простым. Без использования autoconf или другой похожей системы, MRTG собиралась на многих Unix платформах. Даже портирование на Windows NT потребовало только несколько изменений по обработке путей и вызовов внешних программ. Самая прелестная вещь в порте MRTG на NT – это то, что SNMP модуль на Perl Симона Лайнена работал под NT без изменений. MRTG-2 включил в себя большую часть возможностей, которые были интересны большинству пользователей.

Хранилище данных с редукцией

Ключевая возможность MRTG-2 – это метод контроля и хранения лог-файлов. Основное допущение при разработке логов MRTG-2 было то, что интерес к детальной информации о загрузке сети уменьшается пропорционально времени, которое прошло с момента сбора информации и ее анализа. Это привело к реализации логов, которые хранят данные с уменьшающимся разрешением по мере убывания момента сбора этих данных. Данные, старше двух лет, полностью удаляются из лога. Разрешение логов совпадает с разрешением графиков, показанных на веб-странице. Такое хранилище данных с уменьшением разрешения приводит к отсутствию роста размера логов и поэтому позволяет использовать отложенные операции системы на продолжительные периоды времени. Отрисовка индивидуальных графиков относительно проста, потому что не требуются шаги по редукции данных и поэтому количество операций дискового ввода/вывода минимизировано. Логи MRTG-2 хранятся в формате ASCII. Каждая линия начинается с временной отметки, за которой следует соответствующая информация о траффике. Файл начинается с наиболее актуальной записи и заканчивается данными двухлетней давности. Для обработки файл полностью считывается, обрабатывается в памяти и записывается обратно на диск. На рисунке ниже (рис. 2) показано, как это происходит.

На рис. 3 показано, как значения из логов консолидируются во времени.

Определение размера пользовательской базы

Хотя и легко предположить число потенциальных пользователей приложения, гораздо сложнее узнать, сколько их на самом деле. На момент декабря 1998 года домашняя страница проекта MRTG имеет около 700 посетителей и около 200 скачиваний в день. Эти числа достаточно велики для такой страницы, однако, не дают достоверной информации о том, сколько сайтов используют MRTG. Приложения по типу MRTG, которые генерируют информацию, видимую по Web-сети, предлагают уникальный способ измерить количество пользователей по наличию заголовка-referrer в HTTP-запросах. Каждая web-страница, которая генерируется MRTG, содержит ссылку на домашнюю страницу MRTG. Когда кто-либо переходит по этой ссылке на домашнюю страницу MRTG, веб-сервер записывает информацию о referrer. С этой информацией возможно сделать достаточно точную оценку количества сайтов, использующих MRTG. Такой анализ был введен в августе 1998, используя данные с последних двух лет. Он показал заголовки referrer от около 17500 различных хостов с около 11400 сайтов второго уровня и 120 сайтов первого уровня. Это исключает все инсталляции MRTG, где HTML-вывод был изменен и ссылка на домашнюю страницу была удалена, так, что переход по ней был бы невозможен. Однако, этот факт все еще определяет нижнюю границу количества пользователей.

Конец MRTG-2

Все большее число сайтов стали использовать MRTG по причине увеличения его производительности. И скоро предел производительности был достигнут – при около 500 портах, опрашиваемых каждые пять минут. В то же время, людям, которые начали использовать MRTG для мониторинга источников данных "без трафика", потребовалось больше средств контроля над генерацией веб-страниц и графиков. Хотя и MRTG-2 был задуман как широко распространный формат в виде пакета, он не был фундаментально отличен от первоначального MRTG-1 Perl-скрипта. MRTG просто стал более удобным в использовании для большего числа людей. Для мейнтейнеров, же эта эволюция привела к системе, которая, буквально, распухла по сравнению с первоначальной спроектированной архитектурой. Каждое нововведение непропорционально добавляло сложность в систему. В ноябре 1997 было начато полное перепроектирование MRTG. Хотя некоторые возможности должны были быть спроектированы полностью с нуля, изначальные архитектурные веяния были сохранены. Отзывы пользователей и личный опыт показал, что следующий функционал – это ключевые элементы, ведущие к успеху MRTG:

• Простая установка: конфигурация хранится в простых текстовых файлах. Дополнительные утилиты позволяют создавать первичную версию конфигурационного файла, ориентированного для конкретного роутера.
• Легкая поддержка: так как размер и временное разрешение лог-файлов автоматически изменялось во время работы, система могла работать без дополнительного вмешательства месяцами.
• Дружественность: HTML-страницы, генерируемые MRTG, были просты для восприятия и давали хорошее визуальное представление загрузки сети, предлагая основанные на логах предложения об обновлении сетевых каналов связи.
• Интегрированное решение: MRTG выполнял все задачи, связанные с мониторингом трафика. Для его работы не требовалось никаких внешних баз данных или пакетов SNMP.

Главными проблемными зонами MRTG-2 были следующие:

• Производительность: MRTG-2 не мог мониторить больше чем около 600 портов роутера в 5-минутный интервал по причине того, как он работал с лог-файлами.
• Гибкость: хотя MRTG-2 был весьма конфигурируемым, пользователям требовалось проявлять особую осторожность в местах, где способность к конфигурированию была ограниченной. В частности, при использовании программы для мониторинга временно-зависимых данных, а не сетевого трафика.

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

Проектирование и реализация MRTG-3

MRTG-3 перестал быть просто приложением для мониторинга сетевого трафика. Новый MRTG будет платформой для создания приложений, которые могут мониторить большое количество различных данных, протяженных во времени, используя возможность быстрого логирования. Это приведет к возможности генерации широкого типа графиков, базирующихся на данных, собранных от одного или нескольких источников. Параллельный сборщик SNMP поможет повысить эффективность процесса сбора SNMP-данных. Критические ко времени участи MRTG-3 реализованы на С, но соединительным элементом – "клеем" – всего пакета остается Perl. Это позволит пользователям приспособить пакет к своим нуждам без необходимости его перекомпиляции.

"Round Robin" база данных.

Разработка MRTG-3 началась с реализации полностью нового механизма хранения данных. Он был назван Round Robin Database (RRD) и определял, как хранились данные в системе. Обработка данных и генерация графиков была реализована в программе на С rrdtool. Она могла вызываться из командной строки или через биндинги Perl. Round Robin Database была настолько быстрой и конфигурируемой чем MRTG-2, что много людей стали ее использовать в своих собственных приложениях для мониторинга без ожидания окончания написания MRTG-3. После некоторых обсуждений в списке рассылки разработчиков MRTG было решено отделить rrdtool в отдельный пакет как завершенный и удобный в использовании отдельный продукт. Получившееся программное обеспечение оказалось более удобным чем запланированные возможности. Поэтому оставшаяся часть этой секции будет сфокусирована только на Round Robin Database без MRTG-3.

Проектирование базы данных

В ходе проектирования нового формата файлов была предложена возможность включить набор функций, чтоб сделать новый лог-файл не только быстрее, но и гораздо гибче, чем старый текстовый лог-файл MRTG-2. Формат RRD использует double для хранения данных. Это ликвидирует проблему с целочисленным переполнением при мониторинге очень быстрых роутеров и позволяет хранить небольшие числа, такие, как загрузка машины без их масштабирования. RRD также может хранить "неизвестные" (unknown ) значения данных. Это позволяет различать ситуации, когда данные на входе были нулевыми и поэтому не было получено никаких валидных данных. Параметры типа количество записей в логе, разрешение лога и количество источников данных в параллели конфигурируемы. Значения данных в RRD хранятся в нативном бинарном формате. Это делает доступ к данным более эффективным по причине отсутствия их преобразования. Cookie в заголовке RRD используется для проверки совместимости RRD с архитектурой, на которой он запущен. Хранение данных в RRD – это многошаговый процесс. Рис. 4 показывает упрощенную схему дизайна новой базы данных и процедуры обновления.

RRD может быть сконфигурирована на принятие данных от нескольких источников данных параллельно. Источник данных, в данном случае, может быть чем угодно – восьмеричным счетчиком или выходов датчика температуры. Каждый RRD оперирует на конфигурируемом базовом временном разрешении. Все данные, которые приходят из источников, пересемплируются в это разрешение. Процесс пересемплирования данных берет во внимание проблему, что не всегда возможно получить новые данные в желаемый момент времени, но дальнейшая обработка и хранение будут гораздо проще, когда данные расположены по оси времени равномерно. На рис. 5 показан процесс ресемплирования для источника данных типа счетчик с 300-секундым интервалом. Значения счетчика могут приходить нерегулярно, но данные могут хранится в RRD только с фиксированным интервалом. В результате ресемплирования данные гарантированно сохранятся с требуемой частотой и площадь кривой с полученными данными будет такой же.

Главная идея по увеличению производительности логирования – это уменьшение количества данных, которые должны быть переданы от памяти к диску. Это достигается хранением данных в круговой (round robin) манере в выделенных заранее областях памяти, называемых Round Robin Archived (RRA) внутри RRD. Каждый Round Robin Archive имеет свои специальные свойства, такие, как временное разрешение, размер и метод контроля целостности (консолидации). Интервал обновления RRA должен быть кратным базовому интервалу обновления RRD. Несколько значений в базовом разрешении RRD синтезируются в одно значение с разрешением RRA, использую метод консолидации для конкретного RRA. Последняя операция в каждом RRA может быть идентифицирована массивом указателей, так, что только одна операция записи необходима для обновления RRA. Одна Round Robin Database (RRD) может хранить любое количество Round Robin Archived (RRA). Например, один RRA может быть сконфигурирован на хранение данных в базовом разрешении RRD в течение нескольких дней, а другой – хранить только средние значения в сутки на протяжении 5 лет. Также возможно сконфигурировать RRD по аналогии с текстовым MRTG-2 логом. Время, требуемое на обновление RRD новыми данными почти пропорционально количеству RRA в нем плюс константой времени на чтение порции заголовка RRD и выравнивание новых данных по времени. Для обеспечения гарантии качества данных, формат RRD поддерживает указание условий корректности типа минимальное требуемое время обновления или минимальное и максимальное значение, допустимое для источника данных. Если данные не соответствуют этим параметрам, в RRD сохраняется значение unknown. Новый дизайн позволял сохранять около тысячи значений данных в секунду в RRD. Эта скорость драматично падала при доступе к RRD-файлу через NFS или при дисковом кэше, гораздо меньшем, чем количество RRD-файлов, участвующих в работе. Прямое сравнение с MRTG-2 было невозможно, потому что в MRTG-2 процесс создания графиков был интегрирован с процессом логирования.

Генерация графиков

MRTG-2 был сфокусирован на генерации графиков. Большая часть параметров была жестко закодирована. Однако, новый движок построения графиков в RRD Tool был также гибок, как и новый RRD формат. Он позволял создавать графики любого размера, за любой период времени и любого количества источников данных из разных RRD. По возможнсти, движок графиков определял важные конфигурационные значения сам, позволяя пользователю сконцентрироваться на тюнинге внешнего вида. Почти любой аспект визуального представления графиков был конфигурируемым, то есть, перезаписывалось значение по умолчанию. Часто конфигурация вообще не нужна, поскольку RRD Tool имеет функционал, который автоматически добавит, например, метки осей и масштабирование данных по размеру изображения и т.д. Графическая часть RRD Tool также имеет некоторые встроенные возможности анализа. Она может расчитать максимум, минимум и среднее значение для любого источника данных. Для более сложных вычислений можно использовать RPN math для любого числа источников данных и затем вывести их на график. На рис. 6 показан пример графика, демонстрирующий некоторые возможности RRD Tool.

Использование RRD Tool

RRD Tool существует как отдельное приложение rrdtool, которое принимает инструкции по командной строке или через конвейер. Самый предполагаемый способ доступа к RRD Tool – прямой вызов функций через Perl биндинги. Это позволяет избежать генерации нового процесса rrdtool для каждой операции и это работает даже на Windows NT (в отличие от UNIX-конвейеров).

Листинг ниже показывает как создать новую RRD с именем demo.rrd.

rrdtool create demo.rrd --step=300 DS:COUNTER:400:0:1000000 \
DS:GAUGE:600:-100:100 RRA:AVERAGE:1:1000 RRA:AVERAGE:10:2000 \
RRA:MAX:10:2000 

Эта БД имеет базовый интервал обновления 300 секунд. Она принимает информацию от двух источников данных и сохраняет их в два RRA. Первый источник данных – это счетчик, который должен быть опрошен каждые 400 секунд. Его допустимые значения лежат между 0 и 1000000. Второй источник данных – индикатор с минимальным временем обновления 600 секунд. Его выходные значения должны быть от -100 до 100. Все значения, не укладывающиеся в лимит для конкретного источника данных, будет записаны как unknown. Данные хранятся в трех RRA. В первой хранится последние 1000 значений в 300-секундном интервале. Второй RRA хранит 2000 значений в 3000-секундном интервале, строя среднее арифметической из 10 базовых интервалов. Наконец, третий RRA имеет те же свойства, что и второй, за исключением того, что в нем хранится максимум 300-секундных значений взятых за последний 10 базовых интервалов. Сохранение данных в RRD очень выполняется просто:

rrdtool update demo.rtd DATA:1994982:U

Это обновляет RRD с данными с первого источника данных 1994982 и значение unknown со второго источника данных. Время для обновления берется текущее. Если требуется время может быть указано с помощью опции --time. После заполнения RRD данными, RRD Tool может быть использован для генерации визуального представления собранных данных, например, следующим образом:

rrdtool graph demo.gif --start=-86400 --title="LISA Demo Graph" \
--vertical-label=’Degree Fahrenheit’ DEF:celsius=demo.rrd:1:AVERAGE \
"CDEF:fahrenheit=celsius,9,*,5,/,32,+" \
 AREA:fahrenheit#ff0000:"Temperature in Room J97" \
 GPRINT:fahrenheit:AVERAGE:"Average for the last 24h %2.1fF"

Результат, создаваемый этой командой, показан на рис. 7 ниже.

Здесь показаны данные о температуре за последние 24 часа (86400 секунд). Данные выражены в градусах Фаренгейта и получаются из градусов Цельсия используя RPN math, как показано в командной строке с CDEF.

RRD Tool в реальном мире

Реализация системы для домашнего сетевого мониторинга, сделанная Отмаром Лендлом (Otmar Lendl), представляет из себя великолепный пример использования RRD Tool. Это приложение используется в Eunet Austria и мониторит и строит графики с около 6000 значениями с 1200 сетевых интерфейсов, серверов и dial-in линий с 5-минутным интервалом. Система работает на SPARCstation-5/170 с загрузкой около 0.2. Сбор данных написан на Perl 5 с использованием биндингов Perl для RRD и UCD SNMP. Программа разделена на планировщик (и использованием EventServer модуля на Perl) и множественных рабочих процессов, которые взаимодействуют по UDP. Визуализация реализована как скрипты mod_perl, которые работают под Apache 2.3. Все изображения, как и большая часть HTML, генерируется динамически. К сожалению, веб-страницы, генерируемые этим приложением, недоступны извне по причинам закрытой политики EuNet Austria.

Планы по MRTG-3

Сбор данных по SNMP

RRD сдвигает узкое место производительности MRTG к компоненту по сбору данных. План по увеличению производительности сбора SNMP-данных сводится к параллельной обработке SNMP-запросов. Это зависит от задержек в сети и того, что роутеры медленно отвечают на SNMP-запросы.

Графики по требованию

Так как генерация графиков – затратная операция, то нет смысле генерировать тысячи gif-изображений для каждой операции обновления. Гораздо выгоднее генерировать графики только, когда пользователь хочет их увидеть. График, показанный на рис. 6, генерируется около 0.3 секунд на Pentium 120. Это значит, что графики могут создаваться на лету и может быть достигнуто приемлимое время ответа от сервера. Для высоконагруженных сайтов может быть настроен графический кэш, так, чтобы графики регенерировались, только когда они устарели.

Генерация HTML

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

Конфигурация

MRTG-2 была монолитным приложением, а MRTG-3 – набор Perl-модулей, которые могут быть собраны в одно приложение для мониторинга. Пользователь может решать, какие модули использовать. Один модуль будет предлагать высокоуровневый пользовательский интерфейс для создания приложений по аналогии с MRTG-2. Скрипты, которые использует этот модуль, состоят из двух частей. Первая, в которой пользователь определяет все источники данных для мониторинга. Вторая часть представляет из себя обработчик событий, который собирает и обрабатывает данные и обновляет соответствующие RRD и HTML-страницы в указанном порядке.

Текущее состояние

MRTG-2 – текущий релиз. Он доступен по ссылке http://ee-staff.ethz.ch/~oetiker/webtools/. Весь код MRTG-3 доступен по ссылке http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/3.0/. MRTG доступен под лицензией GNU GPL. Для общения с другими пользователями MRTG доступен список рассылки. Дополнительная информация доступна на домашней странице проекта.

Альтернативы

• cacti
• collectd