Комментарии 31
> А к zabbix можно прикрутить модную Graphana и мониторить красиво.
Статья отменная, но против Графаны у меня лично есть один, но весомый аргумент: Графана использует Zabbix API, который: а) Создаёт весьма неэффективные запросы в таблицы history и склонен ещё и отваливаться в таких ситуациях по таймауту; б) написан местами просто из рук вон плохо на языке PHP — и каждый тяжёлый вызов API тормозит базу данных.
Для того, чтобы Графана не аффектила сам мониторинг, нужно написать для неё читалку из кеширующего history бэкенда, в свою очередь обновляющего кэш запросами в базу напрямую, либо — нужно пользоваться возможностью записи history в elastic search, но тогда не очень понятно, зачем вообще будет нужна Garafana. Инструмент визуализации мониторнга, который аффектит мониторинг — это плохо, и если Grafana до сих пор использует Zabbix API, то именно так и происходит.
Относительно же красоты — собственно, сам Zabbix-«фронтенд» в 4.x станет полностью векторным, так что тем более глубокого смысла в графане не вижу.
Статья отменная, но против Графаны у меня лично есть один, но весомый аргумент: Графана использует Zabbix API, который: а) Создаёт весьма неэффективные запросы в таблицы history и склонен ещё и отваливаться в таких ситуациях по таймауту; б) написан местами просто из рук вон плохо на языке PHP — и каждый тяжёлый вызов API тормозит базу данных.
Для того, чтобы Графана не аффектила сам мониторинг, нужно написать для неё читалку из кеширующего history бэкенда, в свою очередь обновляющего кэш запросами в базу напрямую, либо — нужно пользоваться возможностью записи history в elastic search, но тогда не очень понятно, зачем вообще будет нужна Garafana. Инструмент визуализации мониторнга, который аффектит мониторинг — это плохо, и если Grafana до сих пор использует Zabbix API, то именно так и происходит.
Относительно же красоты — собственно, сам Zabbix-«фронтенд» в 4.x станет полностью векторным, так что тем более глубокого смысла в графане не вижу.
Но справедливости ради, запросы к zabbix-api это не сама grafana, а плагин к ней — по сути сторонний, еще до кучи у которого уведомления прикручены непонятно как. И в целом связка zabbix+grafana выглядит избыточной. В боевой системе мониторинга, особенно когда идет опрос большого числа узлов (ну и когда не нужны красивые картинки для менеджмента) наверное лучше либо использовать штатные графики заббикса (может не такие красивые, но зачем там красота) либо другую систему хранения, например прометей.
плагин уже умеет лазить в postgres базу заббикса сам
У нас, например, MySQL на весьма масштабной инсталляции и десяток профессиональных DBA'шников, специализирующихся на MySQL. Т.е. как бы для графаны мы точно не стали бы переходить на PostgreSQL. Особенно учитывая тот факт, что красивые векторные графики — это одно из основных целевых направлений развития Zabbix (направление неверное, на мой взгляд, но кто меня спрашивает).
Чтобы вас хорошенько похаять дам с начала полезной инфы.
Обновляемся до заббикс 3.4 или выше(вы уже).
Потом включаем удалённое выполнение команд, шифрование до агента(если есть прокси, то и до прокси). Можете не включать, тогда вас смело могут вздрючить выполнив rce(найдут способ).
Для LLD нахождения дисков вызываем lsblk с форматом вывода json через system.run `lsblk какие то ключи`
Создаём айтем system.run `cut /path/to/[#lld_blk]/stat`
Потом создаём зависимые айтемы и парсим таблицу.
При таком подходе вот этого не будет:
Пример как надо делать: github.com/AlexGluck/ZBX_NGINX
Теперь хай.
А юзерпараметры в одно место можете засунуть, когда их надо на 2к машин раскидать это лютое УГ. Мониторингом надо рулить на сервере мониторинга, а не по машинам скакать с авоськой тухлых реализаций.
Обновляемся до заббикс 3.4 или выше(вы уже).
Потом включаем удалённое выполнение команд, шифрование до агента(если есть прокси, то и до прокси). Можете не включать, тогда вас смело могут вздрючить выполнив rce(найдут способ).
Для LLD нахождения дисков вызываем lsblk с форматом вывода json через system.run `lsblk какие то ключи`
Создаём айтем system.run `cut /path/to/[#lld_blk]/stat`
Потом создаём зависимые айтемы и парсим таблицу.
При таком подходе вот этого не будет:
Но есть и недостатки:
Некоторые параметры необходимо вычислять делением дельты одного на дельту другого, причем не простой, а временной (скорости). В zabbix это сделать можно, но это будут не одновременные запросы, как если бы это делал сложный скрипт, а отношение последних значений, что в принципе не совсем верно, но в нашем случае довольно точно.
Пример как надо делать: github.com/AlexGluck/ZBX_NGINX
Теперь хай.
А юзерпараметры в одно место можете засунуть, когда их надо на 2к машин раскидать это лютое УГ. Мониторингом надо рулить на сервере мониторинга, а не по машинам скакать с авоськой тухлых реализаций.
Вариант конечно, но и я могу ваш вариант «обхаить» зачем system.run `cut /path/to/[#lld_blk]/stat` когда можно просто: vfs.file.contents['/path/to/[#lld_blk]/stat']
Насчет цитированного — увы будет ибо, делить надо не одновременные значения а дельту… Хотя возможно зависимые элементы и отработают одновременно — в такие моменты заббикса не углублялся.
В оправдание себя скажу — в статью не попало, но реальная срока в моем скрипте посложнее — ибо суммирует значения сразу с кучки дисков, причем в качестве параметра получает маску названий алиасов (несколько устройств разом). Кроме того мне не нужен мониторинг всей тьмы дисков. Разделы побиты на группы в соответствии с назначением и мониторятся именно группы. Но это лютый кастом и лишнее для статьи.
И да любые файлики userparams легко раскидываются на 2к машин разными системами деплоймента типа Ansible например. Ну и потом не всегда можно вот так взять и обновить заббикс на 3.4.
Насчет цитированного — увы будет ибо, делить надо не одновременные значения а дельту… Хотя возможно зависимые элементы и отработают одновременно — в такие моменты заббикса не углублялся.
В оправдание себя скажу — в статью не попало, но реальная срока в моем скрипте посложнее — ибо суммирует значения сразу с кучки дисков, причем в качестве параметра получает маску названий алиасов (несколько устройств разом). Кроме того мне не нужен мониторинг всей тьмы дисков. Разделы побиты на группы в соответствии с назначением и мониторятся именно группы. Но это лютый кастом и лишнее для статьи.
И да любые файлики userparams легко раскидываются на 2к машин разными системами деплоймента типа Ansible например. Ну и потом не всегда можно вот так взять и обновить заббикс на 3.4.
Хотя возможно зависимые элементы и отработают одновременно
Говорю с полной уверенностью, зависимые работают одновременно, проверял. Там логика, что мастер айтем получает текст, а зависимые во время получения мастер айтемом применяют предобработку и тем самым парсят нужные данные.
vfs.file.contents['/path/to/[#lld_blk]/stat'] так даже лучше
И да любые файлики userparams легко раскидываются на 2к машин разными системами деплоймента типа Ansible например.На практике нефига не раскидываются из-за сложности учёта где какие параметры нужно мониторить, либо превращают список добавленных параметров в непотребно огромный. Ну и расскажите мне с какой скоростью можно обновлять на таком количестве хостов эти параметры? Это занимает прилично времени и кроме мониторинга есть и другие задачи для которых необходимо выделять ресурсы.
Вот про группировку бы подробнее… У меня вот тоже куча дисков. И шаблоны чтобы группировать приходится скриптами делать…
А у вас как?
А у вас как?
Извиняюсь за паузу…
В примере есть скрипт дискавери… По сути его задача прочитать на хосте конфиг в котором написано: блочные устройства с именами в /dev/mapper/XXX* это диски индексатора, /dev/mapper/YYY* это диски BLOB, /dev/mapper/ZZZ* это разное логгирование.
Соответственно на такую группу устройств рисуется одна группа метрик которые прибиты к своему application
Затем в самом скрипте метрики чуть более сложный однострочник вида:
Который по идее суммирует информацию по блочным устройствам, которые смонтированы куда надо.
Ну и плюсом собираются метрики по отдельным дискам дабы разобраться что к чему.
Но на самом деле, меня эта схема не очень устраивает потому как учитываются «средние значения», а при этом существует разный профиль например для индексатора крайне важен iops поэтому диски работают параллельно — и там не должно быть перекосов по нагрузке. А для BLOB iops не важны — софт работает на строго последовательный доступ и там диски работают так же последовательно и то что один пашет, а остальные простаивают — это норма. Что то можно учесть кастомными триггерами для приложения, а что то нет.
В примере есть скрипт дискавери… По сути его задача прочитать на хосте конфиг в котором написано: блочные устройства с именами в /dev/mapper/XXX* это диски индексатора, /dev/mapper/YYY* это диски BLOB, /dev/mapper/ZZZ* это разное логгирование.
Соответственно на такую группу устройств рисуется одна группа метрик которые прибиты к своему application
Затем в самом скрипте метрики чуть более сложный однострочник вида:
UserParameter=custom.vfs.dev.read.sectors[*],realpath '$1' | xargs -I{} basename {} | uniq | xargs -I {} cat /sys/class/block/{}/stat | awk '{n += $$3}; END{print n}' Который по идее суммирует информацию по блочным устройствам, которые смонтированы куда надо.
Ну и плюсом собираются метрики по отдельным дискам дабы разобраться что к чему.
Но на самом деле, меня эта схема не очень устраивает потому как учитываются «средние значения», а при этом существует разный профиль например для индексатора крайне важен iops поэтому диски работают параллельно — и там не должно быть перекосов по нагрузке. А для BLOB iops не важны — софт работает на строго последовательный доступ и там диски работают так же последовательно и то что один пашет, а остальные простаивают — это норма. Что то можно учесть кастомными триггерами для приложения, а что то нет.
Возможность запускать команды удаленно это немного опасно как минимум.
Во-первых удалённые команды выполняются всё-таки неким shell'ом, а никак не сервером мониторинга, нет ничего особо выдающегося в том, что агент может забрать STDOUT команды.
Во-вторых — во всех нормальных компаниях (из известных мне — просто во всех), конфигурацией управляют итак централизованно, через штуки типа Puppet и Ansible
Ну и в-третьих — а вы точно проверяли, что все ваши агенты НЕ принимают удалённые команды без шифрования? Проверьте — будете удивлены. Мы на всех агентах эту «возможность» отключили.
Во-вторых — во всех нормальных компаниях (из известных мне — просто во всех), конфигурацией управляют итак централизованно, через штуки типа Puppet и Ansible
Ну и в-третьих — а вы точно проверяли, что все ваши агенты НЕ принимают удалённые команды без шифрования? Проверьте — будете удивлены. Мы на всех агентах эту «возможность» отключили.
На самом деле меня сейчас больше интересует возможность использования для препроцессинга скриптов исполняемых на самом сервере заббикса.
Например такая вот проблема:
Приложение (например elastic) имеет api диагностики через HTTP json. B заббикс может разбирать json. Но увы парсер путей там тупой до безобразия. А в диагности нашего приложения используются массивы, а элементы определяются не позицией, а наличием ключа с определенным значением (например:
На наше счастье названия модулей «удобные» и мы написали несложненький php скриптец, который делает из такой простыни, простыню плоскую:
и до метрики можно добраться плоским zabbix парсером: first_module.metrics.metric
Но вы правы таскать скрипты по серверам неудобно, и хотелось бы иметь такой скрипт например на сервере самого заббикса, ну или на прокси.
Есть ли какие то варианты расширения самого заббикс сервера?
Например такая вот проблема:
Приложение (например elastic) имеет api диагностики через HTTP json. B заббикс может разбирать json. Но увы парсер путей там тупой до безобразия. А в диагности нашего приложения используются массивы, а элементы определяются не позицией, а наличием ключа с определенным значением (например:
"modules" : [
{"module" : "first_module" ,
"metrics": { "metric" : "value" }
},
{"module" : "second_module" ,
"metrics": { "metric" : "value" }
} ]
На наше счастье названия модулей «удобные» и мы написали несложненький php скриптец, который делает из такой простыни, простыню плоскую:
"first_module" : {
"metrics": { "metric" : "value" } },
"second_module": {
"metrics": { "metric" : "value" } }
и до метрики можно добраться плоским zabbix парсером: first_module.metrics.metric
Но вы правы таскать скрипты по серверам неудобно, и хотелось бы иметь такой скрипт например на сервере самого заббикса, ну или на прокси.
Есть ли какие то варианты расширения самого заббикс сервера?
Насколько разумно мониторить всё описанное выше на виртуальных машинах (KVM, ESXi)? На что стоит обратить внимание, какие могут быть нюансы?
Простите, может быть глупый вопрос: а насколько подобное тестирование на целевой машине влияет на ее производительность? Если я правильно понимаю, для более-менее адекватного тестирования надо записать а потом прочитать достаточно большой объем данных, а на это требуются какие-то ресурсы.
Данные тесты не создают какой то дополнительной нагрузки (ну кроме самого получения метрик) и используют реальные данные и реальную среду для оценок.
Мой опыт показывает, что только тестирование на реальной машине, в реальной конфигурации, с реальными данными может показать насколько вашсферический конь в вакууме тест в лаборатории соотноситься с реальной кобылой в сарае нагрузкой.
И как раз только в реальных условиях вы сможете протестировать на реальном объеме записываемых данных с реальными ресурсами.
А то как бывает обычно: мы берем какое то хранилище у которого: кеш у дисков, кеш у raid контроллера, навороченное ssd кеширование, плюс кеш операционной системы и еще кеш внутри приложения. Еще до кучи супер пупер навороченные алгоритмы префетчинга и прочее. За все эти кеши и алгоритмы мы заплатили денежки прямо или опосредованно.
И начинаем тестировать его, так чтобы все эти кеши забились и перестали работать. Т.е. тестируя мы заведомо выходим на режимы в котором наша система работать не будет а все эти навороты ненужны. Ну и какая цена такому тестированию?
Но по другому мы действовать не можем ибо, а кто нам скажет с какой вероятностью мы будем попадать в эти кеши. А еще у которых есть 100500 настоек самого кеша, плюс в десять раз больше настроек всего остального на них влияющих начиная от конфигураций файловой системы, опций форматирования и монтирования, различных LVM.
И только наблюдая за системой «в реальной среде обитания» вы сможете сказать: «да кеши работают» или «нет не работают» или да — форма графиков в реальной среде совпадают с аналогичными в тестовой, значит скорее всего методика тестирования верна.
Мой опыт показывает, что только тестирование на реальной машине, в реальной конфигурации, с реальными данными может показать насколько ваш
И как раз только в реальных условиях вы сможете протестировать на реальном объеме записываемых данных с реальными ресурсами.
А то как бывает обычно: мы берем какое то хранилище у которого: кеш у дисков, кеш у raid контроллера, навороченное ssd кеширование, плюс кеш операционной системы и еще кеш внутри приложения. Еще до кучи супер пупер навороченные алгоритмы префетчинга и прочее. За все эти кеши и алгоритмы мы заплатили денежки прямо или опосредованно.
И начинаем тестировать его, так чтобы все эти кеши забились и перестали работать. Т.е. тестируя мы заведомо выходим на режимы в котором наша система работать не будет а все эти навороты ненужны. Ну и какая цена такому тестированию?
Но по другому мы действовать не можем ибо, а кто нам скажет с какой вероятностью мы будем попадать в эти кеши. А еще у которых есть 100500 настоек самого кеша, плюс в десять раз больше настроек всего остального на них влияющих начиная от конфигураций файловой системы, опций форматирования и монтирования, различных LVM.
И только наблюдая за системой «в реальной среде обитания» вы сможете сказать: «да кеши работают» или «нет не работают» или да — форма графиков в реальной среде совпадают с аналогичными в тестовой, значит скорее всего методика тестирования верна.
Используем SAR, в принципе проще и без наворотов. Шаблон подпил коллега, репа тут github.com/abstractiontensor/sar-zabbix-template
Так как эти метрики очень зависят друг от друга, то не зная все нельзя сделать правильные выводы.
Эх, еще бы и кейсы из практики по параметрам… :)
Например. резко выросла утилизация raid массива, при этом упала пропускная способность, что указало выход из строя диска.
или изменение параметров ОС/ФС/контроллеров с… на… дало прирост параметра на Х %
Сложно говорить про какие то конкретные вещи, но из последнего:
и другое. На самом деле на практике вдруг замечаешь, что резко изменилась форма графиков и просто начинаешь разбираться что случилось. Там уж и dmesg в помощь. И не всегда проблема бывает в вашем софте.
Был случай когда при обновлении не вытерся старый бинарник — он в принципе не очень мешал, а просто подтекал и кушал память потом его OOM прибивал, он перезапускался и так по кругу. На графиках это выглядело как рост операций ввода вывода от софта в виде пилы. Софт перекопали, проблем не нашли — в итоге оказалось что софтина выкушивала кеш операционной системы, что конечно приводило к изменению количества запросов.
- рост IOPS при тех же скоростях записи — признак фрагментации файловой системы
- утилизация дисковой подсистемы строго следует за пропускной способностью, и например составляет 100% для 6,2 гигабита в секунду — уперлись в пропускную способность FC 8gbps линка. Добавляем второй линк и настраиваем мультипас — утилизация падает в 2 раза
- утилизация дисковой подсистемы выросла пи этом iops и скорость записи та же — глючил линк на FC на одном из каналов
- покрутили queue/max_sectors_kb со штатных 512 до 4096 — утилизация упала, но максимально много не значит лучше, при 8192 — утилизация стала расти
и другое. На самом деле на практике вдруг замечаешь, что резко изменилась форма графиков и просто начинаешь разбираться что случилось. Там уж и dmesg в помощь. И не всегда проблема бывает в вашем софте.
Был случай когда при обновлении не вытерся старый бинарник — он в принципе не очень мешал, а просто подтекал и кушал память потом его OOM прибивал, он перезапускался и так по кругу. На графиках это выглядело как рост операций ввода вывода от софта в виде пилы. Софт перекопали, проблем не нашли — в итоге оказалось что софтина выкушивала кеш операционной системы, что конечно приводило к изменению количества запросов.
Еще эти графики полезны например при настройках СУБД типа Postgres и оценках работы например индексов. Т.е. же самые shared_buffers у Postgres или извечные терки — выносить ли pg_xlog на отдельные диски, а avtovacuum ли мешает работе базы.
Рейды, mdadm например, тоже можно мониторить без юзерпараметров, забирать значения через vfs.file.contents и потом предобработкой парсить регулярками.
А из полезных советов могу накинуть ещё один:
Когда вы подключаете в заббикс новый хост, делать это удобно вашей системой управления конфигурацией, например ансибл, ведь это всегда одинаково. На хост навешиваете дефолтный шаблон, который в себе содержит ллд правила для обнаружения использования важных сервисов, типа рейда и следовательно подключает или отключает шаблон мониторинга рейда и\или вашего приложения. Пример, смотрим наличие mdadm, списка процессов и по ним определяем какие сервисы запущены. Для постгреса подключаем шаблон постгреса, для нджиникса свой и т.д. К сожалению заббикс настраивать крайне не удобно для больших конфигураций, и совет выше это хак для упрощения. А уж для контейнерных и микросервисных архитектур его я бы не стал использовать.
Дойдут руки, всем напихаю дефолтные шаблоны феншуйные. ^^
А из полезных советов могу накинуть ещё один:
Когда вы подключаете в заббикс новый хост, делать это удобно вашей системой управления конфигурацией, например ансибл, ведь это всегда одинаково. На хост навешиваете дефолтный шаблон, который в себе содержит ллд правила для обнаружения использования важных сервисов, типа рейда и следовательно подключает или отключает шаблон мониторинга рейда и\или вашего приложения. Пример, смотрим наличие mdadm, списка процессов и по ним определяем какие сервисы запущены. Для постгреса подключаем шаблон постгреса, для нджиникса свой и т.д. К сожалению заббикс настраивать крайне не удобно для больших конфигураций, и совет выше это хак для упрощения. А уж для контейнерных и микросервисных архитектур его я бы не стал использовать.
Дойдут руки, всем напихаю дефолтные шаблоны феншуйные. ^^
В современном мире найти решение получения данных не проблема, проблема правильно понять данные.
Если вернуться к дискам, то каждые n-секунд врятли кто то будет мониторить состояние raid и прогон теста на badblock каждый день тоже врятли делают. А вот утилизация диска мониторится постоянно.
Вот и хотелось бы расширить анамнез различных проблем базируясь минимум данных.
Если вернуться к дискам, то каждые n-секунд врятли кто то будет мониторить состояние raid и прогон теста на badblock каждый день тоже врятли делают. А вот утилизация диска мониторится постоянно.
Вот и хотелось бы расширить анамнез различных проблем базируясь минимум данных.
НЛО прилетело и опубликовало эту надпись здесь
:) прощаю — у меня не было цели предложить кому-то решение. Скорее так — просто поделиться конкретным опытом. Более того я не считаю, что заббикс — правильный или наиболее подходящий инструмент для этой задачи. Просто подвернулся под руку, и возникла задача как сделать именно это и именно с заббиксом. Ну плюсом спровоцировать дискуссию из которой можно было бы почерпнуть что то новое. Вон например в комментариях выше уже были варианты как сделать тоже самое, но проще. То есть считайте профит какой то уже получен.
А в чем смысл вычислять производную от iops и util метрику *_svctime, если ядро предоставляет информацию о суммарном затреченном времени на все дисковые операции (в
В случае с *_svctime цифра может не иметь ничего общего с реальным latency. Наример: за 1 секунду было сделано 5 параллельных r_io опреаций, каждая выполнялась 1 секунду. Реальный средний r_latency (и посчитанный исходя из 5ти секунд read ticks) — 1 секунда, r_svctime же будет 1/5 = 0.2 секунды.
/sys/block/sdX/stat поля read ticks, write ticks или в /proc/diskstat аналоничные по смыслу поля). Делим на количество io в еденицу времени и получаем честный средний latency (await).В случае с *_svctime цифра может не иметь ничего общего с реальным latency. Наример: за 1 секунду было сделано 5 параллельных r_io опреаций, каждая выполнялась 1 секунду. Реальный средний r_latency (и посчитанный исходя из 5ти секунд read ticks) — 1 секунда, r_svctime же будет 1/5 = 0.2 секунды.
Что то или я не до конца уловил вашу мысль или вы не совсем поняли, но вроде вы и говорите про то же самое:
В моем примере делится: количество тиков за интервал измерения (по сути это есть утилизация записью) на количество операций за этот же интервал (количество параллельных записей). Т.е. как и в вашем примере так и будет:
Пусть выполнялось:
5 одновременных операций.
каждая за 100 msec (реальный латенси 1 операции )
интервал опросов заббиксом 1 секунда. тогда…
write_util будет: 100 мсек * 5 операций / 1 секунду = 0.5 = 50 % (100 * 5 = 500 тиков это колонка w_ticks (ms))
а w_svctime: 500 / 1 секунду / (5 операций / 1 секунду )…
собственно технический делитель от забикса «1 секунда» сократится и получим:
100 * 5 / 5 == 100ms или искомыя средняя latency.
В моем примере делится: количество тиков за интервал измерения (по сути это есть утилизация записью) на количество операций за этот же интервал (количество параллельных записей). Т.е. как и в вашем примере так и будет:
Пусть выполнялось:
5 одновременных операций.
каждая за 100 msec (реальный латенси 1 операции )
интервал опросов заббиксом 1 секунда. тогда…
write_util будет: 100 мсек * 5 операций / 1 секунду = 0.5 = 50 % (100 * 5 = 500 тиков это колонка w_ticks (ms))
а w_svctime: 500 / 1 секунду / (5 операций / 1 секунду )…
собственно технический делитель от забикса «1 секунда» сократится и получим:
100 * 5 / 5 == 100ms или искомыя средняя latency.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг производительности дисковой подсистемы при помощи zabbix и block stat