​​На днях проходил очередной масштабный Zabbix Summit 2023 на английском языке. Сейчас уже выложили полную информацию по нему, в том числе видеозаписи и презентации докладов. Всё это на отдельной странице:

⇨ https://www.zabbix.com/ru/events/zabbix_summit_2023

Было много всяких событий, даже не знаю, о чём конкретно рассказать. В принципе, вы можете сами по программе мероприятия посмотреть то, что вам больше всего интересно и перейти на запись выступления или посмотреть презентацию.

Приведу некоторые интересные факты из выступления основателя компании Алексея Владышева:

🔹Компания Zabbix непрерывно растёт. Сейчас это 150 сотрудников в компании и 250 партнёрских компаний по всему миру.

🔹Zabbix старается покрывать все уровни инфраструктуры от железа до бизнес метрик.

🔹Zabbix следует современным требованиям к безопасности: интеграция с hashicorp vault, 2FA, SSO, Токены к API, работа агентов без прав root и т.д.

🔹Анонсировал изменение в 7-й версии, про которое я не слышал ранее. Раньше было одно соединение на один poller, теперь pollers будут поддерживать множественные соединения, буквально тысячи на каждый poller. Также рассказал про другие нововведения:
◽Хранение метрик для увеличения быстродействия в памяти zabbix-proxy, а не в только в базе, как сейчас.
◽Новые айтемы будут сразу же забирать метрики после создания, в течении минуты, а не через настроенные в них интервалы. Если интервал был час, то час и нужно было ждать до первого обновления, если не сделать его принудительно.

🔹В выступлении Алексей упомянул, что сейчас Zabbix не поддерживает OpenTelemetry, Tracing, полноценный сбор логов. В конце этого блока он сказал, что они будут это исправлять. Было бы неплохо, но хз когда всё это появится.

В целом, мне кажется, что Zabbix как-то забуксовал в развитии. Сейчас в продуктах упор идёт на простоту и скорость настройки. Берём Prometheus, ставим на хост Exporter, забираем все метрики, идём в Grafana, берём готовый дашборд, коих масса под все популярные продукты. И в течении 10 минут у нас всё готово. С Zabbix так не получится. Коллекции публичных дашбордов вообще нет. Мне прям грустно становится, когда настраиваешь какой-то мониторинг и приходится самому вручную собирать дашборд. Это небыстрое занятие.

Графики с виджетами как-то коряво и разномастно смотрятся, даже новые. Нет единства стиля. В дашбордах одни графики через виджеты, в панелях и просто графиках другие. Надо всё это как-то к единообразию привести и дать возможность импорта и экспорта всех этих сущностей, а не только полных шаблонов. Шаблоны это больше про метрики, а визуализации могут быть совсем разные в зависимости от задач. Надо их разделить и создать на сайте раздел с дашбордами, как это есть у Grafana.

Что ещё было интересно из саммита:
🟢 Internal Changes and Improvements in Zabbix 7.0 - Внутренние изменения в работе Zabbix, которые будут в 7-й версии.
🟢 Monitoring Kubernetes Cluster with an External Zabbix Server - Про то, как заббиксом мониторят Kubernetes.
🟢 Logs Go LLD - тут знатные костыли автообнаружения на bash и regex, приправленное перлом.
🟢 Tips and Tricks on using useful features of Zabbix in large scale environments - много интересных примеров и конкретики при построении мониторинга в большой распределённой инфраструктуре.
🟢 Implementing TimescaleDB on large Zabbix without downtime - миграция очень большой базы Zabbix с обычного формата на TimescaleDB без остановки на обслуживание и перенос, и без потери метрик.

#zabbix

​​Решил не откладывать в долгий ящик и перевести один из веб серверов на Angie. Как и обещали разработчики, с конфигами Nginx полная совместимость. Установил Angie и скопировал основной конфиг сервиса, а также виртуальных хостов. Виртуальные хосты вообще не трогал, а основной конфиг немного подредактировал, изменив в include пути с /etc/nginx на /etc/angie. Ещё параметр pid изменил с /var/run/nginx.pid на /run/angie.pid. Больше ничего не менял.

Остановил Nginx, запустил Angie. Никаких проблем. Всё мгновенно подхватилось новым веб серверов. Простой пару секунд.

Заметку пишу не про переход, а про мониторинг. Согласно документации настроил передачу метрик сервера через API, веб консоль и метрики Prometheus. С прометеусом пока не разбирался, веб консоль просто для красоты включил, а внимание уделил API. Настроил шаблон Zabbix для сбора метрик через API. Сделал по аналогии с Nginx, но кое-что изменил по своему усмотрению. Шаблон можно скачать тут. Это первая версия. Немного попользуюсь и надеюсь, что оформлю всё это в полноценную статью с какими-то правками, которые наверняка накопятся по мере использования.

В шаблоне используются 2 макроса:
◽{$STATUS_HOST} - ip адрес сервера
◽{$STATUS_PATH} - часть урла для API.
У меня доступ к API настроен по IP, а полный путь выглядит так: http://1.2.3.4/status/. Соответственно, первый макрос - 1.2.3.4, второй - /status/.

На картинке ниже метрики, которые я посчитал полезными и добавил в шаблон. Триггера сделал три: не отвечает внешний порт веб сервера, нет ни одного процесса angie на сервере, не поступают данные от API в мониторинг. Также добавил 4 графика и оформил всё в панель. Картинку панели покажу в комментариях.

