Порой начиная новый проект мы примерно заранее знаем какие инструменты нам могут понадобиться.
Перед началом нового проекта я построил план работ, подобрал набор программ и решил подготовить небольшую и краткую инструкцию.
В качестве системы виртуализации я выбрать VMware Workstation.
1. ОС: CentOS 7
2. Сервер для анализа и поиска данных: Elasticsearch
3. Сервер очередей: RabbitMQ
4. Веб сервер: Nginx + PHP7 FPM
В этом материале я продолжаю делиться полевым опытом работы с системой сбора логов на базе Heka и ElasticSearch.
На этот раз рассказ пойдет про миграцию данных между двумя кластерами ElasticSearch 2.2 и 5.2.2, которая стоила немалых нервов лично мне. Как-никак, предстояло перевезти 24 миллиарда записей, не сломав уже работающую систему.
Прошлая статья закончилась на том, что система работает, логи поступают и складываются в кластер ElasticSearch, доступен их просмотр в реальном времени через Kibana. Но кластер изначально был собран со значительным запасом по памяти как раз на вырост. Читать полностью »
GitLab спроектирован таким образом, что каждый участник проекта может вносить свой вклад, независимо от размера команды и местонахождения ее участников.
Зачастую в процессе разработки продукта несколько человек работают над одной задачей: например, разработчики фронтэнда и бэкэнда, дизайнер интерфейса, тестировщик и менеджер продукта. С выходом GitLab 9.2 все они могут быть назначены исполнителями одной задачи, что упрощает процесс совместной разработки и позволяет наглядно отображать их общую область ответственности.
Также в версии 9.2 положено начало процесса локализации GitLab: аналитика цикла разработки (Cycle Analytics) теперь доступна на испанском и немецком языках. Локализация GitLab будет продолжена в последующих релизах, чтобы каждый мог вносить свой вклад независимо от родного языка.
Кроме того, разработчики получили больше контроля над временем выполнения конвейеров CI/CD. Теперь можно составлять расписание выполнения конвейеров, что позволяет автоматизировать периодические задачи, такие как ночные сборки, профилактика или подтверждение внешних зависимостей.
Всем разработчикам известна ситуация, когда приложение заглючило и пользователь не может сделать то, что ему нужно. Причины разные: пользователь ввёл неправильные данные, у него медленный интернет и многое другое. Без системы логирования разобрать эти ошибки сложно, а порой невозможно. С другой стороны, система логирования — хороший индикатор проблемных мест в работе системы. Я расскажу, как построить систему логирования в своём проекте (да, ещё раз). В статье расскажу об Elasticsearch + Logstash + Kibana и Prometheus и как их заинтегрировать со своим приложением.
ElasticSeach достаточно гибкая платформа, и полученные в него данные можно обрабатывать многими способами, даже за пределами стека ELK. Для этого предоставлено более десятка различных API. Но для многих задач будет достаточно и возможностей Kibana.
Одной из таких я хотел бы поделиться с сообществом. Для меня, как и любого безопасника, важно видеть и понимать коммуникацию своей инфраструктуры с внешним миром. Одной из самых интересных является коммуникация с луковой сетью (Tor).
В этом материале я расскажу о том, как в Яндекс.Деньгах организована система сбора и доставки серверных логов платежных сервисов. Доставкой логов я занимаюсь весь последний год, и за это время накопилось достаточно нюансов, чтобы поделиться опытом с общественностью.
Система построена на базе стека 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. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!
