elk что это такое
Изучаем ELK. Часть I — Установка Elasticsearch
Вступительное слово
Эта статья является первой в серии статей по стеку Elasticsearch, Logstash, Kibana (ELK). Цикл статей ориентирован на тех, кто только начинает знакомится со стеком ELK, и содержит минимально необходимый набор знаний, чтобы успешно запустить свой первый кластер ELK.
В рамках данного цикла будут рассмотрены такие темы, как:
установка и настройка компонентов ELK,
безопасность кластера, репликация данных и шардирование,
конфигурирование Logstash и Beat для сборки и отправки данных в Elasticsearch,
визуализация в Kibana
запуск стека в Docker.
В данной статье будет рассмотрена процедура установки Elasticsearch и конфигурирование кластера.
План действий:
Скачиваем и устанавливаем Elasticsearch.
Запускаем и проверяем работоспособность кластера.
Делаем важные настройки.
Скачиваем и устанавливаем Elasticsearch
Существует множество вариантов установки Elasticsearch, под любые нужды и желания. С перечнем можно ознакомится на официальном сайте. Не смотря на то, что на своем стенде я использовал установку из Deb пакетов, считаю правильным так же описать установку из RPM пакетов и архива tar.gz для Linux системы.
Установка из Deb пакетов
Импортируем Elasticsearch PGP ключ:
Устанавливаем apt-transport-https пакет:
Перед установкой пакета необходимо добавить репозиторий Elastic:
Устанавливаем Elasticsearch из пакета:
Настраиваем Elasticsearch для автоматического запуска при запуске системы:
Установка из RPM пакетов
Импортируем Elasticsearch PGP ключ:
В директории /etc/yum.repos.d/ создаем файл репозитория Elasticsearch elasticsearch.repo :
Установка из архива tar.gz
Скачиваем архив с Elasticsearch
Извлекаем данные из архива и переходим в каталог с Elasticsearch:
На этом шаге установка из архива считается завершенной.
Для запуска Elasticsearch можно создать отдельного пользователя, предоставив все необходимые права к каталогу с Elasticsearch и указывая данного пользователя при настройке файловых дескрипторов.
Настраиваем кластер
На текущем этапе у нас есть три хоста с установленным Elasticsearch. Следующим и самым важным этапом является настройка каждого узла для объединения их в единый кластер.
Ниже будут приведены пример конфигурации для узла es-node01. Аналогичные настройки необходимо сделать на каждом узле, указав соответствующие имя и адрес.
Указываем имя узла и определяем роли. Укажем для узла роли master и data :
master Данная роль дает возможность узлу быть избранным, как управляющий узел кластера
data узел с данной ролью содержит данные и выполняет операции с этими данными
Со списком всех ролей узла можно ознакомится тут.
Настраиваем адрес и порт, на которых узел будет принимать запросы:
Определяем имя кластера и начальный список узлов в голосовании по выбору master узла:
При начальной загрузке кластера определяются узлы, участвующие в голосовании по выбору мастера, поэтому в новом кластере мы должны указать перечень этих узлов. Если данный параметр оставить пустым (по умолчанию), то узел будет ожидать подключения к уже созданному кластеру.
Данный параметр следует удалить после создания кластера и не использовать при добавлении новых узлов в существующий кластер.
Указываем список master узлов кластера:
Определяем, где будем хранить данные и логи
На выходе мы должны получить следующий конфигурационный файл:
При необходимости настраиваем межсетевой экран на хосте:
Запускаем и проверяем
Запускаем на каждом узле службу elasticsearch :
Для установки из архива используем:
или если мы хотим запустить Elasticsearch как демон, то:
После запуска первого узла в логах можно увидеть, что узел ожидает подключение других узлов, чтобы определить, кто возьмет роль master :
После включения остальных узлов в логах появится запись о том, что кластер собрался:
Проверяем состояние кластера, обратившись к любому его узлу:
Делаем важные настройки
Для нормальной работы кластера необходимо произвести еще некоторые настройки.
Heap size
Отключаем подкачку
Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск. Есть несколько вариантов работы с подкачкой:
Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.
Использование mlockall для блокировки адресного пространства в оперативной памяти.
Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:
Если перезапуск Elasticsearch завершился ошибкой вида:
или проверка показывает, что данная настройка не применилась, необходимо сделать следующее в зависимости от способа установки:
Установка из архива
Установка из пакета RPM или Deb
и укажите следующее значение:
Настройка файловых дескрипторов
Elasticsearch работает с большим количеством файловых дескрипторов, и их нехватка может катастрофически сказаться на его работе. Согласно официальной документации необходимо указать значение файловых дескрипторов не ниже 65 536.
Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.
Для установки из архива необходимо в файле /etc/security/limits.conf установить параметр nofile для пользователя, который осуществляет запуск Elasticsearch. В примере ниже таким пользователем является elasticsearch :
Проверить установленные значения можно следующим образом:
Настройка виртуальной памяти
Elasticsearch по умолчанию использует каталог mmapfs для хранения индексов, и ограничение операционной системы по умолчанию для счетчиков mmap может привести к нехватки памяти. Для настройки запустите из-под root следующую команду:
Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.
Настройка потоков
Необходимо убедиться, что количество потоков, которые Elasticsearch может создавать, было не менее 4096.
DNS кеширование
Временный каталог для JNA
На этом шаге дополнительные настройки Elasticsearch окончены.
Заключение
Дойдя до этого места, вы должны иметь работоспособный кластер Elasticsearch.
В следующей статье будут описаны процедуры установки и настройки Kibana и Logstash. А в качестве проверки работоспособности кластера соберём данные из файла и посмотрим на них с помощью Kibana.
Практическое применение ELK. Настраиваем logstash
Разворачивая очередную систему, столкнулись с необходимостью обрабатывать большое количество разнообразных логов. В качестве инструмента выбрали ELK. В данной статье пойдёт речь о нашем опыте настройки этого стека.
Не ставим цели описать все его возможности, но хотим сконцентрироваться именно на решении практических задач. Вызвано это тем, что при наличии достаточно большого количества документации и уже готовых образов, подводных камней достаточно много, по крайней мере у нас они обнаружились.
Мы разворачивали стек через docker-compose. Более того, у нас был хорошо написанный docker-compose.yml, который позволил нам практически без проблем поднять стек. И нам казалось, что победа уже близка, сейчас немного докрутим под свои нужды и всё.
К сожалению, попытка донастроить систему на получение и обработку логов от нашего приложения, с ходу не увенчалась успехом. Поэтому, мы решили, что стоит изучить каждый компонент отдельно, а потом уже вернуться к их связям.
Итак, начали с logstash.
Окружение, развёртывание, запуск Logstash в контейнере
Для развёртывания используем docker-compose, описанные здесь эксперименты проводились на MacOS и Ubuntu 18.0.4.
Образ logstash, который был прописан у нас в исходном docker-compose.yml, это docker.elastic.co/logstash/logstash:6.3.2
Его мы будем использовать для экспериментов.
Для запуска logstash мы написали отдельный docker-compose.yml. Можно конечно было из командной строки образ запускать, но мы ведь конкретную задачу решали, где у нас всё из docker-compose запускается.
Кратко про конфигурационные файлы
Внутри контейнера есть ещё один конфигурационный файл — logstash.yml. Мы его не трогаем, используем как есть.
Итак, структура наших каталогов:
Для получения входных данных пока считаем, что это tcp по порту 5046, а для вывода будем использовать stdout.
Вот такая простая конфигурация для первого запуска. Поскольку ведь начальная задача — запустить.
Итак, у нас есть вот такой docker-compose.yml
Что мы здесь видим?
Здесь описан один канал с идентификатором HABR и путь к его конфигурационному файлу.
И наконец файл «./config/pipelines/habr_pipeline.conf»
Не будем пока вдаваться в его описание, пробуем запустить:
Контейнер запустился. Можем проверить его работу:
И видим в консоли контейнера ответ:
Но при этом, видим также:
logstash_one_channel | [2019-04-29T11:28:59,790] [ERROR][logstash.licensechecker.licensereader] Unable to retrieve license information from license server <:message=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] [Manticore::ResolutionFailure] elasticsearch», …
logstash_one_channel | [2019-04-29T11:28:59,894][INFO ][logstash.pipeline ] Pipeline started successfully <:pipeline_id=>«.monitoring-logstash», :thread=>»#
logstash_one_channel | [2019-04-29T11:28:59,988][INFO ][logstash.agent ] Pipelines running <:count=>2, :running_pipelines=>[:HABR, :».monitoring-logstash»], :non_running_pipelines=>[]>
logstash_one_channel | [2019-04-29T11:29:00,015] [ERROR][logstash.inputs.metrics ] 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 | [2019-04-29T11:29:00,526][INFO ][logstash.agent ] Successfully started Logstash API endpoint <:port=>9600>
logstash_one_channel | [2019-04-29T11:29:04,478][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
l ogstash_one_channel | [2019-04-29T11:29:04,487] [WARN ][logstash.outputs.elasticsearch] 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/][Manticore::ResolutionFailure] elasticsearch»>
logstash_one_channel | [2019-04-29T11:29:04,704][INFO ][logstash.licensechecker.licensereader] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
logstash_one_channel | [2019-04-29T11:29:04,710] [WARN ][logstash.licensechecker.licensereader] 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/][Manticore::ResolutionFailure] elasticsearch»>
И наш лог всё время ползёт вверх.
Здесь я выделил зелёным цветом сообщение о том, что pipeline успешно запустилась, красным — сообщение об ошибке и жёлтым — сообщение о попытке связаться с elasticsearch:9200.
Происходит это из за того, что в logstash.conf, включенном в состав образа, стоит проверка на доступность elasticsearch. Ведь logstash предполагает, что работает в составе Elk стека, а мы его отделили.
Работать можно, но не удобно.
Решением является отключить эту проверку через переменную окружения XPACK_MONITORING_ENABLED.
Внесём изменение в docker-compose.yml и снова запускаем:
Вот теперь, всё нормально. Контейнер готов к экспериментам.
Можем снова набрать в соседней консоли:
Работа в рамках одного канала
Итак, мы запустились. Теперь собственно можно уделить время настройке непосредственно logstash. Не будем пока трогать файл pipelines.yml, посмотрим, что можно получить, работая с одним каналом.
Надо сказать, что общий принцип работы с файлом конфигурации канала хорошо описан в официальном руководстве, вот здесь
Если хочется почитать по-русски, то мы пользовались вот этой статьёй(но синтаксис запросов там старый, надо это учитывать).
Пойдем последовательно от секции Input. Работу по tcp мы уже видели. Что ещё здесь может быть интересного?
Тестовые сообщения, используя heartbeat
Есть такая интересная возможность генерировать автоматические тестовые сообщения.
Для этого в input секцию нужно включить плагин heartbean.
Включаем, начинаем раз в минуту получать
Хотим получать почаще, надо добавить параметр interval.
Вот так будем получать раз в 10 секунд сообщение.
Получение данных из файла
Ещё решили посмотреть режим file. Если нормально с файлом работает, то возможно, и агента никакого не потребуется, ну хотя бы для локального использования.
Итак, что мы хотим получить:
И изменим секцию input в habr_pipeline.conf
Для создания и записывания лог файлов будем пользоваться командой:
При этом, мы видим, что у нас автоматически добавилось поле path. Значит в дальнейшем, мы сможем по нему фильтровать записи.
А теперь в другой файл:
Отлично! Файл подхватился, path указался верно, всё хорошо.
Остановим logstash и запусти заново. Подождём. Тишина. Т.е. Повторно мы эти записи не получаем.
А теперь самый смелый эксперимент.
Кладём logstash и выполняем:
Снова запускаем logstash и видим:
Ура! Всё подхватилось.
Но, надо предупредить о следующем. Если контейнер с logstash удаляется (docker stop logstash_one_channel && docker rm logstash_one_channel), то ничего не подхватится. Внутри контейнера была сохранена позиция файла, до которой он был считан. Если запускать «с нуля», то он будет принимать только новые строки.
Считывание уже существующих файлов
Допустим мы первый раз запускаем logstash, но у нас уже есть логи и мы хотели бы их обработать.
Если мы запустим logstash с той секцией input, которую использовали выше, то мы ничего не получим. Только новые строки будут обрабатываться logstash.
Для того, чтобы подтянулись строки из существующих файлов, следует добавить в input секцию дополнительную строчку:
Причём, есть нюанс, это действует только на новые файлы, которые logstash ещё не видел. Для тех же файлов, что уже попадали в поле зрения logstash, он уже запомнил их размер и теперь будет брать только новые записи в них.
Остановимся на этом на изучении секции input. Там ещё множество вариантов, но нам, для дальнейших экспериментов пока хватит.
Маршрутизация и преобразование данных
Попробуем решить следующую задачу, допустим у нас идут сообщения из одного канала, часть из них информационные, а часть сообщение об ошибках. Отличаются тегом. Одни INFO, другие ERROR.
Нам нужно на выходе их разделить. Т.е. Информационные сообщения пишем в один канал, а сообщения об ошибках в другой.
Для этого, от секции input переходим к filter и output.
С помощью секции filter мы разберём входящее сообщение, получив из него hash(пары ключ-значение), с которым уже можно работать, т.е. разбирать по условиям. А в секции output, отберём сообщения и отправим каждое в свой канал.
Разбор сообщения с помощью grok
Для того, чтобы разбирать текстовые строки и получать из них набор полей, в секции filter есть специальный плагин — grok.
Не ставя себе целью дать здесь его детальное описание (за этим отсылаю к официальной документации), приведу свой простой пример.
Для этого, надо определиться с форматом входных строк. У меня они такие:
1 INFO message1
2 ERROR message2
Т.е. Идентификатор на первом месте, затем INFO/ERROR, затем какое-то слово без пробелов.
Не сложно, но для понимания принципа работы хватит.
Итак, в секции filter, в плагине grok мы должны определить паттерн для разбора наших строк.
Выглядеть он будет так:
По сути, это регулярное выражение. Используются уже готовые паттерны, такие как INT, LOGLEVEL, WORD. Их описание, а также другие паттерны, можно посмотреть вот здесь
Теперь, проходя через этот фильтр, наша строка превратится в hash из трёх полей: message_id, message_type, message_text.
Именно они будут выводиться в секции output.
Маршрутизация сообщений в секции output с помощью команды if
В секции output, как мы помним, мы собирались разделить сообщения на два потока. Одни — которые iNFO, будем выводить на консоль, а с ошибками, будем выводить в файл.
Как нам разделить эти сообщения? Условие задачи уже подсказывает решение — у нас ведь есть уже выделенное поле message_type, которое может принимать только два значения INFO и ERROR. Именно по нему и сделаем выбор с помощью оператора if.
Описание работы с полями и операторами, можно посмотреть вот в этой секции официального мануала.
Теперь, про собственно сам вывод.
Вывод в консоль, здесь всё понятно — stdout <>
А вот вывод в файл — вспоминаем, что мы это всё запускаем из контейнера и чтобы файл, в который мы пишем результат, был доступен снаружи, нам необходимо открыть эту директорию в docker-compose.yml.
Секция output нашего файла выглядит вот так:
В docker-compose.yml добавляем ещё один том, для вывода:
Запускаем, пробуем, видим разделение на два потока.
Elk что это такое
В этой статье рассмотрим ELK-инфраструктуру: разберем, зачем поисковый движок Elasticsearch использует сборщик логов Logstash и при чем здесь визуальный интерфейс Kibana. Также поговорим, в каких Big Data проектах используются эти системы и для чего.
Зачем вам Elasticsearch: полнотекстовый поиск по Big Data
Чтобы определить, почему деньги пропали с банковского счета или кто именно из сотрудников слил персональные данные клиентов в сеть и найти причины прочих инцидентов в корпоративном масштабе, нужна полная картина произошедшего. Составить ее поможет анализ системных логов – журналов, где зафиксированы все события, случившиеся в системе за конкретный промежуток времени [1]. Сегодня наиболее популярным инструментом для построения решений по мониторингу корпоративной инфраструктуры считается ELK – Elasticsearch, Logstash и Kibana. Изначально эти 3 продукта с открытым исходным кодом развивались отдельно друг от друга, но в 2015 году стали принадлежать одной компании Elastic. Сегодня Elasticsearch, Logsatsh и Kibana используются вместе для задач сбора, хранения и анализа данных [2].
Мощные возможности ELK-инфраструктуры позволяют не только анализировать системные логи в рамках задачи администрирования корпоративного ИТ-ландшафта. Также эта Big Data система отлично подходит для решения следующих бизнес-задач [3]:
Далее рассмотрим подробнее, из чего состоит ELK-система и как она устроена.
Что внутри ELK-системы: архитектура и принципы работы
Инфраструктура ELK включает следующие компоненты [2]:
В рамках единой ELK-платформы все вышеперечисленные компоненты взаимодействуют следующим образом [5]:
Завтра мы рассмотрим главные достоинства и недостатки ELK-инфраструктуры. А как эффективно использовать их для сбора и анализа больших данных в реальных проектах, вы узнаете на практических курсах по администрированию и эксплуатации Big Data систем в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков) в Москве.
1.Elastic stack: анализ security логов. Введение
В связи окончанием продаж в России системы логирования и аналитики Splunk, возник вопрос, чем это решение можно заменить? Потратив время на ознакомление с разными решениями, я остановился на решении для настоящего мужика — «ELK stack». Эта система требует времени на ее настройку, но в результате можно получить очень мощную систему по анализу состояния и оперативного реагирования на инциденты информационной безопасности в организации. В этом цикле статей мы рассмотрим базовые (а может и нет) возможности стека ELK, рассмотрим каким образом можно парсить логи, как строить графики и дашбоарды, и какие интересные функции можно сделать на примере логов с межсетевого экрана Check Point или сканера безопасности OpenVas. Для начала, рассмотрим, что же это такое — стек ELK, и из каких компонентов состоит.
«ELK stack» — это сокращение от трех проектов с открытым исходным кодом: Elasticsearch, Logstash и Kibana. Разрабатывается компанией Elastic вместе со всеми связанными проектами. Elasticsearch — это ядро всей системы, которая сочетает в себе функции базы данных, поисковой и аналитической системы. Logstash — это конвейер обработки данных на стороне сервера, который получает данные из нескольких источников одновременно, парсит лог, а затем отправляет в базу данных Elasticsearch. Kibana позволяет пользователям визуализировать данные с помощью диаграмм и графиков в Elasticsearch. Также через Kibana можно администрировать базу данных. Далее более детально рассмотрим каждую систему отдельно.
Logstash
Logstash – это утилита для обработки лог событий из различных источников, с помощью которой можно выделить поля и их значения в сообщении, также можно настроить фильтрацию и редактирование данных. После всех манипуляций Logstash перенаправляет события в конечное хранилище данных. Утилита настраивается только через конфигурационные файлы.
Типичная конфигурация logstash представляет из себя файл(ы) состоящий из нескольких входящих потоков информации (input), несколько фильтров для этой информации (filter) и несколько исходящих потоков (output). Выглядит это как один или несколько конфигурационных файлов, которые в простейшем варианте (который не делает вообще ничего) выглядит вот так:
В INPUT мы настраиваем на какой порт будут приходить логи и по какому протоколу, либо из какой папки читать новые или постоянно дозаписывающиеся файлы. В FILTER мы настраиваем парсер логов: разбор полей, редактирование значений, добавление новых параметров или удаление. FILTER это поле для управления сообщением которое приходит на Logstash с массой вариантов редактирования. В output мы настраиваем куда отправляем уже разобранный лог, в случае если это elasticsearch отправляется JSON запрос, в котором отправляются поля со значениями, либо же в рамках дебага можно выводить в stdout или записывать в файл.
ElasticSearch
Изначально, Elasticsearch – это решение для полнотекстового поиска, но с дополнительными удобствами, типа легкого масштабирования, репликации и прочего, что сделало продукт очень удобным и хорошим решением для высоконагруженных проектов с большими объемами данных. Elasticsearch является нереляционным хранилищем(NoSQL) документов в формате JSON, и поисковой системой на базе полнотекстового поиска Lucene. Аппаратная платформа — Java Virtual Machine, поэтому системе требуется большое количество ресурсов процессора и оперативки для работы.
Каждое приходящее сообщение, как с Logstash или с помощью API запроса, индексируется как “документ” – аналог таблицы в реляционных SQL. Все документы хранятся в индексе – аналог базы данных в SQL.
Пример документа в базе:
Вся работа с базой данных строится на JSON запросах с помощью REST API, которые либо выдают документы по индексу, либо некую статистику в формате: вопрос — ответ. Для того чтобы все ответы на запросы визуализировать была написана Kibana, которая представляет из себя веб сервис.
Kibana
Kibana позволяет искать\брать данные и запрашивать статистику из базы данных elasticsearch, но основе ответов строятся множество красивых графиков и дашбоардов. Также система имеет функционал администрирования базы данных elasticsearch, в последующих статьях мы рассмотрим более подробно данный сервис. А сейчас покажем пример дашбоардов по межсетевому экрану Check Point и сканеру уязвимостей OpenVas, которые можно будет построить.
Пример дашбоарда для Check Point, картинка кликабельна:
Пример дашбоарда по OpenVas, картинка кликабельна:
Заключение
Мы рассмотрели из чего состоит ELK stack, немного познакомились с основными продуктами, далее в курсе отдельно будем рассматривать написание конфигурационного файла Logstash, настройку дашбоардов на Kibana, познакомимся с API запросами, автоматизацией и много чего еще!