Продолжаем цикл статей о том, как мы постигали ES в процессе создания Ambar. Первая статья цикла была о Хайлайтинге больших текстовых полей в ElasticSearch.
В этой статье мы расскажем о том как заставить ES работать быстро с документами более 100 Мб. Поиск в таких документах при подходе "в лоб" занимает десятки секунд. У нас получилось уменьшить это время до 6 мс.
Заинтересовавшихся просим под кат.
У нас используется система управления проектами и задачами Redmine. Мы продолжаем допиливать ее под свои нужды, чтобы повысить удобство работы и расширить функционал. Очередной задачей стало ускорение поиска.
С тех пор как количество задач в Redmine выросло до нескольких сотен тысяч, время на обработку поискового запроса стало занимать десятки секунд, что недопустимо долго для нас. Поэтому мы решили внедрить полнотекстовый поиск на основе Elasticsearch. Про это и будет данный пост.
Читать полностью »
Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.
Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.
Как мы писали ранее, в качестве основной базы для поиска на сайте используется elasticsearch. Поиск в elastic работает очень быстро и из коробки доступно много полезных функций для работы с данными — полнотекстовый поиск, неточный поиск, всевозможные методы агрегации и тд.
И в отличии от классических SQL баз данных или noSQL типа MongoDB здесь очень удобно делать неточный поиск по всему документу. Для этого используется синтаксис Query DSL. Для полнотекстового поиска по всему документу есть несколько поисковых запросов. У себя на сайте мы используем тип query_string. Этот запрос поддерживает Lucene синтаксис, который позволяет и нам и пользователю создавать сложные запросы в google-style. Вот примеры таких запросов:
title:apache AND title:vulnerability
type:centos cvss.score:[8 TO 10]
Можно сделать вот такой простой запрос и все:
{
"query": {
"query_string": {
"query": "exploit wordpress"
}
}
}
Но начав впервые использовать query_string, вы столкнетесь с тем, что поиск выдает не то, что вы хотите видеть. Как же добиться от elasticsearch внятного результата поиска?
Читать полностью »
Безопасная настройка TLS всегда был головной болью. Как для владельцев небольших ресурсов, так и для компаний, размер инфраструктуры которых может достигать нескольких сотен или даже тысяч доменов. Проблемы с TLSSSL появляются постоянно — уязвимости в самих протоколах, крипто-алгоритмах или их имплементациях. От всем известных Poodle и HeartBleed, до достаточно экзотичных и свежих (CVE-2016-2107) проблем с AES-NI.
А к чему приводят проблемы с TLS?
К краже учетных записей пользователей, администраторов, внедрению в трафик вредоносного контента, рекламы или, как это было с HeartBleed, даже к прямому доступу к памяти сервера.
Давайте взглянем на картину в целом.
На июль 2016 по данным проекта SSL Pulse, который анализирует настройки Alexa Top 200k доменов:
А значит, у всех нас проблемы!
Все кто использовал Elasticsearch каластер для своих нужд (особенно для логирования и как основную базу данных) на больших нагрузках сталкивался с проблемами консистентности и масштабируемости. Когда требуется распараллелить нагрузку на Elasticsearch обычно применялись статические решения то типу NGINX+Elasticsearch. Это позволяет распараллелить нагрузку, но выглядит не слишком гибко. Особенно если учесть что ноды могут сами выпадать из кластера и простой хелсчек покажет что все отлично, а на самом деле нода перегружена, исключена из кластера. В любом случае хотелось бы иметь данные о состоянии кластера из первых рук, а не довольствоваться простыми проверками.
Итак, приступим к построению балансировки .
В данном случае мы будем использовать CAT node API, которое является частъю мощьнейшего CAT API, который является инструментом поиска заголовков по Elasticsearch клстреру.
Мы будем использовать только Gobetween и встроенные механизмы Elasticsearch для балансировки записи /чтения СRUD (DATA) нод при произвольном количестве/статусе нод в кластере.
В какой-то момент разработки проекта встал вопрос поиска по большому количеству текстов. Причем, тексты имеют различную длину: от твиттов до больших статей. Сначала, основным поисковым движком был выбран встроенный в Postgres _tsvector. Для поиска по простым правилам его было вполне достаточно. Массив текстов рос с большой скоростью, а правила поиска усложнялись, поэтому встроенный движок уже не покрывал требований.
Да, существует sphinx, у него есть отличная интеграция с Postgres, но была цель найти решение для использования elasticsearch с Postgres. Почему? elasticsearch показывал хорошие результаты в некоторых case-ах проекта. Да и уже был сервер с ним для хранения логов logstash-а. Также было желание найти такой инструмент, который полностью возьмет на себя синхронизацию данных.
В результате всего на просторах сети был найден проект ZomboDb, который как раз подходил под требования.Читать полностью »
Что обычно делает python-программист, когда его отправляют воевать с ошибкой?
Сначала он лезет в sentry. Здесь можно найти время, сервер, подробности сообщения об ошибке, traceback и, может быть, какой-нибудь полезный контекст. Затем, если этих данных недостаточно, программист идет c бутылкой к админам. Те залезают на сервер, ищут это сообщение в файловых логах, и, может быть, находят его и некоторые предшествующие ошибке записи, которые в редких случаях могут помочь в расследовании.
А что делать, если в логах только loglevel=ERROR, а ошибка настолько крута, что ее локализация требует сопоставления логики поведения нескольких различных демонов, которые запущены на десятке серверов?
Решение — централизованное хранилище логов. В самом простом случае — syslog (за 5 лет, что был развернут в rutube, не использовался ни разу), для более сложных целей — ELK. Скажу честно, "ластик" — крут, и позволяет быстро крутить разнообразную аналитику, но вы интерфейс Kibana видели? Этой штуке так же далеко до консольных less/grep, как винде до линукса. Поэтому мы решили сделать свой велосипед, без Java и Node.js, зато с sphinxsearch и Python.
По долгу службы, мне часто приходится анализировать NFS-трафик. Wireshark является моим основным инструментом и для него я даже создавал расширение на lua. Но чего-то не хватало. И вот две недели назад я наткнулся на новый для меня инструмент Packetbeat. К сожалению, paketbeat не поддерживает не поддерживал NFS, но этот недостаток мне удалось исправить.
Paketbeat — это один из инструментов из комплекта beats от создателей elasticsearch, logstash и kibana. Это отправитель (shipper) данных в elasticsearch, который слушает сетевой трафик, конвертирует его в json-записи и посылает в elasticsearch. Если вы используете Kibana4, то есть стандартные панели для визуализации собранного трафика. На данный момент, packetbeat распознаёт TCP, UDP, DNS, ICMP, HTTP, memcache, MongoDB, redis, PostgreSQL, MySQL, thrift и, теперь уже, NFS. Где-то внутри, packetbeat использует libpcap.
В Badoo несколько десятков «самописных» демонов. Большинство из них написаны на Си, остался один на С++ и пять или шесть на Go. Они работают примерно на сотне серверов в четырех дата-центрах.
В Badoo проверка работоспособности и обнаружение проблем с демонами лежат на плечах отдела мониторинга. Коллеги с помощью Zabbix и скриптов проверяют, запущен ли сервис, отвечает ли он на запросы, а также следят за версиями. Кроме того, в отделе анализируется статистика демонов и скриптов, работающих с ними, на предмет аномалий, резких скачков и т.п.
Однако у нас до недавнего времени не было очень важной части — сбора и анализа логов, которые каждый демон пишет локально в файлы на сервере. Зачастую именно эта информация помогает на самом раннем этапе поймать проблему или постфактум понять причины отказа.
Мы построили такую систему и спешим поделиться подробностями. Наверняка у кого-то из вас будет стоять похожая задача, и прочтение данной статьи убережет от ошибок, которые мы успели совершить.
Читать полностью »
