Группа элк пойнт - elk point group

Зачем вам Elasticsearch: полнотекстовый поиск по Big Data

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

Мощные возможности ELK-инфраструктуры позволяют не только анализировать системные логи в рамках задачи администрирования корпоративного ИТ-ландшафта. Также эта Big Data система отлично подходит для решения следующих бизнес-задач :

Далее рассмотрим подробнее, из чего состоит ELK-система и как она устроена.

Сравнение

Язык запросов

В Elasticsearch используется Query DSL и Lucene query language, которые обеспечивают возможность полнотекстового поиска. Это устоявшийся мощный поисковой движок с широкой поддержкой операторов. С его помощью можно искать по контексту и сортировать по релевантности.

На другой стороне ринга — LogQL, применяемый в Loki, наследник PromQL (Prometheus query language). Он использует метки журналов для фильтрации и выборки данных журналов. Есть возможность использовать некоторые операторы и арифметику, как описано здесь, но по возможностям он отстает от Elastic language.

Поскольку запросы в Loki связаны с метками — их легко соотнести с метриками, в результате с ними проще организовать оперативный мониторинг.

Масштабируемость

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

Мультиарендность

Мультиарендность кластера — общая тема для сокращения OPEX, оба стека обеспечивают мультиарендность. Для Elasticsearch есть несколько способов разделения клиентов: отдельный индекс каждому клиенту, маршрутизация на основе клиента, уникальные поля клиента, поисковые фильтры. В Loki есть поддержка в виде заголовка HTTP X-Scope-OrgID.

Стоимость

Loki весьма эффективен экономически из-за того, что он не делает индексацию данных, а только метаданных. Таким образом достигается экономия на хранилище и памяти (кэше), поскольку объектное хранилище дешевле блочного, которое используется в кластерах Elasticsearch.

Стек EFK

Возможно, вы уже слышали о весьма популярном ELK или EFK. Стек состоит из нескольких отдельных частей: Elasticsearch (объектное хранилище), Logstash или FluentD (сбор и агрегация журналов) и Kibana для визуализации.

Типичная схема работы выглядит так:

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

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

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

Архитектура Elasticsearch

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

Типы узлов кластера:

мaster node — управляет кластером, нужно минимум три, одна активна всегда;
data node — хранит индексированные данные и осуществляет с ними разные задачи;
ingest node — организует конвейеры для преобразования данных перед индексацией;
coordinating node — маршрутизация запросов, сокращение фазы обработки поиска, координация массовой индексации;
alerting node — запуск задач по оповещению;
machine learning node — обработка задач машинного обучения.

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

Данные каждой реплики хранятся в инвертированном индексе, схема ниже показывает, как это происходит:

Кратко про конфигурационные файлы

Networks и volumes были взяты из исходного docker-compose.yml (тот где целиком стек запускается) и думаю, что сильно здесь на общую картинку не влияют.
Мы создаём один сервис (services) logstash, из образа docker.elastic.co/logstash/logstash:6.3.2 и присваиваем ему имя logstash_one_channel.
Мы пробрасываем внутрь контейнера порт 5046, на такой же внутренний порт.
Мы отображаем наш файл настройки каналов ./config/pipelines.yml на файл /usr/share/logstash/config/pipelines.yml внутри контейнера, откуда его подхватит logstash и делаем его read-only, просто на всякий случай.
Мы отображаем директорию ./config/pipelines, где у нас лежат файлы с настройками каналов, в директорию /usr/share/logstash/config/pipelines и тоже делаем её read-only.

