Стек ELK
Что такое стек ELK?
ELK – это аббревиатура, используемая для описания стека из трех популярных проектов: Elasticsearch, Logstash и Kibana. Стек ELK, зачастую именуемый Elasticsearch, предоставляет возможность собирать журналы всех ваших систем и приложений, анализировать их и создавать визуализации, чтобы мониторить приложения и инфраструктуры, быстрее устранять неполадки, анализировать систему безопасности и многое другое.
E = Elasticsearch
Elasticsearch – это распределенный поисковый и аналитический движок на базе Apache Lucene. Он становится идеальным инструментом для различных примеров использования аналитики журналов и поиска благодаря поддержке различных языков, высокой производительности и документам JSON без схем. Подробнее »
21 января 2021 года Elastic NV объявила об изменении стратегии лицензирования программного обеспечения и о том, что новые версии Elasticsearch и Kibana под разрешительной лицензией Apache версии 2.0 (ALv2) выходить не будут. Вместо них предложены новые версии программного обеспечения по лицензии Elastic, а исходный код доступен по лицензии Elastic или SSPL. Эти лицензии не являются открытыми исходными кодами и не дают пользователям ту же свободу. Желая предоставить специалистам, которые работают с открытым исходным кодом, и нашим клиентам безопасный высококачественный комплект инструментов для поиска и аналитики с полностью открытым исходным кодом, мы создали проект OpenSearch – развиваемая сообществом ветвь открытого исходного кода Elasticsearch и Kibana с лицензией ALv2. Комплект OpenSearch состоит из поискового движка, OpenSearch и интерфейса визуализации и пользовательского интерфейса OpenSearch Dashboards.
L = Logstash
Logstash – это предназначенный для приема данных инструмент с открытым исходным кодом, который позволяет собирать данные из различных источников, преобразовывать их и отправлять в нужное место назначения. Благодаря встроенным фильтрам и поддержке более 200 подключаемых модулей Logstash обеспечивает пользователям простой доступ к данным независимо от их источника или типа. Подробнее »
K = Kibana
Kibana – это инструмент визуализации и изучения данных для просмотра журналов и событий. Kibana предлагает простые в использовании интерактивные диаграммы, встроенные агрегаторы и фильтры, а также геопространственную поддержку, благодаря чему является предпочтительным выбором для визуализации данных, хранящихся в Elasticsearch. Подробнее »
Стек ELK удовлетворяет потребности в сфере аналитики журналов. Когда большая часть ИТ-инфраструктуры перемещается в публичные облака, вам требуется решение для аналитики и управления журналами, которое позволит мониторить эту инфраструктуру, а также обрабатывать любые журналы серверов или приложений и данные навигации. Стек ELK дает простое, но надежное решение по анализу журналов для разработчиков и инженеров DevOps, которое позволяет получить полезные выводы из диагностики сбоев, производительности приложений и мониторинга инфраструктуры – за небольшую плату.
Почему стек ELK настолько популярен?
Потому что стек ELK удовлетворяет потребности в сфере аналитики журналов. Когда большая часть ИТ-инфраструктуры перемещается в публичные облака, вам требуется решение для аналитики и управления журналами, которое позволит мониторить эту инфраструктуру, а также обрабатывать любые журналы серверов или приложений и данные навигации. Стек ELK дает простое, но надежное решение по анализу журналов для разработчиков и инженеров DevOps, которое позволяет получить полезные выводы из диагностики сбоев, производительности приложений и мониторинга инфраструктуры – за небольшую плату.
Стек ELK. Выбор подходящего варианта
Вы можете развернуть стек ELK и управлять с помощью версий Elasticsearch и Kibana Apache 2.0 (до 7.10.2) под лицензией Apache 2.0 или самостоятельно управляемой альтернативой стека ELK с открытым исходным кодом через OpenSearch, OpenSearch Dashboards и Logstash. Вы предпочтете, чтобы разработчики или инженеры DevOps тратили время на создание инновационных приложений или управление операционными задачами, такими как развертывание, обновление, установка и исправление программного обеспечения, резервное копирование и мониторинг? Кроме того, вертикальное масштабирование в соответствии с нуждами вашего бизнеса или обеспечение безопасности и соответствия требованиям – это сложная задача при самостоятельном управлении.
Или выберите более простой, масштабируемый и безопасный вариант.
Знакомство с Amazon OpenSearch Service (преемник Amazon Elasticsearch Service)
Как начать работу с Amazon OpenSearch Service?
Вам повезло — мы создали пошаговое руководство, чтобы помочь вам на старте работы с Amazon OpenSearch Service. С уровнем бесплатного использования AWS вы можете запустить свой первый домен без риска и затрат.
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, которое стабильно работает при любых адекватных и неадекватных нагрузках, отлично скейлится, и дает себя настраивать так, как это нужно конкретно Вам.
Важно помнить, что лучше не парсить логи, а писать их сразу в нормальном формате для быстрого индексирования.
Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)
Напомним, что в основе Elastic Stack лежат нереляционная база данных Elasticsearch, веб-интерфейс Kibana и сборщики-обработчики данных (самый известный Logstash, различные Beats, APM и другие). Одно из приятных дополнений всего перечисленного стека продуктов — анализ данных при помощи алгоритмов машинного обучения. В статье мы разбираемся что из себя представляют эти алгоритмы. Просим под кат.
Машинное обучение — платная функция условно-бесплатного Elastic Stack и входит в пакет X-Pack. Чтобы начать им пользоваться достаточно после установки активировать 30-дневный триальник. После истечения пробного периода можно запросить поддержку о его продлении или купить подписку. Стоимость подписки рассчитывается не от объёма данных, а от количества используемых нод. Нет, объём данных влияет, конечно, на количество необходимых нод, но всё же такой подход к лицензированию более гуманный по отношению к бюджету компании. Если нет нужды в высокой производительности — можно и сэкономить.
ML в Elastic Stack написан на С++ и работает за пределами JVM, в которой крутится сам Elasticsearch. То есть процесс (он, кстати, называется autodetect) потребляет всё, что не проглотит JVM. На демо-стенде это не так критично, а вот в продуктивной среде важно выделить отдельные ноды для задач ML.
Алгоритмы машинного обучения делятся на две категории — с учителем и без учителя. В Elastic Stack алгоритм из категории «без учителя». По этой ссылке можно посмотреть математический аппарат алгоритмов машинного обучения.
Для проведения анализа алгоритм машинного обучения использует данные, хранящиеся в индексах Elasticsearch. Создавать задания для анализа можно как из интерфейса Kibana так и через API. Если делать это через Kibana, то некоторые вещи знать необязательно. Например, дополнительные индексы, которые использует алгоритм в процессе работы.
.ml-state — информация о статистических моделях (настройках анализа);
.ml-anomalies-* — результаты работы алгоритмов ML;
.ml-notifications — настройки оповещений по результатам анализа.
Структура данных в базе Elasticsearch состоит из индексов и хранящихся в них документах. Если сравнивать с реляционной базой данных, то индекс можно сравнить со схемой базы данных, а документ с записью в таблице. Это сравнение условно и приведено для упрощения понимания дальнейшего материала для тех, кто только слышал про Elasticsearch.
Через API доступен тот же функционал, что и через веб-интерфейс, поэтому для наглядности и понимания концепций мы будем показывать как настраивать через Kibana. В меню слева есть раздел Machine Learning, в котором можно создать новое задание (Job). В интерфейсе Kibana это выглядит как на картинке ниже. Сейчас мы разберем каждый типа задания и покажем виды анализа, которые можно тут сконструировать.
Single Metric — анализ одной метрики, Multi Metric — анализ двух и более метрик. В обоих случаях каждая метрика анализируется в изолированной среде, т.е. алгоритм не учитывает поведение параллельно анализируемых метрик как это могло показаться в случае Multi Metric. Чтобы провести расчёт с учётом корреляции различных метрик можно применить Population-анализ. А Advanced — это тонкая настройка алгоритмов дополнительными опциями для определённых задач.
Single Metric
Анализ изменений одной единственной метрики — самое простое, что можно тут сделать. После нажатия на Create Job, алгоритм поищет аномалии.
В поле Aggregation можно выбрать подход к поиску аномалий. Например, при Min аномальными будут считаться значения ниже типичных. Есть Max, Hign Mean, Low, Mean, Distinct и другие. Описание всех функций можно посмотреть по ссылке.
В поле Field указывается числовое поле в документе, по которому будем проводить анализ.
В поле Bucket span — гранулярность промежутков на таймлайне, по которым будет вестись анализ. Можно довериться автоматике или выбрать вручную. На изображении ниже приведён пример слишком низкой гранулярности — вы можете пропустить аномалию. С помощью этой настройки можно изменять чувствительность алгоритма к аномалиям.
Длительность собранных данных — ключевая вещь, которая влияет на эффективность анализа. При анализе алгоритм определяет повторяющиеся промежутки, рассчитывает доверительный интервал (базовые линии) и выявляет аномалии — нетипичные отклонения от обычного поведения метрики. Просто для примера:
Базовые линии при небольшом отрезке данных:
Когда алгоритму есть на чём поучиться — базовые линии выглядит так:
После запуска задания, алгоритм определяет аномальные отклонения от нормы и ранжирует их по вероятности аномалии (в скобках указан цвет соответствующей метки):
Warning (голубой): менее 25
Minor (yellow): 25-50
Major (orange): 50-75
Critical (red): 75-100
На графике ниже пример с найденными аномалиями.
Тут видно цифру 94, которая обозначает вероятность аномалии. Понятно, что раз значение близкое к 100, значит перед нами аномалия. В столбце под графиком указана уничижительно малая вероятность 0.000063634% появления там значения метрики.
Кроме поиска аномалий в Kibana можно запустить прогнозирование. Делается это элементарно и из того же самого представления с аномалиями — кнопка Forecast в верхнем правом углу.
Прогноз строится максимум на 8 недель вперёд. Даже если очень хочется — больше нельзя by design.
В некоторых ситуациях прогноз будет очень полезен, например, когда отслеживается пользовательская нагрузка на инфраструктуру.
Multi Metric
Переходим к следующей возможности ML в Elastic Stack — анализу нескольких метрик одной пачкой. Но это не значит, что будет анализироваться зависимость одной метрики от другой. Это то же самое, что и Single Metric только с множеством метрик на одном экране для удобства сравнения влияния одного на другое. Про анализ зависимости одной метрики от другой расскажем в части Population.
После нажатия на квадрат с Multi Metric появится окно с настройками. На них остановимся подробнее.
Для начала нужно выбрать поля для анализа и агрегацию данных по ним. Варианты агрегации тут те же, что и для Single Metric (Max, Hign Mean, Low, Mean, Distinct и другие). Далее данные при желании разбиваются по одному из полей (поле Split Data). В примере мы это сделали по полю OriginAirportID. Обратите внимание, что график метрик справа теперь представлен в виде множества графиков.
Поле Key Fields (Influencers) напрямую влияет на найденные аномалии. По умолчанию тут всегда будет хотя бы одно значение, а вы можете добавить дополнительные. Алгоритм будет учитывать влияние этих полей при анализе и показывать самые «влиятельные» значения.
После запуска в интерфейсе Kibana появится примерно такая картина.
Это т.н. тепловая карта аномалий по каждому значению поля OriginAirportID, которое мы указали в Split Data. Как и в случае с Single Metric, цвет обозначает уровень аномального отклонения. Похожий анализ удобно делать, например, по рабочим станциям для отслеживания тех, где подозрительно много авторизаций и т.д. Мы уже писали о подозрительных событиях в EventLog Windows, которые также можно сюда собирать и анализировать.
Под тепловой картой список аномалий, с каждого можно перейти на представление Single Metric для детального анализа.
Population
Чтобы искать аномалии среди корреляций между разными метриками в Elastic Stack есть специализированный Population-анализ. Именно с помощью него можно поискать аномальные значения в производительности какого-либо сервера по сравнению с остальными при, например, увеличении количества запросов к целевой системе.
На этой иллюстрации в поле Population указано значение, к которому будут относиться анализируемые метрики. В данном это имя процесса. В результате мы увидим как загрузка процессора каждым из процессов влияла друг на друга.
Обратите внимание, что график анализируемых данных отличается от случаев с Single Metric и Multi Metric. Это сделано в Kibana by design для улучшенного восприятия распределения значений анализируемых данных.
Из графика видно, что аномально вёл себя процесс stress (к слову сказать, порождённый специальной утилитой) на сервере poipu, который повлиял (или оказался инфлюэнсером) на возникновение этой аномалии.
Advanced
Аналитика с тонкой настройкой. При Advanced анализе в Kibana появляются дополнительные настройки. После нажатия в меню создания на плитку Advanced появляется вот такое окно с вкладками. Вкладку Job Details пропустили намеренно, там базовые настройки не относящиеся непосредственно к настройке анализа.
В summary_count_field_name опционально можно указать название поля из документов, содержащего агрегированные значения. В этом примере — количество событий в минуту. В categorization_field_name указывается название значение поля из документа, которое содержит некое переменное значение. По маске на это поле можно разбивать анализируемые данные на подмножества. Обратите внимание на кнопку Add detector на предыдущей иллюстрации. Ниже результат нажатия на эту кнопку.
Здесь дополнительный блок настроек для настройки детектора аномалий под определённую задачу. Конкретные кейсы использования (особенно по безопасности) мы планируем разобрать в следующих статьях. Для примера, посмотрите один из разобранных кейсов. Он связан с поиском редко появляющихся значений и реализуется функцией rare.
В поле function можно выбрать определённую функцию для поиска аномалий. Кроме rare, есть ещё пара интересных функций — time_of_day и time_of_week. Они вывляют аномалии в поведении метрик на протяжении дня или недели соответственно. Остальные функции анализа есть в документации.
В field_name указывается поле документа, по которому будет вестись анализ. By_field_name может использоваться для разделения результатов анализа по каждому отдельному значению указанного здесь поля документа. Если заполнить over_field_name получится population-анализ, который мы рассматривали выше. Если указать значение в partition_field_name, то по этому полю документа будут рассчитываться отдельные базовые линии для каждого значения (в роли значения могут выступать, например, название сервера или процесса на сервере). В exclude_frequent можно выбрать all или none, что будет означать исключение (или включение) часто встречающихся значений полей документов.
В статье мы попытались максимально сжато дать представление о возможностях машинного обучения в Elastic Stack, за кадром осталось ещё немало подробностей. Расскажите в комментариях какие кейсы удалось решить при помощи Elastic Stack и для каких задач вы его используете. Для связи с нами можно использовать личные сообщения на Хабре или форму обратной связи на сайте.
Мы разработали обучающий курс по основам работы с Elastic Stack, который адаптируется под конкретные потребности заказчика. Подробная программа обучения по запросу.
Введение в 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 (см. чуть ниже).
