Удаление неверных значений

[fox-net]

После перезапуска какого-то компонента zabbix, то ли sql то ли server, в некоторых счетчиках появились неверных значения типа такого как на графике. Во-первых не очень понятно как так получается такой трафик, во-вторых как можно удалить такие значения? Если начать ковыряться в БД на предмет поиска таких значений, не вызовет ли это новые проблемы? Где-нибудь есть описание того как удалять такие значения?

[zalex_ua]

https://support.zabbix.com/browse/ZBXNEXT-683

Не так уж и страшно в бд подчистить, помните что нужно чистить и историю и тренды

[fox-net]

https://support.zabbix.com/browse/zbxnext-683

Не так уж и страшно в бд подчистить, помните что нужно чистить и историю и тренды

Нет ли инструкции по этой операции? Боюсь повредить структуру.

[dima_dm]

Нет ли инструкции по этой операции? Боюсь повредить структуру.

Если просто будете удалять данные из таблиц history* и trends*, ничего не повредите.
Описание полей таблиц, можно увидеть здесь.

https://www.zabbix.com/forum/showthread.php?p=124950

[fox-net]

Если просто будете удалять данные из таблиц history* и trends*, ничего не повредите.
Описание полей таблиц, можно увидеть здесь.
https://www.zabbix.com/forum/showthread.php?p=124950

Спасибо, вроде получилось.
использовал для удаление левых значений: delete from zabbix.history_uint where ns like '683748%' and value > 999999999 order by value desc;
Заранее, естественно, определив примерно определив интервал по полю ns.

Из трендов удалял другим запросом: delete FROM zabbix.trends_uint where value_max-value_min>999999999 and value_min<99999 order by value_max desc;

Может быть что-то затронулось лишнее, думаю, это сильно не испортит картины.

[fox-net]

В целом мне не очень понятно как получаются такие вредные значения.
Можно понять что после рестарта каких-то компонентов могут появляться не совсем верные значения из-за смещения во времени. Но откуда могут появляться сотнями и тысячами вот такие значения? По какой такой причине к значению вдруг добавляется 9 нулей? Баг?
+--------+------------+----------------+-----------+
| itemid | clock | value | ns |
+--------+------------+----------------+-----------+
| 39862 | 1360914981 | 96415000000000 | 683748669 |
| 39862 | 1360914981 | 91829000000000 | 683748671 |
| 39864 | 1360914563 | 64912000000000 | 683748411 |
| 39849 | 1360914668 | 18430857142857 | 683748138 |
| 39857 | 1360914616 | 13894666666666 | 683748620 |
| 39864 | 1360914563 | 10846000000000 | 683748410 |
| 39639 | 1360914998 | 9327833333333 | 683748654 |
| 39849 | 1360914668 | 5942500000000 | 683748140 |
| 34948 | 1360914847 | 5431250000000 | 683748271 |
| 39639 | 1360914998 | 4720000000000 | 683748648 |
| 39849 | 1360914668 | 3835000000000 | 683748142 |

[dima_dm]

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

[fox-net]

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

Данные в данном инциденте собирались разным способом, одно их объединяет, что похоже везде участвовало понятие скорости, то есть расчет чего-то в секунду. Одновременно подобные значения массово появились на многих свитчах, на разных портах, данные собираются по SNMP. Также это встречалось и на серверах, в том же sql сервере был зарегистрирован трафик в несколько Терабит/с. Похоже, что общее в этих случаях Store value, это Delta (speed per second).
Я бы мог понять, что, например, заббикс по какой-то причине сосчитал сырое значение с устройства и поделил его на одну секунду, вписав такой трафик в секунду. Однако это не вяжется с тем, что многие датчики, на которых появились очень большие значения за всю свою историю столько трафика не передали и такого значения в снимаемом устройстве быть просто не могло.

[dima_dm]

Данные в данном инциденте собирались разным способом, одно их объединяет, что похоже везде участвовало понятие скорости, то есть расчет чего-то в секунду. Одновременно подобные значения массово появились на многих свитчах, на разных портах, данные собираются по SNMP. Также это встречалось и на серверах, в том же sql сервере был зарегистрирован трафик в несколько Терабит/с. Похоже, что общее в этих случаях Store value, это Delta (speed per second).
Я бы мог понять, что, например, заббикс по какой-то причине сосчитал сырое значение с устройства и поделил его на одну секунду, вписав такой трафик в секунду. Однако это не вяжется с тем, что многие датчики, на которых появились очень большие значения за всю свою историю столько трафика не передали и такого значения в снимаемом устройстве быть просто не могло.

А время на Zabbix сервере у вас по ntp синхронизируется? Очень похоже на перевод часов на сервере.
Дельта (скорость в секунду) – запись значения как (значение-пред_значение)/(время-пред_время), где
значение – текущее значение
пред_значение – предыдущее полученное значение
время – текущий timestamp
пред_время – timestamp предыдущего значения
Если поделить на число стремящиеся к нулю, можно очень большое значение получить.

[fox-net]

А время на Zabbix сервере у вас по ntp синхронизируется? Очень похоже на перевод часов на сервере.

Хм. Таки да. Вспомнил, что в тот момент я заметил странный пинг, который отвечал, похоже, из прошлого. По-моему дата в том случае стояла верная. Я решил перезапустить сервер, проблема с пингом и временем пропала, но за это время, видимо заббикс успел записать кучу неверных значений. Однако я не придал значение этой ситуации. А зря)

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

[dima_dm]

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

Можно настроить синхронизацию времени через VMware Tools, а на ESXi синхронизировать время по ntp.
Я настраиваю ещё триггер
{Host:system.localtime.fuzzytime(30)}=0
Который кричит, если время на сервере уходит более чем на 30 секунд.