лосиная система

Внимание! Статье уже четыре года и многое в используемых технологиях могло измениться. Не забываем консультироваться с офф. документацией.

Что, если я скажу вам, что логи могут быть не только полезными и содержать тонну важной информации, но и что работа с ними может быть классной, интересной и увлекательной? Настолько же увлекательной, интересной и классной, как кликанье через удобный интерфейс в браузере, позволяющий в считанные секунды вывести любой график и сравнить его с другим графиком? Да чего там: что, если я скажу вам, что после прочтения этой статьи вы сможете развернуть полноценный аналог Google Analytics для ваших логов? А я это и скажу. Точнее, я это уже сказал. Погнали!

Подготовим vagrant-коробку

Прежде чем перейдём к самой сути, нам необходимо провести небольшую подготовительную работу. Возможно, вы уже использовали Vagrant. Если нет – обязательно узнайте что это такое и начните использовать. Знание Vagrant не нужно для этой статьи, но будет классно (и позволит избежать возможных несоответствий в результате), если вы будете запускать примеры кода ниже используя такой же как у меня конфиг vagrant-бокса.

Итак, создаём новую папку, выполняем в ней vagrant init, открываем Vagrantfile и помещаем туда этот конфиг:

# Vagrantfile API/syntax version. Don’t touch unless you know what you’re doing!

Затем выполняем vagrant up и, пока наша виртуальная машинка создаётся, настраивается и запускается, читаем дальше.

ELK stack

ELK расшифровывается как elasticsearch, logstash и kibana. Раньше это были три самостоятельных продукта, но в какой-то момент они стали принадлежать одной компании и развиваться в одном направлении. Каждый из этих инструментов (с небольшими оговорками ниже) является полноценным независимым open source продуктом, а все вместе они составляют мощное решение для широкого спектра задач сбора, хранения и анализа данных. Теперь по порядку о каждом из них.

Logstash

logstash – это утилита для сборки, фильтрации и последующего перенаправления в конечное хранилище данных. Вы могли слышать о fluentd – logstash решает ту же самую задачу, но написан на jruby и чуть более лучше дружит с elasticsearch (потому что теперь это продукт одной и той же компании, помните?).

Типичная конфигурация logstash представляет из себя несколько входящих потоков информации (input), несколько фильтров для этой информации (filter) и несколько исходящих потоков (output). Выглядит это как один конфигурационный файл, который в простейшем варианте (который не делает вообще ничего) выглядит вот так:

Не волнуйтесь, мы скоро перейдём к настоящим примерам.

– Так, так, стоп, Кирилл. Чё ещё за входящие потоки, какие ещё фильтры? Может пример какой приведёшь для этих терминов?

Привожу: допустим, у вас есть лог веб-сервера (nginx). Это входящий поток информации, input. Допустим, вы хотите каждую запись лога не только превратить в json-объект, но ещё и добавить гео-информацию о ней, основываясь на ip. Это фильтр, filter. А после того, как запись лога обработана и обогащена гео-данными, вы хотите отправить её в elasticsearch (скоро поймём почему). Это исходящий поток информации, output.

При этом у вас может быть сколько захочется input’ов, сколько приспичит фильтров (но не забудьте, что чем больше фильтров, тем больше ресурсов понадобится на обработку каждой записи) и сколько душе угодно output’ов. Logstash предоставляет из коробки внушительный набор готовых решений, поэтому вам не придётся писать свой фильтр для гео-данных, например. Он уже есть из коробки. Это, кстати, выгодно отличает logstash от fluentd.

Elasticsearch

Изначально, elasticsearch – это решение для полнотекстового поиска, построенное поверх Apache Lucene, но с дополнительными удобствами, типа лёгкого масштабирования, репликации и прочих радостей, которые сделали elasticsearch очень удобным и хорошим решением для высоконагруженных проектов с большими объёмами данных.

Особенно доставляет в elasticsearch его простота и работоспособность из коробки. Конфигурация по-умолчанию скорее всего будет работать как надо для проектов средней и относительно высокой нагруженности. При этом вокруг ES сложилось отличное сообщество, которое всегда подскажет, как правильно настроить ваш ES-кластер для вашей конкретной задачи.

В какой-то момент elasticsearch стал настолько хорош, что использовать его только для поиска по товарам в интернет-магазинах (ну или там поиску по Basecamp) стало глупо и множество компаний начали основывать на ES свои решения по централизованному хранению логов и различной аналитики.

Kibana

И вот у нас есть logstash, который собирает и обрабатывает данные со всех ваших тысяч серверов и elasticsearch, который изо всех сил эти данные хранит и позволяет искать по ним. Чего не хватает? Верно, не хватает Angular.js.

Поэтому в какой-то момент товарищ Rashid Khan написал для elasticsearch красивое Angular.js приложение kibana, позволяющее братьискать данные по elasticsearch и строить множество красивых графиков. Ребята из elasticsearch не дураки, поэтому, увидев всё удобство этого решения, они забрали разработчика kibana к себе на борт.

Помните, я сказал, что все элементы ELK – независимые продукты? На самом деле, kibana бесполезна без elasticsearch. Это очень (очень) удобный интерфейс, позволяющий любому в вашей компании построить себе красивую панельку, на которую выводить аналитику всего, что logstash отправил в elasticsearch.

