Про RRDtool

Автор: FreeBSP.

рабочий вариант тут [url]http://www.lissyara.su/?id=2088[/url]
В РАБОТЕ, принимаются замечания)
ну, тогда прям тут и начну

Предыстория
   Прочитал я статью daemony про rrdtool и загорелся - захотелось тоже что то нарисовать, визуализировать, собрать и построить =)
   Началось все как обычно, с копипастных решений, достаточно быстро я и сам мог что то накалякать, но при этом некоторая часть процесса оставалось для меня загадкой - а именно, я не понимал некоторые моменты в проектировании КБД(кольцевой бд, она же RRD). Потом наконец то дошли руки осилить это все, и я решил в этой статье осветить те грани процесса, которые показались мне сложными . Возможно, это будет первая статья цикла про RRDtool, а может продолжения и не будет. Пока сказать не могу. Если интересно продолжение, пишите =)

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

Начнем-с
   Итак, работаем с пакетом rrdtool.
Что же это за зверь, как его готовить и с чем употреблять) Как следует из названия - это инструмент для работы с кольцевыми базами данных.
   На самом деле это не одна утилита, а целый букет интересных и не очень программ, предназначенных для создания, изменения и обновления КБД, а так же визуализации данных там хранящихся. Стоит упомянуть, что RRDtool лежит в основе таких продуктов как Cacti, Zabbix, Cricket, MRTG... последний некогда послужил отправной точкой проекта rrdtool, а теперь сам на нем базируется

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

   Ну, с первой порцией теории разобрались, перейдем тогда к практике и добудем себе этот замечательный продукт =)
Конечно же, для начала забываем обновить порты, произносим волшебные слова, топаем по пути указанному добрым whereis, собираем и ставим

# whereis rrdtool # csup -L 2 -h `fastest_csup -Qcru` /usr/local/etc/ports-supfile # cd /usr/ports/databases/rrdtool # make config install clean


   Eсли хотим материться с картинок на родном великорусском, то отмечаем опцию [X] DEJAVU         Use DejaVu fonts (requires X11) без нее вместо русских буковок на картинках будет всякая абракадабра)
кроме того, если вы - адепт перла/руби/пистона, ставим соответствующие опции. Кроме того у меня выбрана  опция mmap.

Трогать rc.conf не надо, ибо никаких демонов и серверов запускаться не будет, да и настраивать, в общем, то нечего.

Приступим
   Теперь пора создавать свою первую, а может и не первую, и надеюсь не последнюю кольцевую базу данных.
А начинается создание с проектировки)
Кольцевая база данных представляет собой обычный файл, то есть ни СУБД, ни таблиц, ни администраторов...

[19:04]rrd/# file traffic.rrd traffic.rrd: RRDTool DB version 0003


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

  Теперь пора подумать, КАКИЕ числа мы будем в нее класть. А числа могут быть самыми разнообразными начиная от занятости оперативки и до количества студентов в аудитории, или направления и скорости ветра. Годовую розу ветров rrdtool строить, конечно, не умеет, но даже это можно будет некоторым образом изобразить.
   Но природа чисел не так важна, как характер их поведения - может это постоянно растущее целое, типа счетчика байтов и пакетов в правилах IPFW, может это температура, а может быть число будет расти с бешенной скоростью, например количество периодов электромагнитного излучения, возникающего при переходе между двумя уровнями основного состояния атома цезия-133 (Википедия про цезий-133). Для каждого характера данных можно подобрать необходимый тип источника данных для описания в RRD. В первом случае нам подойдет COUNTER, во втором GAUGE, в третьем - ABSOLUTE, но об этом позже.

   Для примера будем обрабатывать свободную оперативку. Сначала надо решить, откуда мы хотим получать количество свободной оперативки, в каком формате мы будем получать данные и как из них выделить нужные нам цыфры. Вариантов не то чтобы куча, но имеются несколько - sysctl, vmstat, top, snmp...
Daemony выбрал первый, и я с ним согласен: данные получаем почти напрямую от ядра с точностью до размера страницы (обычно 4096 байт). Если кто подскажет, откуда можно получить более точные данные - хвала ему и почет и благодарность от меня лично )) Число свободных страниц оперативки лежит тут vm.stats.vm.v_free_count, а размер страницы в байтах -  соответственно тут vm.stats.vm.v_page_size. То-есть число свободных байтов оперативки получается банальным перемножением второго на первое или первого на второе - кому как больше нравится =) Кроме того, надо еще решить, как часто мы хотим получать эти данные. Мне, например, интересно их получать каждую минуту
   Итак, в базе будем хранить число свободных байтов ОП и новые данные будут поступать каждые 60 секунд. Того что мы уже знаем достаточно для того чтобы заложить первую часть нашей БД.
   Сама процедура создания не долгая, но при создании указывается достаточно большое число параметров. Набивать их в командной строке громоздко и неудбно. Поэтому начинаем стругать скриптик)


#!/bin/sh rrdtool create freeram.rrd --step 60 \ DS:freeram:GAUGE:120:U:U \

//***********************************//

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

Теория
  В первой строке мы создаем КБД freeram.rrd и устанавливаем частоту обновления базы равной одной минуте.
Затем указан параметр DS (Data Source, источник данных) - он описывает какие данные приходят, как они себя могут вести, и определяет некоторые граничные условия. Еще есть параметр RRA(Round Robin Archive, собственно хранилище данных) - он описывает, что делать с пришедшими данными, как их хранить, что делать с уже накопленными данными при поступлении новых и как из имеющихся данных и поступивших получить новое значения для данной ячейки.
   Каждая БД содержит как минимум один DS (Data Source, истояник данных) и минимум один RRA(Round Robin Archive, собственно хранилище данных), но на практике зачастую в одной базе сожительствуют несколько DS и несколько RRA.
   А теперь интересный момент: полный комплект описанных RRA создается ДЛЯ КАЖДОГО DS. То есть если описать 2 DS и 4 RRA, то в итоге получится всего 8 штук RRA, по 4 штуки на каждый DS
