Почему cacti не подходит для точного биллинга
Дефолтные установки Data Sources для cacti не подходят для точного определения месячного 95% percentile для любого девайса.
Убедиться в этом можно, заглянув в инфо любого RRD файла со статистикой интерфейсов:
#rrdtool info interface-traffic.rrd
Там мы можем наблюдать следующие вещи. Посмотрим на первый (самый точный) Round Robin архив:
rra[0].cf = «AVERAGE»
rra[0].rows = 600
rra[0].cur_row = 335
rra[0].pdp_per_row = 1
Дефолтный шаг значений везде идет 300 секунд. Тут у нас 600 значений архива с шагом 300 секунд = около 2х суток. Т.е. точные пятиминутные значения хранятся тут не более двух суток. Потом они сливаются в AVERAGE в нижние архивы, которые уже не столь точны:
rra[1].cf = «AVERAGE»
rra[1].rows = 700
rra[1].cur_row = 393
rra[1].pdp_per_row = 6
(это архив следующей точности – 700 получасовых (6*300) шагов из Average 5-минутных значений, примерно за две недели)
Вычисление 95% Percentile требует точных значений с 300-секундным шагом за целый месяц а не за двое суток. Соответсвенно, когда будет вычисляться 95% Percentile, RRDTool вернет конечно запрошенный месячный интервал значений, но не пятиминутных!!! А какой то совокупности 5-минутных, получасовых и 3х-часовых Average.
Т.е. он покажет вам 95-ку, но хрен знает с какой погрещностью. Пока в месяце 30-31 день, все окей. Но у меня в феврале наблюдалась тотальная погрешность более 10% вниз от независимо замеряемых значений, сохраненных за месяц с шагом 300 секунд. Скорей всего это связано с тем что в феврале было 28 дней. Именно это подтолкнуло меня на изыскания погрешности.
Для того, чтобы было достаточно точных данных для месячных итогов Burstable Billing, следует создавать такие RR-архивы:
–step 300 –start 0 \
DS:input:COUNTER:600:U:U \
DS:output:COUNTER:600:U:U\
RRA:AVERAGE:0.5:1:17280 \
RRA:AVERAGE:0.5:6:8640 \
RRA:AVERAGE:0.5:36:2880 \
RRA:AVERAGE:0.5:288:1000 \
RRA:MAX:0.5:1:17280 \
RRA:MAX:0.5:6:8640 \
RRA:MAX:0.5:36:2880 \
RRA:MAX:0.5:288:1000
Здесь конечно данные будут раз в 30 более точны нежели в дефолтных кактусовых RRA. Я взял первый архив 3 месяца 300-секундных значений. Т.е. точность 95ки не пострадает даже при обращении к данным 3 месячной давности.
А зачем использовать cacti в качестве биллинга, когда есть куча приложений и механизмов ориентированных для этого, например тот-же netflow, который и сам достаточно документирован и имеет вагон приложений для подсчета всего и вся.
Комментарий от Nikolay T | 8 марта 2009
Просто мы клиентам давали графы на акках cacti. А биллили клиентов своим софтом, заполняли данные своими поллерами.
И вот ситуация, приходит счет чуваку на 56 Мбит, он заходит в кактус и там видит 45.
Ну я все перепроверил, вроде на нашей стороне нормально. И раньше таких расхождений больших с кактусом не было. Начал рыться…
Комментарий от admin | 8 марта 2009
Как же это знакомо.
Именно по причине «сверхточных» данных какти на моем сервере был отправлен на прошлой недели в /dev/null
Ищу альтернативу. Есть какой-то опыт с Zabbix’ом?
Комментарий от Daemony | 23 марта 2009
Гавно этот заббикс. По крайней мере был таким полтора года назад. Неудачная попытка сделать универсальное «все в одном» имхо.
Я вообще разочаровался. Уже и кактус и нагиос не устраивает. Пишу свое.
Комментарий от admin | 23 марта 2009
Я использую заббикс более полугода. Отличная вещь при грамотной настройке. Ресурсоемкая, но при этом функционал просто супер. И на форуме отвечают быстро и грамотно, разработчики – русскоговорящие.
Комментарий от Иван | 8 мая 2009