У Zabbix вчера была рассылка с новостями. Давно ничего не писал про него, потому что новостей особо не было. Буднично проходили новости об очередных обновлениях и конференциях в разных странах. А в этот раз они немного подробностей дали по поводу новой версии 7.0, у которой уже 3-я альфа вышла. Так что работа идёт и релиз всё ближе.
Команда Zabbix показала новые виджеты дашборда, которые будут в новой версии. Можете оценить на прикреплённой картинке. Впечатления двоякие. Вроде бы прикольно, но выглядит как-то колхозно всё это. Не получается им к какому-то единому стилю прийти из-за того, что обновления сильно растянуты. Сначала интерфейс обновили, потом частично графики в виджетах, потом новые виджеты стали добавлять, при этом часть графиков так и осталась в старом дизайне, которому уже около 10-ти лет. Мне кажется, им стоило один раз собраться и в каком-то релизе выкатить полное обновление интерфейса и графиков. А то это так и будет вечно продолжаться.
Помимо новых визуализаций, появится виджет с топом триггеров. Я так понял, что это виджет из отчёта 100 наиболее активных триггеров (в русском интерфейсе). Он показывает триггеры, которые чаще всего меняли своё состояние (срабатывали) за указанный период времени. Кстати, удобный отчёт, который позволяет подредактировать триггеры, которые слишком часто срабатывают.
Из тех обновлений, что точно будут в 7.0, отмечу:
◽увеличится поддержка версий до MySQL 8.1 MariaDB 11
◽появится шаблон для мониторинга за PostgreSQL через ODBC
◽появится шаблон для Cisco SD-WAN
◽появится возможность выполнения удалённых команд при активных проверках
◽некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
◽увеличат возможности обработки в aggregation functions
Вот и всё наиболее значимое, что было объявлено в последних трех релизах альфы. Пока как-то негусто изменений. По обещанному обновлению модуля инвентаризации, поддержке сторонних TSDB, асинхронному сбору данных не сделано ничего в тех версиях, что опубликованы.
#zabbix
Команда Zabbix показала новые виджеты дашборда, которые будут в новой версии. Можете оценить на прикреплённой картинке. Впечатления двоякие. Вроде бы прикольно, но выглядит как-то колхозно всё это. Не получается им к какому-то единому стилю прийти из-за того, что обновления сильно растянуты. Сначала интерфейс обновили, потом частично графики в виджетах, потом новые виджеты стали добавлять, при этом часть графиков так и осталась в старом дизайне, которому уже около 10-ти лет. Мне кажется, им стоило один раз собраться и в каком-то релизе выкатить полное обновление интерфейса и графиков. А то это так и будет вечно продолжаться.
Помимо новых визуализаций, появится виджет с топом триггеров. Я так понял, что это виджет из отчёта 100 наиболее активных триггеров (в русском интерфейсе). Он показывает триггеры, которые чаще всего меняли своё состояние (срабатывали) за указанный период времени. Кстати, удобный отчёт, который позволяет подредактировать триггеры, которые слишком часто срабатывают.
Из тех обновлений, что точно будут в 7.0, отмечу:
◽увеличится поддержка версий до MySQL 8.1 MariaDB 11
◽появится шаблон для мониторинга за PostgreSQL через ODBC
◽появится шаблон для Cisco SD-WAN
◽появится возможность выполнения удалённых команд при активных проверках
◽некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
◽увеличат возможности обработки в aggregation functions
Вот и всё наиболее значимое, что было объявлено в последних трех релизах альфы. Пока как-то негусто изменений. По обещанному обновлению модуля инвентаризации, поддержке сторонних TSDB, асинхронному сбору данных не сделано ничего в тех версиях, что опубликованы.
#zabbix
Много раз в заметках упоминал про сервис по рисованию различных схем draw.io. Судя по отзывам, большая часть использует именно его в своей работе. Схемы из draw.io относительно легко можно наложить на мониторинг на базе Grafana. Если вы с ней работаете, то особых проблем не должно возникнуть. Если нет, то не скажу, что настройка будет простой. Но в целом, ничего особенного. Мне когда надо было, освоил Grafana за пару дней для простого мониторинга.
Речь пойдёт про плагин к Графане — flowcharting. Он есть в официальном списке плагинов на сайте, так что с его установкой вопросов не должно возникнуть. Сразу скажу, что с помощью этого плагина можно нарисовать схему и связать через через Графану его с мониторингом на Zabbix.
Последовательность настройки схемы с помощью плагина следующая:
1️⃣ Вы берёте схему в draw.io и выгружаете её в xml формате.
2️⃣ Создаёте dashboard в Grafana и добавляете туда панель flowcharting.
3️⃣ Загружаете xml код схемы в эту панель и получаете визуализацию.
4️⃣ Сопоставляете объекты на схеме с объектами в Графане, сразу переименовывая их так, чтобы было удобно.
5️⃣ Дальше к объектам можно добавлять метрики, как это обычно делается в Grafana. Соответственно, в качестве Data Source можно использовать тот же Zabbix.
Сразу приведу ссылки, которые помогут вам быстро начать действовать, если плагин заинтересовал.
⇨ Страница плагина в Grafana
⇨ Инструкция по настройке
▶️ Плейлист Flowcharting Grafana (29 видео)
Все видео в плейлисте на португальском языке. Можно включить перевод субтитров на русский. В целом, там важно смотреть, как и что он делает. А что говорит, не так важно. В плейлисте полностью раскрыта тема построения мониторинга с помощью этого плагина. В том числе и в связке с Zabbix (26-й ролик).
Плагин давно не обновлялся. Я не уверен, что он нормально заработает на свежих версиях, хотя, по идее должен. Я до сих пор пользуюсь 7-й версией. И там он работает.
#мониторинг #zabbix #grafana
Речь пойдёт про плагин к Графане — flowcharting. Он есть в официальном списке плагинов на сайте, так что с его установкой вопросов не должно возникнуть. Сразу скажу, что с помощью этого плагина можно нарисовать схему и связать через через Графану его с мониторингом на Zabbix.
Последовательность настройки схемы с помощью плагина следующая:
1️⃣ Вы берёте схему в draw.io и выгружаете её в xml формате.
2️⃣ Создаёте dashboard в Grafana и добавляете туда панель flowcharting.
3️⃣ Загружаете xml код схемы в эту панель и получаете визуализацию.
4️⃣ Сопоставляете объекты на схеме с объектами в Графане, сразу переименовывая их так, чтобы было удобно.
5️⃣ Дальше к объектам можно добавлять метрики, как это обычно делается в Grafana. Соответственно, в качестве Data Source можно использовать тот же Zabbix.
Сразу приведу ссылки, которые помогут вам быстро начать действовать, если плагин заинтересовал.
⇨ Страница плагина в Grafana
⇨ Инструкция по настройке
▶️ Плейлист Flowcharting Grafana (29 видео)
Все видео в плейлисте на португальском языке. Можно включить перевод субтитров на русский. В целом, там важно смотреть, как и что он делает. А что говорит, не так важно. В плейлисте полностью раскрыта тема построения мониторинга с помощью этого плагина. В том числе и в связке с Zabbix (26-й ролик).
Плагин давно не обновлялся. Я не уверен, что он нормально заработает на свежих версиях, хотя, по идее должен. Я до сих пор пользуюсь 7-й версией. И там он работает.
#мониторинг #zabbix #grafana
После публикации про мониторинг Newrelic, где можно наблюдать за каждым процессом в системе в отдельности, решил прикинуть, а как подобное реализовать в Zabbix. Итоговое решение по всем метрикам пока не созрело, но контроль использования памяти уже реализовал. Решил поделиться своими наработками. Может кто-то подскажет другие пути решения задачи.
Прикинул, как снимать метрики. Тут особо не пришлось ломать голову, так как сразу родилась идея с утилитами jc и jq, которые я давно знаю. Взял вывод ps, обернул его в json с помощью jc, отсортировал по метрике rss и вывел top 10:
Понравилось, как получилось. Закинул эти данные в отдельный айтем заббикса, но дальше тупик. Не понимаю, как это всё оформить в правила автообнаружения, чтобы автоматически создавались айтемы с именем процесса в названии, чтобы потом можно было для этих айтемов делать выборку с данными об rss из этого json.
Напомню, что у Zabbix свой определённый формат, иерархия и логика работы правил автообнаружения. Чтобы автоматически создавать айтемы, нужно подать на вход json следующего содержания:
Такую строку он сможет взять, на основе переданных значений
Взял вот такую конструкцию, которая анализирует вывод ps, формирует удобный список, который можно отсортировать с помощью sort и взять top 10 самых нагруженных по памяти процессов и в итоге вывести только их имена:
Далее обернул её в скрипт для формирования json для автообнаружения в Zabbix.
top_mem.discovery.sh:
На выходе получаем то, что нам надо:
Сразу же готовим второй скрипт, который будет принимать в качестве параметра имя процесса и отдавать его память (rss).
top_mem.sh:
Проверяем:
Добавляем в конфиг zabbix-agent:
Теперь идём на сервер, создаём шаблон, правило автообнаружения, прототип айтема, графика и сразу делаем панель.
Получилось удобно и функционально. Все нюансы не смог описать, так как лимит на длину поста. Нерешённый момент - особенности реализации LLD не позволяют автоматом закидывать все процессы на один график. Без API не знаю, как это сделать. Текущее решение придумал и опробовал за пару часов.
#zabbix
Прикинул, как снимать метрики. Тут особо не пришлось ломать голову, так как сразу родилась идея с утилитами jc и jq, которые я давно знаю. Взял вывод ps, обернул его в json с помощью jc, отсортировал по метрике rss и вывел top 10:
# ps axu | jc --ps -p | jq 'sort_by(.rss)' | jq .[-10:]..................................] { "user": "servera+", "pid": 1584266, "vsz": 348632, "rss": 109488, "tty": null, "stat": "S", "start": "19:41", "time": "0:28", "command": "php-fpm: pool serveradmin.ru", "cpu_percent": 0.5, "mem_percent": 2.7 }, { "user": "mysql", "pid": 853, "vsz": 2400700, "rss": 782060, "tty": null, "stat": "Ssl", "start": "Aug28", "time": "365:40", "command": "/usr/sbin/mariadbd", "cpu_percent": 1.8, "mem_percent": 19.4 }]..........................................Понравилось, как получилось. Закинул эти данные в отдельный айтем заббикса, но дальше тупик. Не понимаю, как это всё оформить в правила автообнаружения, чтобы автоматически создавались айтемы с именем процесса в названии, чтобы потом можно было для этих айтемов делать выборку с данными об rss из этого json.
Напомню, что у Zabbix свой определённый формат, иерархия и логика работы правил автообнаружения. Чтобы автоматически создавать айтемы, нужно подать на вход json следующего содержания:
[{"{#COMMAND}":"php-fpm7.4"},{"{#COMMAND}":"mariadbd"}.........,{"{#COMMAND}":"smtpd"}]Такую строку он сможет взять, на основе переданных значений
{#COMMAND} создать айтемы. Как мою json от ps приспособить под эти задачи, я не знал. Для этого можно было бы сделать обработку на javascript прямо в айтеме, но мне показалось это слишком сложным для меня путём. Решил всё сделать по старинке на bash.Взял вот такую конструкцию, которая анализирует вывод ps, формирует удобный список, который можно отсортировать с помощью sort и взять top 10 самых нагруженных по памяти процессов и в итоге вывести только их имена:
# ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'Далее обернул её в скрипт для формирования json для автообнаружения в Zabbix.
top_mem.discovery.sh:
#!/bin/bashTOPPROC=`ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'`JSON=$(for i in ${TOPPROC[@]}; do printf "{\"{#COMMAND}\":\"$i\"},"; done | sed 's/^\(.*\).$/\1/')printf "["printf "$JSON"printf "]"На выходе получаем то, что нам надо:
[{"{#COMMAND}":"php-fpm7.4"},........{"{#COMMAND}":"smtpd"}]Сразу же готовим второй скрипт, который будет принимать в качестве параметра имя процесса и отдавать его память (rss).
top_mem.sh:
#!/bin/bashps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | grep $1 | awk '{print $1}'Проверяем:
# ./top_mem.sh mariadbd780840Добавляем в конфиг zabbix-agent:
UserParameter=top.mem.discovery, /bin/bash /etc/zabbix/scripts/top_mem.discovery.shUserParameter=top.mem[*], /bin/bash /etc/zabbix/scripts/top_mem.sh $1Теперь идём на сервер, создаём шаблон, правило автообнаружения, прототип айтема, графика и сразу делаем панель.
Получилось удобно и функционально. Все нюансы не смог описать, так как лимит на длину поста. Нерешённый момент - особенности реализации LLD не позволяют автоматом закидывать все процессы на один график. Без API не знаю, как это сделать. Текущее решение придумал и опробовал за пару часов.
#zabbix
Провёл аудит своих систем мониторинга Zabbix в связке с Grafana. У меня работают версии LTS 5.0 и 6.0. Промежуточные обычно только для теста ставлю где-то в одном месте. Разбирался в первую очередь с базовым шаблоном для Linux серверов.
У Zabbix есть особенность, что обновление сервера не касается самих шаблонов, а они тоже регулярно обновляются. У этого есть как плюсы, так и минусы. Плюс в том, что всё стабильно и никаких непредвиденных обновлений не будет. Если вы вносили правки в шаблон, они останутся и всё будет работать как раньше с новым сервером. А минус в том, что эти обновления надо проводить вручную.
В процессе аудита понял, что у меня на серверах используются 3 разных версии шаблона. На каких-то серверах все 3 одновременно. У этого есть много причин. Например, у вас есть какая-то удалённая площадка, подключенная по VPN. Я для неё делаю копию стандартного шаблона и в триггерах прописываю зависимость от состояния VPN, чтобы мне не сыпался спам из уведомлений, когда отвалится связь с площадкой. Когда таких изменений много, поддержание актуальной версии шаблонов становится непростой задачей.
Для серверов 6-й версии взял за основу шаблон Linux by Zabbix agent, не забыв указать ветку репозитория 6.0. Методика обновления может быть разной. Безопаснее всего текущий установленный шаблон переименовать, добавив, к примеру, к названию приписку OLD. Потом импортировать новый и вручную накидывать его на хосты, заменяя старый шаблон. Это немного муторно, так как ручной труд.
Проще всего всё сделать автоматом. Отцепить старый шаблон от хостов с удалением всех метрик и соответственно истории к ним. Это обнуляет всю историю метрик по данному шаблону. И потом накатить сверху новый шаблон. Минимум ручной работы, так как нет конфликтов слияния, но потеря всей истории. Если вам не критично, делайте так. Можно не затирая историю применять новый шаблон, перезаписывая старый, но там иногда возникают проблемы, которые нужно опять же вручную разрешать.
У меня хостов не так уж и много, я вручную всё сделал, отключая старый шаблон и подключая новый.
Единообразие шаблонов для Linux позволило сделать единый для всех серверов дашборд в Grafana, куда я вынес наиболее актуальные на мой взгляд метрики, чтобы можно было быстро оценить состояние хоста. Пример, как это выглядит, на картинке. Сам дашборд выложил на сайт, можно скачать. В шаблоне можно выбрать Datasource и конкретный хост. То есть с его помощью можно смотреть все подключенные хосты с такой же версией шаблона Linux. Это намного быстрее и удобнее, чем делать то же самое в самом Zabbix. По настройке Grafana с Zabbix у меня есть отдельная статья.
Ну и в завершении напомню, что обновление шаблонов приносит очень много мелких хлопот на местах, так как опять потребуется калибровка под конкретные хосты. Где-то не нужны какие-то триггеры, например на swap, на отсутствие свободной оперативы, где её и не должно быть, на скорость отклика дисков, потому что они медленные и т.д. Приходится макросы поправлять, триггеры отключать, какие-то изменения в шаблоны и хосты добавлять с зависимостями. Все tun интерфейсы почему-то определяются со скоростью 10 Мегабит в секунду, что приводит к срабатыванию триггеров на загрузку интерфейса. Пока не понял, как это решить, не отключая триггеры.
Из-за всех этих хлопот я всегда сильно откладываю обновление мониторингов, которые в целом и так работают и устраивают. Но всё равно бесконечно отставать от актуальной версии нельзя, приходится обновляться. Вечером будет заметка по обновлению Grafana.
#zabbix #grafana
У Zabbix есть особенность, что обновление сервера не касается самих шаблонов, а они тоже регулярно обновляются. У этого есть как плюсы, так и минусы. Плюс в том, что всё стабильно и никаких непредвиденных обновлений не будет. Если вы вносили правки в шаблон, они останутся и всё будет работать как раньше с новым сервером. А минус в том, что эти обновления надо проводить вручную.
В процессе аудита понял, что у меня на серверах используются 3 разных версии шаблона. На каких-то серверах все 3 одновременно. У этого есть много причин. Например, у вас есть какая-то удалённая площадка, подключенная по VPN. Я для неё делаю копию стандартного шаблона и в триггерах прописываю зависимость от состояния VPN, чтобы мне не сыпался спам из уведомлений, когда отвалится связь с площадкой. Когда таких изменений много, поддержание актуальной версии шаблонов становится непростой задачей.
Для серверов 6-й версии взял за основу шаблон Linux by Zabbix agent, не забыв указать ветку репозитория 6.0. Методика обновления может быть разной. Безопаснее всего текущий установленный шаблон переименовать, добавив, к примеру, к названию приписку OLD. Потом импортировать новый и вручную накидывать его на хосты, заменяя старый шаблон. Это немного муторно, так как ручной труд.
Проще всего всё сделать автоматом. Отцепить старый шаблон от хостов с удалением всех метрик и соответственно истории к ним. Это обнуляет всю историю метрик по данному шаблону. И потом накатить сверху новый шаблон. Минимум ручной работы, так как нет конфликтов слияния, но потеря всей истории. Если вам не критично, делайте так. Можно не затирая историю применять новый шаблон, перезаписывая старый, но там иногда возникают проблемы, которые нужно опять же вручную разрешать.
У меня хостов не так уж и много, я вручную всё сделал, отключая старый шаблон и подключая новый.
Единообразие шаблонов для Linux позволило сделать единый для всех серверов дашборд в Grafana, куда я вынес наиболее актуальные на мой взгляд метрики, чтобы можно было быстро оценить состояние хоста. Пример, как это выглядит, на картинке. Сам дашборд выложил на сайт, можно скачать. В шаблоне можно выбрать Datasource и конкретный хост. То есть с его помощью можно смотреть все подключенные хосты с такой же версией шаблона Linux. Это намного быстрее и удобнее, чем делать то же самое в самом Zabbix. По настройке Grafana с Zabbix у меня есть отдельная статья.
Ну и в завершении напомню, что обновление шаблонов приносит очень много мелких хлопот на местах, так как опять потребуется калибровка под конкретные хосты. Где-то не нужны какие-то триггеры, например на swap, на отсутствие свободной оперативы, где её и не должно быть, на скорость отклика дисков, потому что они медленные и т.д. Приходится макросы поправлять, триггеры отключать, какие-то изменения в шаблоны и хосты добавлять с зависимостями. Все tun интерфейсы почему-то определяются со скоростью 10 Мегабит в секунду, что приводит к срабатыванию триггеров на загрузку интерфейса. Пока не понял, как это решить, не отключая триггеры.
Из-за всех этих хлопот я всегда сильно откладываю обновление мониторингов, которые в целом и так работают и устраивают. Но всё равно бесконечно отставать от актуальной версии нельзя, приходится обновляться. Вечером будет заметка по обновлению Grafana.
#zabbix #grafana
В процессе актуализации мониторинга обновил также и Grafana до последней 10-й версии. Расскажу, как это делаю я. Это не руководство к действию для вас, а только мой персональный опыт, основанный на том, что у меня немного дашбордов и Data sources.
Всю ценность в Grafana у меня представляют только настройки источников данных и несколько дашбордов, поэтому прорабатывать перенос данных или бэкап нет никакого смысла. Если что-то меняется, то я просто выгружаю json и сохраняю новую версию. А так как это происходит нечасто, меня такая схема устраивает.
Соответственно и обновление у меня выглядит максимально просто и быстро:
1️⃣ Выгружаю Data sources и Dashboards в json.
2️⃣ Обновляю Docker образ grafana:latest и запускаю новый контейнер с ним.
3️⃣ Переключаю на Nginx Proxy трафик на новый контейнер.
4️⃣ Захожу в него и импортирую свои данные.
Если что-то забыл, то заглядываю в старый контейнер, который остаётся некоторое время. Как это всё реализуется технически, описано в моей старой статье:
⇨ Обновление Grafana
В плане экспорта и импорта данных не поменялось ничего. Она полностью актуальна и по ней я переехал с 7-й версии на 10-ю. В конце статьи представлены примеры некоторых моих дашбордов. Они хоть и изменились с того времени, но это уже детали.
Предвещая вопросы, отвечу, что Grafana использую исключительно для более удобной и простой визуализации данных с Zabbix Server. А также для объединения на одном дашборде информации с разных серверов. Это актуально для триггеров. У меня есть обзорный дашборд с активными триггерами со всех своих серверов. Ну и дополнительно есть несколько дашбордов с другой необходимой мне информации. Один из таких дашбордов с обзорной информацией о сервере я показал в утренней заметке.
Ниже картинка с обзором триггеров.
#grafana #zabbix
Всю ценность в Grafana у меня представляют только настройки источников данных и несколько дашбордов, поэтому прорабатывать перенос данных или бэкап нет никакого смысла. Если что-то меняется, то я просто выгружаю json и сохраняю новую версию. А так как это происходит нечасто, меня такая схема устраивает.
Соответственно и обновление у меня выглядит максимально просто и быстро:
1️⃣ Выгружаю Data sources и Dashboards в json.
2️⃣ Обновляю Docker образ grafana:latest и запускаю новый контейнер с ним.
3️⃣ Переключаю на Nginx Proxy трафик на новый контейнер.
4️⃣ Захожу в него и импортирую свои данные.
Если что-то забыл, то заглядываю в старый контейнер, который остаётся некоторое время. Как это всё реализуется технически, описано в моей старой статье:
⇨ Обновление Grafana
В плане экспорта и импорта данных не поменялось ничего. Она полностью актуальна и по ней я переехал с 7-й версии на 10-ю. В конце статьи представлены примеры некоторых моих дашбордов. Они хоть и изменились с того времени, но это уже детали.
Предвещая вопросы, отвечу, что Grafana использую исключительно для более удобной и простой визуализации данных с Zabbix Server. А также для объединения на одном дашборде информации с разных серверов. Это актуально для триггеров. У меня есть обзорный дашборд с активными триггерами со всех своих серверов. Ну и дополнительно есть несколько дашбордов с другой необходимой мне информации. Один из таких дашбордов с обзорной информацией о сервере я показал в утренней заметке.
Ниже картинка с обзором триггеров.
#grafana #zabbix
Немного актуальных новостей про Zabbix, которым я постоянно пользуюсь.
1️⃣ В версии 6.0.21 вернулся баг веб проверок. Не работают проверки сайтов, отличных от кодировки UTF-8. У меня есть несколько старых сайтов в WINDOWS-1251. Они нормально работают и трогать их лишний раз не хочется для перекодирования. Для них теперь не работает проверка контрольной строки в коде сайта. Подобный глюк уже был раньше и его вылечили очередным обновлением. Но сейчас уже вышла версия 6.0.22 и этот глюк там остался. Кому актуально, не обновляйтесь с 6.0.20.
2️⃣ Стала доступна 7.0.0alpha5. Релиз всё ближе. Я уже делал несколько заметок по теме новой 7-й LTS версии (1, 2), ключевые новшества там перечислены. В этой альфе анонсировали возможность настройки таймаутов для каждого айтема отдельно, новый виджет pie chart и новые возможности взаимодействия виджетов, возможность с помощью разных правил LLD делать привязку к одной и той же группе хостов, поддержку mariadb 11.1, добавили шаблон для Acronis Cyber Protect Cloud и много других доработок.
Как я и предполагал ранее, выход 7-й версии перенесли с 2023 года на Q1 2024.
3️⃣ У Wireshark в версии 4.2.0 появилась встроенная поддержка протокола передачи данных Zabbix. Можно перехватывать и анализировать трафик от агентов и прокси. Это поможет выполнить дебаг каких-то проблем со связностью и доставкой информации. Подробно работа с Wireshark описана в статье в официальном блоге Zabbix. Поддерживается в том числе и сжатый, и TLS трафик, при условии, что доступны сессионные ключи. Как это на практике должно работать, не совсем понимаю. Автор обещает выпустить отдельную заметку по разбору TLS трафика.
Вообще, это классная штука. Теперь можно перехватить траффик и заглянуть внутрь пакетов, чтобы понять, какая информация идёт на сервер и почему там это вызывает ошибку или вообще не принимается. А то иногда банально не понятно по тексту ошибки, в чём конкретно проблема. А в wireshark можно увидеть в том числе и полное содержание метрики, которая отправляется.
#zabbix
1️⃣ В версии 6.0.21 вернулся баг веб проверок. Не работают проверки сайтов, отличных от кодировки UTF-8. У меня есть несколько старых сайтов в WINDOWS-1251. Они нормально работают и трогать их лишний раз не хочется для перекодирования. Для них теперь не работает проверка контрольной строки в коде сайта. Подобный глюк уже был раньше и его вылечили очередным обновлением. Но сейчас уже вышла версия 6.0.22 и этот глюк там остался. Кому актуально, не обновляйтесь с 6.0.20.
2️⃣ Стала доступна 7.0.0alpha5. Релиз всё ближе. Я уже делал несколько заметок по теме новой 7-й LTS версии (1, 2), ключевые новшества там перечислены. В этой альфе анонсировали возможность настройки таймаутов для каждого айтема отдельно, новый виджет pie chart и новые возможности взаимодействия виджетов, возможность с помощью разных правил LLD делать привязку к одной и той же группе хостов, поддержку mariadb 11.1, добавили шаблон для Acronis Cyber Protect Cloud и много других доработок.
Как я и предполагал ранее, выход 7-й версии перенесли с 2023 года на Q1 2024.
3️⃣ У Wireshark в версии 4.2.0 появилась встроенная поддержка протокола передачи данных Zabbix. Можно перехватывать и анализировать трафик от агентов и прокси. Это поможет выполнить дебаг каких-то проблем со связностью и доставкой информации. Подробно работа с Wireshark описана в статье в официальном блоге Zabbix. Поддерживается в том числе и сжатый, и TLS трафик, при условии, что доступны сессионные ключи. Как это на практике должно работать, не совсем понимаю. Автор обещает выпустить отдельную заметку по разбору TLS трафика.
Вообще, это классная штука. Теперь можно перехватить траффик и заглянуть внутрь пакетов, чтобы понять, какая информация идёт на сервер и почему там это вызывает ошибку или вообще не принимается. А то иногда банально не понятно по тексту ошибки, в чём конкретно проблема. А в wireshark можно увидеть в том числе и полное содержание метрики, которая отправляется.
#zabbix
