Компания «Дистрибьютед Сервис» на рынке уже более 11 лет. Компания долго использовала собственную систему мониторинга баз данных, но со временем система перестала отвечать современным тенденциям и возрастающим потребностям. Компания проанализировала несколько систем мониторинга, и, взвесив все «за» и «против», остановила свой выбор на Zabbix.
Требования к решению
Компания проанализировала подходы к мониторингу баз данных непосредственно в Zabbix и сформулировала требования к агенту мониторинга:
– кросс-платформенное (Linux, Windows, AIX, Solaris, а может будет нужно HP-UX или FreeBSD?);
– поддержка разных СУБД (Oracle, MSSQL, MySQL, PostgreSQL);
– широкий спектр поддерживаемых версий ОС — от самых старых Windows Server 2003 или Oracle Linux 5 и выше, учитывая различные ОС клиентов;
– широкий спектр поддерживаемых версий СУБД — от самых старых PostgreSQL 9.4 или MariaDB 5.5, которые уже не поддерживаются, и выше;
– поддержка пула соединений к СУБД, учитывая стоимость установки соединения с базой;
– работа за NAT, поддержка шифрования (PSK/SSL) при работе с Zabbix Server (proxy), учитывая требования служб безопасности, а также тот факт, что многие базы данных находятся в закрытых сетях без выхода в Интернет, и единственным способом выхода в открытые сети — пограничный маршрутизатор с функцией NAT;
– быстрая работа агента-мониторинга для частого опроса состояния СУБД и малое потребление ресурсов (CPU, RAM);
– готовые модульные шаблоны под разные СУБД (Oracle, MSSQL, MySQL, PostgreSQL);
– максимально простая установка и настройка агента, чтобы его мог установку сам заказчик не обладая высокими техническими навыками;
– компактное решение — минимум зависимостей от сторонних библиотек, чтобы обеспечить возможность работы без выхода в Интернет и установки дополнительных модулей;
– возможность кастомизации собираемых данных без перекомпиляции/изменения кода самого агента, т. е. возможность написания кастомизированных SQL запросов в файле конфигурации;
– открытый исходный код, чтобы обеспечить возможность модернизации.
Инструменты Zabbix для мониторинга баз данных
1. ODBC мониторинг (встроенный модуль Zabbix)
Преимущества
– Встроен в Zabbix.
– Поддерживает большое количество СУБД (Oracle, MySQL, PostgreSQL, MSSQL, IBM DB2, MongoDB, Firebird и т. д.);
– Официальные шаблоны для популярных СУБД (MySQL, MSSQL, Oracle) (с февраля 2020 г.);
Недостатки
– Работает только на сервере, где запущен zabbix-server и zabbix-proxy, поэтому для мониторинга необходимо прямое соединение с СУБД, проводить мониторинг СУБД, находящихся за NAT – невозможно;
– Нет поддержки пула соединений. Каждый запрос — это новое соединение с СУБД (в версии 4.4 появился db.odbc.get, поэтому можно минимизировать количество запросов, и предобрабатывать данные);
– Платформенно-зависимое решение (решение нельзя использовать там где нет Linux-серверов);
2. Zabbix agent с помощью UserParameter (сторонние скрипты на bash/python/powershell/и т. д.)
Преимущества
– Работает непосредственно на сервере с СУБД (активный или пассивный режим агента, при активном NAT не страшен);
– Быстро и относительно легко можно написать свое решение;
– Кросс-платформенность за счет скриптов на разных языках;
Недостатки
– Нет поддержки пула соединений. Каждый запуск скрипта — это новое соединение с СУБД;
– При большом количестве собираемых метрик и высокой частоте опроса возрастает нагрузка на сервер (CPU, RAM);
– Нет единого решения под Windows/Linux/AIX и разные СУБД;
– Невозможность использования решения из-за инфраструктурных ограничений или политики безопасности (например, в отношении сторонних скриптов);
– Необходимо ставить дополнительное ПО (например, Python);
3. Модули для Zabbix Agent (libzbxpgsql, libzbxredis, zabbix-modulemysql и т. д.)
Преимущества
– Работают непосредственно на сервере СУБД (активный или пассивный режим агента, при активном NAT не страшен).
Недостатки
– Работают только на Linux;
– Каждый модуль рассчитан под определенную СУБД (нет единого модуля под все популярные СУБД);
– Поддержка многих модулей заброшена, модули и шаблоны не развиваются;
– Нет поддержки пула соединений. Каждый запрос — это новое соединение с СУБД;
– Многие модули нужно самостоятельно собирать из исходников, для этого нужен квалифицированный инженер;
4. Внешние агенты (mamonsu, DBforBIX, ZabbixDBA, zbxdb, zbxora и т. д.)
Преимущества
– Работают непосредственно на сервере СУБД (активный или пассивный режим агента, при активном NAT не страшен);
– Многие агенты кросс-платформенны, но не все проверены на Windows/AIX;
– Многие агенты поддерживают пул соединений;
Недостатки
– Некоторые агенты давно заброшены и не развиваются, нет готовых шаблонов под разные СУБД (DBforBIX, ZabbixDBA);
– Сложные настройки некоторых агентов (DBforBIX, zbxdb);
– Невозможность использования решения из-за инфраструктурных ограничений или политики безопасности (например, требуется PSK/SSL-шифрование при передаче данных мониторинга);
– Необходимо ставить дополнительное ПО (например Python, Java или Perl);
5. Zabbix Agent 2 (Redis, Memcached, PostgreSQL, MySQL, недавно появился плагин Oracle)
Преимущества
– Работает непосредственно на сервере с СУБД (активный или пассивный режим агента, при активном NAT не страшен, поддержка шифрования PSK/SSL);
– Написан на Golang — кросс-платформенный, но только под Linux и Windows;
– Поддержка мониторинга Redis, Memcached, PostgreSQL, MySQL «из коробки». Недавно появился плагин Oracle;
– С 17.09.2020 доступна поддержка в виде службы в Windows [ZBXNEXT 6023];
Недостатки
– Написан на Golang — недостаточно кросс-платформенный — AIX версии < 7.2 не поддерживается компилятором Golang, Solaris или FreeBSD под вопросом;
– Пока реализована поддержка далеко не всех популярных СУБД (нет MSSQL);
– Не поддерживает работу в виде демона в Linux;
Доработанный Zabbix Agent
Ни одно решение не отвечает всем требованиям компании. 2 года назад компания начала внедрение мониторинга СУБД с помощью Zabbix на основе UserParameter с использованием собственных скриптов и шаблонов.
– Для Linux/AIX — bash (1 скрипт, порядка 7000 строк кода);
– Для Windows — powershell/c# (несколько скриптов, 4000 строк кода);
Но через 2 года пройдя по всем проблемам, мы осознали, что нужно новое решение, которое бы отвечало нашим требованиям (см. выше). Примерно за 1 месяца (декабрь 2019) я доработал Zabbix agent (на Си) чтобы он мог осуществлять базовый мониторинг 3 популярных баз (Oracle, MySQL, PostgreSQL) под Windows/Linux/AIX.
Что может доработанный Zabbix-agent ?
– Агент остался кросс-платформенным (поддерживается сборка под Linux, Windows, AIX, Solaris, etc);
– Агент поддерживает мониторинг Oracle, MySQL, PostgreSQL, MSSQL на всех ОС без дополнительных скриптов (для Oracle полностью отказаться от скриптов и внешних утилит невозможно в виду специфики самой СУБД);
– Пула соединений пока нет, но планируется реализовать в ближайшее время (декабрь 2020);
– Zabbix Agent по-прежнему поддерживает мониторинг параметров ОС, шифрование (PSK/SSL) и другие базовые возможности;
– Быстрый мониторинг, малое потребление ресурсов CPU и RAM;
– Используются готовые модульные шаблоны для мониторинга Oracle, MySQL, PostgreSQL для разных ОС;
– Минимум настроек у агента;
– Для Oracle/MySQL нужно только указать логин и пароль для подключения к СУБД в zabbix_agentd_dbmon.conf, все остальное настраивается через макросы через веб-интерфейс.
– Для Oracle возможна работа как с подключением в формате Easy connect, так и через tnsname (опция OracleUseLocalEnv=1 + переменные среды ORACLE_SID/ORACLE_HOME или TWO_TASK/LOCAL);
– Для PostgreSQL/MySQL строка подключения полностью указывается через веб-интерфейс через макрос;
– Поддержка макросов для Oracle (красные – обязательные).
– Компактное решение с минимумом зависимостей;
– Для Windows используется всего 12 бинарных файлов + файл конфигурации zabbix_agentd_dbmon.conf, есть инсталлятор, в котором можно настроить базовые параметры;
– Для RedHat-подобных дистрибутивов используется собственный репозиторий агента, все ставиться из него – минимум телодвижений;
– Есть отдельные сборки агента под разные Oracle RDBMS (11g/12c/18c/19c) + скрипт на bash для автоматизации развертывания;
– Возможность кастомизации собираемых данных — возможность создавать собственные элементы данных и писать SQL запросы в файле конфигурации без перекомпиляции агента (пока реализовано для MySQL и PostgreSQL).
Доработанный Zabbix Agent в цифрах
Oracle
> 90 метрик Oracle (версии 10i/11g/12c/18c/19c), а так же Oracle RAC и Oracle ASM;
> 70 триггеров:
– мониторинг основных показателей экземпляра (uptime, доступность, статус, сессии, процессы, лимиты по дата-файлам, блокировки, статус archiver и т.д.);
– мониторинг Single database/Pluggable database (размер, role, open_mode, flashback и т. д.);
– мониторинг Fast Recovery Area (FRA);
– мониторинг бэкапов;
– мониторинг permanent, undo, temporary tablespace;
– мониторинг Dataguard (MRP status, apply и transport lag);
– мониторинг ошибок в alert.log (ORA-00600 и другие);
– мониторинг Archive Log Destination;
– мониторинг параметров экземпляра (изменение дефолтных параметров);
– мониторинг Automatic Storage Management (Oracle ASM);
– мониторинг работы листенера и сервисов;
MySQL
> 120 метрик MySQL (MySQL 5.5-7/8.0, MariaDB 5.5/10.1-4, Percona 5.6-7/8.0);
> 25 триггеров:
– мониторинг основных показателей экземпляра (uptime, доступность, версия, threads, query cache, slow query, innodb buffer pool и т. д.) и возможность легко добавлять новые наблюдаемые показатели через веб-интерфейс;
– мониторинг основных параметров (query cache, репликации) и возможность легко добавлять новые наблюдаемые параметры через веб-фронтенд;
– мониторинг и расчет основных показателей производительности (Buffer pool dirty, Buffer pool efficiency, Buffer pool utilization, Query cache efficiency и т. д);
– мониторинг каждой базы (размер, кодировки);
– мониторинг репликации (статус, лаг);
– мониторинг размеров больших таблиц (TOP10 по размеру, по количеству записей);
– мониторинг блокировок в InnoDB;
– мониторинг error.log на предмет ошибок, блокировок и т. д.
PostgreSQL
> 100 метрик PostgreSQL (9.4 – 12.2);
> 15 триггеров:
– мониторинг основных показателей экземпляра (uptime, доступность, версия);
– количество соединений в разных состояниях;
– чекпойнты;
– блокировки;
– подготовленные транзакции;
– процессы autovacuum;
– скорость генерации WAL;
– скорость чтения и записи;
– размеры БД, deadlock и т. д.
Планы на будущее
– Разработка мониторинга MSSQL (ноябрь 2020);
– Реализация пула соединений к СУБД (декабрь 2020);
– Расширение возможностей легкой кастомизации собираемых данных без перекомпиляции агента;