logstash_one_channel | Unable to retrieve license information from license server {:message=>«Elasticsearch Unreachable: [http://elasticsearch:9200/]logstash_one_channel | Pipeline started successfully logstash_one_channel | logstash_one_channel | X-Pack is installed on Logstash but not on Elasticsearch. Please install X-Pack on Elasticsearch to use the monitoring feature. Other features may be available.logstash_one_channel | logstash_one_channel | ogstash_one_channel | Attempted to resurrect connection to dead ES instance, but got an error. {:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] elasticsearch»}logstash_one_channel | logstash_one_channel | Attempted to resurrect connection to dead ES instance, but got an error. {:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] elasticsearch»}elasticsearch

Стек PLG

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

Promtail — агент для отправки журналов из операционной системы в кластер Loki. Grafana — инструмент визуализации на основе данных из Loki.

Loki построен на тех же принципах, что и Prometheus, поэтому он хорошо подходит для хранения и анализа журналов Kubernetes.

Архитектура Loki

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

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

Давайте посмотрим на архитектуру системы сбора журналов без детализации:

А здесь — описание (микросервисная архитектура):

Составные части:

Promtail — агент, устанавливаемый на узлы (в виде набора сервисов), он снимает журналы из задач и обращается к API Kubernetes для получения метаданных, которыми будут помечены журналы. Затем он отправляет журнал к основному сервису Loki. Для сопоставления метаданных поддерживаются те же правила для маркировки, что и в Prometheus.

Distributor — сервис-распределитель, работающий как буфер. Для обработки миллионов записей он производит упаковку входящих данных, сжимая их блоками по мере их поступления. Одновременно работает несколько приемников данных, но журналы, принадлежащие одному потоку входящих данных должны оказаться только в одном из них для всех его блоков. Это организовано в виде кольца приемников и последовательного хэширования. Для отказоустойчивости и избыточности оно делается n раз (3, если не настраивать).

Ingester — сервис-приемник. Блоки данных приходят сжатыми с добавленными журналами. Как только блок оказывается достаточного размера, производится сброс блока в базу данных. Метаданные идут в индекс, а данные от блока с журналом попадают в Chunks (обычно это объектное хранилище). После сброса приемник создает новый блок, куда будут добавляться новые записи.

Index — база данных, DynamoDB, Cassandra, Google BigTable и прочее.

Chunks — блоки журналов в сжатом виде, обычно хранятся в объектном хранилище, например, S3.

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

А теперь давайте посмотрим все в работе.

Установка

Для установки в Kubernetes проще всего воспользоваться helm. Полагаем, что вы уже его поставили и настроили (и третьей версии! прим. переводчика)

Добавляем репозиторий и ставим стек.

Ниже приведен пример панели инструментов, на которой показаны данные из Prometheus для метрик Etcd и Loki для журналов подов Etcd.

А теперь давайте обсудим архитектуру обеих систем, а также сравним их возможности между собой.

Настраиваем несколько экземпляров Kibana

Чтобы организовать работу нескольких экземпляров Kibana, размещаем их за балансировщиком нагрузки. Для каждого экземпляра Kibana необходимо:

Настроить уникальное имя:

server.name уникальное имя экземпляра. По умолчанию имя узла.

Для каждого экземпляра в рамках одного узла необходимо указать уникальные настройки:
- директория для хранения логов;
- директория для хранения данных;
- файл для записи ID процесса;
- порт, который будет использовать данный экземпляр Kibana ;

Указать следующие параметры одинаковыми для каждого экземпляра:
- произвольный ключ для шифрования сессии. Длина не менее 32 символов.
- произвольный ключ для шифрования отчетов. Длина не менее 32 символов.
- ключ для шифрования данных до отправки их в Elasticsearch. Длина не менее 32 символов.
- список ранее использованных ключей. Позволит расшифровать ранее сохраненные данные.

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

концепция

Что такое ELK

ELK — это три продукта эластичной компанииElasticSearch 、Logstash 、KibanaПервая буквенная комбинация.

ElasticSearchОснован наLuceneСозданная распределенная поисковая система с открытым исходным кодом RESTful.

LogstashПередавать и обрабатывать ваши журналы, транзакции или другие данные.

KibanaАнализируйте данные из Elasticsearch и преобразуйте их в визуальные отчеты.

Зачем использовать ELK?

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

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

Смотрим полученные данные в Kibana

Открываем Kibana, в верхнем левом углу нажимаем меню и в секции выбираем . Далее слева выбираем и нажимаем кнопку . В поле описываем шаблон , в который попадут все индексы, начинающиеся с logstash.

Создание шаблона индекса

Жмем и выбираем поле , чтобы иметь возможность фильтровать данные по дате и времени. После жмем :

Выбор Time field

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

Чтобы посмотреть полученные данные на основе созданного шаблона нажимаем меню и в секции выбираем .

Kibana Discover

В правой части экрана можно выбрать интервал в рамках которого отображать данные.

Выбор временного интервала

В левой часте экрана можно выбрать шаблон индекса или поля для отображения из списка . При нажатии на доступные поля можно получить топ-5 значений.

Шаблон индекса и доступные поля

Для фильтрации данных можно использовать . Запрос пишется в поле . Запросы можно сохранять, чтобы использовать их в будущем.

Фильтрация данных с помощью KQL

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

Типы визуализации Kibana

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

Круговая диаграмма

Чтобы посмотреть данные в Elasticsearch необходимо сделать запрос к любому узлу кластера. Добавление параметра позволяет отобразить данные в читабельном виде. По умолчанию вывод состоит из 10 записей, чтобы увеличить это количество необходимо использовать параметр :

Заключение

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

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

Теме безопасности будет посвящена следующая статья данного цикла.

Делаем важные настройки

Для нормальной работы кластера необходимо произвести еще некоторые настройки.

Heap size

Так как Elasticsearch написан на Java, то для работы необходимо настроить размер «кучи» (). В каталоге установки Elasticsearch имеется файл , в котором уже указаны размеры, по умолчанию — это 1 Гб. Однако, для настройки рекомендуется указать новые параметры в файле каталога , который находится там же.

Пример выше использует минимальный и максимальный размер , равный 16 Гб. Для настройки данных параметров следует использовать следующие рекомендации:

установите значения и не более 50% от имеющейся физической памяти узла. Оставшуюся память Elasticsearch будет использовать для других целей. Чем больше , тем меньше памяти используется под системные кеш;
устанавите значение не более того значения, которое использует для сжатия указателей, он же . Данное значение составляет около 32 Гб. Стоит также отметить, что рекомендуется ограничивать еще одним параметром , а именно (обычно размер около 26 Гб). Узнать подробнее об этих параметрах можно тут.

Отключаем подкачку

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

Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.
Ограничение подкачки через значение для .
Использование для блокировки адресного пространства в оперативной памяти.

Чтобы включить в конфигурации Elasticseach указываем для параметра значение .

Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:

Если перезапуск Elasticsearch завершился ошибкой вида:

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

Установка из архива

Установите перед запуском Elasticsearch или значению устанвоите в файле .

Установка из пакета RPM или Deb

Установите значение параметра как в для или для .

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

и укажите следующее значение:

Настройка файловых дескрипторов

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

Если Elasticsearch установлен из или пакетов, то настройка не требуется.
Для установки из архива необходимо в файле установить параметр для пользователя, который осуществляет запуск Elasticsearch. В примере ниже таким пользователем является :

Проверить установленные значения можно следующим образом:

Настройка виртуальной памяти

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

Чтобы настройка сохранилась после перезапуска системы, необходимо указать параметр в файле .

Если Elasticsearch установлен из или пакетов, то настройка не требуется.

Настройка потоков

Необходимо убедиться, что количество потоков, которые Elasticsearch может создавать, было не менее 4096.

Это можно сделать, установив или установив значение равным 4096 в файле .

Если Elasticsearch работает под управлением , то настройка не требуется.

DNS кеширование

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

Что внутри ELK-системы: архитектура и принципы работы

Инфраструктура ELK включает следующие компоненты :

Elasticsearch (ES) – масштабируемая утилита полнотекстового поиска и аналитики, которая позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных. Как правило, ES используется в качестве NoSQL-базы данных для приложений со сложными функциями поиска. Elasticsearch основана на библиотеке Apache Lucene, предназначенной для индексирования и поиска информации в любом типе документов. В масштабных Big Data системах несколько копий Elasticsearch объединяются в кластер .
Logstash — средство сбора, преобразования и сохранения в общем хранилище событий из файлов, баз данных, логов и других источников в реальном времени. Logsatsh позволяет модифицировать полученные данные с помощью фильтров: разбить строку на поля, обогатить или их, агрегировать несколько строк, преобразовать их в JSON-документы и пр. Обработанные данные Logsatsh отправляет в системы-потребители.
Kibana – визуальный инструмент для Elasticsearch, чтобы взаимодействовать с данными, которые хранятся в индексах ES. Веб-интерфейс Kibana позволяет быстро создавать и обмениваться динамическими панелями мониторинга, включая таблицы, графики и диаграммы, которые отображают изменения в ES-запросах в реальном времени. Примечательно, что изначально Kibana была ориентирована на работу с Logstash, а не на Elasticsearch. Однако, с интеграцией 3-х систем в единую ELK-платформу, Kibana стала работать непосредственно с ES .
FileBeat – агент на серверах для отправки различных типов оперативных данных в Elasticsearch.

В рамках единой ELK-платформы все вышеперечисленные компоненты взаимодействуют следующим образом :

Logstash представляет собой конвейер обработки данных (data pipeline) на стороне сервера, который одновременно получает данные из нескольких источников, включая FileBeat. Здесь выполняется первичное преобразование, фильтрация, агрегация или парсинг логов, а затем обработанные данные отправляется в Elasticsearch.
Elasticsearch играет роль ядра всей системы, сочетая функции базы данных, поискового и аналитического движков. Быстрый и гибкий поиск обеспечивается за счет анализаторов текста, нечеткого поиска, поддержки восточных языков (корейский, китайский, японский). Наличие REST API позволяет добавлять, просматривать, модифицировать и удалять данные .
Kibana позволяет визуализировать данные ES, а также администрировать базу данных.

Принцип работы ELK-инфраструктуры: как взаимодействуют Elasticsearch, Logstash и Kibana

Завтра мы рассмотрим главные достоинства и недостатки ELK-инфраструктуры. А как эффективно использовать их для сбора и анализа больших данных в реальных проектах, вы узнаете на практических курсах по администрированию и эксплуатации Big Data систем в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков) в Москве.

Смотреть расписание
Записаться на курс

Источники

https://www.softlab.ru/blog/technologies/5816/
https://ru.bmstu.wiki/Elastic_Logstash
https://system-admins.ru/elk-o-chem-i-zachem/
http://samag.ru/archive/article/3575

использовать

Я использую решение для ведения журналов Java slf4j + logback, поэтому я воспользуюсь logback, чтобы объяснить это здесь.

Журнал вывода Java-приложения в ELK

Измените конфигурацию logstash.conf

Во-первых, нам нужно изменить конфигурацию на сервере logstash logstash.conf.

input { 
  # stdin { }
  tcp { 
    # host: port - это пункт назначения в приложении выше,
	 # Фактически, logstash здесь используется как сервис, а порт 9250 открыт для приема сообщений, отправленных методом logback 
    host => "127.0.0.1" port => 9250 mode => "server" tags =>  codec => json_lines 
  }
}
output {
  elasticsearch { hosts =>  }
  stdout { codec => rubydebug }
}

Затем введите пакет jar в pom.xml приложения Java:

<dependency>
  <groupId>net.logstash.logback</groupId>
  <artifactId>logstash-logback-encoder</artifactId>
  <version>4.11</version>
</dependency>

Затем добавьте appender в logback.xml

<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
  <!--
     назначение - это хост: порт службы logstash,
     Это эквивалентно созданию конвейера с logstash для передачи данных журнала в logstash.
  -->
  <destination>127.0.0.1:9250</destination>
  <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>
<logger name="io.github.dunwu.spring" level="TRACE" additivity="false">
  <appender-ref ref="LOGSTASH" />
</logger>

Вы закончили, после этого,Информация журнала TRACE и выше в пакете будет направлена для вывода в службу logstash.

Заключение

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

Стек Loki полезен в экосистеме Kubernetes из-за механизма обнаружения метаданных. Можно легко сопоставить данные для мониторинга на основе временных рядов в Grafana и журналах.

Когда речь идет о стоимости и длительном хранении журналов, Loki является отличным выбором для входа в облачные решения.

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

Ссылки: