Задача
К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга 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>.
1.) Для начала необходимо установить zabbix-agent, если он не установлен:
— tar -xzvf zabbix-x.x.x.tar.gz
— cd zabbix-x.x.x
— ./configure --enable-agent --prefix=/usr/local/zabbix
— make install
2.) Затем завести Host с поисковым сервером в Zabbix, создать Items типа Zabbix trapper указанием key на каждый наблюдаемый параметр лога
3.) Настроить в zabbix_conf.ini адрес zabbix-сервера [ZabbixServer], маппинг вытаскиваемых из строки параметров лога на созданные в zabbix key [ZabbixKeyLogFieldMapping]
4.) startSphinxLogMonitor.sh, stopSphinxLogMonitor.sh сделаны для возможности запуска демона в фоновом режиме и корректной остановки python-процесса и tail-подпроцесса
— make sh executable chmod +x startSphinxLogMonitor.sh
— chmod +x stopSphinxLogMonitor.sh
5.) Для старта: ./startSphinxLogMonitor.sh <путь до query.log> <путь до zabbix_conf.ini> <путь до log>
Для остановки: ./stopSphinxLogMonitor.sh
Автор: kuptservol
