Поднимаем сервер мониторинга Zabbix 7 + TimescaleDB в docker

• docker-compose.yml — файл описания сервисов, запускаемых в docker контейнерах:
  • Секция NETWORK — определяет две виртуальные сети docker:
    • zbx_net_backend — изолированная сеть для взаимодействия контейнеров postgres-server, zabbix-server, zabbix-web и zabbix-agent;
    • zbx_net_frontend — сеть с доступом к контейнерам со стороны хостовой ОС: для контейнеров zabbix-server и zabbix-web.
  • Секция SERVICES — определяет параметры запускаемых сервисов/контейнеров:
    • postgres-server — сервис СУБД TimescaleDB;
    • zabbix-server — сервис Zabbix сервера;
    • zabbix-web — сервис веб интерфейса для Zabbix сервера (под капотом nginx + php-fpm);
    • zabbix-agent — сервис агента Zabbix для сбора метрик с самого сервера Zabbix.
  • Секция SECRETS — определяет файлы, содержащие чувствительную информацию, которые прокидываются внутрь контейнеров postgres-server, zabbix-server и zabbix-web:
    • POSTGRES_USER (файл ./env/.POSTGRES_USER) — имя пользователь для базы данных Zabbix в СУБД TimescaleDB;
    • POSTGRES_PASSWORD (файл ./env/.POSTGRES_PASSWORD) — соответственно, пароль пользователя.
• env — директория с файлами, содержащие переменные окружения, значения которых передаются внутрь контейнера при его запуске:
  • .env_db — параметры для postgres-server;
  • .env_srv — параметры для zabbix-server;
  • .env_web — параметры для zabbix-web;
  • .env_agent — параметры для локального zabbix-agent;
  • .POSTGRES_PASSWORD — пароль пользователя в БД zabbix;
  • .POSTGRES_USER — имя пользователя в БД zabbix.
• src — директория с исходными файлами для сборки кастомного контейнера zabbix-server с расширенным функционалом:
  • alertscripts — директория с файлами для отправки уведомлений в Telegram:
  • docker-entrypoint.sh — скрипт подготовки окружения внутри контейнера (не изменялся);
  • Dockerfile — кастомизированный файл описания сборки образа;
  • externalscripts — директория со скриптом мониторинга делегирования домена.

adgroup — команда создания группы;

• --system — помечает группу, как системную и применяет к ней установленные политики;
• --gid 1995 — указывает явный идентификатор группы (GID) — в данном случае 1995 (именно такой GID задают разрабы Zabbix в своих контейнерах);
• zabbix — название создаваемой группы;

adduser — команда создания пользователя

• --system — помечает группу, как системную и применяет к ней установленные политики;
• --gecos — позволяет задать описание пользователя;
• --disabled-password — отключает пароль у пользователя (в таком случае под ним нельзя авторизоваться в системе с помощью пароля);
• --uid 1997 — указывает явный идентификатор пользователя (UID) — в данном случае 1997 (именно такой UID задают разрабы Zabbix в своих контейнерах);
• --ingroup zabbix — добавляет пользователя в созданную ранее группу zabbix;
• --shell /sbin/nologin — в качестве оболочки пользователя устанавливает nologin — под ней невозможно авторизоваться в системе;
• --home /opt/zabbix/zabbix_data — задает домашний каталог пользователя, в нашем случае это директория с файлами сервисов zabbix;
• zabbix — имя создаваемого пользователя.

Команда tr -cd с помощью механизма перенаправления стандартных потоков получает на ввод латинские буквы и цифры (класс символов [:alnum:]), генерируемые псевдоустройством /dev/urandom. Затем команда head, получая данные по конвейеру, с помощью ключа -c отбирает 30 первых символов (байт). И в конце, полученная псевдорандомная строка передается на ввод команде tee, запущенной от имени суперпользователя. Полученные данные tee записывает в указанный файл (/opt/zabbix/env/.POSTGRES_PASSWORD) и дублирует вывод в стандартный поток (stdout).

1. Если Zabbix сервер развернут на локальной машине

