Задача
К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга Zabbix а ещё вы пользуетесь поисковым движком Sphinx. Он ищет быстро, но встроенных средств для живого мониторинга его производительности в разрезе индекса не имеет. К примеру, поисковых серверов у вас много и вы хотите соотносить потребление ресурсов системы каждым конкретным индексом дабы понимать — как распределять их по серверам — а так же видеть — какая из коллекций начинает отвечать дольше, чем хотелось бы — и понимать, коррелируется ли это с возрастанием пользовательской нагрузки или ещё чем-то.
Проектирование решения
Sphinx предоставляет возможность отображения более детальной информации потребления ресурсов на запрос с небольшими потерями производительности и небольшим увеличением размера лога. Для этого процесс searchd можно запустить с параметрами searchd --iostats --cpustats, при этом, начиная с версии 2.0.1-beta необходимо запускать searchd с конфигурацией query_log_format = sphinxql, для отображения полного лога. При этом строка лога выглядит так:
/* Sun Jun 8 16:05:00.098 2014 conn 531 real 0.01 wall 0.06 found 1 */ SELECT tmstmp FROM index ORDER BY tmstmp desc LIMIT 0,1; /* ios=0 kb=0.0 ioms=0.0 cpums=0.6 */
Где
conn — порядковый номер запроса со старта
real — время, потраченное на запрос суммарно со всех ядер
wall — общее время отклика для клиента
found — число найденных записей
ios — число I/O операций
kb — объём считанных файлов индекса
ioms — время iowait на запрос
cpums — время user CPU на запрос
1.) Снятие параметров с Sphinx:
Самым прозрачным и безопасным вариантом для основного процесса представляется запуск простого tail -F над текстовым логом — и построчная его обработка
2.) Забор параметров в Zabbix:
Среди возможных вариантов можно рассмотреть jmx, snmp, zabbix trap, — для jmx необходимо дополнительно поднимать jvm на каждом поисковом сервере, для snmp требуется проработка собственного дерева элементов MIB, остаётся zabbix trap — www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/trapper — штука, позволяющая отправлять данные в zabbix напрямую с помощью программы zabbix_sender — требует установки агента, но если у вас уже есть мониторинг Zabbix — наверняка он уже установлен.
3.) На средство реализации никаких ограничений по производительности не накладывается — минимально на linux-сервер предустановлен Python — его и выберем в качестве реализации
Решение
Исходный код решения можно скачать здесь: github.com/kuptservol/SphinxLogMonitor — решение представляет собой python-процесс, который запускает tail-подпроцесс, получает строку за строкой из query.log, парсит её по заданному regexp<log_parse_pattern> и отправляет данные на Zabbix, может аггрегировать данные, подсчитывая среднее арифметическое показателя за заданный период <time_aggregation_period_sec>.