​​Один из читателей канала давно мне скидывал информацию про скрипт для 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