Пора практиковаться!

У меня возникла проблема: в какой-то момент в mkdev.me произошла какая-то беда, и чтобы разобраться в ней мне нужно было внимательно изучить что-то вроде сотни с лишним мегабайт логов. Удовольствие от использования grep для этой задачи сомнительное, поэтому я решил взять лог с сервера, залить его в elasticsearch при помощи logstash и спокойно проанализировать проблему через браузер при помощи kibana.

Внимание! Возможно, у вас нет пары сотен с лишним мегабайт логов production приложения и вы скажете «э! а мне то чего пихать в elasticsearch»? Честно – не знаю. Но я почти уверен, что у вас локально лежит какое нибудь Ruby on Rails приложение, над которым вы работаете. А значит в папке log этого приложения есть необходимый вам файлик. Вот его и возьмите. А если нет такого файла, то можете попробовать найти в интернете чужие логи.

Не отдам же я вам логи mkdev, в самом-то деле.

Заходим в виртуалку: vagrant ssh.

Установка logstash

sudo apt-get update
sudo apt-get install openjdk-7-jdk curl
curl -O https://download.elasticsearch.org/logstash/logstash/logstash-2.2.0.tar.gz
tar zxvf logstash-2.2.0.tar.gz
cd logstash-2.2.0

Всё, готово. Установили.

Установка elasticsearch

Версия elasticsearch тоже 2.2.0

sudo apt-get install unzip
curl -L -O https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-2.2.0.zip
unzip elasticsearch-2.2.0.zip
cd elasticsearch-2.2.0

Установка kibana

Используемая версия Kibana: 4.4.2. В реальных условиях, конечно, kibana должна быть отделена от logstash и elasticsearch и крутиться на отдельном сервере.

curl -O https://download.elastic.co/kibana/kibana/kibana-4.4.2-linux-x64.tar.gz
tar zxvf kibana-4.4.2-linux-x64.tar.gz

Конфигурируем logstash

У нас будет всего один input – stdin, стандартный ввод. Он позволит нам загрузить все данные из нашего лог-файла стандартной программой cat. Обратите внимание на type – к каждой итоговой записи, попадающей в output будет добавлено это поле.

Самая сложная часть – фильтры. Я использую multiline, потому что каждая запись в логах rails занимает несколько строчек. Опция pattern указывает на начало каждой записи.

grok – это регулярные выражения на стероидах. Позволяет определять конкретные шаблоны регулярных выражений, которые могут содержать в себе другие шаблоны. В logstash куча встроенных шаблонов grok. К сожалению, для rails там встроенного шаблона нет. После недолгих поисков в интернете я нашёл почти готовый шаблон, немного отредактировал его и он отлично сработал для логов mkdev.me (см. чуть ниже).

Найдите в папке logstash-2.2.0 папку patterns, закиньте туда файл rails со следующим содержанием:

Если какая-то запись не соответствует шаблону grok, то logstash добавит к ней тег _grokparsefailure. Если у записи есть такой тег, то мы её просто выкидываем. Заметьте, что фильтры выполняются сверху вниз.

Целиком секция с фильтрами выглядит следующим образом:

output у нас один – elasticsearch.

Итоговый logstash.conf я загрузил в gist.

Конфигурируем elastisearch

Прежде чем мы перейдём к настоящим чудесам, нам необходимо добавить кое-что в конфиг elasticsearch. Открываем elastichsearch-2.2.0/config/elasticsearch.yml и добавляем в самый конец строчку http.cors.enabled: true. Это позволит проводить CORS-запросы из kibana в ES.

Заливаем данные в elasticsearch

Переходим непосредственно к насыщенному экшену. Сначала запустим (из папки elasticsearch-2.2.0, созданной ранее при разархивировании) elasticsearch командой bin/elasticsearch —config=./config/elasticsearch.yml. Затем заходим в папку с logstash и выполняем:

Вместо production.log подставьте путь к своему лог-файлу. На обработку и сохранение данных уйдёт какое-то время, особенно с учётом того, что мы всё это дело запускаем в виртуалке и того, что и logstash и elasticsearch любят брать много памяти (java же всё таки).

Смотрим данные

После того как обработка данных закончена мы можем их смотреть и анализировать. Это самая приятная часть.

Сначала покажем Kibana где у нас Elasticsearch:

Затем запускаем kibana командой bin/kibana. И открываем в браузере localhost:5601. Не выключайте elasticsearch, так как kibana берёт все данные оттуда.

Замечания

Естественно, приведённая выше конфигурация не является идеальной и не рекомендуется для production окружения. grok-шаблон, например, распознает далеко не все записи из рельсовых логов. Тем не менее, принцип работы остаётся тем же: logstash берёт данные, обрабатывает их и посылает в elasticsearch, к которому затем цепляется kibana.

Если вас интересует как развернуть и автоматизировать production-ready elasticsearch кластер со всеми сопутствующими сервисами вокруг него и при помощи chef – обращайтесь ко мне на почту.

Круто?!

Теперь, дорогие читатели, вы можете стать настоящими властелинами данных. Области применения ELK стэка ограничены лишь вашей фантазией. Централизованное хранилище логов – лишь простейший пример. Другая популярная задача – сбор различных бизнес-событий из приложений и их аналитика. В конце концов, лог – это любая строчка текста, к которой прикреплены дата и время.

