Компания «Дистрибьютед Сервис» на рынке уже более 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);
— Расширение возможностей легкой кастомизации собираемых данных без перекомпиляции агента;