В сервере мониторинга Zabbix есть интересная возможность по отправке регулярных отчётов. К сожалению, у неё несколько громоздкая реализация, поэтому лишний раз её настраивать не хочется. Но в целом, ничего сложного, настройка простая. Реализованы эти отчеты на базе рендеринга pdf файлов из изображения дашборда средствами браузера chrome. В связи с этим, chrome необходимо устанавливать на сервер. Не обязательно именно на тот же сервер, где и мониторинг.
Меня не раз спрашивали, можно ли с помощью Zabbix раз в день, к примеру, утром, получить письмо со списком всех активных триггеров. Да, можно. Достаточно сделать дашборд с виджетом активных триггеров. Настроить регулярный отчёт и отправлять его себе.
Покажу на практике, как выглядит настройка. Использовать буду реальный сервер на базе Oracle Linux Server 8.10. Для любого другого сервера настройка будет выглядеть так же, только команды и ссылки на скачивание будут другие.
Устанавливаем необходимые пакеты:
Добавляем в конфиг
Службу zabbix-web-service установил на ту же машину, где сам мониторинг, поэтому указал соответствующий адрес. Если будете устанавливать её отдельно, то не забудьте его поменять.
Перезапускаем сервер мониторинга:
Идём в веб интерфейс, в раздел Отчёты ⇨ Регулярные отчёты. Настройка там интуитивна, так что рассказывать особо нечего. Нужно будет выбрать панель и период, который будет выбран при формировании отчёта. Если в панели несколько страниц, то в отчёте они будут все по очереди отражены.
Отчёты будут отправляться на e-mail, так что у пользователя, для которого вы их будете отправлять, он должен быть указан. Здесь же можно проверить отправку отчёта.
Интересная возможность, которая позволяет получать на почту информацию в любом необходимом вам виде, который позволяет оформить функциональность дашбордов zabbix сервера. Называть их отчётами слишком громко, по сути это просто картинки.
📌 Ссылки на документацию:
⇨ Scheduled reports
⇨ Setting up scheduled reports
#zabbix
Меня не раз спрашивали, можно ли с помощью 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=1WebServiceURL=http://127.0.0.1:10053/reportСлужбу zabbix-web-service установил на ту же машину, где сам мониторинг, поэтому указал соответствующий адрес. Если будете устанавливать её отдельно, то не забудьте его поменять.
Перезапускаем сервер мониторинга:
# systemctl restart zabbix-serverИдём в веб интерфейс, в раздел Отчёты ⇨ Регулярные отчёты. Настройка там интуитивна, так что рассказывать особо нечего. Нужно будет выбрать панель и период, который будет выбран при формировании отчёта. Если в панели несколько страниц, то в отчёте они будут все по очереди отражены.
Отчёты будут отправляться на e-mail, так что у пользователя, для которого вы их будете отправлять, он должен быть указан. Здесь же можно проверить отправку отчёта.
Интересная возможность, которая позволяет получать на почту информацию в любом необходимом вам виде, который позволяет оформить функциональность дашбордов zabbix сервера. Называть их отчётами слишком громко, по сути это просто картинки.
📌 Ссылки на документацию:
⇨ Scheduled reports
⇨ Setting up scheduled reports
#zabbix
👍74👎4
У Zabbix есть отдельная страница, где публикуются все найденные уязвимости:
⇨ https://www.zabbix.com/security_advisories
Какого-то API или выгрузки для этих данных нет. В официальном блоге появилась статья на эту тему: Monitoring Zabbix Security Advisories. Автор предложил решение, как настроить мониторинг этой страницы. Я его попробовал и изучил. В целом, мне понравилось, как это работает, оставил у себя на одном из серверов для информирования.
Автор распарсил указанную страницу с помощью rust, scraper и AWS Lambda function. Положил итоговый файл в формате json на S3 бакет и обновляет его раз в 2 часа. Вот ссылка на файл.
Далее был сделан шаблон для сбора данных. В статье есть ссылка на него. Он довольно простой, так как парсить json с помощью Zabbix просто и удобно. В шаблоне 2 триггера:
▪️появилась новая уязвимость
▪️файл с уязвимостями не обновлялся дольше 6-ти часов
Последний триггер сделан как-то непонятно. У меня он работал неправильно, я не понял его логику. Подставив макросы в триггере, там получилось вот такое выражение:
Значение zbx_sec.last_updated в формате unixtime. Я заменил этот триггер на свой. Он срабатывает, если время обновления json файла отличается больше чем на 24 часа (86400 секунд) от текущего времени сервера. То есть обновление было больше суток назад.
В таком формате он нормально работает. Ещё из интересного в этом шаблоне то, что он собирает всю информацию о каждой уязвимости в отдельном айтеме. На дашборде в отдельной странице можно сделать удобную навигацию по этим значениям. Конкретно в данном случае это не очень актуально, потому что список проще и быстрее посмотреть на веб странице. Но для демонстрации возможностей подойдёт.
В 7-й версии Zabbix появился новый виджет - Навигатор по элементам данных. Его можно связать с виджетом - Значение элемента данных. Как это выглядит вместе можно посмотреть на картинке снизу, либо в самой статье. Там автор показал, как подобное настроить.
Если работаете с Zabbix, рекомендую обратить внимание на эту статью в блоге и шаблон. Удобно получать оперативно информацию о том, что появилась какая-то уязвимость в Zabbix от самих разработчиков.
#zabbix
🦖 Selectel — дешёвые и не очень дедики с аукционом!
⇨ https://www.zabbix.com/security_advisories
Какого-то API или выгрузки для этих данных нет. В официальном блоге появилась статья на эту тему: Monitoring Zabbix Security Advisories. Автор предложил решение, как настроить мониторинг этой страницы. Я его попробовал и изучил. В целом, мне понравилось, как это работает, оставил у себя на одном из серверов для информирования.
Автор распарсил указанную страницу с помощью rust, scraper и AWS Lambda function. Положил итоговый файл в формате json на S3 бакет и обновляет его раз в 2 часа. Вот ссылка на файл.
Далее был сделан шаблон для сбора данных. В статье есть ссылка на него. Он довольно простой, так как парсить json с помощью Zabbix просто и удобно. В шаблоне 2 триггера:
▪️появилась новая уязвимость
▪️файл с уязвимостями не обновлялся дольше 6-ти часов
Последний триггер сделан как-то непонятно. У меня он работал неправильно, я не понял его логику. Подставив макросы в триггере, там получилось вот такое выражение:
last(/Zabbix Security Advisories/zbx_sec.last_updated)>2h*3Значение zbx_sec.last_updated в формате unixtime. Я заменил этот триггер на свой. Он срабатывает, если время обновления json файла отличается больше чем на 24 часа (86400 секунд) от текущего времени сервера. То есть обновление было больше суток назад.
fuzzytime(/Zabbix Security Advisories/zbx_sec.last_updated,86400)=0В таком формате он нормально работает. Ещё из интересного в этом шаблоне то, что он собирает всю информацию о каждой уязвимости в отдельном айтеме. На дашборде в отдельной странице можно сделать удобную навигацию по этим значениям. Конкретно в данном случае это не очень актуально, потому что список проще и быстрее посмотреть на веб странице. Но для демонстрации возможностей подойдёт.
В 7-й версии Zabbix появился новый виджет - Навигатор по элементам данных. Его можно связать с виджетом - Значение элемента данных. Как это выглядит вместе можно посмотреть на картинке снизу, либо в самой статье. Там автор показал, как подобное настроить.
Если работаете с Zabbix, рекомендую обратить внимание на эту статью в блоге и шаблон. Удобно получать оперативно информацию о том, что появилась какая-то уязвимость в Zabbix от самих разработчиков.
#zabbix
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍66👎3
На прошлой неделе была рассылка от Zabbix. В ней анонсировали запуск Zabbix Cloud. Я сразу предположил, что они запустят свой облачный сервис после недавней замены лицензии GPL на AGPL. Так и случилось. Решил проверить, что это такое и как работает.
После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.
По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.
Каких-то особых фишек и возможностей не увидел, кроме автоматического обновления до новых версий сервера. Причём отказаться от такого обновления вы не сможете. Автоматические бэкапы обещают раз в неделю. Чаще можно делать вручную через веб панель управления нодой. Выгрузить свой бэкап за пределы облака нельзя, как и загрузить туда версию своего сервера. Восстановление из бэкапа только там. Наверняка есть какой-то тюнинг СУБД, чтобы всё это работало побыстрее, чем дефолтная установка.
В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.
Вторая идея - преднастроенные агенты. Скачиваешь из веб интерфейса сервера дистрибутив агента с уже зашитыми настройками подключения к серверу и некоторых параметров. По идее это нетрудно сделать, а удобство развёртывания сильно повышается. Не надо свои инструменты придумывать для быстрой раскатки агентов с подстановкой нужных конфигов.
#zabbix
После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.
По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.
Каких-то особых фишек и возможностей не увидел, кроме автоматического обновления до новых версий сервера. Причём отказаться от такого обновления вы не сможете. Автоматические бэкапы обещают раз в неделю. Чаще можно делать вручную через веб панель управления нодой. Выгрузить свой бэкап за пределы облака нельзя, как и загрузить туда версию своего сервера. Восстановление из бэкапа только там. Наверняка есть какой-то тюнинг СУБД, чтобы всё это работало побыстрее, чем дефолтная установка.
В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.
Вторая идея - преднастроенные агенты. Скачиваешь из веб интерфейса сервера дистрибутив агента с уже зашитыми настройками подключения к серверу и некоторых параметров. По идее это нетрудно сделать, а удобство развёртывания сильно повышается. Не надо свои инструменты придумывать для быстрой раскатки агентов с подстановкой нужных конфигов.
#zabbix
👍71👎3
Небольшие советы из практики по настройке Zabbix, которые уменьшат спам от триггеров. Если развернуть Zabbix, взять стандартные шаблоны, применить к хостам и всё это запустить в работу, то очень скоро на мониторинг никто не будет обращать внимание. Мониторинг всегда нуждается в калибровке. Она может быть очень простой на базе небольших изменений стандартных настроек, а может быть очень глубокой с полной заменой всех базовых шаблонов на свои. Я расскажу про первый вариант.
1️⃣ Я практически везде настраиваю отложенные уведомления. Это не очень красивый, но самый простой и быстрый вариант существенно уменьшить спам уведомлений. Не очень красивый он потому, что триггеры всё равно будут срабатывать, но уведомления будут приходить только о тех триггерах, что активны более 5-ти минут. Настраивается это в стандартном правиле уведомлений о триггерах. Там всё делается очень просто. Настройка описана в моей статье.
2️⃣ Триггеры в стандартных шаблонах могут вести себя в целом нормально, но на каких-то хостах вызывать спам. Например, у вас триггер на занятое место на диске в 80%. Если ночью делается дамп БД, потом он сжимается, копируется и удаляется на исходном хосте, вы каждую ночь будете получать уведомление о занятом месте. То есть в момент окончания создания дампа у вас занято 82%, дамп сжимается, пересылается и удаляется, и занято снова 70%, что в целом нормально. И 80% нормально для этой ситуации.
В этой ситуации вам нет смысла менять триггер в изначальном шаблоне. Можно его просто отключить на этом хосте, но не хочется. Конкретно в этом примере вопрос можно решить изменением макроса, если он используется в выражении триггера, но так бывает не всегда. Я в этом случае просто копирую в этом хосте данный триггер, настраиваю его так, как мне нужно, а тот, что наследуется из шаблона, отключаю. Получается не очень красиво, так как появляется непереносимая привязка на конкретном хосте, но если это нужно редко и не хочется готовить для таких хостов отдельные шаблоны, то пойдёт.
3️⃣ У меня часто бывает так, что какой-то триггер или несколько спамят, но прямо сейчас мне лень ими заниматься или нет возможности. Чтобы потом разом их все откалибровать, можно зайти в раздел Отчёты ⇨ Топ 100 триггеров, посмотреть там самые активные и вручную с ними поработать.
4️⃣ Очевидный совет, но добавлю, чтобы был готовый список действий. Я почти всегда отключаю те или иные правила обнаружения, которые мне не нужны, либо правлю их. На Windows хостах всегда в стандартном шаблоне отключаю правило автообнаружения служб, а на Linux - в правиле автообнаружения блочных устройств отключаю триггер на отклик диска при операциях чтения/записи. Я не скажу, что эти данные бесполезны, но на практике они дают очень много срабатываний, которые лично для меня практической пользы не несут.
Альтернатива всем этим действиям - создание собственных шаблонов, где во-первых, стоит использовать только те айтемы, что вам реально нужны. Во-вторых, стоит особое внимание обратить на зависимость триггеров. Их грамотная настройка очень сильно снижает количество бесполезных событий мониторинга. Это в разы увеличивает затраты на начальное внедрение, но компенсируется в процессе эксплуатации. Особенно на больших инфраструктурах, где не вы один следите за мониторингом.
#zabbix
В этой ситуации вам нет смысла менять триггер в изначальном шаблоне. Можно его просто отключить на этом хосте, но не хочется. Конкретно в этом примере вопрос можно решить изменением макроса, если он используется в выражении триггера, но так бывает не всегда. Я в этом случае просто копирую в этом хосте данный триггер, настраиваю его так, как мне нужно, а тот, что наследуется из шаблона, отключаю. Получается не очень красиво, так как появляется непереносимая привязка на конкретном хосте, но если это нужно редко и не хочется готовить для таких хостов отдельные шаблоны, то пойдёт.
Альтернатива всем этим действиям - создание собственных шаблонов, где во-первых, стоит использовать только те айтемы, что вам реально нужны. Во-вторых, стоит особое внимание обратить на зависимость триггеров. Их грамотная настройка очень сильно снижает количество бесполезных событий мониторинга. Это в разы увеличивает затраты на начальное внедрение, но компенсируется в процессе эксплуатации. Особенно на больших инфраструктурах, где не вы один следите за мониторингом.
#zabbix
Please open Telegram to view this post
VIEW IN TELEGRAM
Server Admin
Настройка отложенных уведомлений в Zabbix
Демонстрация на простом примере настройки отложенного уведомления о событии в системе мониторинга zabbix.
👍124👎3
У Zabbix Server сегодня был релиз версии 7.2 Напомню, что это промежуточный, не LTS релиз. Данная версия будет поддерживаться 6 месяцев полной поддержкой, и 6 ограниченной, с выпуском только обновлений безопасности. Промежуточные релизы служат в основном для теста и отладки обновлений для LTS веток. Так что не спешите обновляться на эти версии, если у вас нет необходимости во что бы то ни стало получить новую функциональность. Я рабочие сервера обновляю только на LTS версии, а промежуточные ставлю на свой личный тестовый, да и то не всегда.
Полная информация на официальном сайте с картинками и на английском языке:
⇨ What’s new in Zabbix 7.2
Перечислю основные моменты со своими комментариями.
🔹Обновления визуализации и появление новых виджетов. Это основа обновлений данного релиза. Появился виджет Top items, который заменил собой устаревший Data overview (Обзор данных). Последний я активно использую. Например, на отдельные дашборды вывожу список айтемов с информацией о времени жизни сертификатов, доменов, статусы пиров asterisk или клиентов openvpn, уровень тонера в картриджах. Это универсальный виджет, который удобен для вывода точных значений айтемов. Попробуем новый виджет. Выглядит он поинтереснее старого.
Появилась новая диаграмма Sparkline chart, которую можно использовать в виджетах Top hosts, Top items, Item value. Смотрится неплохо.
Добавлен новый виджет Host card с подборкой информации о хосте. Особо не вижу применения для данного виджета, кроме быстрого доступа к Latest data. Лично я там провожу много времени в мониторингах.
🔹Добавлены новый шаблон для Nvidia GPU. Теперь можно мониторить видеокарты в связке с Zabbix Agent 2. Полезная штука для тех, кто использует видеокарты. Их как-то обычно стороной обходят.
Обновились шаблоны для мониторинга сертификатов и LAMP Stack. Я внимательно посмотрел ссылки на шаблоны, прочитал полностью Release Notes, но не смог найти подробностей обновлений. Надо пробовать. Для сертификатов описание такое же, как и было, а что имеется ввиду под шаблон для LAMP Stack я вообще не понял. Ссылки ведут на шаблон Zabbix Agent for Linux. Если у кого-то есть информация на этот счёт, пожалуйста, поделитесь.
Также масштабно обновился шаблон для VMware.
🔹Если я правильно понял описание, то доработали тип айтема на базе SSH агента, чтобы он мог подключаться туда, где разрешены только протоколы SFTP и NETCONF, а не полноценный SSH.
🔹Параметры компонентов Zabbix в файле конфигурации можно указывать в виде переменных. Сделано для упрощения использования в динамических средах. Не придётся свои костыли городить для подстановки значений из переменных в конфиг. Теперь их там можно сразу в виде переменных указывать.
🔹Добавлена поддержка PostgreSQL 17. Убрана поддержка Oracle DB. Судя по всему никто не использует эту СУБД для мониторинга.
Завтра будет 2 вебинара на английском утром и вечером по обновлениям этого релиза. Постараюсь посмотреть, если не отвлечёт ничего. Интересно посмотреть вживую на новые виджеты.
Кстати, последние обновления внешнего вида в Zabbix Server мне лично нравятся. Речь идёт об изменениях в 7.0 и далее. Я раньше критиковал Zabbix за его невыразительные визуализации. Но сейчас стало значительно лучше. Мне строгий светлый дизайн дашбордов Zabbix Server нравится больше, чем контрастный тёмный в Grafana. Он какой-т более мультяшный что ли. Чисто субъективное восприятие.
#zabbix
Полная информация на официальном сайте с картинками и на английском языке:
⇨ What’s new in Zabbix 7.2
Перечислю основные моменты со своими комментариями.
🔹Обновления визуализации и появление новых виджетов. Это основа обновлений данного релиза. Появился виджет Top items, который заменил собой устаревший Data overview (Обзор данных). Последний я активно использую. Например, на отдельные дашборды вывожу список айтемов с информацией о времени жизни сертификатов, доменов, статусы пиров asterisk или клиентов openvpn, уровень тонера в картриджах. Это универсальный виджет, который удобен для вывода точных значений айтемов. Попробуем новый виджет. Выглядит он поинтереснее старого.
Появилась новая диаграмма Sparkline chart, которую можно использовать в виджетах Top hosts, Top items, Item value. Смотрится неплохо.
Добавлен новый виджет Host card с подборкой информации о хосте. Особо не вижу применения для данного виджета, кроме быстрого доступа к Latest data. Лично я там провожу много времени в мониторингах.
🔹Добавлены новый шаблон для Nvidia GPU. Теперь можно мониторить видеокарты в связке с Zabbix Agent 2. Полезная штука для тех, кто использует видеокарты. Их как-то обычно стороной обходят.
Обновились шаблоны для мониторинга сертификатов и LAMP Stack. Я внимательно посмотрел ссылки на шаблоны, прочитал полностью Release Notes, но не смог найти подробностей обновлений. Надо пробовать. Для сертификатов описание такое же, как и было, а что имеется ввиду под шаблон для LAMP Stack я вообще не понял. Ссылки ведут на шаблон Zabbix Agent for Linux. Если у кого-то есть информация на этот счёт, пожалуйста, поделитесь.
Также масштабно обновился шаблон для VMware.
🔹Если я правильно понял описание, то доработали тип айтема на базе SSH агента, чтобы он мог подключаться туда, где разрешены только протоколы SFTP и NETCONF, а не полноценный SSH.
🔹Параметры компонентов Zabbix в файле конфигурации можно указывать в виде переменных. Сделано для упрощения использования в динамических средах. Не придётся свои костыли городить для подстановки значений из переменных в конфиг. Теперь их там можно сразу в виде переменных указывать.
🔹Добавлена поддержка PostgreSQL 17. Убрана поддержка Oracle DB. Судя по всему никто не использует эту СУБД для мониторинга.
Завтра будет 2 вебинара на английском утром и вечером по обновлениям этого релиза. Постараюсь посмотреть, если не отвлечёт ничего. Интересно посмотреть вживую на новые виджеты.
Кстати, последние обновления внешнего вида в Zabbix Server мне лично нравятся. Речь идёт об изменениях в 7.0 и далее. Я раньше критиковал Zabbix за его невыразительные визуализации. Но сейчас стало значительно лучше. Мне строгий светлый дизайн дашбордов Zabbix Server нравится больше, чем контрастный тёмный в Grafana. Он какой-т более мультяшный что ли. Чисто субъективное восприятие.
#zabbix
👍86👎2
В продолжении вчерашней темы мониторинга Zabbix небольшая заметка из практики, с которой столкнулся на днях. Я абсолютно всегда без исключения настраиваю мониторинг TLS сертификатов и делегирование доменов. Даже если кажется, что всё под контролем, уведомления рассылаются, сертификаты обновляются и т.д.
Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил
Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.
У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил
Для https аналогично.
Без мониторинга очень часто протухают сертификаты. Сколько раз это видел даже у крупных компаний. Помню у Rebrain когда-то давно был анонс вебинара про мониторинг. Переходишь по ссылке, а там браузер даёт ошибку на протухший сертификат. Получилось забавно. Поправили сразу, но сам факт. Либо не было мониторинга, либо за ним никто не следил. На протухшие домены и сертификаты лучше всего делать повторяющие уведомления, которые будут раз в сутки прилетать, пока не продлишь.
#zabbix #мониторинг
Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил
location /.well-known без переадресации. Сделал и забыл. Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.
У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил
location /.well-known и для http, и для https, чтобы в любом случае проверка домена проходила успешно. Что-то типа такого:server { listen 80; server_name mail.example.com; location /.well-known { root /var/www/mail.example.com; } location / { return 301 https://webmail.example.com$request_uri; }}Для https аналогично.
Без мониторинга очень часто протухают сертификаты. Сколько раз это видел даже у крупных компаний. Помню у Rebrain когда-то давно был анонс вебинара про мониторинг. Переходишь по ссылке, а там браузер даёт ошибку на протухший сертификат. Получилось забавно. Поправили сразу, но сам факт. Либо не было мониторинга, либо за ним никто не следил. На протухшие домены и сертификаты лучше всего делать повторяющие уведомления, которые будут раз в сутки прилетать, пока не продлишь.
#zabbix #мониторинг
Server Admin
Повторяющиеся уведомления в Zabbix
Настройка регулярных повторяющихся оповещений в системе мониторинга zabbix. Показано на конкретном примере с триггером.
2👍92👎4
Решил всё же после выхода Zabbix Server 7.2 обновить один из работающих серверов до этой версии. Давно собирался там порядок навести и нарисовать новые дашборды. Имеет смысл это сделать уже на свежей версии.
Сервер был версии 6.0 на ОС Debian 11. Первым делом обновил Debian 11 до 12. Всё прошло гладко. Debian хорошо обновляется с релиза на релиз. Не припоминаю серьёзных проблем с этим. Потом подключил репозиторий от Zabbix 7 и обновил его с 6.0 до 7.0. Процесс обновления в целом прошёл штатно, но на выходе я столкнулся с проблемой.
Это был старый сервер, который обновляется с релиза на релиз, с системы на систему с 4-й версии. А может и того раньше. Не помню точно. Он всегда работал под Apache. После обновления на 7.0 в веб интерфейсе пропал русский язык. В настройках он остался, но если в профиле выбрать русский язык и сохранить настройки, то ничего не менялось. Оставался английский.
Я немного погуглил, решения не нашёл. Несмотря на то, что все необходимые условия для появления русского языка выполнены, он не работал. Я не стал дальше решать вопрос, а просто заменил Apache на Nginx и Php-fpm. Русский язык появился. То есть проблема сидела где-то в настройках Apache и скорее всего php.
Дальше в пару шагов обновил 7.0 до 7.2:
Тут тоже столкнулся с ошибкой. В 7.2 веб интерфейс вынесли в новую директорию
❗️С версией сервера 7.2 не будут работать прокси 6.0. Для меня это было сюрпризом, так как в одном сегменте сети до сих пор работают Centos 7 и туда максимум можно поставить версию 6.0. С сервером 7.0 они нормально работали, а с 7.2 уже не хотят. Пришлось решать этот вопрос отдельной установкой туда более свежей системы.
Несмотря на то, что проделал довольно значительные обновления не только со сменой ветки программы, но и самой системы, прошло всё без особых сюрпризов. Потратил на всё про всё около двух часов. В комментариях к своим статьям по обновлению Zabbix постоянно встречаю различные ошибки у людей. То база не обновляется, то бэкенд остался старой версии. Сам с ними не сталкиваюсь. Если всё делать аккуратно с пониманием и проверкой того, что делаешь, то всё получается.
Перед обновлением сделал снепшот виртуалки и не забыл его удалить, когда убедился, что всё получилось и работает.
#zabbix
Сервер был версии 6.0 на ОС Debian 11. Первым делом обновил Debian 11 до 12. Всё прошло гладко. Debian хорошо обновляется с релиза на релиз. Не припоминаю серьёзных проблем с этим. Потом подключил репозиторий от Zabbix 7 и обновил его с 6.0 до 7.0. Процесс обновления в целом прошёл штатно, но на выходе я столкнулся с проблемой.
Это был старый сервер, который обновляется с релиза на релиз, с системы на систему с 4-й версии. А может и того раньше. Не помню точно. Он всегда работал под Apache. После обновления на 7.0 в веб интерфейсе пропал русский язык. В настройках он остался, но если в профиле выбрать русский язык и сохранить настройки, то ничего не менялось. Оставался английский.
Я немного погуглил, решения не нашёл. Несмотря на то, что все необходимые условия для появления русского языка выполнены, он не работал. Я не стал дальше решать вопрос, а просто заменил Apache на Nginx и Php-fpm. Русский язык появился. То есть проблема сидела где-то в настройках Apache и скорее всего php.
Дальше в пару шагов обновил 7.0 до 7.2:
# wget https://repo.zabbix.com/zabbix/7.2/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.2+debian12_all.deb# dpkg -i zabbix-release_latest_7.2+debian12_all.deb# apt update# apt upgradeТут тоже столкнулся с ошибкой. В 7.2 веб интерфейс вынесли в новую директорию
/usr/share/zabbix/ui вместо прошлой /usr/share/zabbix. Нужно поправить это в настройках nginx. Больше ничего менять не надо. Перезапускаем службу и тестируем новую версию 7.2.❗️С версией сервера 7.2 не будут работать прокси 6.0. Для меня это было сюрпризом, так как в одном сегменте сети до сих пор работают Centos 7 и туда максимум можно поставить версию 6.0. С сервером 7.0 они нормально работали, а с 7.2 уже не хотят. Пришлось решать этот вопрос отдельной установкой туда более свежей системы.
Несмотря на то, что проделал довольно значительные обновления не только со сменой ветки программы, но и самой системы, прошло всё без особых сюрпризов. Потратил на всё про всё около двух часов. В комментариях к своим статьям по обновлению Zabbix постоянно встречаю различные ошибки у людей. То база не обновляется, то бэкенд остался старой версии. Сам с ними не сталкиваюсь. Если всё делать аккуратно с пониманием и проверкой того, что делаешь, то всё получается.
Перед обновлением сделал снепшот виртуалки и не забыл его удалить, когда убедился, что всё получилось и работает.
#zabbix
1👍111👎3
Небольшая заметка на тему Zabbix Server на основе своего опыта. Иногда бывает ситуация, особенно после системных обновлений, когда ты перезагружаешь сервер, а он зависает. Тебя отрубает от SSH, виртуалка висит в неопределённом состоянии, приходится принудительно завершать работу. Проблема актуальна, когда мониторинг и СУБД живут на одной машине.
Смысл проблемы в том, что процесс с СУБД завершает свою работу раньше, чем Zabbix Server. И он пытается достучаться до базы, которая уже выключилась. А серверу надо туда свои кэши или буферы скинуть перед остановкой. И он не может. Пытается, но не может. В итоге все службы завершают работу, в том числе SSH, а Zabbix Server всё ещё висит и держит всю систему.
Сколько времени он может пробыть в таком состоянии - не знаю, не проверял. Обычно минут 10 повисит и я принудительно завершаю работу виртуалки. Так как СУБД завершает свою работу штатно, к проблемам это ни разу не приводило.
Так что перезагружая виртуалку с Zabbix Server, я сначала вручную завершаю работу мониторинга:
А потом уже набираю
По этой проблеме был заведён баг на официальном трекере мониторинга. Проблему решили перечислением зависимостей в systemd юните zabbix-server.service. Добавили параметр
Если у вас используется версия СУБД, которая не перечислена в системном юните, то вы по-прежнему можете получить эту ошибку. Выглядит это примерно так:
Если у вас используется PostgreSQL, то задача усложняется. Там службы СУБД указаны с номерами версий. Для юнита Zabbix это выглядит так:
Соответственно, если у вас имя службы СУБД выглядит как-то иначе, получите описанную проблему, если не обновите юнит сами.
В общем, я со стародавних времён привык сначала останавливать мониторинг, убеждаться, что он остановлен, а потому уже перезапускать сервер.
Соблюдаю это правило для всех систем, где есть зависимость от службы СУБД. Например, на серверах с 1С + PostgreSQL всегда сначала вручную останавливаю службу 1С, а потом уже выполняю какие-то другие действия - обновление, перезагрузка и т.д. Баг с заббиксом приучил так действовать просто на всякий случай.
#zabbix #ошибка
Смысл проблемы в том, что процесс с СУБД завершает свою работу раньше, чем Zabbix Server. И он пытается достучаться до базы, которая уже выключилась. А серверу надо туда свои кэши или буферы скинуть перед остановкой. И он не может. Пытается, но не может. В итоге все службы завершают работу, в том числе SSH, а Zabbix Server всё ещё висит и держит всю систему.
Сколько времени он может пробыть в таком состоянии - не знаю, не проверял. Обычно минут 10 повисит и я принудительно завершаю работу виртуалки. Так как СУБД завершает свою работу штатно, к проблемам это ни разу не приводило.
Так что перезагружая виртуалку с Zabbix Server, я сначала вручную завершаю работу мониторинга:
# systemctl stop zabbix-serverА потом уже набираю
# rebootПо этой проблеме был заведён баг на официальном трекере мониторинга. Проблему решили перечислением зависимостей в systemd юните zabbix-server.service. Добавили параметр
After и перечислили службы СУБД, от которых зависит служба Zabbix Server. Если я правильно понял, то этот параметр указывает на то, что служба мониторинга запускается после службы СУБД и эта же настройка управляет завершением работы, но в обратном порядке. То есть сначала завершается служба мониторинга, а потом уже СУБД. Если у вас используется версия СУБД, которая не перечислена в системном юните, то вы по-прежнему можете получить эту ошибку. Выглядит это примерно так:
After=mysql.serviceAfter=mysqld.serviceAfter=mariadb.serviceЕсли у вас используется PostgreSQL, то задача усложняется. Там службы СУБД указаны с номерами версий. Для юнита Zabbix это выглядит так:
After=postgresql-9.4.serviceAfter=postgresql-9.5.serviceAfter=postgresql-9.6.serviceAfter=postgresql-10.serviceAfter=postgresql-11.serviceAfter=postgresql-12.serviceAfter=postgresql-13.serviceAfter=postgresql-14.serviceAfter=postgresql-15.serviceAfter=postgresql-16.serviceСоответственно, если у вас имя службы СУБД выглядит как-то иначе, получите описанную проблему, если не обновите юнит сами.
В общем, я со стародавних времён привык сначала останавливать мониторинг, убеждаться, что он остановлен, а потому уже перезапускать сервер.
Соблюдаю это правило для всех систем, где есть зависимость от службы СУБД. Например, на серверах с 1С + PostgreSQL всегда сначала вручную останавливаю службу 1С, а потом уже выполняю какие-то другие действия - обновление, перезагрузка и т.д. Баг с заббиксом приучил так действовать просто на всякий случай.
#zabbix #ошибка
👍182👎4
Давно заметил, что в Proxmox с какой-то версии в разделе настройки уведомлений появился тип Gotify. Его же видел в качестве поддерживаемых каналов доставки уведомлений в некоторых других сервиах. Сам никогда им не пользовался и вот решил повнимательнее посмотреть, что это такое.
Gotify – open source проект по доставке уведомлений. Это небольшой одиночный бинарник на Go, который собран даже под Windows. Он состоит из:
▪️API для приёма сообщений;
▪️веб интерфейса для управления и просмотра сообщений;
▪️Android клиента для получения сообщений и пушей на смартфоне.
То есть схема работы такая. Вы поднимаете свой сервер Gotify. Добавляете туда приложение, получаете для него токен. Идёте в тот же Proxmox, добавляете в качестве получения уведомлений Gotify сервер. Для этого нужно будет указать его URL и токен приложения. И всё. Теперь все уведомления от этого Proxmox будут в отдельном канале уведомлений в Gotify, где их можно будет просматривать. Если Gotify открыт в браузере, будете получать уведомления от браузера, если на смартфоне – от смартфона. Только надо не забыть его настроить, чтобы система позволяла работать приложению в фоне, чтобы приходили пуши.
Это почти то же самое, что и ntfy.sh, про который я когда-то рассказывал. Хотел дальше написать, что Gotify более популярный, но глянул звёзды на github, а у ntfy их 19.7k, против 11.9k у Gotify. Так что о популярности трудно так сказать. Тем не менее, не припоминаю, чтобы где-то видел явное указание поддержки ntfy, а вот Gotify встречал много раз.
Даже если в каком-то софте не заявлена поддержка Gotify, отправлять туда сообщения можно обычными веб хуками примерно так:
Из консоли или скриптов можно прямо бинарником Gotify-CLI отправлять уведомления:
Параметры URL и token указываются в конфигурационном файле, который формируется с помощью команды
Запустить сервер можно в Docker:
По умолчанию состояние хранится в sqlite3 базе. Можно настроить хранение в mysql или postgres. Параметры задаются в файле конфигурации сервера. Он небольшой, все значения описаны в документации. В проде сервер имеет смысл ставить за обратным прокси. Примеры настроек всех популярных веб серверов тоже есть в документации.
Пример того, как отправлять уведомления от Zabbix в Gotify через alertscripts. Задача скрипта преобразовать уровни значимости формата Zabbix в приоритеты Gotify. А дальше просто через curl отправка уведомлений.
Продукт простой и полезный. Позволяет с минимумом усилий навести порядок с уведомлениями от различных сервисов, выделив их в отдельный поток, не перемешивая с остальными уведомлениями на смартфоне или почте. Отлично изолирует работу от личной жизни. Не хватает только пересылки в какие-то другие системы. Gotify все уведомления замыкает на себя. Хотелось бы их ещё куда-то дублировать, если появится такая необходимость.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониоринг #zabbix
Gotify – open source проект по доставке уведомлений. Это небольшой одиночный бинарник на Go, который собран даже под Windows. Он состоит из:
▪️API для приёма сообщений;
▪️веб интерфейса для управления и просмотра сообщений;
▪️Android клиента для получения сообщений и пушей на смартфоне.
То есть схема работы такая. Вы поднимаете свой сервер Gotify. Добавляете туда приложение, получаете для него токен. Идёте в тот же Proxmox, добавляете в качестве получения уведомлений Gotify сервер. Для этого нужно будет указать его URL и токен приложения. И всё. Теперь все уведомления от этого Proxmox будут в отдельном канале уведомлений в Gotify, где их можно будет просматривать. Если Gotify открыт в браузере, будете получать уведомления от браузера, если на смартфоне – от смартфона. Только надо не забыть его настроить, чтобы система позволяла работать приложению в фоне, чтобы приходили пуши.
Это почти то же самое, что и ntfy.sh, про который я когда-то рассказывал. Хотел дальше написать, что Gotify более популярный, но глянул звёзды на github, а у ntfy их 19.7k, против 11.9k у Gotify. Так что о популярности трудно так сказать. Тем не менее, не припоминаю, чтобы где-то видел явное указание поддержки ntfy, а вот Gotify встречал много раз.
Даже если в каком-то софте не заявлена поддержка Gotify, отправлять туда сообщения можно обычными веб хуками примерно так:
# curl "https://gotify.example.com/message?token=<apptoken>" -F "title=my title" -F "message=my message" -F "priority=5"Из консоли или скриптов можно прямо бинарником Gotify-CLI отправлять уведомления:
# gotify push -t "my title" -p 10 "my message"# echo my message | gotify pushПараметры URL и token указываются в конфигурационном файле, который формируется с помощью команды
gotify init. Запустить сервер можно в Docker:
# docker run -p 80:80 -v /var/gotify/data:/app/data gotify/serverПо умолчанию состояние хранится в sqlite3 базе. Можно настроить хранение в mysql или postgres. Параметры задаются в файле конфигурации сервера. Он небольшой, все значения описаны в документации. В проде сервер имеет смысл ставить за обратным прокси. Примеры настроек всех популярных веб серверов тоже есть в документации.
Пример того, как отправлять уведомления от Zabbix в Gotify через alertscripts. Задача скрипта преобразовать уровни значимости формата Zabbix в приоритеты Gotify. А дальше просто через curl отправка уведомлений.
Продукт простой и полезный. Позволяет с минимумом усилий навести порядок с уведомлениями от различных сервисов, выделив их в отдельный поток, не перемешивая с остальными уведомлениями на смартфоне или почте. Отлично изолирует работу от личной жизни. Не хватает только пересылки в какие-то другие системы. Gotify все уведомления замыкает на себя. Хотелось бы их ещё куда-то дублировать, если появится такая необходимость.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониоринг #zabbix
2👍145👎2
❓Возник вопрос вчера на тему OpenVPN. Можно как-то собирать статистику по подключениям пользователей и выводить отчёт? В целом, задача эта решаема, так как OVPN сервер выдаёт всю статистику о своём состоянии и пользователях как через встроенную консоль управления, так и через лог файл, который задаётся параметром status в конфигурационном файле.
Расскажу, как эту задачу решаю я. Вроде бы в контексте именно статистики по пользователям я про неё не писал. В интернете можно найти много вариантов настройки мониторинга за пользователями OpenVPN. Я лично по старинке использую тот, что когда-то давно попробовал и внедрил. Видел варианты более элегантные и удобные. Я уже просто привык к своему, он нормально работает, так что использую:
⇨ Мониторинг openvpn подключений пользователей в zabbix
Идея сбора статистики в том, что при подключении пользователя срабатывает триггер, при отключении он гаснет. И всё. Zabbix сам собирает всю статистику. Потом по ней можно какой-то отчёт сделать и выгрузить его в CSV. Триггерам можно повесить отдельный тэг и самую низкую важность, чтобы они больше нигде не отсвечивали.
Тут получается немного нецелевое использование системы мониторинга, но зато ничего самому по аналитике делать не надо: искать какую-то панель для этого, агрегировать данные и т.д.
Дополнительно можно сделать отдельный Dashboard с информацией об активных сессиях. Там же добавить виджет с историей подключений и отключений и т.д. В целом удобно и заменяет многие простые панели без непосредственно управления. При этом лично мне именно в Zabbix функциональность подобного рода нравится больше, чем примерно то же самое, но в Grafana с метриками от какого-нибудь экспортера Prometheus. По крайней мере из тех, что я видел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #openvpn
Расскажу, как эту задачу решаю я. Вроде бы в контексте именно статистики по пользователям я про неё не писал. В интернете можно найти много вариантов настройки мониторинга за пользователями OpenVPN. Я лично по старинке использую тот, что когда-то давно попробовал и внедрил. Видел варианты более элегантные и удобные. Я уже просто привык к своему, он нормально работает, так что использую:
⇨ Мониторинг openvpn подключений пользователей в zabbix
Идея сбора статистики в том, что при подключении пользователя срабатывает триггер, при отключении он гаснет. И всё. Zabbix сам собирает всю статистику. Потом по ней можно какой-то отчёт сделать и выгрузить его в CSV. Триггерам можно повесить отдельный тэг и самую низкую важность, чтобы они больше нигде не отсвечивали.
Тут получается немного нецелевое использование системы мониторинга, но зато ничего самому по аналитике делать не надо: искать какую-то панель для этого, агрегировать данные и т.д.
Дополнительно можно сделать отдельный Dashboard с информацией об активных сессиях. Там же добавить виджет с историей подключений и отключений и т.д. В целом удобно и заменяет многие простые панели без непосредственно управления. При этом лично мне именно в Zabbix функциональность подобного рода нравится больше, чем примерно то же самое, но в Grafana с метриками от какого-нибудь экспортера Prometheus. По крайней мере из тех, что я видел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #openvpn
1👍91👎3