рабочий вариант тут
http://www.lissyara.su/?id=2088
В РАБОТЕ, принимаются замечания)
ну тогда прям тут и начну
в общем то даже и статья-не статья,а так, сборная солянка из других источников, помноженная на собственое видение ситуации
итак, работаем с пакетом rrdtool
что это это такое) как следует из названия - это тулза для работы с кольцевыми базами данных.
на самом деле это не одна тулза, целый букет интересных и не очень программок
а RRD представляет собой базу данных фиксированого размера(то есть с фиксированным числом ячеек), в которую и кладуться данные, предваритаельно обработанные по каким то сложным алгоритмам.
ну перейдем тогда к практике и добудем себе этот замечательный пакет утилит
конечно же для начала забываем обновить порты, произносим волшебные слова, топаем по пути указанному добрым whereis, собираем и ставим
Код: Выделить всё
# csup -L 2 /usr/local/etc/ports-supfile
# cd /usr/ports/databases/rrdtool
# make config install clean
если хотим материться с картинок на родном великорусском, то отмечаем опцию
DEJAVU Use DejaVu fonts (requires X11) без нее вместо русских буковок на картинках будет всякая абракадабра)
кроме того, если вы - адепт перла/руби/пистона, ставим соответствующие опции. у меня еще выбрана опция mmap
трогать rc.conf не надо, ибо никаких демонов и серверов запускаться не будет, да и настраивать в общем то нечего
теперь пора создавать свою первую, а может и не первую, и надеюсь не последнюю базу
а начинается создание с проектировки)
кольцевая база данных представляет собой обычный файл, тоесть ни какой то СУБД, ни таблиц, ни администраторов...
Код: Выделить всё
[19:04]rrd/# file local-inet-internal-http_traffic.rrd
local-inet-internal-http_traffic.rrd: RRDTool DB version 0003
в базе данных хранятся только голые числа, хотя и специальным образом обработанные.
теперь пора подумать, КАКИЕ числа мы будем в нее класть. а числа могут быть самыми разнообразными, вплоть до скорости течения воды в реке, или направления и скорости ветра. годовую розу ветров rrdtool строить конечно не умеет, но даже это можно будет некоторым образом изобразить
Не знаю как кому, но мне розы ветров по барабану, есть и поважнее данные которые хочется визуализировать, например оперативка, которая вечно куда то утекает..
итак, что мы будем визуализировать - решили - свободную оперативку
далее. где мы ее будем брать. источник данных в принципе не важен, но мы должны знать в каком формате он поставляет данные и как из этого выдернуть нужные нам цыфры.
вариантов не то чтобы куча, но имеются несколько - sysctl, vmstat, top, snmp...
Daemony выбрал первый, и я с ним согласен... данные получаем из "уважаемых" системных переменных с точностью до размера сраницы(обычно 4096 байт). если кто присоветует откуда брать более точные данные - хвала ему и почет и благодарность от меня лично ))
значит число свободных страниц оперативки лежит тут vm.stats.vm.v_free_count а размер страницы в байтах - соответствено тут vm.stats.vm.v_page_size.то-есть число свободных байтов оперативки получается банальным перемножением второго на первое )
мы уже знаем, что хранить мы будет число свободных байтов ОП.
как часто нам надо это знать. мне например интересно знать это каждую минуту
того что мы уже знаем достаточно для того чтобы заложить первую часть нашей БД
сама процедура создания не долгая, но долго набивать все параметры и ключи в командной строке. поэтому начинаем стругать скриптик)
Код: Выделить всё
#!/bin/sh
rrdtool create freeram.rrd --step 60 \
DS:freeram:GAUGE:120:U:U \
тут самое время вернуться к теории
Параметр 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
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
затем функция консолидации,
т.н. 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 на последние двое суток без усреднения, один - на период еще какой то , а остальные rra я опишу завтра)
завтра же бнапишу о том как базу заполнять и как собственно рисовать, там уже теории почти нет, чисто практика..
min:max
)
