Привет!
Мы решили собрать очередную встречу разработчиков, на этот раз поговорим о backend.
Когда: 21 июня, четверг, с 19:00.
Где: Москва, ул. Большая Полянка, д.2/10, стр. 1 (Corporate Innovations Hub).
Регистрация на событие открыта, подробности – под катом.
Читать полностью »
Привет всем, меня зовут Андрей, и я разработчик. Давным-давно — кажется, в прошлую пятницу — у нашей команды был проект, где понадобился поиск по ингредиентам, входящим в состав продуктов. Допустим, в состав колбасы. В самом начале проекта от поиска требовалось не много: показать все рецепты, в которых нужный ингредиент содержится в определенном количестве; повторить для N ингредиентов.
Читать полностью »
«А оно там делает магию»
кто-то из тех, кого я удалённо консультировал по Эластику.
Я всегда говорю, что верю в три вещи: мониторинг, логи и бэкапы.
Тема про то, как мы собираем и храним логи, достаточно полно была раскрыта в предыдущих статьях, тема про бэкапы в Elasticsearch — совсем отдельная история, поэтому в этой, возможно заключительной, статье цикла я расскажу как происходит мониторинг моего любимого кластера. Это не очень сложно (и не требует использования дополнительных плагинов и сторонних сервисов) — ибо REST API, предоставляемое самим Elasticsearch простое, понятное и удобное в использовании. Всего-то надо немного углубиться в его внутреннее устройство, понять, что означают все эти метрики, пулы тредов, веса распределения шардов по нодам, настройки очередей — и не останется никаких вопросов о том, что же за «магию» эластик делает прямо сейчас.
На недавней конференции Highload++ 2017 я рассказал о том, как строил кластер своей мечты, и говорил, что недостаточно просто построить сервис. Критически важно в любой момент знать, в каком он состоянии, причём контроль обязательно должен быть многоуровневым. Разбудите меня посреди ночи (отделу мониторинга привет!) — и через две минуты я буду знать, в каком состоянии находится кластер. Причём одна минута из двух уйдёт на подключение к корпоративному VPN и логин в Zabbix.
Читать полностью »
Если вы связаны с эксплуатацией IT, то наверняка сталкивались либо со Splunk, либо с ELK, либо с обоими продуктами. Это два основных игрока на рынке продуктов по лог-менеджменту и операционной аналитике данных.
В нашем блоге мы пишем о Splunk и нам часто задают вопрос, чем же Splunk лучше ELK? За что мы должны платить деньги за лицензию, если есть хороший open source конкурент? На эту тему отрывками в комментариях сказано уже очень много, но мы решили все объединить и посвятить этому вопросу отдельную статью.
Читать полностью »
Прим. переводчика. X-Pack — это проприетарное расширение для продуктов ELK.
От открытых комуникаций до свободного ПО, открытость всегда была в духе Elastic.
Поэтому мы открываем проприетарный код X-Pack. X-Pack включает в себя функционал, связанный с безопасностью, оповещениями, мониторингом, а также отчеты, аналитику и машинное обучение.
Изначально мы создали X-Pack как набор проприетарного функционала, расширяющего стек Elastic — Elasticsearch, Kibana, Beats и Logstash. Некоторые функции, например, мониторинг были бесплатными. Некоторые, например, безопасность и машинное обучение были платными.
Наша компания построена на сочетании открытого кода и коммерческой выгоды(подробнее в посте Shay). Открытие кода X-Pack должно ускорить разработку и увеличить вовлеченность сообщества. Каждый может контрибутить, комментировать и изучать код.
Для поиска нужной информации на веб-сайтах и в мобильных приложениях часто используется поиск по словам или фразам, которые пользователь свободно вводит с клавиатуры (а не выбирает например из списка). Естественно, что пользователь может допускать ошибки и опечатки. В этом случае полнотекстовый поиск, полнотекстовые индексы, которые реализованы в большинстве базы данных не дают ожидаемого результата и практически бесполезны. Такой функционал все чаще реализуют на основе elasticsearch.
Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.
Читать полностью »
Это шестнадцатая часть серии Мега-учебников Flask, в которой я собираюсь добавить в микроблог возможность полнотекстового поиска.
Полнотекстовый поиск даёт возможность искать документы по текстовому содержимому. Такая необходимость может возникнуть, когда система содержит много текстовых сущностей, а пользователям требуется учитывать эти данные во время поиска. Мы столкнулись с подобной ситуацией при разработке решения для документооборота*. Данные системы хранятся в MS SQL Server или PostgreSQL, а гибкий атрибутивный поиск позволяет находить документы по различной мета-информации. Однако со временем этого стало недостаточно. Перед нами встала задача: научиться искать документы по текстовым свойствам и приложенным файлам.
В этой статье мне хотелось бы поделиться способом настройки технологии единого входа (SSO) в Elastic Stack, использующим X-Pack для аутентификации пользователей и разграничения доступа к данным.
Для своих ETL (Extract, Transform, Loading) процессов, на этапах E и T, то есть извлечение и преобразование данных мы используем Apache Storm, и, так как большинство ошибок, связанных с инвалидацией сырых данных, происходит именно на этом этапе, — появилось желание централизованно логировать всё это, используя ELK стэк (Elasticsearch, Logstash, Kibana).
Каким же было моё удивление, что нигде не то, что на русском языке, но даже в оригинальных туториалах не было описана работа с логами в формате log4j2, который является дефолтом в мире Java-приложений.
Исправляя это упущение — под катом туториал по настройке централизованного сбора любых log4j2 логов на основе:
