Elk стек что это
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 запросами, автоматизацией и много чего еще!
ELK Stack
ELK Stack, What?
Юз кейсы, когда нужно внедрять ELK:
Юз кейсы, когда рекомендуется внедрять ELK:
когда девы хотят красивенько смотреть логи в браузере
когда Вы хотите красивенько смотреть логи в браузере
когда у Вас есть необходимость посмотреть что было с аппом в период с 19:45:08 до 19:45:10 и nano на сервере подвисает
Анти юз кейсы, когда не нужно внедрять ELK:
Во всех остальных случаях внедрять агрегацию логов однозначно нужно, тем более, что это решает одну самую главную проблему любого Ops/DevOps/Sysadmin:
— Здравствуйте, бородатый сисадмин! Зайдите, пожалуйста, на сервер sheet.prod.it.company, и скопируйте мне одну строку лога за неделю назад, я не знаю какую, но она была примерно 500000 секунд назад, там ещё ошибка была! Спасибо!
— Я DevOps, вот тебе инструмент: зайди на kibana.it.company ищи там что тебе нужно.
— Благодарю Вас, о великий DevOps! Больше никогда не буду отвлекать Вас по таким пустякам!
Внедряем!
Сначала определимся с терминами:
Пререквизиты
В Logstash заваливаются сами логи, он их процессит внутри согласно правилам которые Вы опишете, и индексирует в хранилку, в Elasticsearch. Соответственно ему нужен CPU для парсинга, и немного мема чтобы держать в памяти то, что уже распарсилось но еще не успело залезть в Еластик.
Через Kibana все будут взаимодействовать с хранилкой логов. Кибана любит открывать 100500 соединений в кластер Еластиксерча, рекомендую поставить эти продукты поближе.
Filebeat опа, внезапность, будет стоять на каждой виртуалке и отправлять нам логи.
Сетап
Ничего сложного, довольно тривиальный процесс.
Как оно работает
Filebeat Интерналс
В конфигах нужно указать путь к лог файлу, дать тип для этого типа логов, и настроить урлу логстеша, куда он будет отсылать. Все.
Logstash Интерналс
Конфиг логстеша делится на 3 части: инпут, фильтр, аутпут. Инпутов у него очень много разных, реально используется beats:
На этих портах будет слушать Логстеш. Закрываем его шифрованием, чтобы никто плохой ничего лишнего не прислал.
После того как лог попадёт в инпут, и это будет валидный тип (тот, который слушает логстеш на этом инпуте), он уйдет дальше в фильтр.
Инпутов очень много. Справедливости ради стоит сказать, что пацаны которые не успевают парсить логстешем логи ставят перед ним Rabbit/Redis/Kafka для того, чтобы создавать пул задач на логстеш. Это не очень хорошее решение.
> Кстати, хоть grok и mutate использовать плохо, потому что grok выносит CPU своими регекспеми, а mutate превращает Logstash в однопоточный костыльный апп, все равно почитать про них нужно.
Когда лог пройдет все фильтры, он попадет в аутпут. Как правило, с аутпутом все просто:
До этого этапа я пытался вызвать когнитивный диссонанс:
юзать только beats инпут
не делать пул тасок перед логстешами
— Кококо, у меня логи стремные, я не смогу их так красиво распарсить и разложить по полкам! Я cдохну собирать разные строки стектрейса используя multiline, и потом это матчить регекспом, используя grok!
— Да. Поэтому пиши лог в json.
Это очень элегантное решение которое разруливает все вопросы с перформенсом и серчем. Девы должны сразу писать в джейсоне. Не буду останавливаться на этом, это слишком очевидно чтобы объяснять что-то еще.
> Кстати, в json писать умеют все. Начиная с nginx и haproxy, заканчивая log4j, log4net, log4py, etc.
Elasticsearch Интерналс
Он работает даже если его не трогать. Пусть работает. Главное не забывать писать в отдельные индексы:
Перформенс будет теряться на больших или размазанных выборках. Не нужно пытаться серчить все ерроры за миллион лет, ищите точное вхождение нужного ексепшена, который вызвал этот еррор.
С Еластиком интегрится очень много крутых штук. Например, для понимания того что происходит внутри еластика отлично подходит elasticsearch-kopf, с помощью его можно смотреть стату по всему кластеру: ноды/индексы/шарды/ресурсы/маппинги.
Очень интересно интегрироваться с Grafana, и потом рисовать, например, персентили скорости ответа нжинкса хомяка.
Graylog
Альтернатива
> Кстати, Уважаемый Сева из Grammarly рассказывал интереснейшую историю про Mozilla Heka, судя по отзывам эта вещь немного бревно, но универсальное. В общем, интересно что получится из этого.
Severity: Important
Резюмируя скажу, что ELK Stack на данный момент единственное продакшн решение для Logs aggregation, которое стабильно работает при любых адекватных и неадекватных нагрузках, отлично скейлится, и дает себя настраивать так, как это нужно конкретно Вам.
Важно помнить, что лучше не парсить логи, а писать их сразу в нормальном формате для быстрого индексирования.
Практическое применение 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: собираем, фильтруем и анализируем большие данные
Внимание! Статье уже четыре года и многое в используемых технологиях могло измениться. Не забываем консультироваться с офф. документацией.
Что, если я скажу вам, что логи могут быть не только полезными и содержать тонну важной информации, но и что работа с ними может быть классной, интересной и увлекательной? Настолько же увлекательной, интересной и классной, как кликанье через удобный интерфейс в браузере, позволяющий в считанные секунды вывести любой график и сравнить его с другим графиком? Да чего там: что, если я скажу вам, что после прочтения этой статьи вы сможете развернуть полноценный аналог Google Analytics для ваших логов? А я это и скажу. Точнее, я это уже сказал. Погнали!
Подготовим vagrant-коробку
Прежде чем перейдём к самой сути, нам необходимо провести небольшую подготовительную работу. Возможно, вы уже использовали Vagrant. Если нет – обязательно узнайте что это такое и начните использовать. Знание Vagrant не нужно для этой статьи, но будет классно (и позволит избежать возможных несоответствий в результате), если вы будете запускать примеры кода ниже используя такой же как у меня конфиг vagrant-бокса.
Затем выполняем 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, в самом-то деле.
Установка logstash
Я использовал logstash 2.2.0, документация по его установке валяется на оф. сайте. Прежде чем перейти к установке необходимо дополнительно установить на машине java. Выполняем одно за другим:
Всё, готово. Установили.
Установка elasticsearch
Версия elasticsearch тоже 2.2.0
Установка kibana
Используемая версия Kibana: 4.4.2. В реальных условиях, конечно, kibana должна быть отделена от logstash и elasticsearch и крутиться на отдельном сервере.
Конфигурируем logstash
Самая сложная часть – фильтры. Я использую multiline, потому что каждая запись в логах rails занимает несколько строчек. Опция pattern указывает на начало каждой записи.
grok – это регулярные выражения на стероидах. Позволяет определять конкретные шаблоны регулярных выражений, которые могут содержать в себе другие шаблоны. В logstash куча встроенных шаблонов grok. К сожалению, для rails там встроенного шаблона нет. После недолгих поисков в интернете я нашёл почти готовый шаблон, немного отредактировал его и он отлично сработал для логов mkdev.me (см. чуть ниже).