Не стоит забывать, что использовать ELK для небольших проектов не имеет особого смысла и затратно. Разворачивать на единственном маленьком сервере помимо самого приложение ещё и elasticsearch с logstash точно не стоит – как минимум память закончится очень быстро.

Настоятельно рекомендую попробовать разные типы input’ов, фильтров и output’ов logstash. Буду рад ответить на любые вопросы в комментариях.

With millions of downloads for its various components since first being introduced, the ELK Stack is the world’s most popular log management platform. In contrast, Splunk — the historical leader in the space — self-reports 15,000 customers in total.

What exactly is ELK? Why is this software stack seeing such widespread interest and adoption? How do the different components in the stack interact?

In this guide, we will take a comprehensive look at the different components comprising the stack. We will help you understand what role they play in your data pipelines, how to install and configure them, and how best to avoid some common pitfalls along the way.

Additionally, we’ll point out the advantages of using OpenSearch and OpenSearch Dashboards – the open source forked versions of Elasticsearch and Kibana, respectively, launched by AWS together with Logz.io and other community members shortly after Elastic closed sourced the ELK Stack, in an effort to keep the projects open source.

And lastly, we will reference Logz.io as a solution to some of the challenges discussed in this article – which offers a SaaS logging and observability platform that’s based on these popular open source stacks, while offloading the maintenance tasks required to run your own ELK Stack or OpenSearch.

Much of our content covers the ELK Stack and the iteration of it that appears within the Logz.io platform. Some features are unavailable in one version and available in the other.

The ELK Stack grew into the most popular log management and analytics solution in the world as a collection of open source projects maintained by Elastic – whose founders launched the ELK Stack. Since then, Elastic’s relationship with the open source community has grown more complicated.

In early 2021, Elastic announced a bombshell in the open source world: the ELK Stack would no longer be open source, as of version 7.11. The company implemented dual proprietary licenses to govern ELK-related projects – including SSPL and the Elastic license – which includes ambiguous legal language on appropriate usage for the ELK Stack.

Shortly after, AWS announced the launch of OpenSearch and OpenSearch Dashboards, which would fill the role originally held by Elasticsearch and Kibana, respectively, as the leading open source log management platform.

There are a few capabilities supported by OpenSearch that are only available in the paid versions of ELK:

These differences also motivated Logz.io’s migration from ELK to OpenSearch. Полностью управляемая платформа управления журналами Logz.io построена на основе OpenSearch и OpenSearch Dashboards, что устраняет необходимость самостоятельно устанавливать, масштабировать, управлять, обновлять или защищать стек журналов, а также объединять журналы с метриками и данными трассировки.

Logz.io осуществил эту миграцию, чтобы оставаться верным сообществу открытого исходного кода и передавать преимущества продукта OpenSearch нашим клиентам.

Что такое стек ELK?

Стек ELK начинался как набор из трех продуктов с открытым исходным кодом — Elasticsearch, Logstash и Kibana — все они разрабатывались, управлялись и поддерживались Elastic. Внедрение и последующее добавление Beats превратило стек в четырехсторонний проект.

Elasticsearch — это система полнотекстового поиска и анализа, основанная на поисковой системе с открытым исходным кодом Apache Lucene.

Logstash — это агрегатор журналов, который собирает данные из различных источников ввода, выполняет различные преобразования и улучшения, а затем отправляет данные в различные поддерживаемые места назначения вывода. Важно знать, что многие современные реализации ELK не включают Logstash. Чтобы заменить его возможности обработки журналов, большинство обращаются к облегченным альтернативам, таким как Fluentd, который также может собирать журналы из источников данных и пересылать их в Elasticsearch.

Почему ELK так популярен? Превзойдет ли OpenSearch ELK?

Стек ELK популярен, потому что он удовлетворяет потребности в области управления журналами и аналитики. Для мониторинга современных приложений и ИТ-инфраструктуры, в которой они развернуты, требуется решение для управления журналами и аналитики, которое позволяет инженерам преодолевать трудности мониторинга высокораспределенных, динамичных и шумных сред.

Конечно, неудивительно, что ELK теряет популярность после объявления о закрытии исходного кода. Использование открытого исходного кода означает, что организации могут избежать привязки к поставщику и гораздо проще привлекать новые таланты. Открытый исходный код также означает активное сообщество, постоянно внедряющее новые функции и инновации и помогающее в случае необходимости.

По этим причинам в Logz.io мы ожидаем, что OpenSearch и OpenSearch Dashboards в конечном итоге займут место ELK в качестве самого популярного решения для ведения журналов.

Конечно, Splunk уже давно является лидером рынка в этой области. Но его многочисленные функциональные возможности все чаще не стоят высокой цены, особенно для небольших компаний, таких как продукты SaaS и технологические стартапы. У Splunk около 15 000 клиентов, в то время как ELK и OpenSearch загружаются за один месяц больше раз, чем общее количество клиентов Splunk, и при этом во много раз больше. E LK и OpenSearch могут не иметь всех функций Splunk, но им не нужны эти аналитические навороты. Это простые, но надежные платформы для управления журналами и аналитики, которые стоят намного дешевле.

Почему анализ журнала становится все более важным?

