Простий спосіб моніторингу часу відгуку Sphinx індексів c допомогою Zabbix

    

Завдання

 Наприклад, у вас є вже налаштований і поширений по всій компанії сервіс моніторингу 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
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.