Просто вбейте в браузере URL 😁😁😁:

http://127.0.0.1:8080/

2. Если Zabbix сервер развернут на удаленном сервере, который находится в локальной или VPN сети

В таком случае отредактируйте настройки сети для сервисов zabbix-server и zabbix-web в docker-compose.yml файле.

Например, внутренний адрес моего сервера в сети VPN: 192.168.122.24. Правлю docker-compose.yml:

sudo vim /opt/zabbix/docker-compose.yml

zabbix-server:

zabbix-web:

Перезапускаю все контейнеры:

sudo docker compose -f /opt/zabbix/docker-compose.yml down

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d

sudo docker ps

На подключенном к VPN сети клиенте открываю в браузере такой URL:

http://192.168.122.24:8080/

3. Если Zabbix сервер развернут на удаленном сервере и не подключен к локальной или VPN сети

При таком раскладе можно прокинуть SSH порт либо открыть доступ напрямую или через обратный прокси, наподобие nginx. Я рассмотрю лишь первый случай, как самый простой. А еще потому, что два других выходят за рамки данной статьи 😜.

На клиенте открываем терминал и выполняем:

ssh -L 8080:127.0.0.1:8080 user@example.com

Где (по порядку):

• -L – ключ перенаправления локального порта;
• 8080 – порт, который будет слушать клиентская машина и перенаправлять его на 8080 порт сервера;
• 127.0.0.1 – адрес сервера, на котором он слушает порт;
• 8080 – соответственно порт, на который перенаправляем;
• user@example.com – пользователь и адрес SSH сервера.

В моём примере команда такая:

Теперь открываем браузер и переходим по адресу: http://127.0.0.1:8080/

Доступ к веб интерфейсу будет пока открыта SSH сессия.

Не буду сильно вдаваться в подробности настройки Zabbix, т.к. это тема не одной статьи 🤯. Покажу лишь как поменять язык интерфейса, создать нового пользователя с админскими правами, отключить стандартного Admin и настроить локальный Zabbix agent для мониторинга самого Zabbix сервера.

Все действия отображены в картинках и особо в комментариях не нуждаются 😏.

Смена языка

Создание новго пользователя

И перезаходим в интерфейс уже под новым пользователем:

Отключение стандартного пользователя Admin

Подключение локального Zabbix agent

Данный агент был поднят нами, в момент запуска всей инсталяции и доступен по доменному имени zabbix-agent внутри сети контейнеров.

Тут обязательно выбираем «Подключаться через» — DNS:

Теперь переходим на страницу «Мониторинг» — «Проблемы». Через несколько минут проблема с доступностью локального zabbix-agent должна решиться:

В начале статьи мы создали сервисного пользователя zabbix. Используем его для безопасного запуска сервисов стека Zabbix.

Настройка sudoers для запуска Zabbix от сервисного пользователя

Недавно я разбирал тонкости механизма повышения привилегий в Linux. Для лучшего понимания дальнейших действию рекомендую к прочтению: Командная строка Linux, повышение привилегий: команды su, sudo 😌.

Создаем новый файл с описанием ограниченных полномочий для пользователя zabbix:

sudo visudo -f /etc/sudoers.d/zabbix

И наполняем следующим:

Cmnd_Alias ZBX = \
    /usr/bin/docker compose -f /opt/zabbix/docker-compose.yml up, \
    /usr/bin/docker compose -f /opt/zabbix/docker-compose.yml down

zabbix ALL = (:docker) NOPASSWD: ZBX

Разрешаем пользователю zabbix запуск и остановку сервисов, описанных в нашем docker-compose.yml, от имени привилегированной группы docker с помощью sudo.

Сохраняем файл и закрываем редактор.

Создание systemd service файла

Открываем на редактирование:

sudo vim /etc/systemd/system/zabbix.service

И наполняем:

[Unit]
Description=Zabbix service
Requires=docker.service
After=docker.service

