Пики и скачки на графиках

[QTol]

Добрый день! Почему возникают такие пики на графиках? В основном элементы данных снимающие скорость. Счётчики 64Б раз в 60с.
на форуме видел тему, но там единственный ответ, человек патчил сорцы. обновлять и пересобирать заббикс никак нильзя.Посоветуйте как решить проблему, Спасибо

[egorrabota]

Добрый день! Почему возникают такие пики на графиках? В основном элементы данных снимающие скорость. Счётчики 64Б раз в 60с.
на форуме видел тему, но там единственный ответ, человек патчил сорцы. обновлять и пересобирать заббикс никак нильзя.Посоветуйте как решить проблему, Спасибо

) Зашел по другом вопросу, но у меня та же фигня произошла неделю назад. Первый раз за наверное примерно год с хвостиком

[ableev]

Это просто удивительно.

"Доктор, у меня раз в день в коленке что-то стреляет, вот вам фото коленки во время выстрела."
"Странно, у меня такая же коленка, но ничего не стреляет."

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

[egorrabota]

"Доктор, у меня раз в день в коленке что-то стреляет, вот вам фото коленки во время выстрела."
"Странно, у меня такая же коленка, но ничего не стреляет."
.

Хороший шутка )
На то вы и Zabbix Certified Specialist чтобы с ходу направить по нужному направлению ) Спасибо )

[Jimson]

Нет, в данном случае, шутка не к месту. Просто при вычислении дельты надо проверять результат. Про чувака, который правил сорсы, это видимо про меня было.

Есть вещи в разработке Zabbix которые не просто удивляют, а просто ставят в тупик. Например, недавняя разработке "snmp bulk" и ее фикс: мало того что изначально решили все OID в один get() запихать и никому в голову не пришло что наверно железки какой то предел имеют, так в качестве фикса сделали "выключатель" вместо числового ограничения на кол-во OID в одном get().

Возвращаясь к проблеме поднятой тут. Zabbix полагает что если данные приходят регулярно (относительно интервала опроса элемента данных), то значит они верные и можно смело вычислять дельту. На самом деле этого не достаточно, для элементов данных типа дельта необходимо задавать предел, так как SNMP счетчик может "скакнуть" в пределах интервала опроса. Это я и правил, точнее грязно похачил добавив проверку на delta < 100000000000, что, естественно, не решило проблем с 32 битными счетчиками, которые на некоторых железках вообще имеют тип INTEGER вместо COUNTER и скачут от -2^31 к нулю при перезагрузке оборудования и я на графиках наблюдаю по 50 мегабит на спутниковом линке к VSAT, который теоритически не может протолкать больше 8 мегабит. Такая вот печаль.

[QTol]

Нет, в данном случае, шутка не к месту. Просто при вычислении дельты надо проверять результат. Про чувака, который правил сорсы, это видимо про меня было.

Есть вещи в разработке zabbix которые не просто удивляют, а просто ставят в тупик. Например, недавняя разработке "snmp bulk" и ее фикс: мало того что изначально решили все oid в один get() запихать и никому в голову не пришло что наверно железки какой то предел имеют, так в качестве фикса сделали "выключатель" вместо числового ограничения на кол-во oid в одном get().

Возвращаясь к проблеме поднятой тут. Zabbix полагает что если данные приходят регулярно (относительно интервала опроса элемента данных), то значит они верные и можно смело вычислять дельту. На самом деле этого не достаточно, для элементов данных типа дельта необходимо задавать предел, так как snmp счетчик может "скакнуть" в пределах интервала опроса. Это я и правил, точнее грязно похачил добавив проверку на delta < 100000000000, что, естественно, не решило проблем с 32 битными счетчиками, которые на некоторых железках вообще имеют тип integer вместо counter и скачут от -2^31 к нулю при перезагрузке оборудования и я на графиках наблюдаю по 50 мегабит на спутниковом линке к vsat, который теоритически не может протолкать больше 8 мегабит. Такая вот печаль.

Спасибо, что внесли ясность А сделать проверку возможностями заббикса возможно? Не правкой сорцов

[Jimson]

Спасибо, что внесли ясность А сделать проверку возможностями заббикса возможно? Не правкой сорцов

Если бы можно было сделать, то я, наверно, не стал бы править исходники

[ableev]

Если бы можно было сделать, то я, наверно, не стал бы править исходники

Где можно увидеть ваши правки?

[yukra]

Если бы можно было сделать, то я, наверно, не стал бы править исходники

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

[QTol]

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

Лишнее звено. данный вариант тоже отпадает

[Jimson]

Где можно увидеть ваши правки?

--- src/libs/zbxdbcache/dbcache.c.orig  2012-08-27 23:57:57.000000000 +0400
+++ src/libs/zbxdbcache/dbcache.c       2012-08-28 00:19:26.000000000 +0400
@@ -1000,6 +1000,10 @@
                                                        (item->lastclock < h->clock ||
                                                                (item->lastclock == h->clock && item->lastns < h->ns)))
                                        {
+                                               if (h->value_orig.ui64 - item->prevorgvalue.ui64 > 1000000000000000)
+                                               {
+                                                       h->value_orig.ui64 = item->prevorgvalue.ui64;
+                                               }
                                                h->value.ui64 = (h->value_orig.ui64 - item->prevorgvalue.ui64) /
                                                                ((h->clock - item->lastclock) +
                                                                        (double)(h->ns - item->lastns) / 1000000000);

но как я написал выше это не решает проблемы сбросы 32х битных счетчиков, порог "скачка" в идеале должен зависеть от конкретного элемента данных, т.е. быть конфигурируемым

[QTol]

А в новых версиях сервера это не исправлено? Сейчас стоит 2.0.10

[ableev]

А в новых версиях сервера это не исправлено? Сейчас стоит 2.0.10

Нет, не исправлено.

[Zentarim]

А zbxnext на это дело есть? Если нет, и это интересует большое количество народу, может быть организовать?

[Jimson]

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