Введение в стек ELK

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

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

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

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

В настоящее время большинство ИТ-инфраструктур переместилось в общедоступные облака, такие как Amazon Web Services , Microsoft Azure , Digital Ocean или Google Cloud .

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

ELK Stack создан именно для таких ситуаций.

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

ELK означает:

ElasticSearch - используется для глубокого поиска и анализа данных. Это распределенная база данных NoSQL с открытым исходным кодом, построенная на Java и основанная на Apache Lucene. Lucene заботится о хранении данных на диске, индексировании и сканировании документов, в то время как ElasticSearch хранит обновления документов, API-интерфейсы и распределение документов между экземплярами ElasticSearch в одном кластере.
Logstash - используется для централизованного ведения журнала, обогащения и анализа журнала. Это инструмент ETL (извлечение, передача, загрузка), который преобразует и хранит журналы в ElasticSearch.
Kibana - используется для мощной и красивой визуализации данных. Это веб-инструмент, с помощью которого базы данных ElasticSearch визуализируют и анализируют ранее сохраненные данные.

Эти три инструмента необходимы для анализа и визуализации событий в системе.

Анализ журнала

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

Хорошей «целью» для ведения журнала на уровне приложения является все, что связано с любым взаимодействием пользователя с системой - будь то авторизация пользователя в системе или запрос пользователя на какой-либо URL-адрес, электронное письмо, отправленное пользователю, и т. Д. регистрировать разнообразную информацию, этот журнал вообще не структурирован, но он должен содержать некоторую базовую информацию, чтобы вам было легче получить к нему доступ.

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

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

Logstash

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

Он собирает данные из разных источников, а затем передает их в виде конвейера обработки данных в экземпляр ElasticSearch.

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

Обработка Logstash проходит в три этапа:

Ввод - запись, помимо файла, также может быть системным журналом, Redis или Lumberjack (теперь logstash-forwarder). Redis часто используется в качестве брокера pub / sub в централизованной инфраструктуре Logstash, где производители Logstash отправляют свои сообщения, а один из экземпляров обрабатывает их дальше.
Преобразование и фильтрация - этот этап происходит в соответствии с набором ранее определенных правил, где, помимо, например, преобразования формата даты, также может быть зарегистрирована информация об IP-адресе (город / страна IP). Для этого используется бесплатная база данных MaxMind.
Вывод - вывод может быть преобразован с помощью плагинов практически в любой формат, в нашем случае это будет ElasticSearch.

Давайте посмотрим на файл конфигурации Logstash и пример журнала приложения:

logstash.conf :

 input { 
 file { 
 path => ["/var/log/myapp/*.log"] 
 } 
 } 
 
 filter { 
 // Collect or process some data (eg 'time') as timestamp and 
 // store them into @timestamp data. 
 // That data will later be used by Kibana. 
 
 date { 
 match => [ "time" ] 
 } 
 
 // Adds geolocation data based on the IP address. 
 geoip { 
 source => "ip" 
 } 
 } 
 
 output { 
 elasticsearch { 
 hosts => ["localhost:9200"] 
 } 
 stdout { codec => rubydebug } 
 }

Журнал приложений ::

 { 
 "action": "action log", 
 "user": "John", 
 "time": 12:12:2012, 
 "ip": "192.168....", 
 "transaction-id": "r5e1244-32432-1465-q346-6ahsms57081x4" 
 }

ElasticSearch

В тот момент, когда Logstash завершает свою работу и пересылает журналы, ElasticSearch уже может обрабатывать данные.

С простого curl команды curl -XGET 'http://192.168.(host ip):9200/_search' вы можете увидеть «документы» в базе данных.

192.168.(host ip) в данном случае является адресом виртуальной машины boot2docker , а 9200 - это открытый порт по умолчанию.

Поскольку результат находится в формате JSON, ваши результаты готовы для дальнейшей обработки. curl -XGET 'http: //192.168.(host ip):9200/_search?hello' возвращает более читаемую версию документа для быстрой проверки. В зависимости от разработки, обычная практика заключается в регистрации запроса / ответа полезной нагрузки, идентификатора корреляции и т. Д., Чтобы вы могли отслеживать ошибку через панель управления пользовательского интерфейса Kibana позже.

Кибана

Kibana - это, по сути, просто клиент статического пользовательского интерфейса (HTML + CSS + JS), который отображает данные так, как вы хотели, в экземпляре ElasticSearch, где вы видите различные отчеты и аналитику. За исключением того, что с помощью Kibana вы можете легко выполнять запросы по индексам ElasticSearch, главное преимущество заключается в том, что для этих запросов, какими бы сложными они ни были, вы можете «упорядочить» их на очень прозрачной «панели инструментов» и эту «панель мониторинга» для сохранения и поделитесь с другими.

Kibana поставляется с очень мощным набором инструментов визуализации, поэтому, например, вы можете видеть, как часто подобное событие повторяется с течением времени, вы можете агрегировать события по различным критериям (например, сколько запросов пришло с определенного IP-адреса. за последний час, увеличилось ли количество ошибок на конкретном сервере, или даже заметили ли увеличение количества запросов для конкретной страницы). Кроме того, это отличный инструмент для обнаружения аномалий, вызванных изменениями в вашей системе.

Кибана {.ezlazyload .img-responsive}

Испытание стека ELK

Чтобы иметь возможность опробовать стек ELK и попробовать некоторые из команд, которые мы собираемся рассмотреть, вам необходимо установить ELK и Docker или boot2docker локально.

Docker - это инструмент, предназначенный для упрощения создания, развертывания и запуска приложений с использованием контейнеров.

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

Для этого теста мы будем использовать образ ELK Docker :

 $ docker pull sebp/elk 
 $ docker run -p 5601:5601 -p 9200:9200 -p 5000:5000 -it --name elk sebp/elk 
 $ docker exec -it elk /bin/bash 
 $ /logstash/bin/logstash -e 'input { stdin { } } output { elasticsearch { host => localhost } }' 
 # Now write the message eg 
 This is a test message. 
 CTRL-C

На хост-машине мы будем использовать curl :

 $ curl -s -XGET 'http://192.168.(host ip):9200/_search?hello&q=message'

Результат будет таким:

 { 
 "took" : 3, 
 "timed_out" : false, 
 "_shards" : { 
 "total" : 6, 
 "successful" : 6, 
 "failed" : 0 
 }, 
 "hits" : { 
 "total" : 1, 
 "max_score" : 0.4790727, 
 "hits" : [ { 
 "_index" : "logstash-2018.08.26", 
 "_type" : "logs", 
 "_id" : "Z8kCtFYHOWWinjAN6pHUqE", 
 "_score" : 0.5720636, 
 "_source":{"message":"This is a test message.","@version":"1","@timestamp":"2018-08-26T09:41:17.634Z","host":"5136b631e113"} 
 } ] 
 } 
 }

Как видите, в результате нашего поиска нам был возвращен 1 экземпляр журнала в формате JSON.

ElasticSearch и потеря данных на сетевых разделах

Как и все другие инструменты, ELK Stack имеет собственный набор проблем. В прошлом году и в этом году было написано множество статей о том, как ElasticSearch теряет данные из-за раздела сети, даже если состояние раздела в сети длится всего несколько секунд.

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

Интересно то, что даже микро-разделы могут вызывать задержку в 90 секунд, в течение которой новый лидер в кластере работает, и все, что было вставлено во время этого кластера, потенциально может быть отброшено, поэтому рекомендуется хранить ваши журналы в оригинале. форматировать и не полагаться на 100% ElasticSearch даже для «критически важных» журналов.

Заключение

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

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

Удачной регистрации!