[Service]
Restart=always
RestartSec=5
User=zabbix
ExecStart=/usr/bin/sudo --group=docker /usr/bin/docker compose -f /opt/zabbix/docker-compose.yml up
ExecStop=/usr/bin/sudo --group=docker /usr/bin/docker compose -f /opt/zabbix/docker-compose.yml down

[Install]
WantedBy=multi-user.target

Сохраняем, закрываем. После этого останавливаем запущенные контейнеры, перечитываем конфигурацию systemd, активируем автозапуск сервиса zabbix и запускаем его:

sudo docker compose -f /opt/zabbix/docker-compose.yml down

sudo systemctl enable --now zabbix

sudo systemctl status zabbix

Проверяем статус контейнеров:

sudo docker ps

Все запущено. Вот и славно 🙂.

Раз уж мы разворачивали Zabbix в docker, логичным действием будет поднятие Zabbix агентов аналогичным способом.

Очевидно, для этого необходим установленный и запущенный Docker engine.

Скачивание файлов проекта и создание сервисного пользователя

Клонируем репозиторий с файлами:

sudo git clone https://github.com/r4ven-me/zabbix-agent /opt/zabbix-agent

Как и в случае сервера, создаем сервисного пользователя для запуска Zabbix агента:

sudo addgroup --system --gid 1995 zabbix

sudo adduser --system --gecos "Zabbix agent" \
    --disabled-password --uid 1997 --ingroup zabbix  \
    --shell /sbin/nologin --home /opt/zabbix-agent/data zabbix

Корректируем .env файл — файл с параметрами Zabbix агента.

sudo vim /opt/zabbix-agent/.env

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

В моем примере такие данные:

• адрес Zabbix сервера: 192.168.122.24
• адрес Zabbix агента: 192.168.122.105
• хостнейм Zabbix агента: zabbix-agent.example.com

Описание всех параметров смотрите тут.

Теперь на всякий случай проверяем готовый sudoers файл и если все ок — копируем его в /etc/sudoers.d/:

sudo visudo -c -f /opt/zabbix-agent/zabbix_agent

sudo cp /opt/zabbix-agent/zabbix_agent /etc/sudoers.d/

Далее копируем файл сервиса systemd, перечитываем конфигурацию и запускаем zabbix-agent:

sudo cp /opt/zabbix-agent/zabbix-agent.service /etc/systemd/system/

sudo systemctl daemon-reload

sudo systemctl enable --now zabbix-agent

Имейте ввиду, что при первом запуске docker будет качать образ из реестра.

Проверить статус агента можно такими командами:

sudo systemctl status zabbix-agent

sudo journalctl -fu zabbix-agent

sudo docker ps

Zabbix agent запущен.

Нюанс. Если у вас на сервере примонтировано множество внешних разедлов, необходимо их добавить в блок volume в docker-compose.yml, чтобы Zabbix агент их обнаружил.

Добавление Zabbix агента на Zabbix сервер

Тут почти все в картинках 😇.

Переходим в «Мониторинг» — «Узлы сети» и через некоторое время:

Уря!🥳🥳🥳

А теперь интересное 🧐. Для реализации возможности отправки аварийных уведомлений в Telegram с графиками, я пересобрал контейнер zabbix-server, добавив в него интерпретатор Python, специальный venv и файлы из GitHub репозитория разработчика xxsokolov — данный способ отмечен на официальном сайте Zabbix, как валидный 👌.

В инструкции ниже, рассмотрен вариант использования моего образа: r4venme/zabbix-server-pgsql:alpine-7.0.3, но вы также можете собрать собственный. Все файлы для сборки вы найдете в скачанном репозитории из начала статьи, в папке src.

Приступаем к настройке.

Создание типа оповещения (веб интерфейс)

• Имя (произвольное): Alerter
• Тип: Скрипт
• Имя скрипта: zbxTelegram.py
• Параметры скрипта:
  • {ALERT.SENDTO}
  • {ALERT.SUBJECT}
  • {ALERT.MESSAGE}

Далее переходим на вкладку шаблоны и добавляем 2 штуки: для проблем и для восстановления:

