Математика в Zabbix

[sadman]

Уважаемые форумчане, специалисты и такие, как я. Мне хотелось бы прояснить для себя вопросы связанных с вычисляемыми функциями.
Сразу поясню, что осознаю, что заббикс -- это исключительно система мониторинга и никаких сверхточных результатов от неё не жду. Так же не исключаю, что где-то накосячил.

Вводная часть
Итак, имеем:
FreeBSD 7.x
Zabbix 1.8.3
PostgreSQL 8.4
Cisco ASA 5510

C ASA показания снимаются по SNMP, раунд -- 30 сек, устройство не сильно нагружено, поллеров сервера достаточно, поэтому потери части показаний исключаю.

Случай 1. Вычисляемый совокупный траффик
Снимаются показания ifHCInOctets, ifHCOutOctets.
Вычисляется ifHCInOutOctets по формуле last("ifHCInOctets[interface]")+last("ifHCOutOctets[interface]")
Все показатели имеют одинаковую размерность и интервалы обновления.
По этим трём показателям рисуется два графика: один нормальный, второй стекируемый. Изображения прикладываю к посту.

Вопрос такого плана: отчего график вычисляемого значение "запаздывает" за графиками своих составляющих?

В том, что вычисления проводятся верно -- сомнений нет, стекируемый график подтверждает форму линии ifHCInOutOctets. Интерес вызывает отставание. Попытка использовать формулу вида last(..., <round_time>)+last(..., <round_time>) немного приближает результат к желаемому, но накладки тем не менее случаются. На графиках такие места помечены красными вертикальными линями.

Казалось бы -- зачем это нужно? Мне хотелось на карте сети видеть параметры связи, такие как UL/DL и тотальную скорость. В итоге на картинке получается, что в некоторые периоды времени 5KBps+7KBps=16KBps или 3KBps.

Случай 2. Вычисляемая загрузка процессора
В документации к Zabbix приведена вполне обоснованная рекомендация, которая гласит о том, что незачем считывать с устройств cpu[,avg5] вместе с cpu[,avg1].

Я попытался сделать avg5 вычисляемой величиной (мощность сервера под Zabbix все равно избыточна). Для этого я с ASA получаю параметр "system.util[avg1]", "system.util[avg5]" и на основе первого вычисляю "system.util[avg5clc]" по формуле avg(system.util[avg1],300).

Отражая все три параметра на графике вижу, что вычисляемое avg ведёт себя как-то совсем иначе, чем считываемое.
Откуда проистекает вопрос: какой из показателей avg5 точнее отразит картину происходящего и отчего такой разброд в их значениях?

Буду рад пояснениям и рекомендациям.

[dima_dm]

Почему происходит небольшой сдвиг – очевидно. Вычисляемое значение пересчитывается по интервалу обновления. Поскольку ifHCInOctets и ifHCOutOctets и вычисляемое_значение снимаются не одновременно, отсюда и сдвиг.
Поставьте меньше интервал обновления для вычисляемого значения, сдвиг будет меньше
http://www.zabbix.com/documentation/...l/config/items

В отличии от выражений триггеров, процесс Zabbix вычисляет элементы данных в соответствии с интервалом обновления, а не при получении нового значения.

[imperorr]

Для ASA5510 я использую следующие SNMP OID:
CPU 5 sec 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
CPU 5 min 1.3.6.1.4.1.9.9.109.1.1.1.1.5.1
CPU 1 min 1.3.6.1.4.1.9.9.109.1.1.1.1.4.1

[zalex_ua]

Вопрос такого плана: отчего график вычисляемого значение "запаздывает" за графиками своих составляющих?

dima_dm уже все сказал по этому поводу, я лишь добавлю некоторые примечания. Если значительно уменьшить Интервал обновления для вычисляемого значения - то и возрастет и частота записи этих вычисленных значений в БД, поэтому не нужно забывать о переформансе БД если таких вычисляемых элементов у вас много. Если все же решитесь уменьшать, тогда чтобы сильно не раздувать БД, можно подумать об уменьшении периода хранения истории до оптимально минимального.

А еще бы я сказал что отставание вычисляемого значения на графике в пределах 30 секунд - совсем не страшная картина, может достаточно просто предупредить, проинструктировать персонал?