удостовериться в этом можно командой  

rrdtool info filename.rrd

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



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


при описании DS мы ограничимся частным случаем. В большинстве ситуаций этого хватит, а что сюда не попадает - не шибко описано и у самого Тоби. в этом самом частном случае DS  задается так: DS:ds-name:GAUGE | COUNTER | DERIVE | ABSOLUTE:heartbeat:min:max
вначале ключевое слово DS  
затем имя из латинских букв, цифр и подчеркивания [a-zA-Z0-9_]
затем тип DS, об этом ниже
затем heartbeat - максимальное время, в течение которого интервал не заполняется значениями *UNKNOWN*
затем максимальное и минимальное значение

теперь немного о типах DS
GAUGE - это "для вещей типа температуры, или количества людей в комнате" ©
то есть некоторая величина, которая характеризует состояние измеряемой величины в данный момент и которая ляжет в базу без обработки
COUNTER - "для постоянно растущих величин, типа числа байтов прошедших через интерфейс". Не может уменьшаться. Хранится как скорость изменения величины в секунду(per-second rate.)
DERIVE  - грубо говоря, это counter, который может уменьшаться. Хранит изменение величины от предыдущего значения до текущего значения DS
ABSOLUTE - используется для счетчиков, которые сбрасываются при чтении

а сейчас настало время поговорить об RRA. задаются они так
RRA:AVERAGE | MIN | MAX | LAST:xff:steps:rows

ключевое слово RRA
затем функция консолидации (буду звать ее CF),
затем т.н. x-files factor - максимальная доля неопределенных значений в интервале консолидации, при которой значение еще считается определенным
steps - размер интервала консолидации в шагах (размер шага - это параметр --step). Все полученные значения в течение этого интервала преобразуются функцией консолидации в одно значение, которое и кладется в  очередную ячейку базы
rows - количество ячеек в данном RRA
с функциями консолидации проще, чем с типами DS
они все используются для получения итогового значения, которое ляжет в базу из ряда значений DS
AVERAGE вычисляет среднее на интервале консолидации
MIN , MAX и LAST - соответственно минимальное, максимальное и последнее значения
кроме того, меня терзают смутные сомнения о том, что при записи в базу поверх уже существующих значений опять же применяются эти функции

теперь надо думать, какие графики мы хотим получать, и с какой точностью.
например, если строить 6-часовой график, а значения получаются каждую минуту, то при ширине графика в 720 пикселей мы получим масштаб 2 пикселя на минуту
если же в те же 720 пикселей впихнуть год, с точностью до минуты, то получится что-то около 720 минутных измерений  на пиксель.
отсюда вывод - хранить большие интервалы времени с большой точностью не целесообразно потому, что 1) точности не увидишь, 2) база разрастется до десятков мегабайт
Например, я хочу рисовать графики за последние 6 часов, сутки, 3 суток, неделю месяц, 3 месяца и  6 месяцев.

прикидывая, около 720px на график - сделаю один RRA на период до 3 суток без усреднения, один - на период до 30 дней с усреднением до 15 минут, и один - на период до 180 дней с усреднением до двух часов
плюс можно сделать еще один - на два года с усреднением 12 часов
внимательные заметят, что я ни слова не сказал про CF, а еще более внимательные спросят, как же так, про CF ни слова, а везде разговор про усреднение
поясню: под усреднением я имел в виду размер интервала консолидации, а не сказал про функцию консолидации, рассчитывая использовать их все
исходя из вышесказанного, дописываем к нашему скрипту описание RRA

#!/bin/sh rrdtool create freeram.rrd --step 60 \ DS:freeram:GAUGE:120:U:U \ RRA:AVERAGE:0.5:1:4320 \ RRA:AVERAGE:0.5:15:2880 \ RRA:AVERAGE:0.5:120:2160 \ RRA:AVERAGE:0.5:720:1440 \ RRA:MIN:0.5:1:4320 \ RRA:MIN:0.5:15:2880 \ RRA:MIN:0.5:120:2160 \ RRA:MIN:0.5:720:1440 \ RRA:MAX:0.5:1:4320 \ RRA:MAX:0.5:15:2880 \ RRA:MAX:0.5:120:2160 \ RRA:MAX:0.5:720:1440 \ RRA:LAST:0.5:1:4320 \ RRA:LAST:0.5:15:2880 \ RRA:LAST:0.5:120:2160 \ RRA:LAST:0.5:720:1440

разъясню смысл цыферек
возьмем второй RRA
RRA:AVERAGE:0.5:15:2880
в этом архиве 2880 ячеек. в каждую кладутся данные, консолидированные из 15 сделанных подряд измерений
учитывая, что каждое измерения делаются раз в минуту, этого архива хватит чтобы хранить данные, собранные
в течение месяца. данные, получаемые в каждой 15-минутной серии измерений усредняются и кладутся в очередную ячейку БД. если в серии из 15 получаемых данных доля неизвестных значений не превысит 0.5, то весь интервал консолидации будет считаться определенным

другой пример
RRA:LAST:0.5:1:4320
в этом RRA хранятся измеряемые данные за последние 3 дня(4320 ежеминутных измерений.

третий пример
RRA:MAX:0.5:720:1440
в базу будет попадать максимальное значение измеряемой величины из всей серии в 720 ежеминутных измерений. в базе есть места для хранения данных на 2 года(720 дней) (1440 ячеек, в каждой 12-часовой максимум)





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

© lissyara 2006-10-24 08:47 MSK