В современном конкурентном мире организации не могут позволить себе ни секунды простоя или низкой производительности своих приложений. Проблемы с производительностью могут нанести ущерб бренду, а в некоторых случаях привести к прямой потере дохода. По той же причине организации также не могут позволить себе быть скомпрометированными, а несоблюдение нормативных стандартов может привести к большим штрафам и нанести ущерб бизнесу так же, как и проблемам с производительностью.

Чтобы обеспечить постоянную доступность, производительность и безопасность приложений, инженеры полагаются на различные типы данных телеметрии, генерируемых их приложениями и поддерживающей их инфраструктурой. Эти данные, будь то журналы событий, трассировки, метрики или все три, позволяют осуществлять мониторинг этих систем, а также выявлять и устранять проблемы в случае их возникновения.

Журналы существовали всегда, поэтому для их анализа были доступны различные инструменты. Однако изменилась базовая архитектура сред, генерирующих эти журналы. Архитектура превратилась в микросервисы, контейнеры и инфраструктуру оркестрации, развернутую в облаке, в разных облаках или в гибридных средах. Мало того, сам по себе объем данных, генерируемых этими средами, постоянно растет и сам по себе представляет собой проблему. Давно прошли те времена, когда инженер мог просто подключиться к машине по SSH и просмотреть файл журнала. Это невозможно сделать в средах, состоящих из сотен контейнеров, ежедневно генерирующих ТБ данных журнала.

Именно здесь на сцену выходят решения для централизованного управления журналами и аналитики, такие как ELK Stack, которые позволяют инженерам, будь то DevOps, ИТ-эксплуатация или SRE, получать необходимую им информацию и обеспечивать постоянную доступность и производительность приложений. .

Как использовать стек ELK для анализа журнала

Как я упоминал выше, вместе взятые, различные компоненты стека ELK представляют собой простое, но мощное решение для управления журналами и аналитики.

Различные компоненты в ELK Stack были спроектированы так, чтобы хорошо взаимодействовать и работать друг с другом без особой дополнительной настройки. Однако то, как вы в конечном итоге проектируете стек, сильно различается в зависимости от вашей среды и варианта использования.

Однако для обработки более сложных конвейеров, созданных для обработки больших объемов данных в производственной среде, в вашу архитектуру ведения журналов, вероятно, будут добавлены дополнительные компоненты для обеспечения отказоустойчивости (Kafka, RabbitMQ, Redis) и безопасности (nginx):

Это, конечно, упрощенная диаграмма для иллюстрации. Архитектура полного производственного уровня будет состоять из нескольких узлов Elasticsearch, возможно, нескольких экземпляров Logstash, механизма архивирования, плагина оповещения и полной репликации между регионами или сегментами вашего центра обработки данных для обеспечения высокой доступности. Вы можете прочитать полное описание того, что требуется для развертывания ELK в качестве решения для управления журналами и аналитики производственного уровня, в соответствующем разделе ниже.

Для многих команд не составляет труда потратить время на настройку, настройку, масштабирование, обновление, управление и защиту этих компонентов. Тем не менее, для тех, кому нужно сосредоточить свои ресурсы в другом месте, Logz.io предоставляет полностью управляемый сервис OpenSearch, включая готовый полный конвейер ведения журналов, чтобы команды могли сосредоточить свои усилия на других начинаниях, таких как создание новых функций.

Что нового?

Как и следовало ожидать от чрезвычайно популярного набора инструментов, стек ELK постоянно и часто обновляется новыми функциями. Быть в курсе этих изменений непросто, поэтому в этом разделе мы расскажем о новых функциях, представленных в основных выпусках.

Elasticsearch 7.x намного проще в настройке, так как теперь он поставляется вместе с Java. Улучшения производительности включают настоящий прерыватель цепи памяти, улучшенную производительность поиска и политику 1-shard. Кроме того, новый уровень координации кластера делает Elasticsearch более масштабируемым и устойчивым.

Версии Elasticsearch 8.x, которые не являются открытым исходным кодом, включают улучшения, такие как оптимизация индексов для данных временных рядов и включение функций безопасности по умолчанию.

Механизм исполнения Logstash Java (объявленный экспериментальным в версии 6.3) включен по умолчанию в версии 7.x. Заменяя старый исполнительный механизм Ruby, он может похвастаться более высокой производительностью, меньшим использованием памяти и в целом — более быстрой работой.

Kibana претерпевает значительные изменения, добавляя новые страницы и улучшая удобство использования. Последний выпуск включает темный режим, улучшенные запросы и фильтрацию, а также улучшения Canvas.

Удары

Beats 7.x соответствуют новой Elastic Common Schema (ECS) — новому стандарту форматирования полей. Metricbeat поддерживает новый модуль AWS для извлечения данных из Amazon CloudWatch, Kinesis и SQS. Новые модули также были представлены в Filebeat и Auditbeat.

Когда Elastic закрыл исходный код стека ELK, они также незаметно запретили Beats отправлять данные в:

Установка ELK

Стек ELK можно установить различными способами и в самых разных операционных системах и средах. E LK можно установить локально, в облаке, с помощью Docker и систем управления конфигурацией, таких как Ansible, Puppet и Chef. Стек можно установить с помощью пакетов tarball или .zip или из репозиториев.