Случай 2. Вычисляемая загрузка процессора
Отражая все три параметра на графике вижу, что вычисляемое avg ведёт себя как-то совсем иначе, чем считываемое.
Откуда проистекает вопрос: какой из показателей avg5 точнее отразит картину происходящего и отчего такой разброд в их значениях?

Вот как раз на этом графике все очень правильно
Мы видим что циска вообще не показала маленький одиночный всплеск загруженности ЦП (красная линия).
В это же время вычисляемое значение (синяя линия) показало усредненное увеличение с небольшим отставанием. При этом усреднение в остальное время дает почти постоянную ровную линию, потому что маленькие "бугорочки" зеленой линии достаточно редкие.
Так что с математикой у заббикса все нормально - к ней просто нужно привыкнуть

[zalex_ua]

А теперь ПОЖЕЛАНИЕ ВСЕМ ФОРУМЧАНАМ, КОТОРЫЕ ПРОЧТУТ ЭТО СООБЩЕНИЕ!

Видите как эта страница расплылась по ширине? Читать всю страницу правда же неудобно? А все это из-за приатаченых картинок автором топика!

Если вы просто приатачили картинки и запостили сообщение, тогда картинки расположатся горизонтально в одну линию внизу вашего сообщения и как следствие страница ужасно расползется по ширине.

Как этого избегать:
После того, как вы приатачили все картинки закройте окошко для приатачивания и на панели инструментов редактора рядом с кнопочкой скрепки нажимаете маленькую кнопку стрелки и там по желанию или "Insert All" или картинки индивидуально.

Важно соблюдать чтобы между тегами атачментов были переносы строк !
В результате вы должны видеть в своем исхотном тексте сообщения нечто вроде:

[ATTACH]3570[/ATTACH]
[ATTACH]3571[/ATTACH]
[ATTACH]3572[/ATTACH]

Этот же способ дает возможность разместить картинки в произвольных местах вашего сообщения.


Вот результат:

[sadman]

dima_dm
Т.е., иными словами, нет никакого гарантированного способа получить на карте сети "математически правильное" отображение сочетаний ряда параметров и вычисляемого на их основе результата (напр. Total=UL+DL)?

imperorr
Да, я тоже использую эти OID, просто ключи назвал таким образом, чтобы сохранить стилистику. Может быть не очень удачно -- не отрицаю.

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

Приношу свои извинения за расползшийся из-за картинок пост. На превью поста в Firefox проблем не наблюдалось -- картинки в столбик. Не наблюдается и сейчас.
Посмотрел его в Opera -- картинки в ряд.

[dima_dm]

Т.е., иными словами, нет никакого гарантированного способа получить на карте сети "математически правильное" отображение сочетаний ряда параметров и вычисляемого на их основе результата (напр. Total=ul+dl)?

С математикой здесь как раз все правильно. Всё дело во временных сдвигах.
Про cpu задача из той-же серии. Среднее зависит от положения границ 5-минутных интервалов.
Пример:
Нарисуйте на листке бумаги 20-минутный интервал и значения каждую минуту. Дальше разбивайте его на 5 минутные интервалы разными способами ( со сдвигом 1,2,3 и т.д. минуты.) т.е.
Цифрами указан номер отсчёта
1-й способ
0-5 5-10 10-15 15-20
2-й способ
1-6 6-11 11-16
3-й способ
2-7 7-12 12-17
И вычисляйте среднее за 5 минут и стройте графики, и о чудо, они получаются разные.

[imperorr]

Кстате да.

Среднее между 4-5-7-3-5-6 =5 (замер раз в 10 секунд)
Среднее между 4-5-7-3-5-0 =4 (замер раз в 10 секунд)
Среднее между 4-5-7-3-5-6 =5 (замер раз в 10 секунд)

Среднее между 5-4-5=4,(6) (замер раз в минуту)

Нарисуй график и все поймешь
Для наглядности сделай резкие перепады в 10 секундных измерениях.

[sadman]

Про отставание, интервалы всё стало понятно после первого ответа -- надо уменьшать раунды получения параметров и вычисляемого значения, тогда графики будут максимально сближены.

Уточняющий вопрос был задан вот в каком ключе.