Шаблон для проблем:

• Тип сообщения: Проблема
• Тема: {Problem} Проблема ({TRIGGER.SEVERITY})
• Сообщение:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
    <body>
        <messages>
<![CDATA[
Проблема: {EVENT.NAME}

Хост: {HOST.NAME} ({HOST.IP})
Начало: {EVENT.TIME} {EVENT.DATE}

Последнее значение: {ITEM.LASTVALUE1}

###########################
]]>
        </messages>
    </body>
    <settings>
        <graphs>True</graphs>
        <hostlinks>True</hostlinks>
        <graphlinks>False</graphlinks>
        <acklinks>True</acklinks>
        <eventlinks>True</eventlinks>
        <triggerlinks>True</triggerlinks>
        <eventtag>False</eventtag>
        <eventidtag>False</eventidtag>
        <itemidtag>False</itemidtag>
        <triggeridtag>False</triggeridtag>
        <actionidtag>False</actionidtag>
        <hostidtag>False</hostidtag>
        <zntsettingstag>True</zntsettingstag>
        <zntmentions>True</zntmentions>
        <keyboard>True</keyboard>
        <graphs_period>default</graphs_period>
        <host>{HOST.HOST}</host>
        <itemid>{ITEM.ID1} {ITEM.ID2} {ITEM.ID3} {ITEM.ID4}</itemid>
        <triggerid>{TRIGGER.ID}</triggerid>
        <eventid>{EVENT.ID}</eventid>
        <actionid>{ACTION.ID}</actionid>
        <hostid>{HOST.ID}</hostid>
        <title><![CDATA[{HOST.NAME} - {EVENT.NAME}]]></title>
        <triggerurl><![CDATA[{TRIGGER.URL}]]></triggerurl>
        <eventtags><![CDATA[{EVENT.TAGS}]]></eventtags>
    </settings>
</root>

После заполнения нажимаем «Добавить»:

Затем еще раз «Добавить» следующий:

Шаблон восстановления:

• Тип сообщения: Восстановление проблемы
• Тема: {Resolved} Восстановление
• Сообщение:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
    <body>
        <messages>
<![CDATA[
Проблема: {EVENT.RECOVERY.NAME}

Хост: {HOST.NAME} ({HOST.IP})
Продолжительность: {EVENT.DURATION} 
Время восстановления: {EVENT.RECOVERY.TIME} {EVENT.RECOVERY.DATE}

Последнее значение: {ITEM.LASTVALUE1}

###########################
]]>
        </messages>
    </body>
    <settings>
        <graphs>True</graphs>
        <hostlinks>True</hostlinks>
        <graphlinks>False</graphlinks>
        <acklinks>True</acklinks>
        <eventlinks>True</eventlinks>
        <triggerlinks>True</triggerlinks>
        <eventtag>False</eventtag>
        <eventidtag>False</eventidtag>
        <itemidtag>False</itemidtag>
        <triggeridtag>False</triggeridtag>
        <actionidtag>False</actionidtag>
        <hostidtag>False</hostidtag>
        <zntsettingstag>True</zntsettingstag>
        <zntmentions>True</zntmentions>
        <keyboard>True</keyboard>
        <graphs_period>default</graphs_period>
        <host>{HOST.HOST}</host>
        <itemid>{ITEM.ID1} {ITEM.ID2} {ITEM.ID3} {ITEM.ID4}</itemid>
        <triggerid>{TRIGGER.ID}</triggerid>
        <eventid>{EVENT.ID}</eventid>
        <actionid>{ACTION.ID}</actionid>
        <hostid>{HOST.ID}</hostid>
        <title><![CDATA[{HOST.NAME} - {EVENT.NAME}]]></title>
        <triggerurl><![CDATA[{TRIGGER.URL}]]></triggerurl>
        <eventtags><![CDATA[{EVENT.TAGS}]]></eventtags>
    </settings>
</root>

Далее «Добавить»:

И в конце еще раз тут:

Должно получиться вот так:

Создание сервисного пользователя (веб интерфейс)