#angie #zabbix

​​Один из читателей канала давно мне скидывал информацию про скрипт для Zabbix, который отправляет оповещения с графиками в Telegram. Он его сам написал. У меня как-то затерялась эта информация и только сейчас дошли руки посмотреть. Я проверил, всё работает нормально. В целом, таких скриптов немало, я сам пользуюсь и в статье рассказываю про настройку. Тут отличие в том, что он полностью на Bash, в то время как я использую решения, написанные на Python. Вариант с башем лично для мне выглядит более привлекательным.

В принципе, всё описание есть в репозитории и в отдельной статье от автора. Я по ним без проблем настроил. Если раньше уведомления в Telegram не настраивали, то, возможно, придётся повозиться. Там надо бота создать, с токеном ничего не напутать и т.д. Судя по количеству комментариев с вопросами к моей статье по этой теме, у многих не получается быстро с этим разобраться.

Отмечу несколько моментов, с которыми сам столкнулся.
1️⃣ Скрипт по умолчанию пишет лог файл в директорию /usr/lib/zabbix/alertscripts, владельцем которой является root, соответственно у скрипта нет прав на запись туда. Либо сделайте владельцем пользователя Zabbix, либо вынесите лог куда-то в другое место.

2️⃣ Второй момент - когда будете добавлять новый способ оповещений (media type), не забудьте добавить туда шаблоны. По умолчанию они не создаются. Я забыл об этом и не сразу догадался, почему ошибку при отправке через этот тип сообщений получаю.

3️⃣ Для айтема должен существовать график, чтобы он прилетел в оповещения. Иначе графика не будет. Если что-то не будет получаться, то почитайте комментарии к статье. Там автор подробно объясняет нюансы и показывает, как дебажить отсутствие графиков

#zabbix

​​Zabbix последнее время не сильно радует новостями или какими-то событиями. Как-будто у компании проблемы. Раньше регулярно были рассылки с множеством событий: обновления, статьи в блоге, ролики в ютубе, новые шаблоны, вебинары и т.д.

Сейчас и количество рассылок сократилось, и количество событий в них. В блоге давно не вижу ничего интересного, на ютубе тоже в основном пусто. Вчера была рассылка, там единственное интересное событие - одно из обновлений в новой версии 7.0.

✔️ Рассказывают, что реализовали возможность передавать параметры к скриптам прямо из веб интерфейса. Если я правильно понял, то можно добавить какой-то скрипт, к примеру, для перезапуска службы. В случае необходимости, можно через веб интерфейс к нему обратиться и передать что-то в качестве параметра. Например, адрес сервера и/или имя службы. И скрипт выполнит перезапуск на целевом сервере. Подробного описания нет. Свою интерпретацию сделал на основе вот этих строк: "The latest alpha release introduces the ability to pass custom input to frontend scripts, enabling many new host administration scenarios directly from the Zabbix frontend." и картинки, что будет в конце публикации.

✔️ Посмотрел список остальных нововведений. Понравился новый тип проверки net.dns.perf. С его помощью можно проверять DNS записи. Это полезная штука, так как зачастую изменение записей может обрушить всю систему. За этим важно следить.

✔️ Ещё из полезного - добавили возможность пушить метрики через Zabbix API. Раньше для этого можно было только zabbix_sender использовать. Теперь можно без него обойтись. Это позволит быстро и просто передавать метрики из других систем через их вебхуки. В будущем обещают виджет на дашборд для ввода метрик вручную. Это, кстати, было бы полезно. Сейчас нет простых способов передать вручную в айтем значение.
▶️ Zabbix 7.0 - History Push API Feature
В видео в том числе можно увидеть новый интерфейс в Zabbix 7.0. Всё левое меню существенно изменилось.

✅ Также вышла новая версия Zabbix Server 6.0.25, в которой наконец-то исправили баг, когда не работали веб проверки сайтов в кодировке, отличной от utf8. В комментариях кто-то писал, что тоже заметил эту проблему. Так вот теперь её исправили. У меня наконец-то заработали проверки старых сайтов в кодировке Windows-1251. Раньше Битрикс по умолчанию в ней устанавливался и до сих пор успешно работает и обновляется с этой кодировкой.

У Zabbix изменились сроки поддержки не LTS версий, то есть версий X.2 и X.4. Теперь это будет 6 месяцев полной поддержки и 6 месяцев исправлений критичных багов и проблем с безопасностью. То есть поддержка будет 1 год со времени выхода нового релиза. Напомню, что у LTS версии поддержка 5 лет. Я обычно на LTS версиях сижу. Редко обновляю на промежуточные релизы. Только если интересно потестить какие-то нововведения.
⇨ Zabbix Life Cycle and Release Policy.

Ждём версию 7.0. Пока что только alpha, потом ещё несколько месяцев будут beta выходить. К весне, наверное, зарелизятся.

#zabbix

​​Расскажу про очень простой и быстрый способ мониторить размер какой-нибудь директории или файла на сервере с помощью Zabbix. Способов реализации может быть очень много. Предлагаю наиболее простой, который подойдёт для директорий, где проверку надо делать не часто, и она относительно быстро выполнится. В пределах настроенных таймаутов для агента.

Смотрим размер директории в килобайтах:

# du -s /mnt/backup | awk '{print $1}'
57004

Эту цифру надо передать на Zabbix Server. Для этого открываем конфиг zabbix_agentd.conf и добавляем туда:

UserParameter=backup.size, du -s /mnt/backup | awk '{print $1}'

Перезапускаем агента и проверяем работу метрики:

# systemctl restart zabbix-agent
# zabbix_agentd -t backup.size
backup.size                  [t|57004]

Отлично, метрика работает. Идём на Zabbix Server, создаём новый шаблон или добавляем айтем напрямую в нужный хост (лучше всегда делать шаблоны). Указываем:

◽Имя: DIR Size /mnt/backup (указываете любое)
◽Тип: Zabbix agent
◽Ключ: backup.size
◽Тип информации: целое положительное
◽Единицы измерения: B (латинская B - байты)

Единица измерения байты указана для того, чтобы Zabbix понимал, что речь идёт о размере данных. Тогда он будет автоматически их переводить на графиках в килобайты, мегабайты, гигабайты, что удобно. Единственный нюанс, у нас данные приходят не в байтах, а килобайтах, поэтому нам нужно добавить множитель 1024. Для этого переходим в настройках айтема на вкладку Предобработка и добавляем шаг:

◽Пользовательский множитель: 1024

Сохраняем айтем. Теперь шаблон можно прикрепить к хосту, где настраивали агента и проверить, как работает. При необходимости можно сделать триггер на этот размер. Не знаю, за чем конкретно вам нужно будет следить, за превышением или наоборот за уменьшением размера, или за изменениями в день. В зависимости от этого настраивается триггер. Там всё интуитивно и по-русски, не трудно разобраться.

По аналогии можно следить за размером отдельного файла. Для этого достаточно указать именно его, а не директорию:

# du -s /mnt/backup/daily/mysql/daily_mysql_2024-03-01_16h13m_Friday.sql.gz
530004

Ну и точно так же добавляем потом в UserParameter новый айтем, настраиваем его на сервере.

Если в UserParameter написать примерно так:

UserParameter=file.size[*], du -s $1 | awk '{print $1}'

То в качестве имени файла можно передавать значения из ключа айтема, который настраивается на сервере. Примерно так будет выглядеть ключ:

file.size[/mnt/backup/daily/mysql/daily_mysql_2024-03-01_16h13m_Friday.sql.gz]

Вот это значение из квадратных скобок приедет на агента вместо * в квадратные скобки, и вместо $1 в консольную команду.. То есть не придётся для каждого файла настраивать UserParameter. Звёздочка будет разворачиваться в переданное значение.

Такой простой механизм передачи в Zabbix любых значений с сервера. Это открывает безграничные возможности для мониторинга всего, что только можно придумать.

Отдельно отмечу, что если директорий у вас много, там много файлов, и частота проверок приличная, то сажайте эти подсчёты на cron, записывайте результаты в файл, а в Zabbix забирайте уже из файла. Так будет надёжнее и проще для сервера мониторинга. Не будет его нагружать лишними соединениями и ожиданиями результата.

Если у кого-то есть вопросы по Zabbix, можете позадавать. Если что, подскажу. Особенно если надо придумать мониторинг какой-нибудь нестандартной метрики. Я чего только не мониторил с ним. От давления жидкости в контуре с контроллера по Modbus протоколу до числа подписчиков в Telegram группе.

#zabbix

​​Заглядывал на днях на один из серверов 1С, который настраивал примерно 3 года назад. Купил туда бюджетные серверные диски KINGSTON SEDC500M 960G в RAID1. Стоят они очень умеренно, а по ресурсу значительно преворсходят десктопные модели. Раньше там каждые год-два меняли SSD. В принципе, хватало производительности, но при интенсивной записи во время дампов баз всё подтормаживало. С этими стало намного лучше.

Я, собственно, зашёл проверить ресурс и статистику по записи. Просто любопытно стало. Решил и с вами поделиться цифрами. У меня все метрики SMART собирал Zabbix, а основные выведены на дашборд. Так что удобно оценить разом.

Основные метрики, за которыми следил:

▪️ Flash_Writes_GiB - количество сырых данных, записанных в NAND flash.
▪️ Lifetime_Writes_GiB - количество записанных данных, прошедших через ATA интерфейс.
▪️ Lifetime_Reads_GiB - количество прочитанных данных.
▪️ SSD_Life_Left - остаток ресурса жизни SSD.

По записи для обоих дисков получились примерно одинаковые значения:

sdb: ID 233 Flash_Writes_GiB 515.61 TB
sdb: ID 241 Lifetime_Writes_GiB 431.86 TB

sdc: ID 233 Flash_Writes_GiB 516.49 TB
sdc: ID 241 Lifetime_Writes_GiB 432.73 TB

Сырых данных на флеш пишется значительно больше, чем переданных на диск реальных, прошедших через интерфейс передачи данных. Если я правильно понимаю, это связно с тем, что данные записываются не как есть, а в зависимости от кратности ячеек памяти, куда происходит запись. То есть реально на диск пишется больше данных, чем передаётся.

А вот по чтению данные сильно разнятся:

sdb: ID 242 Lifetime_Reads_GiB 205.54 TB
sdc: ID 242 Lifetime_Reads_GiB 148.85 TB

С одного диска данные читались на четверть чаще, чем с другого. Рейд организован средствами mdadm. То есть обычный софтовый RAID1.

Ну и по ресурсу там запас ещё огромный. SMART показывает 92%. За последние два года изменение с 97% до 92%. Если смарт не врёт, то скорее заменят сервер с дисками, чем они израсходуют свой ресурс. В день там примерно по 400 GB пишется.

Мониторится всё это через парсинг вывода smartctl:

# smartctl -A /dev/sdb

Примерный вариант настройки можно в моей статье посмотреть:

⇨ Настройка мониторинга SMART жесткого диска в zabbix

#железо #zabbix

​​Давно не писал ничего про Zabbix. Всё жду, когда выйдет обещанная 7-я версия, а её всё нет. Решил навести справки, почитать имеющуюся информацию. От Zabbix последнее время мало новостей, так что я и следить перестал.

🔹Основная новость в том, что Zabbix, как и многие другие open source проекты в последнее время, изменил свою лицензию. Об этом была заметка в блоге от владельца компании. Расскажу, в чём суть замены лицензии GPL на AGPL и что это означает на практике.

Сразу отмечу, что для обычных пользователей Zabbix изменения не будут заметны. Для них ничего не меняется. Изменения, как и в случае с другими продуктами, коснутся тех, кто продаёт услуги на основе Zabbix другим людям. То есть компании таким образом защищают свои коммерческие интересы. С GPL вы обязаны выкладывать свои исходники только если продаёте готовый продукт на основе другого продукта с лицензией GPL. Если я правильно понял, то можно взять продукт под лицензией GPL, реализовать на его основе какой-то сервис и продавать этот сервис пользователям. Лицензия GPL позволяет вам его использовать таким образом и не выкладывать исходники своего сервиса.

AGPL убирает такую возможность. Если вы продаёте какой-то сервис, к примеру, по модели saas, где используется продукт с лицензией AGPL, вы обязаны опубликовать исходники своего сервиса. В целом, выглядит вполне логично для авторов продукта. По такой же схеме в своё время меняли лицензию MongoDB, Elastic, HashiCorp, Redis. Там хоть и другие лицензии используются, но общий смысл такой же и по своей сути лицензии похожи друг на друга, но со своими нюансами. Основной посыл - запретить облачным сервисам предоставлять услуги на основе open source продуктов без покупки коммерческой версии или открытия своего кода.

🔹К другим новостям. Недавно вышла версия 7.0.0beta3. В целом, релиз движется к публикации. Думаю, к лету он состоится. Изначально стояла дата Q4 2023, потом перенесли на Q1 2024, сейчас уже на Q2 2024. В целом, ничего необычного. У Zabbix релизы всегда откладываются. Кто-то уже сейчас пользуется 7-й версией. Видел такие комментарии не раз. Я так понимаю, что она вполне стабильна. Если делать новую установку, то можно уже 7-ю версию ставить.

🔹Zabbix периодически проводит вебинары на русском языке. Ближайший назначен на 2 мая, тема - Расширение возможностей Zabbix. Речь там пойдёт про userparametres и плагины агента 2. Тема полезная, если с ней не знакомы.

🔹Из последних статей в блоге была одна реально полезная. Там рассказано, как сгенерировать самоподписанный сертификат, чтобы по HTTPS ходить на веб интерфейс по DNS имени или IP адресу и не получать предупреждения браузера. Там ничего особенного, просто все команды и конфиги собраны в одно место, что удобно. Надо будет оформить в небольшую заметку. Обычно лень с этим возиться и получаешь сертификаты от Let's Encrypt. Но зачастую проще и удобнее выпустить свои с условно бесконечным сроком действия и забыть про этот вопрос.

#zabbix

​​Вчера был релиз новой версии Zabbix Server 7.0. Это LTS версия со сроком поддержки 5 лет. Я буду обновлять все свои сервера со временем на эту версию. Почти всегда на рабочих серверах держу LTS версии, на промежуточные не обновляюсь.

Не буду перечислять все нововведения этой версии. Их можно посмотреть в официальном пресс-релизе. Они сейчас много где будут опубликованы. На русском языке можно прочитать в новости на opennet. Отмечу и прокомментирую то, что мне показалось наиболее интересным и полезным.

1️⃣ Обновился мониторинг веб сайтов. Очень давно ждал это. Почти все настроенные мной сервера так или иначе мониторили веб сайты или какие-то другие веб службы. Функциональность востребована, а не обновлялась очень давно. Как в версии то ли 1.8, то ли 2.0 я её увидел, так она и оставалось неизменной. Появился новый тип айтема для этого мониторинга - Browser.

2️⃣ Появилась централизованная настройка таймаутов в GUI. На функциональность особо не влияет, но на самом деле нужная штука. Таймауты постоянно приходится менять и подгонять значения под конкретные типы проверок на разных серверах. Удобно, что это можно будет делать не в конфигурационном файле, а в веб интерфейсе. И эти настройки будут иметь приоритет перед всеми остальными.