На карте присутствуют два узла, между ними существует линк, на линк навешена подпись:
DL: {asa5510:ifHCInOctets}
UL: {asa5510:ifHCOutOctets}
Total: {asa5510:ifHCInOutOctets}
где ifHCInOctets, ifHCOutOctets -- параметры, ifHCInOutOctets - вычисляемое значение.

Изначально нужно было на линке нарисовать ifHCInOutOctets, чтобы он был равен ifHCInOctets+ifHCOutOctets. Т.е. чтобы не было ситуаций когда на картинке 6+7=34. И это, скорее, не техническая, а политическая необходимость.

График же я стал строить, чтобы понять почему происходит несоответствие математической суммы отображаемых на линке исходных параметров рассчитываемому и рисуемому рядом с ними значению.

Касаемо процессора меня смутила явная непохожесть графиков по рассчитываемому и считываемому параметрам. Там вопрос был более ориентирован на практику: какую в целом из стратегий выбрать -- переносить расчеты avg на Zabbix и снизить кол-во запросов к устройствам или же оставить все как есть без оптимизации.

[dima_dm]

Зачем Вам вообще этот Total нужен?

[sadman]

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

Понимаете, Дмитрий, я живу в неидеальной стране и работаю в неидеальной организации с неидеальными распределителями финансов (не имеющих технического образования и вообще желания вдумываться в какие-то там рассинхронизации графиков), которые принимают решения на основании идеальных картинок и некоторых внутренних убеждений, которые зачастую привносятся в их голову извне.
Поэтому для обоснования необходимости модернизации инфраструктуры мне надо предъявить картину (а ещё эффектней будет если она будет мигать, подрыгивать иконками и повизгивать в опасных ситуациях) на которой будет изображено, что между объектом А и объектом Б идёт траффик такого-то состава и объёма. И что этот траффик практически всегда (когда картинку демонстрируют) равен 99% пропускной способности канала.
Поэтому менеджер С. не может продать 14 машин в час и в связи с этим водка, баня и икра под новый год у замглавсбытснабдира накрывается медным тазом. И увольнять нужно за это не меня, не менеджера С., а ком.дира, который уже год пишет на счетах "отказать".

Ситуация, знаете ли, стандартная для периферийных организаций, не связанных с телекоммуникационным бизнесом.

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

Несомненно, что можно найти ещё какие-то варианты отображения характера траффика на линке, но самый простой вариант был тот, что породил этот пост -- возможно ли сохранить "математическую точность" суммы двух слагаемых на картинке или нет. Если нет, то буду искать варианты.

[dima_dm]

На самом деле Total c загрузкой канала не связан. Если есть симметричный канал 100Mbps, то он способен пропустить 100Mbps на in и 100Mbps на out. По этой причине, я не понимаю физического смысла Total, и что на основании этого параметра Вы собираетесь доказывать вашим не идеальным менеджерам.
Если вам так нужна синхронизация, можете опрашивать переменные сторонним скриптом из cron, а на zabbix присылать готовые данные через zabbix_sender
http://www.zabbix.com/documentation/.../zabbix_sender
Тогда картинки и графики будут “идеальными”.

[sadman]

Согласен, в этом смысле Total выглядит нелепо.

Мне нужно было вычислять Total DL / Total UL с нескольких тэгированных подсетей (показания снимаются с портов свича), которые прокинуты через узкий арендуемый линк в другое здание. На картинке отобразить сколько генерит каждая подсеть и сколько идёт в целом по транку.

В качестве экспериментального взял свободный линк ASA, который можно произвольно загружать траффиком. Хотел отработать на нём, а потом уже прикручивать айтем к рабочим параметрам. Соответственно, взял оттуда два сетевых параметра -- In & Out. В математическом-то смысле нет разницы что складывать в ходе создания формулы.

[dima_dm]

Ну так снимите трафик с нескольких vlan и отдельно с линка, а не складывайте. Так делать намного правильней, т.к. там идёт ещё и служебный трафик. И разнесите на разные графики, чтобы сдвигов не видно было, либо рисуйте график за больший интервал.

[sadman]

Дмитрий, с Вашего позволения я остановлюсь на zabbix_sender, иначе диалог наш мы никогда не закончим.

Спасибо большое за разъяснения.