В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.
Читать полностью »
Рубрика «sphinx search»
«В активном поиске»: как мы выбирали поисковый механизм для DLP-системы
2017-10-26 в 6:45, admin, рубрики: dlp, elastic search, oracle, oracle context, postgresql, solar dozor, sphinx, sphinx search, Блог компании Solar Security, информационная безопасность, поисковые технологииКак устроен поиск
2016-09-16 в 16:23, admin, рубрики: highload, sphinx, sphinx search, андрей аксёнов, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, поисковые технологии, Разработка веб-сайтов
Андрей Аксенов ( shodan, Разработчик поискового движка Sphinx)
Поиск устроен вот так:
Индексация – по большому счету, ничего сложного. Понятное дело, что по малому счету, там в каждой из трех «деталей» спрятан не то, что демон, а целое где-то стадо, где-то легион, не совсем понятно. Но концепция всегда простая. Все начинается с маленького простенького патчика к Многосерчу, а потом 15 лет этой херней занимаешься.
Берешь документы, разваливаешь их на ключевые слова. И просто взять и развалить документ на ключевые слова «мама, мыла, раму» – это ты не далеко ушел от grep’а, потому что потом все равно эти ключевые слова перебирать. Надо строить некую спец. структуру – полнотекстовый индекс. Вариантов для его построения человечество придумало в свое время довольно много, но, слава Богу, от всех отказалось и в нормальных продакшн системах, по большому счету, победил на данный момент вариант ровно один. Про него и буду рассказывать. Все остальные имеют скорее историческое значение, что ли, и практического интереса не представляют.
Читать полностью »
Простой способ мониторинга времени отклика Sphinx индексов c помощью Zabbix
2014-06-23 в 20:08, admin, рубрики: sphinx, sphinx search, метки: sphinx, sphinx searchЗадача
К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга 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>.
Сегодня IndexTank выключает все свои сервера
2012-04-10 в 17:52, admin, рубрики: search engine, sphinx, sphinx search, метки: search engine, sphinx searchКак сообщалось в @IndexTank на прошлой неделе:
IndexTank will be shutting down it's service on Tuesday, April 10th 2012 at 4PM (Pacific). email support@indextank.com for questions.
В первую очередь интересно будет узнать куда будут мигрировать такие крупные проекты как Reddit, Twitvid и Blip.tv.
Так как IndexTank открыл исходники Indextank-engine, то скорее всего эти ребята поднимут поисковые сервера сами.
Для большинства клиентов альтернативами на данный момент являются:
Совместимы с IndexTank API:
* IndexDen www.indexden.com/
* Searchify www.searchify.com/
Читать полностью »