Представлен (https://www.zabbix.com/whats_new) выпуск системы мониторинга Zabbix 3.4 (http://www.zabbix.co/). Вышедшая версия содержит новую систему дэшбордов, несет новые возможности по предварительной обработке поступающих данных, предлагает новые механизмы массового сбора метрик и многое другое. Код проекта распространяется под лицензией GPLv2.
Напомним, что Zabbix состоит из трёх базовых компонентов: сервера для координации выполнения проверок, формирования проверочных запросов и накопления статистики; агентов для осуществления проверок на стороне внешних хостов; фронтэнда для организации управления системой. Для снятия нагрузки с центрального сервера и формирования распределённой сети мониторинга может быть развёрнута серия прокси-серверов, агрегирующих данные о проверке группы хостов. Данные могут храниться в СУБД MySQL, PostgreSQL, DB2 и Oracle. Без агентов Zabbix-сервер может получать данные по таким протоколам как SNMP, IPMI, JMX, SSH/Telnet, ODBC, проводить тестирование доступности Web-приложений и систем виртуализации.
Основные (http://www.zabbix.com/whats_new.php) улучшения (https://www.zabbix.com/documentation/3.4/manual/introduction...):- Новая система дэшбордов. Пользователи могут самостоятельно создавать дэшборды, располагая на странице различные виджеты. Дэшборды могут быть личными или доступны другим пользователям.
- Препроцессинг поступающих значений такими функциями как Trim, Regexp,XPath, JSON Path
- Массовый сбор данных. Новый механизм зависимых метрик позволяет один раз получать сразу группу элементов в формате, в котором предоставляет само контролируемое приложение, будь то XML, JSON или другой, а затем, используя возможности препроцессинга, пересылать каждое значение в зависимые отдельные метрики.
- Выполнение удаленных команд и скриптов через Zabbix-прокси
- Поддержка пользовательских макросов в интервалах опроса или хранения. Вместе с поддержкой суффиксов времени вида 30s, 5m, 2h, 1d, 1d позволяет добиться гибкости управления временными интервалами- Коллекция шаблонов сетевых устройств для таких вендоров как Alcatel, Brocade, Cisco, D-Link, HP, Huawei, Intel, Juniper, Mellanox, Mikrotik, Netgear и Ubiquiti
- Настраиваемые JMX endpoint;
- Низкоуровневое обнаружение (LLD) для JMX вида jmx.discovery[discovery mode,object name]
- Более эффективная синхронизация конфигурационного кэша.- Реализован функционал полного клонирования карт и комплексных экранов- Прекращена поддержка Internet Explorer 9 и 10. А также SQLite для сервера( поддерживается на Zabbix proxy)- Возможность получать уведомления о подтверждении аварий
- Реализована параллельная отсылка оповещений- Возврат сообщения об ошибке при выполнении скриптов и отправке уведомлений
- Оптимизирована работа сбора данных по IPMI- Добавлена поддержка {HOST.*} макросов в тэгах событий- Реализована новая агентская проверка vfs.dir.size для контроля размера директорииURL: https://www.zabbix.com/whats_new
Новость: http://www.opennet.me/opennews/art.shtml?num=47070
Не обновляйтесь!
Коллега скинул инфу.
там сейчас злобная бага - если хост/item становятся недоступными, т.е. сервер ушел оффлайн - они сами не включатся, так и будут висеть в failed.
спасает рестарт заббикс сервера.
Этот баг обнаружили буквально через 5 минут после релиза. Проблема достаточно серьёзная, всех призываю подождать 3.4.1.
https://support.zabbix.com/browse/ZBX-12549
Пользуюсь данной системой много лет. Складывается впечатление, что либо очень амбициозная и юная публика делает релизы, либо контроль перед релизом очень слабый. Очень часто, после обновления на свежую мажорную версию присутствуют серьёзные баги. Но система в целом классная, если не ставить версии х.х.0 :)
Сложно придумать, кто кроме "очень юной и амбициозной публики" начнет обновлять свои боевые мониторинги в день релиза.
Дык... Некорректное применение методологии Continuos Integration/Continous Delivery - это какбэ частая нынче ошибка - тех самых _девопсов_ качественных нет, некому заставить разработчиков обложить проект юнит-тестами по самое "небалуйся", некому организовать тестирование в полном объёме - вот и выходят такие "жиденькие" релизы, "под себя", так сказать.Этим страдает нынче не только zabbix, но и многие другие проекты, как открытые, так и закрытые. И даже не ИТ-проекты, но это уже другая история.
Некорректное? в чем некорректность?
> Пользуюсь данной системой много лет. Складывается впечатление, что либо очень амбициозная
> и юная публика делает релизы, либо контроль перед релизом очень слабый.
> Очень часто, после обновления на свежую мажорную версию присутствуют серьёзные баги.
> Но система в целом классная, если не ставить версии х.х.0 :)Я тоже не тестирую ни devel ветки, ни rc, ни не-LTS-релизы. Переходу на следующий lts, когда предыдущий протухает, т.е. через год после .0 нового lts.
Тестирование? Пусть кто-нибудь другой. Да!
Дык ить конфиг от старого новый не всегда сожрёт. Ы? Врёшь ведь? :)
> Дык ить конфиг от старого новый не всегда сожрёт. Ы? Врёшь ведь?
> :)Обидны для меня такие ваши слова!!
Тестовый апгрейд (2.2LTS>>3.0LTS) же с копией боевой базы: отметить изменение конфига и сделать правленый для новой версии (+красиво 3-way-merge...), засечь, сколько (примерно) оно при первом запуске будет бд корёжить, чтобы планировать Час Ч, обязательно не пустить его при этом собирать с реальных клиентов, а то ж агенты ж. После успешного Часа Ч ещё месяц-два-три собирать "эвона, а оно вот тут чего-то не того...". Во время теста, сразу после Ч, или не совсем сразу собирать скрипты, окривевшие от Нового, править... А до тестовыхъ апгрейдов ещё $[какое-то время] пытаться [наконец заставить себя начать//] мержить, перенести или выкинуть in-house патчи.
...не забыть записать - предупредить пользователей, что теперь "цвета именно такие", и что "именно так и надо"...
//Впрочем, тестовый инстанс таки поднимал -- с "инишиал" конфигом об одном хосте инхаус-патчи портить-тестить.
Например, я. Поднимаешь параллельно работающему софту новую версию, выгребаешь баги, репортишь/фиксишь, через некоторое время вводишь в продакшен. Это для софта с кровно необходимыми фичами. Если в новой версии таких нет - то да, типа твоего варианта.
Юмор не уместен, т.к. данная система мониторинга часто обслуживает бизнес-критичные процессы в предприятиях.
> Юмор не уместен, т.к.
>часто обслуживает бизнес-критичные процессы в предприятиях.Как одно следует из другого? Поясните ход Вашей мысли.
неожиданно здравая мысль от Митрофанова, плюсую неистово.
Судя по тому, что в анонсах и афишках старательно обходится стороной вопрос о том, на каком языке ЭТО написано, и только на странице manual/installation/requirements обнаруживается требование иметь Apache+PHP, описанная Вами ситуация выглядит вполне естественной.
ЭТО написано на Си. Только веб-интерфейс на PHP.
> ЭТО написано на Си. Только веб-интерфейс на PHP....и немножечко джаввы сбоку прилепилось!
Жаба там совсем опциональна.
> Жаба там совсем опциональна.Я скзал, что она там есть, ничего более. Это возражений не вызывает, я прям волнуюсь?7!
>> Жаба там совсем опциональна.
> Я скзал, что она там есть, ничего более. Это возражений не
> вызывает, я прям волнуюсь?7!Джава есть для тех, у кого она и без Zabbix'а есть. Или у вас есть приложения с JMX, написанные не на Java?
>>> Жаба там совсем опциональна.
>> Я скзал, что она там есть, ничего более. Это возражений не
>> вызывает, я прям волнуюсь?7!
> Джава есть для тех, у кого она и без Zabbix'а есть. Или
> у вас есть приложения с JMX, написанные не на Java?У кого там словарь для перевода с нормального на джббистский! Сросная медицинская необходимость!11
Спасибо огромное за предупреждение! Сейчас бы бился об стену в поисках бага.
Эти молодцы даже предупреждение на сайт не вывесили...
Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?
нет конечно. Это не типовое использование. Уж извините но такие вещи странно желать из коробки.
Да неужто? Валить все данные в одну (две - хистори и тренд) таблицу это более типовое использование?Как мне кажется, partitioning - один из основных, как по мне, залогов успеха в использовании zabbix'a. Можно, конечно, тратить деньги на SAS-винты (а они недешевы) и =усиление= остального железа. Но хотя бы помесячная разбивка history - почему бы и нет? Даже без partitioning, а просто - новый месяц - новая таблица? Мб, конечно, я что-то не понимаю в этом, тогда прошу просветить меня в этом вопросе.
> Да неужто? Валить все данные в одну (две - хистори и тренд)
> таблицу это более типовое использование?А-ага. для 3-4-20 хостов и sqlite-а -- самое то.
Ну, и о себе:
4x history + 2x trends. +их индексы. => 99%+ бд.
relname | size | size_b
trends_uint | 22 GB | 24 074 412 032
history | 17 GB | 17 982 316 544
history_1 | 13 GB | 14 055 489 536
history_uint | 11 GB | 12 208 955 392
history_uint_1 | 11 GB | 11 488 436 224
trends | 11 GB | 11 354 144 768
trends_uint_pkey | 10 GB | 10 905 575 424
trends_pkey | 4910 MB | 5 148 925 952
history_text | 918 MB | 962 666 496
alerts | 418 MB | 438 370 304
history_str | 326 MB | 341 729 280
history_text_pkey | 285 MB | 298 926 080
history_str_1 | 259 MB | 271 941 632
events | 233 MB | 244 039 680
> Как мне кажется, partitioning - один из основных, как по мне, залогов
> успеха в использовании zabbix'a. Можно, конечно, тратить деньги на SAS-винты (а
> они недешевы) и =усиление= остального железа. Но хотя бы помесячная разбивка
> history - почему бы и нет? Даже без partitioning, а просто
> - новый месяц - новая таблица? Мб, конечно, я что-то не
> понимаю в этом, тогда прошу просветить меня в этом вопросе.Здесь history [в массе] 3 day(*) и сбор раз в минуту, trends 365d.
Все history - 54гига из 104~(**) -- "горячие", переписываются полностью (float/int по кр.мере; 51.9ГБ) каждые 3 дня... тормозят и фрагментируются...... . . . . . .....
housekeeper-ы, vacuum-ы, pg_repack-и -- ужос, ухос, ужос. А, да! thin lvm + fstrim!11
Работаем! //"А, чтобы попасть куда-нибудь, нужно бежать вдвое быстрее."
(*) какое там "новый месяц". И трендсы, месяца ч-з 3 после репака, - тоже тормозят.
(**) "из 104~" - репак неделю тому, .../base/ size был 93.7ГБ. NVPS="1.12 K", avg(1mnth) Да, тот самый кейс для партишенинга... Да... Обдумываю. Третий год! Но 8 шпинделей и 128ГБ озу -- много проще и :) "безопаснее".
Кстати, похожая картина, только 7 дней хистори и оперативы поменьше. У меня в наследство остался старый Zabbix еще версии 1.8. БД на postgres'e, большая, более 100 гиг, две таблицы забиты всерьез - history_uint и trends_uint. Принялся настраивать тестовый, посвежее, и =очевидно= же (: , что грузит людей не пиво, а housekeeper да vacuum. С vacuum все понятно, с housekeeper пишут все кто во что горазд. Да, пока спасают SAS-винты, но когда они начинают подламываться, то обращаешь внимание на цену и оптимизацию.Мои рассуждения тут не новы - надо отстегивать старую статистику, как последние вагоны в =Чапаеве и Пустоте= - решительно и бесповоротно, без всяких housekeeper'ов, с помощью partitioning. А partitioning - тоже на него смотрю и обдумываю, но какая-то документация про него на zabbix'e староватая.
8 шпинделей и 128 ГБ? А сколько у вас values/second?MariaDB. RAID 10 из четырёх стареньких SAS 300, и 300 Гб. Два шестиядерника, потому что из базы регулярно забираются данные для внешних графиков и отчётов.
history_uint - в TokuDB - ~90 гиг со сжатием LZMA, хистори партиционируется и хранится за месяц. Вся база с трендами и прочими хисторями весит ~130 гиг.
Не чихает.
Number of hosts (enabled/disabled/templates) 6296 5423 / 777 / 96
Number of items (enabled/disabled/not supported) 192574 164756 / 25101 / 2717
Number of triggers (enabled/disabled [problem/ok]) 36556 36475 / 81 [323 / 36152]
Required server performance, new values per second 1036.44top - 09:33:23 up 91 days, 14:00, 3 users, load average: 9.00, 6.63, 6.60
Tasks: 1438 total, 23 running, 1412 sleeping, 0 stopped, 3 zombie
%Cpu(s): 32.0 us, 35.2 sy, 0.0 ni, 29.3 id, 0.3 wa, 0.0 hi, 2.5 si, 0.8 st
KiB Mem : 28555988 total, 1020028 free, 25595728 used, 1940232 buff/cache
KiB Swap: 1048572 total, 865316 free, 183256 used. 1964288 avail Memdf -h | grep DB
/dev/mapper/DB-DB 197G 138G 59G 71% /db
Фак.Вторую строчку читать так:
---
MariaDB. RAID 10 из четырёх стареньких SAS 300, и 32 Гб RAM. Два шестиядерника, потому что из базы регулярно забираются данные для внешних графиков и отчётов.
---
> 8 шпинделей и 128 ГБ? А сколько у вас values/second?2 zabbix-а на одинаковом железе
NVPS(*): "1.12 K"; "1.26 K" //avg/month
Required server performance, nvps: 832.11 ; 1480.13(*) - который zabbix[requiredperformance] - фактические insert-ы в базу, не то же самое, что "Required server performance" - айтемы поделенные на интервалы.
> MariaDB. RAID 10 из четырёх стареньких SAS 300, и 300 Гб. Два
> шестиядерника, потому что из базы регулярно забираются данные для внешних графиков
> и отчётов.Какие-то диски на каком то megaraid-е, кажется, в raid-$каком-то... Вообще не копенгаген.
> history_uint - в TokuDB - ~90 гиг со сжатием LZMA, хистори партиционируется
> и хранится за месяц. Вся база с трендами и прочими хисторями
> весит ~130 гиг.vanila Pg 9.1. Соответственно, ни сжатия, ни партиций.
> Не чихает.
С LA > 6 ? А вот пользователь открывает скрин с 5-7 графиками по 5-10 айтемов, да за год -- и ждёт, ждёт, ждёт. :) Да?
[два сервера: #1; #2]
Number of users online: 17; 10> Number of hosts (enabled/disabled/templates) 6296 5423 / 777 / 96
> Number of items (enabled/disabled/not supported) 192574 164756 / 25101 / 2717
> Number of triggers (enabled/disabled [problem/ok]) 36556 36475 / 81 [323 / 36152]
> Required server performance, new values per second 1036.44[два сервера: #1; #2]
hosts (en,/dis./templates) 2265 1653 / 144 / 468; 1052 838 / 87 / 127
items (en,/dis./not sup.) 73326 71170 / 1359 / 797; 90769 81400 / 6559 / 2810
triggers (en,/dis.) 44245 41907 / 2338; 9267 8703 / 564
Required server performance, nvps: 832.11 ; 1480.13
> top - 09:33:23 up 91 days, 14:00, 3 users, load
> average: 9.00, 6.63, 6.60LA5, avg(month): 3.53; 0.97
[на втором web-юзеров, видимо, меньше; скриптов меньше, возможно... может, ещё чего... са мне знаю]Переход с Zb 2.0 на 3.0 снизил LA, кстати: 4.67 => 3.52; 1.48 => 1.04
После крайнего pg_repack-а (вкл.trends-ы) -
LA5, за почти 8/10 посл.дней, avg/max: 2.83 / 6.45 ; 0.91 / 2.82
недедя прямо до репака, avg/max: 4.1 / 9.8; 1.04 / 3.49> df -h | grep DB
> /dev/mapper/DB-DB 197G 138G
> 59G 71% /dbbase/ + pg_xlog/ -
до репака: 108.7G + 12..27GB; 96.6G + 11.8G
сразу после репака: 93.7G + 11.8G; 85.4G + 11.8G
сейчас (почти 8;почти 10 дней) base/ вырос до: 104G ; 95G
> vanila Pg 9.1. Соответственно, ни сжатия, ни партиций.Ээээ... Апстрим как бы в следующем месяце 9.2 торжественно отправляет на свалку, а вы до сих пор на 9.1 хромаете.
>> vanila Pg 9.1. Соответственно, ни сжатия, ни партиций.
> Ээээ... Апстрим как бы в следующем месяце 9.2 торжественно отправляет на свалку,
> а вы до сих пор на 9.1 хромаете.И вам не кашлять.
2017-08-10 https://github.com/credativ/postgresql-lts/releases/tag/REL9...
2017-08-10 https://lists.debian.org/debian-lts-announce/2017/08/msg0000...
2017-08-12 https://debconf17.debconf.org/talks/54/
Это что за ссылки на левак? Смотрите в первоисточник: https://www.postgresql.org/about/news/1712/ а так-то ничто не мешает в боевую бросать работать 6.4. Будет очень винтажно-лампово.====
This is also the last update for the PostgreSQL 9.1 series as it is now end-of-life.
====Нет у PG такого понятия как LTS. Пять лет на каждую ветку и ни неделей больше - https://www.postgresql.org/support/versioning/
> Это что за ссылки на левак?
> Нет у PG такого понятия как LTS. Пять лет на каждую ветку
> и ни неделей больше - https://www.postgresql.org/support/versioning/Ну, пусть подают в суд за ТМ. Какие ко мне-то претензии. Ты не адвокат, нет?
"Суслика видишь? Нет, А он есть!"
Та же история: "у PG" lts-а нет, а Pg-9.1.24lts2 есть.
>>> С LA > 6 ? А вот пользователь открывает скрин с 5-7 графиками по 5-10 айтемов, да за год -- и ждёт, ждёт, ждёт. :) Да?Именно, с LA > 6. Иногда и > 12. Весьма здоровая установка, LA в данном случае (сотни поллеров и пингеров) - показатель совершенно не адекватный. Может отчасти потому, что всё крутится под XenServer, хз.
Основной показатель для меня то, что сервер при этом прекрасно отзывается на любые раздражители, а очередь Zabbix не растёт.
Там ещё и пачка тяжёлых отчётов крутится. Причём их запуск на собственно работу Zabbix не влияет, очередь не растёт.
К слову, графики вытащены на внешний сервер, в RRD, но и на самом Zabbix при необходимости генерятся быстро. Даже приоритеты мучать не пришлось.
Для расчёта нагрузки смотрю на конкретные perCPU показатели, они все в рамках нормы. Wait'а около 0, в основном user и system (сеть/диск). Running processes болтается в диапазоне 5-25, из-за тех же резво бегающих пингеров.
Чуть побольше топа для понимания ситуации с загрузкой:
top - 16:38:58 up 91 days, 21:06, 3 users, load average: 3.58, 5.34, 6.14
Tasks: 1426 total, 7 running, 1418 sleeping, 0 stopped, 1 zombie
%Cpu0 : 5.1 us, 3.7 sy, 0.0 ni, 90.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu1 : 8.8 us, 8.8 sy, 0.0 ni, 80.4 id, 0.0 wa, 0.0 hi, 1.4 si, 0.7 st
%Cpu2 : 4.5 us, 4.8 sy, 0.0 ni, 90.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.7 st
%Cpu3 : 7.8 us, 5.1 sy, 0.0 ni, 81.2 id, 5.5 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu4 : 23.3 us, 5.7 sy, 0.0 ni, 70.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu5 : 12.8 us, 4.7 sy, 0.0 ni, 82.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu6 : 5.1 us, 5.1 sy, 0.0 ni, 89.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu7 : 8.5 us, 3.9 sy, 0.0 ni, 78.2 id, 0.4 wa, 0.0 hi, 8.8 si, 0.4 st
%Cpu8 : 9.1 us, 5.7 sy, 0.0 ni, 84.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu9 : 55.5 us, 2.0 sy, 0.0 ni, 42.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu10 : 5.4 us, 4.7 sy, 0.0 ni, 89.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
%Cpu11 : 7.2 us, 3.8 sy, 0.0 ni, 84.0 id, 4.8 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem : 28555988 total, 1311012 free, 25342528 used, 1902448 buff/cache
KiB Swap: 1048572 total, 861052 free, 187520 used. 2216968 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26558 mysql 20 0 44.388g 0.011t 5360 S 72.4 41.8 211816:03 /usr/sbin/mysqld
24084 zabbix 20 0 565792 12464 7468 S 12.0 0.0 0:00.39 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
20440 zabbix 20 0 93332 936 724 S 6.2 0.0 896:49.85 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]
24161 zabbix 20 0 565792 12516 7484 S 4.5 0.0 0:00.14 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
23986 root 20 0 159340 3796 1644 R 2.3 0.0 0:00.78 top
24048 zabbix 20 0 565792 12940 7624 S 2.3 0.0 0:00.11 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
24072 zabbix 20 0 7984 708 584 S 1.9 0.0 0:00.07 /usr/sbin/fping -C3
24090 zabbix 20 0 7984 708 580 S 1.9 0.0 0:00.06 /usr/sbin/fping -C3
23982 zabbix 20 0 7984 724 584 R 1.6 0.0 0:00.15 /usr/sbin/fping -C3
24010 zabbix 20 0 7984 724 584 S 1.6 0.0 0:00.12 /usr/sbin/fping -C3
24019 zabbix 20 0 7984 720 584 S 1.6 0.0 0:00.11 /usr/sbin/fping -C3
24023 zabbix 20 0 7984 724 584 S 1.6 0.0 0:00.11 /usr/sbin/fping -C3
24036 zabbix 20 0 7984 720 584 S 1.6 0.0 0:00.09 /usr/sbin/fping -C3
24045 zabbix 20 0 7984 720 584 S 1.6 0.0 0:00.09 /usr/sbin/fping -C3
24049 zabbix 20 0 565792 12608 7472 S 1.6 0.0 0:00.12 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
24066 zabbix 20 0 7984 720 584 S 1.6 0.0 0:00.07 /usr/sbin/fping -C3
24068 zabbix 20 0 7984 720 584 S 1.6 0.0 0:00.07 /usr/sbin/fping -C3
24076 zabbix 20 0 7984 724 584 S 1.6 0.0 0:00.05 /usr/sbin/fping -C3
24079 zabbix 20 0 7984 724 584 S 1.6 0.0 0:00.05 /usr/sbin/fping -C3
24086 zabbix 20 0 565792 12680 7368 S 1.6 0.0 0:00.08 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
24147 zabbix 20 0 565792 12964 7672 S 1.6 0.0 0:00.05 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
24153 zabbix 20 0 565792 12680 7368 S 1.6 0.0 0:00.05 /opt/httpd/bin/httpd -f /etc/httpd/php70/httpd.conf -DFOREGROUND
24184 zabbix 20 0 7984 700 584 R 1.6 0.0 0:00.05 /usr/sbin/fping -C3
24222 zabbix 20 0 299940 13740 8660 R 1.6 0.0 0:00.05 /opt/php70/bin/php /usr/lib/zabbix/externalscripts/mass_sip_check.php -H 1
24224 zabbix 20 0 297860 13796 8720 R 1.6 0.0 0:00.05 /opt/php70/bin/php /usr/lib/zabbix/externalscripts/mass_sip_check.php -H 2
24226 zabbix 20 0 299408 12180 7732 R 1.6 0.0 0:00.05 /opt/php70/bin/php /usr/lib/zabbix/externalscripts/mass_sip_check.php -H 3
Держите нас в курсе.
Обязательно. Как только заплатите.
832 и 1480 - да, неплохо, у нас явно сопоставимые инсталляшки.Попробуйте MariaDB + TokuDB где-то на "небоевой", если есть возможность, вполне возможно, что вас устроит. Единственное что - при таких объёмах надо сразу закладывать партиционирование, а встроенный очищальщик через "DELETE" выключать нафиг.
---
По графикам , кстати, основной набор графиков у нас, как и говорил, на внешней системе - их просто очень много, там тысячи графиков, в RRD на 3 года. Данные в RRD сливаются с Zabbix, запросами в базу - таким образом разгружаем системы за счёт запроса данных оптом, а не по каждому элементу.
>> 8 шпинделей и 128 ГБ? А сколько у вас values/second?
> 2 zabbix-а на одинаковом железе
> NVPS(*): "1.12 K"; "1.26 K" //avg/month
> Required server performance, nvps: 832.11 ; 1480.132013-04-29 http://www.opennet.me/openforum/vsluhforumID13/848.html#1 "Давно сидим..."(ц)
а перед тем как раз разделил сервер пополам -
2013-04-11 NVPS "до": 770
2013-04-xx NVPS "после": 313 + 461
12 HDD, 32GB RAM.
Размер базы в пределах 1.5 TB.
Год назад реализовал partitioning на pg + pg_partman. Жить можно.
relation | size
-----------------------------------------------+----------
public.history_uint_p2017_05 | 114 GB
public.history_uint_p2017_05_itemid_clock_idx | 113 GB
public.history_uint_p2017_07 | 112 GB
public.history_uint_p2017_07_itemid_clock_idx | 111 GB
public.history_uint_p2017_06 | 109 GB
public.history_uint_p2017_06_itemid_clock_idx | 108 GB
public.history_uint_p2017_08 | 86 GB
public.history_uint_p2017_08_itemid_clock_idx | 85 GB
public.history_str_p2017_05 | 7883 MB
public.history_str_p2017_07 | 7035 MB
public.history_str_p2017_06 | 6861 MB
public.history_str_p2017_05_itemid_clock_idx | 6739 MB
public.history_p2017_05 | 6173 MB
public.history_p2017_05_itemid_clock_idx | 5986 MB
public.history_str_p2017_07_itemid_clock_idx | 5978 MB
public.history_p2017_07 | 5963 MB
> хотя бы помесячная разбивка historyМожет быть, Вы на своих серверах ещё и ротацию логов делаете?
> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?Про "не будет" написали. hi-end (ниже - про NVPS) клиенты должны плОтить за поддержку...
https://www.zabbix.org/irclogs/%23zabbix/%23zabbix...
+ 00:26 <Richlv> nvps.
00:26 <iooioo> 78.48
00:27 <Richlv> DO NOT USE PARTITIONING
+ 00:27 <Richlv> normally you need it if you scale above at least
500 nvps, probably 1k with 2.0 and more with 2.2
+ 00:33 <Richlv> maybe tune pgsql properly, that should do it
>> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?
> Про "не будет" написали. hi-end (ниже - про NVPS) клиенты должны плОтить
> за поддержку...Ну вот жаль, что не будет (: Хотя вроде как ранее мелькало, что сделают.
>>> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?
>> Про "не будет" написали. hi-end (ниже - про NVPS) клиенты должны плОтить
>> за поддержку...
> Ну вот жаль, что не будет (: Хотя вроде как ранее мелькало,
> что сделают.Вот всё Ж))) думаю, кто бы https://github.com/peak6/tab_tier пропатчил с ::DATE ключей на ::integer для history стало быть clock...
..."как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост, на котором"...
=
..."как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост, на котором"...
=тоже люблю эту цитату (: Спасибо за объяснения, приведенные вами выше.
За pg не скажу, но в мускуле работать с innodb таблицами жирнее 10 гигов - тяжковато. :-/ mysql partitioning неплохо так выручает.
> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?Что мешает использовать партицирование на уровне БД?
Мне не то чтобы мешает, но настораживает =древнегреческая= документация по этому поводу у Zabbix'a в части postgresql - howto выложено за 2014 год - https://www.zabbix.org/wiki/Docs/howto/postgresql_partitioni...
Мб, есть что-то посвежее или этого достаточно?
До выхода PG 10 указанная дока достаточна. Как выйдет десятый постгрес, можно будет думать про партицирование средствами БД без плясок с внешними скриптами.
> Мне не то чтобы мешает, но настораживает =древнегреческая= документация по этому поводу
> у Zabbix'a в части postgresql - howto выложено за 2014 год
> - https://www.zabbix.org/wiki/Docs/howto/postgresql_partitioni...
> Мб, есть что-то посвежее или этого достаточно?В принципе, достаточно, всё зависит от задач, имеющегося железа и объёмов данных.
Но я документацию по партицированию таблиц брал на сайте посгреса и сам писал скрипты, которые по крону дропают и создают партиции с индексами/ключами.
> Мне не то чтобы мешает, но настораживает =древнегреческая= документация по этому поводу
> у Zabbix'a в части postgresql - howto выложено за 2014 год
> - https://www.zabbix.org/wiki/Docs/howto/postgresql_partitioni...
> Мб, есть что-то посвежее или этого достаточно?3 года - это уже древнегреческая? Где вас таких стругают, дeбилов? Что там за 3 года изменилось в секционировании таблиц? Или тебе 15 лет и ты по возрасту своему судишь? Тогда да, 3 года - это 1/5 твоей жизни, а сам ты древний как гoвно мамонта.
Вы напрасно кипятитесь (:
Я, во-первых, осторожничаю, во-вторых, новое часто лучше старого, в-третьих, на форуме Zabbix'а встречаются разные =истории успеха= по секционированию в зависимости от версии Zabbix'a. Про то, что секционирование в postgresql связано с определенными костылями, здесь уже поясняли.Так что, пожалуйста, умерьте свой пыл.
>> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?
> Что мешает использовать партицирование на уровне БД?В Pg нет партициониорвания. В v10 вроде, да, но это ещё не релиз.
В MySQL мы не обучены, как-то хочется без Монти и Оракла пешком постоять.Древние описания, на которые ссылается коллега, -- страшнючие костыли с триггерами на insert-row или как их там. И страшничи они потому, что добавлять тормоза там, где и так уже под завязочку нагружено -- стрёмно. Ну, как поливать костёр бензином -- здорово, но вдруг "зацепит"... Хотя с drop-table-ами вместо housekeeper-ов... кто ж его знает.
>[оверквотинг удален]
>> Что мешает использовать партицирование на уровне БД?
> В Pg нет партициониорвания. В v10 вроде, да, но это ещё не
> релиз.
> В MySQL мы не обучены, как-то хочется без Монти и Оракла пешком
> постоять.
> Древние описания, на которые ссылается коллега, -- страшнючие костыли с триггерами на
> insert-row или как их там. И страшничи они потому, что добавлять
> тормоза там, где и так уже под завязочку нагружено --
> стрёмно. Ну, как поливать костёр бензином -- здорово, но вдруг
> "зацепит"... Хотя с drop-table-ами вместо housekeeper-ов... кто ж его знает.Нет никаких тормозов, всё зависит от того, как написана процедура триггера.
Например, моя для history:
\sf+ on_insert_history_function
CREATE OR REPLACE FUNCTION public.on_insert_history_function()
RETURNS trigger
LANGUAGE plpgsql
1 AS $function$
2 begin
3 execute 'insert into history_'||((new.clock/43200)*43200)||' values (($1).*)' using new;
4 return null;
5 end;
6 $function$Опять же, когда за половину суток набирается 20 гигов только данных, без drop table никак.
Housekeeper с его delete from ... where ... просто положит СУБД.
Так же не стоит забывать про время для вакуум и сложность обновления индексов при insert/update для больших таблиц.
Вполне возможно, кстати, что ваш "загружено под завязочку" с этим и связано.
>> Интересно, когда-нибудь mysql/postgresql partitioning будет в нем из коробки?
> Что мешает использовать партицирование на уровне БД?Ааааа. "из коробки" - это знач.разработчикам что мешает?? Вы с кем разговариваете? Наверное, я зря.
Назрело, нужно с базой что-то уже делать
хоть партиции, хоть Току движок пора разработчикам начинать поддерживать
> Назрело, нужно с базой что-то уже делать
> хоть партиции, хоть Току движок пора разработчикам начинать поддерживатьНудк, озвучьте им сумму.
А почему ьы разработчикам не озвучить?
https://www.zabbix.com/development_services
> Нудк, озвучьте им сумму.А за чё им платить-то?
TokuDB и без ихних кривых рук работает.
>> Нудк, озвучьте им сумму.
> А за чё им платить-то?
> TokuDB и без ихних кривых рук работает.То есть "искаропки" не надь? Отлично же, расходимся.
Не работает ибо внешние ключи в заббике, только InnoDB и MyISAM
> Не работает ибо внешние ключи в заббике, только InnoDB и MyISAMчё ты несёшь???
> Не работает ибо внешние ключи в заббике, только InnoDB и MyISAMАга, а это что:
MariaDB [zabbix]> show create table `history_uint` \G
*************************** 1. row ***************************
Table: history_uint
Create Table: CREATE TABLE `history_uint` (
`itemid` bigint(20) unsigned NOT NULL,
`clock` int(11) NOT NULL DEFAULT 0,
`value` bigint(20) unsigned NOT NULL DEFAULT 0,
`ns` int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=latin1 `COMPRESSION`=tokudb_snappy
PARTITION BY RANGE (`clock`)
(PARTITION `p2016_08_25` VALUES LESS THAN (1472158800) ENGINE = TokuDB,
PARTITION `p2016_08_26` VALUES LESS THAN (1472245200) ENGINE = TokuDB,
.....
PARTITION `p2017_08_24` VALUES LESS THAN (1503608400) ENGINE = TokuDB,
PARTITION `p2017_08_26` VALUES LESS THAN (1503781200) ENGINE = TokuDB)
1 row in set (0.00 sec)MariaDB [zabbix]> SELECT SUM(table_rows) FROM information_schema.tables WHERE table_name like 'history%'\G
*************************** 1. row ***************************
SUM(table_rows): 3735662783
1 row in set (0.01 sec)Но анонимам виднее, да.
Вот шедулер у mariadb местами работает через фигзнаеткак, это даа.
К хисторям нет внешних ключей.
А всё остальное держать в tokudb смысла не имеет.
Ура! Очень долго системы мониторинга не обновляются.
grafana prometheus?
https://github.com/firehol/netdata
> Ура! Очень долго системы мониторинга не обновляются.Не эта обновляется регулярно
А с радостью согласен
3.2 был прекрасен, надеюсь и этот релиз получился не хуже
Нахрена выпилили SQLite для zabbix-proxy?
А разве не для сервера выпилили?
Да, это у меня косоглазие развилось)
> Нахрена выпилили SQLite для zabbix-proxy?Эээ... Извините?? http://repo.zabbix.com/zabbix/3.4/rhel/7/x86_64/
[ ] zabbix-proxy-sqlite3-3.4.0-1.el7.x86_64.rpm 2017-08-22 12:48 618K
>> Выполнение удаленных команд и скриптов через Zabbix-проксинадеюсь это отключаемо ...
>>> Выполнение удаленных команд и скриптов через Zabbix-прокси
> надеюсь это отключаемо ...Ну, Криптографию-то они сделали. Когда-нибудь и Аутентификацию [удалённых действий] смогут!
> Ну, Криптографию-то они сделали. Когда-нибудь и Аутентификацию [удалённых действий] смогут!Уже сделано.
По умолчанию это выключено.
>>> Выполнение удаленных команд и скриптов через Zabbix-прокси
> надеюсь это отключаемо ...Это самая ожидаемая, если не сказать вожделенная, фишка
Для полного счастья не хватает выполнения команд на исключительно активных агентах
в 3.6 или около того обещали nosql.плюс заббиксу просто необходимо добавить поддержку нахождения сервисов через популярные сервис дискавери ну и вообще ввести понятие сервиса, который может скейлиться вширь и обратно. иначе прометеусы и прочая шняга их переплюнет скоро.
> в 3.6 или около того обещали nosql.
> плюс заббиксу просто необходимо добавить поддержку нахождения сервисов через популярные
> сервис дискавери ну и вообще ввести понятие сервиса, который может скейлиться
> вширь и обратно. иначе прометеусы и прочая шняга их переплюнет скоро.Как же вы достали со своими и банными микросервисами. Да, давайте теперь всех будем вширь масштабировать и сервисы дискаверить. Даже тех, у кого этот zabbix в виртуалке работает и мониторит 10 компьютеров и 20 сервисов. Ставьте себе этот ваш прометеус с покером и блудницами и отстаньте уже от zabbix'а.
> присутствуют серьёзные баги. Но система в целом класснаяАга. То, что делается в ipMon'е на одном экране, здесь настраивается в десяти местах путём нащёлкивания мышОй.
Это что надо в голове иметь, что бы сравнить кастрюлю с вилкой?
Что для вас кастрюля, а что вилка?Читаем:
ipMonitor - Monitor IT Infrastructure Performance
Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution
>> присутствуют серьёзные баги. Но система в целом классная
> Ага. То, что делается в ipMon'е на одном экране, здесь настраивается в
> десяти местах путём нащёлкивания мышОй.Да, книгой тоже подтираться неудобно - страницы твёрдые и отрываются с трудом. То ли дело туалетная бумага. Правда тексты полезные на ней не печатают, да и читать было бы не удобно - рулон постоянно рвался бы.
Вышел в свет Zabbix 3.4.1 RC1 с исправлением проблем, обнаруженных в 3.4.0. Подробности: https://www.zabbix.com/rn3.4.1rc1
Что-то они там жрут эдакое в последнее время, похоже. 3.4.1rc1 у них в меню в релнотах значится, как 3.4.0rc1 xD
> Вышел в свет Zabbix 3.4.1 RC1 с исправлением проблем, обнаруженных в 3.4.0.
> Подробности: https://www.zabbix.com/rn3.4.1rc1Ну и да, не вышел. Отменён, видимо что-то где-то ещё надо править, чтобы этот блокер пофиксить.
Тем временем 3.4.0 не отозван, и даже никаких варнингов. Релиз менеджмент, майнфилд стайл.
>> Вышел в свет Zabbix 3.4.1 RC1 с исправлением проблем, обнаруженных в 3.4.0.anomymous, 10:31 , [U]26-Авг-17[/U]:
> Ну и да, не вышел. Отменён, видимо что-то где-то ещё надо править,
> чтобы этот блокер пофиксить.https://www.zabbix.com/rn3.4.1rc2 ""[U]25 August 2017[/U]""
> Тем временем 3.4.0 не отозван, и даже никаких варнингов. Релиз менеджмент, майнфилд
> стайл.
Вот и релиз подоспел
https://www.zabbix.com/rn3.4.1