Многие этапы установки одинаковы для разных сред, и, поскольку мы не можем охватить все различные сценарии, мы приведем пример установки всех компонентов стека — Elasticsearch, Logstash, Kibana и Beats — в Linux. . Ссылки на другие руководства по установке можно найти ниже.

Для тех, кто хочет пропустить установку ELK, они могут попробовать Logz.io Log Management, который предоставляет масштабируемый, надежный, готовый конвейер ведения журналов, не требующий установки или настройки — все на основе OpenSearch и Панели инструментов OpenSearch.

Характеристики окружения

Для выполнения описанных ниже шагов мы настроили один компьютер AWS Ubuntu 18.04 на инстансе m4.large, используя его локальное хранилище. Мы запустили экземпляр EC2 в общедоступной подсети VPC, а затем настроили группу безопасности (брандмауэр), чтобы разрешить доступ из любого места с использованием SSH и TCP 5601 (Kibana). Наконец, мы добавили новый эластичный IP-адрес и связали его с нашим работающим экземпляром для подключения к Интернету.

Обратите внимание, что мы установили здесь версию 6.2. В более поздних версиях модели лицензирования были внесены изменения, включая включение основных функций X-Pack в установочные пакеты по умолчанию.

Установка Elasticsearch

Во-первых, вам нужно добавить ключ подписи Elastic, чтобы можно было проверить загруженный пакет (пропустите этот шаг, если вы уже установили пакеты из Elastic):

Для Debian нам нужно установить пакет apt-transport-https:

sudo apt-get update sudo apt-get install apt-transport-https

Следующим шагом будет добавление определения репозитория в вашу систему:

Чтобы установить версию Elasticsearch, которая содержит только функции, лицензированные под Apache 2.0 (он же OSS Elasticsearch):

Осталось обновить ваши репозитории и установить Elasticsearch:

sudo apt-get update sudo apt-get install elasticsearch

Конфигурации Elasticsearch выполняются с использованием файла конфигурации, который позволяет настроить общие параметры (например, имя узла), а также сетевые параметры (например, хост и порт), где хранятся данные, память, файлы журналов и многое другое.

В нашем примере, поскольку мы устанавливаем Elasticsearch на AWS, рекомендуется привязать Elasticsearch либо к частному IP-адресу, либо к локальному хосту:

Для запуска Elasticsearch используйте:

запуск службы sudo elasticsearch

Установка Logstash

Для запуска Logstash требуется Java 8 или Java 11, поэтому мы начнем процесс настройки Logstash с:

sudo apt-get install default-jre

Убедитесь, что Java установлен:

java -version версия openjdk «1.8.0_191» Среда выполнения OpenJDK (сборка 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12) 64-разрядная виртуальная машина сервера OpenJDK (сборка 25.191-b12, смешанный режим)

Поскольку мы уже определили репозиторий в системе, все, что нам нужно сделать для установки Logstash, это запустить:

sudo apt-get install logstash

Перед запуском Logstash вам необходимо настроить конвейер данных. Мы вернемся к этому, когда установим и запустим Kibana.

Установка Кибаны

Как и раньше, мы будем использовать простую команду apt для установки Kibana:

sudo apt-get install kibana

server.port: 5601 elasticsearch.url: «http://localhost:9200»

Эти конкретные конфигурации сообщают Kibana, к какому Elasticsearch подключаться и какой порт использовать.

Теперь начните Кибану с:

запуск службы sudo kibana

Откройте Kibana в браузере по адресу: http://localhost:5601. Вам будет представлена ​​домашняя страница Kibana.

Установка Beats

Различные грузоотправители, принадлежащие к семейству Beats, могут быть установлены точно так же, как мы устанавливали другие компоненты.

В качестве примера установим Metricbeat:

sudo apt-get установить metricbeat

Чтобы запустить Metricbeat, введите:

запуск службы sudo metricbeat

Metricbeat начнет отслеживать ваш сервер и создаст индекс Elasticsearch, который вы можете определить в Kibana. Однако на следующем шаге мы опишем, как настроить конвейер данных с помощью Logstash.

Более подробная информация об использовании различных битов доступна в нашем блоге:

Отправка некоторых данных

Для целей этого руководства мы подготовили несколько примеров данных, содержащих ежедневно обновляемые журналы доступа Apache. Вы можете скачать данные здесь: sample-data

Затем создайте новый файл конфигурации Logstash по адресу: /etc/logstash/conf.d/apache-01.conf:

sudo vim /etc/logstash/conf.d/apache-01.conf

Запустите Logstash с помощью:

запуск службы sudo logstash

Если все пойдет хорошо, в Elasticsearch будет создан новый индекс Logstash, шаблон которого теперь можно определить в Kibana.

Нажмите Создать шаблон индекса, и вы готовы анализировать данные. Перейдите на вкладку «Обнаружение» в Kibana, чтобы просмотреть данные (посмотрите на сегодняшние данные вместо данных по умолчанию за последние 15 минут).

Поздравляем! Вы настроили свой первый конвейер данных ELK с помощью Elasticsearch, Logstash и Kibana.

Дополнительные инструкции по установке

Как упоминалось ранее, это всего лишь один пример среды установки ELK. В других статьях нашего блога описаны другие системы и платформы, которые могут быть вам интересны:

