ST
Просто проблема в том, что в новой версии заббикса проблемы с unreacheble серверами остается + проблема с histry syncer internal processes, хотя и нет проблемы с housekeeper
Size: a a a
2020 April 22
AK
Просто проблема в том, что в новой версии заббикса проблемы с unreacheble серверами остается + проблема с histry syncer internal processes, хотя и нет проблемы с housekeeper
используй timescaledb, это единственное удобное решение, которое хорошо описано, хорошо работает и в мануалах всё написано достаточно чётко.
C
🌟 A K has reached level 2!
SS
можно сделать как-то чтоб график с данными траппера не рисовался, если нет данных?
OK
в виджете Graph - не рисуется
SS
это для дашборда всмысле? я всё по старинке комплексными экранами... но спасибо, щас гляну!
DK
Добрый день. А кто-то настраивал в Timescaledb сжатие данных?
AK
Ребят, всем привет. Может сталкивался кто? Подскажите пожалуйста.
На текущий момент имеем 3 разных сервера мониторинга с версией 2.4 по ±300 узлов на каждом. Под ними БД MySQL 5.7, все в innodb per table. В среднем запись на каждом Zabbix-Server по ±1000 значений в секунду. В какой-то момент на них перестает отрабатывать housekeeper (когда база разрастается до 30-45GB на диске), точнее начинает отрабатывать все дольше и дольше, хотя чистка стоит каждый час и по 100000 записей. В итоге буквально за недели 2 происходит наполнение БД с нуля до 30-45Gb и housekeeper перестает отрабатывать. При ходится каждый раз чистить таблицы с историей, что вообще плохо. В шаблоне zabbix agent есть элемент данных agent ping, на который завязна триггер "server ${hostname} is unreachble". Так вот при отработке housekeeper все узлы начинают периодичнски загораться красным, и шлют алерты. При этом они могут погаснуть и потом опять начать загораться и снова слать алерты и так постоянно пока работает housekeeper. А он никогда почему-то никогда не может закончить свою отрабокту, даже если поставить ему удалять по 500 записей. В чем дело не понятно. Тюнинг везде на максимум, что делать не знаю.
Грешили на старую версию Zabbix, решили попробовать новую для тестов. Сейчас имеем Zabbix 4.4 пустой, с БД в виде PostgreSQL на базе stolon. И сохранением истории в ElasticSearch 6.3 (3 ноды). Подключили для тестирования 30 узлов. В 100% стала нагрука "history syncer internal processes. Проблем с houskeeper нет, но периодически все узлы постоянно начинают гореть unreachble. Хотя с чего бы, если на сервере всего 30 узлов подключено..
Если убрать запись в Elasticsearch, и настроить ее в PostgreSQL, то график history syncer internal processes при 30 узлах держится где-то на 20%, что конечно лучше при 100% в ElasticSearch. Но почему так? Да и ладно бы, можно оставить запись в PostgreSQL, если с ElasticSearch нагрузка выше почему-то. Но даже на новой версии узлы все равно загораются unreacheble и шлют ложные уведомления.
Кто-нибудь сталкивался с таким? Куда копать просто не понятно. Подскажите пожалуйста.
На текущий момент имеем 3 разных сервера мониторинга с версией 2.4 по ±300 узлов на каждом. Под ними БД MySQL 5.7, все в innodb per table. В среднем запись на каждом Zabbix-Server по ±1000 значений в секунду. В какой-то момент на них перестает отрабатывать housekeeper (когда база разрастается до 30-45GB на диске), точнее начинает отрабатывать все дольше и дольше, хотя чистка стоит каждый час и по 100000 записей. В итоге буквально за недели 2 происходит наполнение БД с нуля до 30-45Gb и housekeeper перестает отрабатывать. При ходится каждый раз чистить таблицы с историей, что вообще плохо. В шаблоне zabbix agent есть элемент данных agent ping, на который завязна триггер "server ${hostname} is unreachble". Так вот при отработке housekeeper все узлы начинают периодичнски загораться красным, и шлют алерты. При этом они могут погаснуть и потом опять начать загораться и снова слать алерты и так постоянно пока работает housekeeper. А он никогда почему-то никогда не может закончить свою отрабокту, даже если поставить ему удалять по 500 записей. В чем дело не понятно. Тюнинг везде на максимум, что делать не знаю.
Грешили на старую версию Zabbix, решили попробовать новую для тестов. Сейчас имеем Zabbix 4.4 пустой, с БД в виде PostgreSQL на базе stolon. И сохранением истории в ElasticSearch 6.3 (3 ноды). Подключили для тестирования 30 узлов. В 100% стала нагрука "history syncer internal processes. Проблем с houskeeper нет, но периодически все узлы постоянно начинают гореть unreachble. Хотя с чего бы, если на сервере всего 30 узлов подключено..
Если убрать запись в Elasticsearch, и настроить ее в PostgreSQL, то график history syncer internal processes при 30 узлах держится где-то на 20%, что конечно лучше при 100% в ElasticSearch. Но почему так? Да и ладно бы, можно оставить запись в PostgreSQL, если с ElasticSearch нагрузка выше почему-то. Но даже на новой версии узлы все равно загораются unreacheble и шлют ложные уведомления.
Кто-нибудь сталкивался с таким? Куда копать просто не понятно. Подскажите пожалуйста.
Не очень большая нагрузка так-то. 1000 нвпс на 35-40 гиговой базе, вполне можно и с хаускипером жить. Оно вообще хорошо настроено, ресурсов достаточно под БД?
AK
Добрый день. А кто-то настраивал в Timescaledb сжатие данных?
Оно только в 5.0 будет поддерживаться.
ST
Не очень большая нагрузка так-то. 1000 нвпс на 35-40 гиговой базе, вполне можно и с хаускипером жить. Оно вообще хорошо настроено, ресурсов достаточно под БД?
Да
AK
Ну тогда ладно.
DK
Оно только в 5.0 будет поддерживаться.
Понятно. Ну тогда ждем)
VN
Доброго утра всем.
Вновь кину клич: Нет ли гуру по Сервисам ИТ в заббиксе?
Вновь кину клич: Нет ли гуру по Сервисам ИТ в заббиксе?
AK
Доброго утра всем.
Вновь кину клич: Нет ли гуру по Сервисам ИТ в заббиксе?
Вновь кину клич: Нет ли гуру по Сервисам ИТ в заббиксе?
А в чём вообще вопрос-то основной?
VN
А в чём вообще вопрос-то основной?
основной вопрос во времени работы.
Такая структура:
Регион - Сервис - Сервера - Триггеры
У каждого сервера настроил рабочее время. Потомки в зависимостях, что если хотя бы у одного проблемы - тогда проблемы у родителя.
У Региона не проставлял время. Получается что у всех потомков SLA 100%, а у Региона - уменьшается.
При чём сервисы могут иметь разное время работы. Как их объединить в одну группу и на выходе получить один SLA?
Такая структура:
Регион - Сервис - Сервера - Триггеры
У каждого сервера настроил рабочее время. Потомки в зависимостях, что если хотя бы у одного проблемы - тогда проблемы у родителя.
У Региона не проставлял время. Получается что у всех потомков SLA 100%, а у Региона - уменьшается.
При чём сервисы могут иметь разное время работы. Как их объединить в одну группу и на выходе получить один SLA?
VN
Верхний это регион, ниже это сервисы.
AK
Я не знаток вот. А триггеры по дочерним срабатывали вне настроенного рабочего времени услуги?
VN
Да, они срабатывают, но у их родителей тоже прописано время и сла 100% выходит.
AM
Ребят, всем привет. Может сталкивался кто? Подскажите пожалуйста.
На текущий момент имеем 3 разных сервера мониторинга с версией 2.4 по ±300 узлов на каждом. Под ними БД MySQL 5.7, все в innodb per table. В среднем запись на каждом Zabbix-Server по ±1000 значений в секунду. В какой-то момент на них перестает отрабатывать housekeeper (когда база разрастается до 30-45GB на диске), точнее начинает отрабатывать все дольше и дольше, хотя чистка стоит каждый час и по 100000 записей. В итоге буквально за недели 2 происходит наполнение БД с нуля до 30-45Gb и housekeeper перестает отрабатывать. При ходится каждый раз чистить таблицы с историей, что вообще плохо. В шаблоне zabbix agent есть элемент данных agent ping, на который завязна триггер "server ${hostname} is unreachble". Так вот при отработке housekeeper все узлы начинают периодичнски загораться красным, и шлют алерты. При этом они могут погаснуть и потом опять начать загораться и снова слать алерты и так постоянно пока работает housekeeper. А он никогда почему-то никогда не может закончить свою отрабокту, даже если поставить ему удалять по 500 записей. В чем дело не понятно. Тюнинг везде на максимум, что делать не знаю.
Грешили на старую версию Zabbix, решили попробовать новую для тестов. Сейчас имеем Zabbix 4.4 пустой, с БД в виде PostgreSQL на базе stolon. И сохранением истории в ElasticSearch 6.3 (3 ноды). Подключили для тестирования 30 узлов. В 100% стала нагрука "history syncer internal processes. Проблем с houskeeper нет, но периодически все узлы постоянно начинают гореть unreachble. Хотя с чего бы, если на сервере всего 30 узлов подключено..
Если убрать запись в Elasticsearch, и настроить ее в PostgreSQL, то график history syncer internal processes при 30 узлах держится где-то на 20%, что конечно лучше при 100% в ElasticSearch. Но почему так? Да и ладно бы, можно оставить запись в PostgreSQL, если с ElasticSearch нагрузка выше почему-то. Но даже на новой версии узлы все равно загораются unreacheble и шлют ложные уведомления.
Кто-нибудь сталкивался с таким? Куда копать просто не понятно. Подскажите пожалуйста.
На текущий момент имеем 3 разных сервера мониторинга с версией 2.4 по ±300 узлов на каждом. Под ними БД MySQL 5.7, все в innodb per table. В среднем запись на каждом Zabbix-Server по ±1000 значений в секунду. В какой-то момент на них перестает отрабатывать housekeeper (когда база разрастается до 30-45GB на диске), точнее начинает отрабатывать все дольше и дольше, хотя чистка стоит каждый час и по 100000 записей. В итоге буквально за недели 2 происходит наполнение БД с нуля до 30-45Gb и housekeeper перестает отрабатывать. При ходится каждый раз чистить таблицы с историей, что вообще плохо. В шаблоне zabbix agent есть элемент данных agent ping, на который завязна триггер "server ${hostname} is unreachble". Так вот при отработке housekeeper все узлы начинают периодичнски загораться красным, и шлют алерты. При этом они могут погаснуть и потом опять начать загораться и снова слать алерты и так постоянно пока работает housekeeper. А он никогда почему-то никогда не может закончить свою отрабокту, даже если поставить ему удалять по 500 записей. В чем дело не понятно. Тюнинг везде на максимум, что делать не знаю.
Грешили на старую версию Zabbix, решили попробовать новую для тестов. Сейчас имеем Zabbix 4.4 пустой, с БД в виде PostgreSQL на базе stolon. И сохранением истории в ElasticSearch 6.3 (3 ноды). Подключили для тестирования 30 узлов. В 100% стала нагрука "history syncer internal processes. Проблем с houskeeper нет, но периодически все узлы постоянно начинают гореть unreachble. Хотя с чего бы, если на сервере всего 30 узлов подключено..
Если убрать запись в Elasticsearch, и настроить ее в PostgreSQL, то график history syncer internal processes при 30 узлах держится где-то на 20%, что конечно лучше при 100% в ElasticSearch. Но почему так? Да и ладно бы, можно оставить запись в PostgreSQL, если с ElasticSearch нагрузка выше почему-то. Но даже на новой версии узлы все равно загораются unreacheble и шлют ложные уведомления.
Кто-нибудь сталкивался с таким? Куда копать просто не понятно. Подскажите пожалуйста.
Можно еще посмотреть в сторону оптимизации шаблонов, 3нвпс на один узел мониторинга это многовато. В 4.4 появился в препроцессинге не писать в базу если значение не менялось, полезно для всяких статусов минутных. У себя добился 0.5 нвпс на хост при 100 метриках на узел.