3️⃣ Добавили много разных виджетов. Не скажу, что это прям сильно нужно лично мне при настройке мониторинга. Скорее больше для эстетического удовольствия их делаю. Для анализа реальных данных обычно достаточно очень простых дашбордов с конкретным набором графиков, а не различные красивые виджеты в виде спидометров или сот. Но ситуации разные бывают. Например, виджет с географической картой активно используется многими компаниями. Из новых виджетов наиболее интересные - навигаторы хостов и айтемов.

4️⃣ Появилась мультифакторная аутентификация из коробки для веб интерфейса. Так как он часто смотрит напрямую в интернет, особенно у аутсорсеров, которые могут давать доступ заказчикам к мониторингу, это удобно.

5️⃣ Добавилось много менее значительных изменений по мониторингу. Такие как мониторинг DNS записей, возможность передавать метрики напрямую в мониторинг через API с помощью метода history.push, объекты, обнаруженные через discovery, теперь могут автоматически отключаться, если они больше не обнаруживаются, выборку через JSONPath теперь можно делать и в функциях триггеров, а не только в предобработке, можно выполнять удалённые команды через агенты, работающие в активном режиме.

Много работы проделано для увеличения производительности системы в целом. Перечислять всё это не стал, можно в новости от вендора всё это увидеть. Новость, в целом приятная. Мне нравится Zabbix как продукт. Буду обновляться потихоньку и изучать новые возможности.

Если что-то ещё значительное заметили среди изменений, дайте знать. А то я иногда что-то пропускаю, а потом через год-два после релиза вдруг обнаруживаю, что какая-то полезная возможность, про которую я не знал, реализована. Много раз с таким сталкивался.

#zabbix

Вчера обновил один из своих серверов Zabbix до версии 7.0. Сразу же оформил всю информацию в статью. У меня сервер был установлен на систему Oracle Linux Server 8.10. Процедура прошла штатно и без заминок. Основные моменты, на которые нужно обратить внимание:

▪️ Версия 6.0 требовала php 7.2, эта требует 8.0. Не забудьте отдельно обновить и php. Напрямую к Zabbix Server это не относится, так что само не обновится. Мне пришлось подключить отдельный репозиторий Remi и поставить php 8.0 оттуда. В более свежих системах этого делать не потребуется, так как там 8.0+ в базовых репах. Особо заморачиваться не придётся.

▪️ Обновление самого сервера прошло штатно. Подключил репу новой версии и обновил пакеты. Можно воспользоваться официальной инструкцией, но она куцая.

💥Прямое обновление до 7.0 возможно практически в любой прошлой версии. Дословно с сайта Zabbix: Direct upgrade to Zabbix 7.0.x is possible from Zabbix 6.4.x, 6.2.x, 6.0.x, 5.4.x, 5.2.x, 5.0.x, 4.4.x, 4.2.x, 4.0.x, 3.4.x, 3.2.x, 3.0.x, 2.4.x, 2.2.x and 2.0.x. For upgrading from earlier versions consult Zabbix documentation for 2.0 and earlier.

▪️ Шаблоны мониторинга, оповещений и интеграций нужно обновлять отдельно, если хотите получить свежую версию. С самим сервером они автоматически не обновляются. В статье я написал, как можно провести эту процедуру.

▪️ Обновлять агенты до новой версии не обязательно. Всё будет нормально работать и со старыми версиями агентов. Обновление агентов опционально, но не обязательно.

▪️ Обновлять прокси тоже не обязательно, но крайне рекомендуется. Полная поддержка прокси сервером возможна только в рамках одной релизной ветки. Прокси прошлого релиза поддерживаются в ограниченном формате.

#zabbix

Вчера вечером сел за компьютер посмотреть почту, в том числе сообщения от мониторинга. Всегда это делаю вечером в воскресенье, чтобы оценить состояние инфраструктуры перед понедельником. Привлёк внимание триггер от Zabbix с одной виртуалки. Там в течении почти 6-ти часов было высокие метрики по Load Average. Потом прошло.

Посмотрел остальные метрики за это время. Ни повышенного трафика, ни чтения/записи диска, ни жора памяти или swap не было. В логах тоже ничего. Выяснить, что же там было, теперь не представляется возможным. К сожалению, это существенный пробел Zabbix, так как стандартными шаблонами этот вопрос никак не решается.

Когда-то давно я придумал решение этой задачи в лоб:

1️⃣ Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.

2️⃣ Разрешаю на zabbix agent запуск внешних команд.

3️⃣Настраиваю на Zabbix Server действие при срабатывании триггера на загрузку CPU. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.

# ps aux --sort=-pcpu,+pmem | head -10

Решение очень простое в реализации и главное удобное в анализе. Список процессов получается в наглядном виде. И при этом постоянно не собираются эти данные, а запрашиваются только в нужные моменты.

Описал этот способ в статье:

⇨ Мониторинг списка запущенных процессов в Zabbix

Способ рабочий, я им одно время пользовался, а потом забил по нескольким причинам:

1️⃣ По возможности стараюсь не использовать скрипты на хостах, потому что это усложняет настройку, неудобно быстро разворачивать и переносить настройки.

2️⃣ Настройка EnableRemoteCommands=1 потенциально небезопасна. По возможности её лучше не использовать. А если используешь, то надо и за фаерволом следить, и за tls. А если что-то от root запускаешь, то через мониторинг тебе вообще всю инфру положить могут.