Ознакомьтесь с другими разделами этого руководства, чтобы понять более сложные темы, связанные с работой с Elasticsearch, Logstash, Kibana и Beats.

Elasticsearch — это живое сердце самой популярной в мире платформы лог-аналитики — стека ELK (Elasticsearch, Logstash и Kibana). Роль Elasticsearch настолько велика, что стала синонимом названия самого стека. Elasticsearch, используемый в основном для поиска и анализа журналов, сегодня является одной из самых популярных систем баз данных, доступных сегодня.

Однако, в отличие от большинства баз данных NoSQL, Elasticsearch уделяет большое внимание возможностям и функциям поиска — фактически настолько, что самый простой способ получить данные из Elasticsearch — это выполнить поиск с помощью его обширного REST API.

В контексте анализа данных Elasticsearch используется вместе с другими компонентами стека ELK, Logstash и Kibana и играет роль индексации и хранения данных.

К сожалению, как было сказано ранее, Elasticsearch больше не является базой данных с открытым исходным кодом. Для тех, кто предпочитает альтернативу с открытым исходным кодом, см. стек OpenSearch. OpenSearch в настоящее время очень похож на Elasticsearch с некоторыми возможностями, доступными только для платных версий Elasticsearch.

Основные концепции Elasticsearch

Индексы Elasticsearch — это логические разделы документов, которые можно сравнить с базой данных в мире реляционных баз данных.

Продолжая наш пример с приложением электронной коммерции, у вас может быть один индекс, содержащий все данные, связанные с продуктами, а другой — со всеми данными, связанными с клиентами.

Вы можете определить столько индексов в Elasticsearch, сколько захотите, но это может повлиять на производительность. Они, в свою очередь, будут содержать документы, уникальные для каждого индекса.

Индексы идентифицируются именами в нижнем регистре, которые используются при выполнении различных действий (таких как поиск и удаление) над документами, которые находятся внутри каждого индекса.

Настройка индексов Elasticsearch и управление ими, скорее всего, отнимет значительную часть времени обслуживания вашего ELK. Если вы предпочитаете разгрузить это обслуживание, рассмотрите Logz.io Log Management, который управляет всем конвейером ведения журналов через SaaS, чтобы вы могли сосредоточиться на других вещах.

Документы

Документы — это объекты JSON, которые хранятся в индексе Elasticsearch и считаются базовой единицей хранения. В мире реляционных баз данных документы можно сравнить со строкой в ​​таблице.

В примере с нашим приложением электронной коммерции у вас может быть один документ для каждого продукта или один документ для каждого заказа. Нет ограничений на количество документов, которые вы можете хранить в определенном индексе.

Данные в документах определяются с помощью полей, состоящих из ключей и значений. Ключ — это имя поля, а значение может быть элементом многих различных типов, например строкой, числом, логическим выражением, другим объектом или массивом значений.

Документы также содержат зарезервированные поля, которые составляют метаданные документа, такие как _index, _type и _id.

Типы

Типы Elasticsearch используются в документах для разделения похожих типов данных, при этом каждый тип представляет уникальный класс документов. Типы состоят из имени и сопоставления (см. ниже) и используются путем добавления поля _type. Затем это поле можно использовать для фильтрации при запросе определенного типа.

Типы постепенно удаляются из Elasticsearch. Начиная с Elasticsearch 6 индексы могут иметь только один тип отображения. Начиная с версии 7.x, указание типов в запросах не рекомендуется. Начиная с версии 8.x (версия Elasticsearch без открытого исходного кода), указание типов в запросах больше не поддерживается.

Картирование

Подобно схеме в мире реляционных баз данных, сопоставление определяет различные типы, находящиеся в индексе. Он определяет поля для документов определенного типа — тип данных (например, строковый и целочисленный) и то, как поля должны быть проиндексированы и сохранены в Elasticsearch.

Отображение может быть определено явно или создано автоматически, когда документ индексируется с использованием шаблонов. (Шаблоны включают настройки и сопоставления, которые могут автоматически применяться к новому индексу.)

Осколки

Размер индекса — частая причина сбоев Elasticsearch. Поскольку нет ограничений на количество документов, которые вы можете хранить в каждом индексе, индекс может занимать место на диске, превышающее ограничения хост-сервера. Как только индекс приближается к этому пределу, индексация начинает давать сбой.

Одним из способов решения этой проблемы является горизонтальное разбиение индексов на части, называемые осколками. Это позволяет распределять операции по сегментам и узлам для повышения производительности. Вы можете контролировать количество осколков на индекс и размещать эти «индексоподобные» осколки на любом узле в вашем кластере Elasticsearch.

Реплики

Elasticsearch построен на основе Apache Lucene и предоставляет синтаксис запросов Lucene. Знакомство с синтаксисом и его различными операторами поможет вам выполнять запросы к Elasticsearch.

Булевы операторы

Как и в большинстве компьютерных языков, Elasticsearch поддерживает операторы И, ИЛИ и НЕ:

Поля

Вы можете выполнять поиск по полям в пределах определенного диапазона, используя квадратные скобки для поиска включающего диапазона и фигурные скобки для поиска в монопольном диапазоне:

Подстановочные знаки, регулярные выражения и нечеткий поиск