Теперь создадим сервисного пользователя с для отправки уведомлений:

Заполняем все нужные поля:

От выбора темы зависит фон графиков в уведомлениях.

После этого переходим на вкладку «Оповещения» и в поле «Отправлять на» указываем Telegram ID чата или группы (инструкция с оф. сайта Zabbix, как получить ID):

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

И в конце клик на основной «Добавить»:

Настройка условий оповещений (веб интерфейс)

Идем в «Действия триггеров» и создаем новое:

Задаем имя и добавляем условие. В условии указываем 2 шаблона, как на скрине:

Далее переходим на вкладку «Операции» и там добавляем 2 действия: для «Операции» и «Операции восстановления»:

Указываем адресата — нашего сервисного пользователя, у которого прописывали ID группы/чата в телеге. Тут же указываем способ отправки: тот, что мы создали ранее:

Примерно так:

Правка docker-compose.yml (консоль сервера)

Возвращаемся на сервер и открываем на редактирование:

sudo vim /opt/zabbix/docker-compose.yml

Правим сервис zabbix-server, блок image. Текущую строку комментируем, и расскоменнтирываем строку с адресом собранного мной образа:

# image: zabbix/zabbix-server-pgsql:alpine-7.0.3
image: r4venme/zabbix-server-pgsql:alpine-7.0.3

Сохраняем и перезапускаем zabbix-server:

sudo systemctl restart zabbix

sudo journalctl -fu zabbix

sudo docker ps

После запуска создаем папку скриптов алармов, из докер контейнера zabbix-server копируем туда конфиг файл скрипта отправки уведомлений в телегу и меняем его владельца:

sudo mkdir -p /opt/zabbix/zabbix_data/server/alertscripts/

sudo docker cp zabbix-server:/usr/lib/zabbix/alertscripts/zbxTelegram_config.py \
    /opt/zabbix/zabbix_data/server/alertscripts/

sudo chown -R zabbix:zabbix /opt/zabbix/zabbix_data/server/alertscripts/

Вновь открываем docker-compose.yml:

sudo vim /opt/zabbix/docker-compose.yml

Для сервиса zabbix-server и в блоке volume расскоментирываем такую строку:

- ./zabbix_data/server/alertscripts/zbxTelegram_config.py:/usr/lib/zabbix/alertscripts/zbxTelegram_config.py

Не забываем сохраниться.

Настройка отправки (консоль сервера)

Осталось совсем чуть-чуть 🥺.

Открываем на редактирование скопированный конфиг файл:

sudo vim /opt/zabbix/zabbix_data/server/alertscripts/zbxTelegram_config.py

И указываем токен своего бота (как получить) в строке tg_token внутри одинарных кавычек:

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

zabbix_api_url — это внутренний сетевой адрес контейнера. Не трогаем, если вы его не меняли.

Пересоздаем контейнер zabbix-server:

sudo docker compose -f /opt/zabbix/docker-compose.yml down zabbix-server

sudo docker compose -f /opt/zabbix/docker-compose.yml up -d zabbix-server

Проверка (консоль сервера)

Проверяем отправку сообщений в командной строке:

sudo docker exec -it zabbix-server \
    /usr/lib/zabbix/alertscripts/zbxTelegram.py 1234567890 test test

Где 1234567890 — ID чата или группы в телеге.

Работает 👍.

Проверка на практике

Если вы подключили локальный zabbix-agent на шаге начальной настройки, то для проверки просто остановите его командой:

sudo docker compose -f /opt/zabbix/docker-compose.yml stop zabbix-agent

Идем в веб интерфейс по пути: «Мониторинг» — «Проблемы». Через несколько минут, агент получит статус «Недоступен», появится проблема на соответствующей веб панели и вам должно прийти уведомление в Telegram.

Сообщение пришло, отлично. Теперь запускаем агента:

sudo docker compose -f /opt/zabbix/docker-compose.yml start zabbix-agent

Через несколько минут он восстановится в веб панели и в телеграм придет соответствующее уведомление:

Прэлэсть 🤤.