Попытался придумать какую-то другую реализацию, но в голове не сложилась итоговая картинка, как это может выглядеть, поэтому прошу помощи тех, кто возможно уже решал такую задачу, либо есть идеи, как это можно сделать.

В Zabbix Server 6.2 появился новый айтем:

◽proc.get[<name>,<user>,<cmdline>,<mode>]

С его помощью можно вывести подробную информацию либо обо всех процессах системы, либо о заданных. Описание параметров есть в документации. Посмотреть через консоль, как он работает и что выводит, можно так:

# zabbix_agentd -t proc.get[zabbix_server,,,]
# zabbix_agentd -t proc.get[zabbix_server,,,summary]
# zabbix_agentd -t proc.get[]

Вся информация в json. Теоретически её можно собрать обо всех процессах, обработать, отсортировать по CPU или различным метрикам памяти и как-то вывести. Но наглядность будет сильно хуже, чем отсортированный вывод ps aux. Плюс, не совсем понимаю, как всё это организовать в рамках Zabbix Server без скриптов на хосте с привязкой к триггеру, чтобы не постоянно это всё собирать, а только когда нужно.

Если у кого-то есть идеи, поделитесь. Ну а кому интересно подобное настроить, то решение в статье вполне рабочее. Нужно только сделать поправку на то, что статья писалась давно, а интерфейс Zabbix Server с тех пор изменился. Некоторые настройки изменили своё положение. Но сам подход через скрипт и EnableRemoteCommands сработает и сейчас.

#zabbix

​​Расскажу про простую и удобную возможность мониторинга Zabbix, с помощью которой можно выполнять команды на наблюдаемых хостах. Покажу на конкретном примере, как это работает. Настрою отдельный пункт меню у хоста в веб интерфейсе, с помощью которого можно мышкой выключить систему. То есть выбираем Windows хост, жмём на него мышкой и выбираем в выпадающем списке пункт "Выключение системы" и компьютер выключается. Я так выключаю компы и прочее оборудование дома, а так же свои тестовые лабы. По аналогии можно будет настроить любые другие действия.

Настраиваем всё по шагам для Zabbix Server 7.0.

1️⃣ Идём в веб интерфейсе в раздел Оповещения ⇨ Скрипты и добавляем новый скрипт. Я его назвал Windows Shutdown. У него следующие параметры:
- Область: Действие вручную над узлом
- Тип: Скрипт
- Выполнение на: Zabbix Agent
- Команды: shutdown /s
- Описание: System shutdown
- Группы узлов сети: Выбранные, Windows (у меня все виндовые машины в отдельной группе)
- Текст подтверждения: Уверен, что хочешь потушить систему?
Сохраняем.

2️⃣ Идём на целевую систему, где установлен Zabbix agent 2. Для первой версии вроде бы настройки не поменяются, но я не проверял. Последнее время ставлю 2-й агент. Агент должен работать в пассивном режиме, то есть быть способен принимать команды от сервера.

Добавляем в конфиг агента два параметра:

AllowKey=system.run[shutdown /s]
Plugins.SystemRun.LogRemoteCommands=1

Вторую команду не обязательно, но я предпочитаю логировать выполнение внешних команд. Перезапускаем агента.

Вот и вся настройка. Теперь открываем список хостов: Мониторинг ⇨ Узлы сети. Выбираем любой хост из группы Windows, для которой назначили добавленный скрипт, и выполняем на нём команду. Система завершит работу. Запись об этом ручном действии останется в разделе Отчёты ⇨ Журнал аудита. Нужно выбрать действие - Выполнить, ресурс - Скрипт.

Люди спорят, что лучше, Zabbix или Prometheus. Они разные. Как вы в Проме так же просто настроите подобную возможность? Причём её ещё можно и по пользователям разграничить, и по группам хостов, и аудит ко всему этому. И настраивается всё за 10 минут. Потом человек заходит в веб интерфейс и мышкой запускает готовый большой скрипт или выполняет одиночную команду. Туда ведь всё, что угодно можно засунуть: сброс кэшей, перезапуск сервиса, запуск какой-нибудь проверки. Не всё имеет смысл запускать автоматически, как реакцию на триггер. Какие-то вещи можно поставить на ручной контроль.

#zabbix

​​Ещё один пример расскажу про неочевидное использование Zabbix. Люблю эту систему мониторинга больше всех остальных именно за то, что это с одной стороны целостная система, а с другой - конструктор, из которого можно слепить всё, что угодно. Безграничный простор для построения велосипедов и костылей.

У Zabbix есть тип элемента данных - SSH Агент. Он может ходить по SSH на хосты с аутентификацией по паролю или ключу, выполнять какие-то действия и сохранять вывод. С помощью этого можно, к примеру, сохранять бэкапы Микротиков. Причём встроенные возможности Zabbix позволят без каких-то дополнительных телодвижений отбрасывать неизменившиеся настройки, чтобы не хранить одну и ту же информацию много раз. А также можно оповещать об изменениях в конфигурациях, если сохранённая ранее отличается от полученной в новой проверке.

Рассказываю, как это настроить. Создаём новый шаблон. Я всегда рекомендую использовать сразу шаблоны, не создавать айтемы и триггеры на хостах. Это неудобно и труднопереносимо. Лучше сразу делать в шаблоне. Добавляем новый айтем:

◽Тип: SSH агент
◽Ключ: ssh.run[mikrotik,10.20.1.20,22,,]
Формат этого ключа: ssh.run[description,<ip>,<port>,<encoding>,<ssh options>]
◽Тип информации: Текст
◽Метод аутентификации: Пароль (можете выбрать ключ)
◽Выполняемый скрипт: /export

Остальные параметры ставите по желанию. Логин и пароль лучше вынести в макросы шаблона и скрыть их, так будет удобнее и безопаснее. Я указал явно для наглядности. Переходим в этом же айтеме на вкладку Предобработка и добавляем один шаг:

◽Отбрасывать не изменившееся

Тэги добавьте по желанию. Сохраняем. Сразу добавим триггер, который сработает, если конфигурация изменилась. Параметры там выставляйте по желанию. Выражение можно сделать такое:

last(/SSH Get/ssh.run[mikrotik,10.20.1.20,22,,],#1)<>last(/SSH Get/ssh.run[mikrotik,10.20.1.20,22,,],#2)

Сработает, если текст последней проверки будет отличаться от предыдущей.

Теперь можно прикрепить этот шаблон к хосту, который будет делать подключения и проверить. Я обычно на Zabbix Server подобную функциональность вешаю. Но это зависит от вашей конфигурации сети. Сервер должен мочь заходить по SSH на указанный в айтеме адрес.

В разделе Мониторинг -> Последние данные увидите выгрузку конфигурации своего Микротика. Единственный момент, который не понравился - добавляются лишние пустые строки. Не знаю, с чем это связано. Всё остальное проверил, конфиг нормальный. Символы не теряются. На вид рабочий.

Не знаю, насколько актуально делать бэкапы таким способом. В принципе, почему бы и нет. Тут сразу и бэкап, и мониторинг изменений в одном лице. Сам так не делал никогда. Написал эту заметку, чтобы просто продемонстрировать возможность. Вдохновился вот этой статьёй в блоге Zabbix, где они скрестили мониторинг с Oxidized:

⇨ https://blog.zabbix.com/monitoring-configuration-backups-with-zabbix-and-oxidized/28260/

Неплохой материал. Там берут json со статусами бэкапов из Oxidized и с помощью lld и jsonpath парсят его на статусы отдельных устройств.

Возвращаясь к бэкапу Микротиков. Если таки надумаете его делать, то в случае больших выгрузок увеличьте таймауты на сервере. И следите за размером бэкапов. У Zabbix вроде есть ограничение на размер текстовой записи айтема в 64KB. Если у вас конфиг будет больше, то он обрежется без каких-либо уведомлений. Ну а в общем случае всё заработает, и сбор, и триггер. Я лично проверил на своём стенде во время написания заметки.

А вообще интересна тема разных проверок с помощью Zabbix? Я могу много всяких примеров привести ещё. Что-то я уже писал раньше, что-то нет. С Zabbix постоянно работаю.

#zabbix #mikrotik

Я смотрю, заметки с Zabbix бодро заходят, а если ещё Mikrotik или Proxmox добавить, то вообще отлично. Сегодня опять Микротики будут. Типовая задача по настройке переключения канала с основного на резервный и обратно. Плюс, там ещё поднимается VPN канал. Хочется мониторить и переключение каналов, то есть получать уведомления, если канал переключился, и состояние VPN соединения, и состояние каналов, чтобы не получилось так, что резерв уже давно не работает, а мы не знаем об этом. Плюс, если точка висит на резервном канале, то это подсвечивается триггером в дашборде Zabbix.

Я делал это на базе скриптов Mikrotik. Как это может выглядеть, отражено в моей статье про переключение провайдеров. Это один из примеров. Я эти скрипты много раз менял, дорабатывал под конкретные условия. Там может быть много нюансов. Да, переключение провайдеров можно сделать проще через динамическую маршрутизацию, но это только часть задачи. Скрипт решает не только переключение, но и логирование, плюс выполнение некоторых других задач - сброс сетевых соединений, выключение и включение VPN соединения, чтобы оно сразу переподключилось через нового провайдера и т.д.

В итоге, я через скрипты настраивал переключение канала и проверку доступности каналов. Примерно так может выглядеть проверка работы канала:

:local PingCount 3;
:local CheckIp1 77.88.8.1;
:local CheckIp8 77.88.8.8;
:local isp1 [/ping $CheckIp1 count=$PingCount interface="ether1"];
:local isp2 [/ping $CheckIp8 count=$PingCount interface="lte1"];
:if ($isp1=0) do={
:log warning "MAIN Internet NOT work";
} else={
:log warning "MAIN Internet WORK";
}
:if ($isp2=0) do={
:log warning "RESERV Internet NOT work";
} else={
:log warning "RESERV Internet WORK";
}

Результат работы скриптов выводился в стандартный лог Микротика. Дальше этот лог может уезжать куда-то на хранение и анализ. Например, в ELK или Rsyslog. Если мы настраиваем мониторинг через Zabbix, то выбираем rsyslog.

Zabbix Server забирает к себе все логи через стандартный айтем с типом данных лог и анализирует. Потом создаётся триггер с примерно таким выражением, если брать приведённый выше скрипт Микротика:

find(/Mikrotik logs/log[/var/log/mikrotik/mikrotik.log],#1,"like","Router-01: MAIN Internet NOT work")=1'

и восстановление:

find(/Mikrotik logs/log[/var/log/mikrotik/mikrotik.log],#1,"like","Router-01: MAIN Internet WORK")=1

В таком подходе есть одно неудобство. Все триггеры будут привязаны к Zabbix Server, а имя устройства видно только в описании триггера. Если вам это не подходит, придётся использовать что-то другое.

Я придумывал другую схему, чтобы триггеры о состоянии каналов были привязаны к самим устройствам, чтобы на географической карте были видны хосты с проблемами. Уже точно не помню реализацию, но вроде порты куда-то внутрь пробрасывал через разные каналы. И делал стандартные TCP проверки этих портов через Zabbix сервер. Если какой-то порт не отвечает, то канал, через который он работает, считается неработающим.

И ещё один вариант мониторинга каналов. Через каждого провайдера поднимаем разное VPN соединение и мониторим его любым способом. Можно простыми пингами, если Zabbix сервер или его прокси заведён в эти VPN сети, можно по SNMP.

Мне лично больше всего нравятся варианты с логами. Я люблю всё собирать и хранить. Логи удобно анализировать, всегда на месте исторические данные по событиям. Другое дело, что Zabbix не любит большие логи и нагружать его ими не стоит. Он всё хранит в SQL базе, а она для логов плохо подходит. Какие-то простые вещи, типа вывод работы скриптов без проблем можно заводить, а вот полноценный сбор масштабных логов с их анализом устраивать не надо.

Через анализ логов удобно слать уведомления о каких-то событиях в системных логах. Например, информировать об аутентификации в системе через анализ лог файла /var/log/auth.log. Можно о slow логах mysql или php-fpm сообщать. Это актуально, если у вас нет другой, полноценной системы для хранения и анализа логов.

#mikrotik #zabbix

​​В сервере мониторинга Zabbix есть интересная возможность по отправке регулярных отчётов. К сожалению, у неё несколько громоздкая реализация, поэтому лишний раз её настраивать не хочется. Но в целом, ничего сложного, настройка простая. Реализованы эти отчеты на базе рендеринга pdf файлов из изображения дашборда средствами браузера chrome. В связи с этим, chrome необходимо устанавливать на сервер. Не обязательно именно на тот же сервер, где и мониторинг.

Меня не раз спрашивали, можно ли с помощью Zabbix раз в день, к примеру, утром, получить письмо со списком всех активных триггеров. Да, можно. Достаточно сделать дашборд с виджетом активных триггеров. Настроить регулярный отчёт и отправлять его себе.

Покажу на практике, как выглядит настройка. Использовать буду реальный сервер на базе Oracle Linux Server 8.10. Для любого другого сервера настройка будет выглядеть так же, только команды и ссылки на скачивание будут другие.

Устанавливаем необходимые пакеты:

# dnf install zabbix-web-service
# wget dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
# dnf install google-chrome-stable_current_x86_64.rpm
# systemctl enable --now zabbix-web-service

Добавляем в конфиг zabbix_server.conf:

StartReportWriters=1
WebServiceURL=http://127.0.0.1:10053/report

Службу zabbix-web-service установил на ту же машину, где сам мониторинг, поэтому указал соответствующий адрес. Если будете устанавливать её отдельно, то не забудьте его поменять.

Перезапускаем сервер мониторинга:

# systemctl restart zabbix-server

Идём в веб интерфейс, в раздел Отчёты ⇨ Регулярные отчёты. Настройка там интуитивна, так что рассказывать особо нечего. Нужно будет выбрать панель и период, который будет выбран при формировании отчёта. Если в панели несколько страниц, то в отчёте они будут все по очереди отражены.

Отчёты будут отправляться на e-mail, так что у пользователя, для которого вы их будете отправлять, он должен быть указан. Здесь же можно проверить отправку отчёта.

Интересная возможность, которая позволяет получать на почту информацию в любом необходимом вам виде, который позволяет оформить функциональность дашбордов zabbix сервера. Называть их отчётами слишком громко, по сути это просто картинки.

 📌 Ссылки на документацию:
⇨ Scheduled reports
⇨ Setting up scheduled reports

#zabbix

На прошлой неделе была рассылка от Zabbix. В ней анонсировали запуск Zabbix Cloud. Я сразу предположил, что они запустят свой облачный сервис после недавней замены лицензии GPL на AGPL. Так и случилось. Решил проверить, что это такое и как работает.

После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.

По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.

Каких-то особых фишек и возможностей не увидел, кроме автоматического обновления до новых версий сервера. Причём отказаться от такого обновления вы не сможете. Автоматические бэкапы обещают раз в неделю. Чаще можно делать вручную через веб панель управления нодой. Выгрузить свой бэкап за пределы облака нельзя, как и загрузить туда версию своего сервера. Восстановление из бэкапа только там. Наверняка есть какой-то тюнинг СУБД, чтобы всё это работало побыстрее, чем дефолтная установка.

В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.

Вторая идея - преднастроенные агенты. Скачиваешь из веб интерфейса сервера дистрибутив агента с уже зашитыми настройками подключения к серверу и некоторых параметров. По идее это нетрудно сделать, а удобство развёртывания сильно повышается. Не надо свои инструменты придумывать для быстрой раскатки агентов с подстановкой нужных конфигов.

#zabbix