Поиск не был бы поиском без подстановочных знаков. Вы можете использовать символ * для многосимвольных подстановочных знаков или ? символ для односимвольных подстановочных знаков.

Поиск URI

В сочетании с синтаксисом Lucene вы можете создавать впечатляющие результаты поиска. Обычно вам придется кодировать символы URL, такие как пробелы (в этих примерах это опущено для ясности):

Доступен ряд опций, позволяющих настроить поиск по URI, в частности, с точки зрения того, какой анализатор использовать (analyzer), должен ли запрос быть отказоустойчивым (снисходительным) и требуется ли объяснение оценки необходимо указать (объяснить).

Хотя поиск по URI — это простой и эффективный способ запроса вашего кластера, вы быстро обнаружите, что он не поддерживает все функции, предлагаемые вам Elasticsearch. Полная мощь Elasticsearch раскрывается через Request Body Search. Использование Request Body Search позволяет создавать сложный поисковый запрос с использованием различных элементов и предложений запроса, которые будут сопоставляться, фильтроваться и упорядочиваться, а также манипулировать документами на основе нескольких критериев.

Дополнительную информацию о поиске тела запроса в Elasticsearch, Query DSL и примерах можно найти в нашем документе: Запросы Elasticsearch: подробное руководство.

REST API Elasticsearch

Одна из замечательных особенностей Elasticsearch — обширный REST API, который позволяет интегрировать индексированные данные, управлять ими и запрашивать их бесчисленными способами. Примеров использования этого API для интеграции с данными Elasticsearch множество, они охватывают разные компании и сценарии использования.

Взаимодействовать с API легко — вы можете использовать любой HTTP-клиент, но Kibana поставляется со встроенным инструментом Console, который можно использовать для этой цели.

Какими бы обширными ни были API-интерфейсы Elasticsearch REST, существует кривая обучения. Для начала ознакомьтесь с соглашениями об API, узнайте о различных параметрах, которые можно применять к вызовам, о том, как создавать API и как фильтровать ответы. Следует помнить, что некоторые API-интерфейсы меняются и устаревают от версии к версии, и рекомендуется следить за критическими изменениями.

Ниже приведены некоторые из наиболее распространенных категорий API Elasticsearch, заслуживающих изучения. Примеры использования доступны в статье Elasticsearch API 101. Конечно, официальная документация Elasticsearch также является важным ресурсом.

API документов Elasticsearch

Эта категория API используется для обработки документов в Elasticsearch. С помощью этих API, например, вы можете создавать документы в индексе, обновлять их, перемещать в другой индекс или удалять.

Поисковый API Elasticsearch

Как следует из названия, эти вызовы API можно использовать для запроса индексированных данных для получения определенной информации. API поиска можно применять глобально, ко всем доступным индексам и типам или, точнее, внутри индекса. Ответы будут содержать совпадения с конкретным запросом.

API индексов Elasticsearch

Это специфичные для кластера вызовы API, которые позволяют вам управлять кластером Elasticsearch и отслеживать его. Большинство API позволяют определить, какой узел Elasticsearch вызывать, используя внутренний идентификатор узла, его имя или адрес.

Плагины Elasticsearch

Плагины Elasticsearch используются для расширения базовой функциональности Elasticsearch различными специфическими способами. Например, есть плагины, которые добавляют в Elasticsearch функции безопасности, механизмы обнаружения и возможности анализа.

Точно так же OpenSearch имеет широкий спектр подключаемых модулей для улучшения анализа журналов и возможностей наблюдения.

Категории плагинов

Установка основных плагинов проста и выполняется с помощью менеджера плагинов. В приведенном ниже примере я собираюсь установить плагин EC2 Discovery. Этот подключаемый модуль запрашивает у AWS API список экземпляров EC2 на основе параметров, которые вы определяете в настройках подключаемого модуля:

Плагины должны быть установлены на каждом узле в кластере, и каждый узел должен быть перезапущен после установки.

Чтобы удалить плагин, используйте:

sudo bin/elasticsearch-plugin удалить discovery-ec2

Плагины сообщества немного отличаются, так как каждый из них имеет разные инструкции по установке.

Некоторые плагины сообщества устанавливаются так же, как и основные плагины, но требуют дополнительных шагов настройки Elasticsearch.

Что дальше?

Мы описали Elasticsearch, детализировали некоторые из его основных концепций и объяснили REST API. Чтобы продолжить изучение Elasticsearch, вот несколько полезных ресурсов:

Эффективный анализ журналов основан на хорошо структурированных журналах. Структура — это то, что позволяет вам легче искать, анализировать и визуализировать данные в любом инструменте регистрации, который вы используете. Структура также дает контекст вашим данным. Если возможно, эту структуру необходимо адаптировать к журналам на уровне приложения. В других случаях, например, для журналов инфраструктуры и системы, вы сами определяете структуру журналов, анализируя их.

Logstash можно использовать для придания вашим журналам такой структуры, чтобы их было легче искать и визуализировать.

К сожалению, Logstash часто ломается и оставляет большой компьютерный след. По этим причинам многие современные развертывания ELK на самом деле являются развертываниями EFK, заменяя Logstash облегченными альтернативами, такими как Fluentd или FluentBit.

