В этом материале я расскажу о том, как в Яндекс.Деньгах организована система сбора и доставки серверных логов платежных сервисов. Доставкой логов я занимаюсь весь последний год, и за это время накопилось достаточно нюансов, чтобы поделиться опытом с общественностью.
Система построена на базе стека EHK (Elasticsearch/Heka/Kibana), с прицелом на работу практически в реальном времени. Особый упор сделаю на тонкие места и нюансы обработки миллиардов строк текста в сутки.Читать полностью »
В первой части статьи мы обнаружили проблемы с хранением данных приложений в блокчейне. Во второй части мы описали требования к хранилищу данных и рассмотрели, насколько существующие реализации отвечают этим требованиям. Результаты были неутешительные — удовлетворительной реализации не нашлось. В данной части мы предложим концепцию децентрализованного хранилища данных, которое удовлетворяет поставленным требованиям. Разумеется, для более глубокого понимания сути происходящего рекомендуется просмотреть две предыдущие части.
Читать полностью »
GitLab спроектирован с расчетом на то, чтобы давать вам конструктивную обратную связь на всех этапах жизненного цикла приложения и в разных временных рамках.
В версии GitLab 9.1 появились канареечные развертывания. Они позволяют вам развертывать новый код на небольшой части вашей инфраструктуры. Если обнаружатся проблемы, они успеют затронуть лишь малую часть пользователей, и вы сможете легко откатиться к предыдущей версии. Это быстрая обратная связь от боевого окружения.
С новой фичей Service Desk ваши пользователи могут отправлять свои вопросы и сообщать о проблемах на специальный адрес электронной почты, отдельный для каждого проекта. По письму от пользователя Service Desk заводит конфиденциальную задачу (issue) в вашем проекте. Когда кто-либо комментирует задачу, пользователь получает этот комментарий в ответном письме.
Это — встроенный непосредственно в GitLab канал обратной связи от пользователей.
Пользователи ищут товары в интернет-магазине, ищут стати, поиск это неотъемлемый компонент сайта. Быстрый и гибкий поиск сложно реализовать средствами реляционных баз данных. Для таких задач используют поисковые движки, один из которых Elasticsearch. Elasticsearch хорошо документирован и доступен из коробки на AWS.
Для работы с elasticsearch используется библиотека elasticsearch-py или elasticsearch-dsl-py. elasticsearch-dsl-py это надстройка над elasticsearch-py, она проста в использовании и поддерживает elasticsearch версии 5.x. На базе этой библиотеки была создана библиотека django-rest-elasticsearch, которая основана на идеологии существующего поиска в Django REST Framework. Ниже я детально распишу как реализовать поиск в Django REST Framework с помощью elasticsearch используя данную библиотеку.
Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!
Продолжаем цикл статей о том, как мы постигали 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 доменов:
А значит, у всех нас проблемы!