В Logz.io наш инструмент управления журналами использует проект с открытым исходным кодом под названием Sawmill для обработки журналов, а не для обслуживания Logstash. Для распространенных типов журналов данные анализируются автоматически. Для менее распространенных журналов вы можете обратиться к нашему инженеру службы поддержки через чат приложения, и они проанализируют ваши журналы за считанные минуты!

Что такое Логсташ?

В стеке ELK (Elasticsearch, Logstash и Kibana) решающая задача анализа данных возложена на «L» в стеке — Logstash.

Logstash начинался как инструмент с открытым исходным кодом, разработанный для обработки потоковой передачи большого количества данных журнала из нескольких источников. После того, как он был включен в стек ELK, он превратился в рабочую лошадку стека, отвечающую также за обработку сообщений журнала, их улучшение и массирование, а затем отправку их в определенное место для хранения (сохранение).

Благодаря большой экосистеме плагинов Logstash можно использовать для сбора, обогащения и преобразования широкого спектра данных различных типов. Существует более 200 различных плагинов для Logstash, и обширное сообщество использует его расширяемые функции.

Тем не менее, несмотря на эти недостатки, Logstash по-прежнему остается важным компонентом стека. Были предприняты большие шаги, чтобы попытаться облегчить эти проблемы, внедрив улучшения в сам Logstash, такие как совершенно новый механизм выполнения, доступный в версии 7.0, что в конечном итоге помогло сделать ведение журнала с помощью ELK намного более надежным, чем раньше.

Конфигурация Логсташа

События, собираемые и обрабатываемые Logstash, проходят три этапа: сбор, обработка и отправка. Какие данные собираются, как они обрабатываются и куда отправляются, определяется в файле конфигурации Logstash, который определяет конвейер.

Каждый из этих этапов определяется в файле конфигурации Logstash с помощью так называемых плагинов — плагинов «Ввод» для этапа сбора данных, плагинов «Фильтр» для этапа обработки и плагинов «Выход» для этапа диспетчеризации. Плагины ввода и вывода поддерживают кодеки, которые позволяют вам кодировать или декодировать ваши данные (например, json, многострочный, простой).

Плагины ввода

Одна из вещей, которая делает Logstash таким мощным, — это его способность объединять журналы и события из различных источников. Используя более 50 подключаемых модулей ввода для различных платформ, баз данных и приложений, Logstash можно настроить для сбора и обработки данных из этих источников и отправки их в другие системы для хранения и анализа.

Наиболее часто используемые входные данные: файл, beats, syslog, http, tcp, udp, stdin, но вы можете получать данные из множества других источников.

Плагины фильтров

Logstash поддерживает ряд чрезвычайно мощных подключаемых модулей фильтров, которые позволяют вам обогащать журналы, управлять ими и обрабатывать их. Именно сила этих фильтров делает Logstash очень универсальным и ценным инструментом для анализа данных журналов.

Фильтры можно комбинировать с условными операторами для выполнения действия, если выполняется определенный критерий.

Плагины вывода

Как и в случае ввода, Logstash поддерживает ряд подключаемых модулей вывода, которые позволяют вам отправлять данные в различные места, службы и технологии. Вы можете сохранять события, используя выходные данные, такие как File, CSV и S3, преобразовывать их в сообщения с помощью RabbitMQ и SQS или отправлять их в различные службы, такие как HipChat, PagerDuty или IRC. Количество комбинаций входов и выходов в Logstash делает его действительно универсальным преобразователем событий.

События Logstash могут поступать из нескольких источников, поэтому важно проверить, должно ли событие обрабатываться конкретным выходом. Если вы не определите вывод, Logstash автоматически создаст вывод stdout. Событие может проходить через несколько плагинов вывода.

Кодеки Logstash

Кодеки можно использовать как на входе, так и на выходе. Входные кодеки обеспечивают удобный способ декодирования данных перед их поступлением на вход. Выходные кодеки обеспечивают удобный способ кодирования данных до того, как они покинут вывод.

Некоторые распространенные кодеки:

Пример конфигурации

Logstash имеет простую конфигурацию DSL, которая позволяет вам указать входы, выходы и фильтры, описанные выше, вместе с их конкретными параметрами. Порядок имеет значение, особенно в отношении фильтров и выходов, поскольку конфигурация в основном преобразуется в код, а затем выполняется. Помните об этом, когда будете писать свои конфиги и пытаться их отлаживать.

Раздел ввода в файле конфигурации определяет используемый плагин ввода. Каждый плагин имеет свои собственные параметры конфигурации, которые вы должны изучить перед использованием.

Здесь мы используем плагин для ввода файлов. Мы ввели путь к файлу, который хотим собрать, и определили начальную позицию как начало обработки логов с начала файла.

Раздел filter в файле конфигурации определяет, какие плагины фильтров мы хотим использовать, или, другими словами, какую обработку мы хотим применить к журналам. Каждый плагин имеет свои собственные параметры конфигурации, которые вы должны изучить перед использованием.

В этом примере мы обрабатываем журналы доступа Apache:

Раздел вывода в файле конфигурации определяет пункт назначения, которому мы хотим отправить журналы. Как и прежде, у каждого плагина есть свои параметры конфигурации, которые вы должны изучить перед использованием.

В этом примере мы определяем локально установленный экземпляр Elasticsearch.