Как искать логи в kibana

Сервер логов Elasticsearch + Logstash + Kibana4 + Beats(windows/linux). Установка и настройка

Встал вопрос централизованного хранения и обработки журналов с серверов на базе Linux и Windows. Мой выбор пал на продукты от Elastic.
Большинство прочитанных статей на тему установки приложений Elastic показались мне достаточно расплывчатыми и неполными.

Основной и единственный источник информации, который я использовал: www.elastic.co/guide/index.html.

Этот мануал конечно не является исчерпывающим, но является достаточным для первоначальной установки и настройки рабочего лог-сервера elasticsearch+logtash+kibana4+beats (windows\linux-агенты).

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

Будем собирать и склеивать

Подготовка

Редактируем hosts и hostname:

Устанавливаем Java 8:

Создаём каталоги, которые нам понадобятся для фасовки пакетов:

Идём на сайт www.elastic.co/downloads/elasticsearch и скачиваем актуальную (2.2.0) версию:

Редактируем конфиг /etc/elasticsearch/elasticsearch.yml:

Раскомментируем и отредактируем стоки cluster.name и node.name:

(вместо «elk-server.ss.lu» и «mynodename» можете вставьте свои значения)
Должно получится так:

cluster.name: elk-server.ss.lu
node.name: mynodename

Добавляем в автозагрузку:

Скачиваем актуальную (2.2.0) версию Logstash www.elastic.co/downloads/logstash и устанавливаем:

Создаём INPUT-файл для «битсов»…

… и копируем туда код:

Это будет означать что logstash начнёт слушать порт 5044. Данный порт является по умолчанию для этой версии и будет прописан по умолчанию в битсах. Можете задать любой другой.

… и копируем туда код для связи с elasticsearch:

Проверяем конфиг на ошибки, запускаем, и вносим в автозапуск:

Пример успешной работы:

Скачиваем и устанавливаем публичный ключ:

Обновляем репозиторий и устанавливаем:

Нас просят создать первый индекс, но мы пока оставляем всё как есть и переходим к настройке клиентов.

Ставим на клиенты. Для начала, на сервер скачаем и поставим несколько готовых дашбордов Kibana с индексами Beats:

И видим что были добавлены дашборды Kibana с индексами Beats:

Получение данных об инфраструктуре сервера.
Передаёт информацию о работе процессора, использованию памяти. Для каждого процесса отображается информации о родители, pid, состояние и т.д. Также Topbeat позволяет просматривать информацию о файловой системе — состояние дисков, объём свободного пространства и т.д.

Установка (на клиенте):

На сервер нужно добавить шаблоны индексов Topbeat чтобы Elasticsearch стал правильно анализировать информацию на входе:

При успешной загрузки мы должны увидеть:

Редактируем конфиг (на клиенте):

В блоке output нужно за комментировать обращение к elasticsearch, т.к мы будем использоватеть logstash:

Раскомментируем блок с Logstash, укажем его IP-адресс и порт:

Важно: не используйте табуляцию для передвижения курсора в конфиге! Только пробелы. Иначе получите ошибку:

Если сервер Logstash находится во внешней сети, то на фаерволле удалённого сервера нужно настроить форвардиг порта, в данном случаем 5044 (tcp/udp).
Дополнительные опции логирования хорошо описаны в конфигах.

Открываем интерфейс Kibana и наблюдаем поступающую информацию:

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

Добавим индексы на сервере (по аналогии с как мы настраивали Topbeat. Т.е. если на сервере шаблон отсутствует — мы его создаём):

Указываем то, что нужно нам на данном клиенте, например:

Помните про отсутствие табуляции в коде!

Мы также будем использовать logstash для обработки индексов:

Смотрим информацию от Filebeat:

Очень полезный инструмент. Анализирует трафик между серверами. Моментально выявляет ошибки. Анализирует протоколы DNS, HTTP, MySQL, PostgreSQL, КЗС, Memcache и другие.

Настраивается по той же аналогии что и Topbeat/Filebeat:

Редактируем кофиг (комментируем Elasticsearch и настраиваем Logstash)
output:

Идём на сервер и добавляем индекс для Packetbeat:

Скачиваем www.elastic.co/downloads/beats/winlogbeat. Распаковываем в C:\ и переименовываем в Winlogbeat. Запускаем PowerShell от админа и устанавливаем сервис:

Если мы видим сообщение о том что скрипты отключены в системе по умолчанию (а так оно и будет), то мы просто создаём политику для Winlogbeat:

Перед стартом сервиса правим в конфиге — C:\Winlogbeat\winlogbeat.yml.

В блоку event_logs перечислены основные журналы системы, которые нужно транспортировать на Logstash:

В event_logs можно добавить и другие журналы, список которых можно посмотреть так:

Если система выше Vista, то можно указать каналы:

Далее нам нужно загрузить на сервер индексы для winlogbeat как мы это делали для topbeat, filebeat, packetbeat. Это можно сделать удалённо:

Есть есть проблемы такого метода, то можно сделать следующее:

Создаём на сервере файл индекса winlogbeat.template.json
sudo vi

/ELK/releases/beats/winlogbeat/winlogbeat.template.json. На клиенте Windows открываем файл C:\winlogbeat\winlogbeat.template.json и копируем его содержимое в файл

Далее (на сервере) загружаем этот индекс на elasticsearch, для того чтобы он смог верно проанализировать информацию и предоставить её привычном формате:
Переходим в каталог где у нас лежит созданный файл winlogbeat.template.json.

На выходе должно быть:

<"acknowledged":true>

Идём на клиент и запускаем сервис winlogbeat. После это начинаем мониторить данные через Kibana, определяя представление по загруженным индексам:

Удаление всех индексов:

Вместо * можно указать неугодный индекс, например:

Для удаление старых логов не обходимо установить «питоновский» модуль:

Если pip не установлен, то устанавливаем:

Посмотерть статус работы Elasticsearch:

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

Дополнительные настройки (оптимизация, настройки geoip и т.д.) описаны в официальной документации и конфигах.

Источник

Русские Блоги

Кибана: как использовать панель поиска

Как искать

В панели поиска Kibana есть три способа поиска:

Когда мы выключаем переключатель KQL, он становится следующим:

Ниже мы опишем, как использовать их для нашего поиска отдельно.

Что такое шаблон индекса?

Шаблон индекса: он указывает на один или несколько индексов Elasticsearch и сообщает Kibana, с какими индексами работать.

тип данных

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

Когда мы создаем наш собственный шаблон индекса, нам нужно выбрать наш тип данных:

Выше мы должны ввести соответствующий шаблон индекса в соответствии с именем нашего собственного индекса. Он может указывать на один индекс или на несколько индексов через символы подстановки. Если ваш индекс содержит поля, относящиеся ко времени, Kibana автоматически отобразит опцию, позволяющую нам выбрать, нужен ли Time Filter:

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

Если мы хотим удалить шаблон индекса, мы также можем выбрать удаление на странице выше:

Подготовить данные

Мы можем использовать данные, поставляемые с Kibana, для демонстрации. Мы загружаем данные следующим образом:

Выбрать»Add sample data”:

Мы выбираем»Add datamsgstr «, чтобы мы могли загрузить нужные нам образцы данных в Elasticsearch.

Прежде чем искать, мы должны понять две важные вещи:

Кибана поиск

Давайте сначала посмотрим на документ, проиндексированный нашими kibana_sample_data_flights.

Как я упоминал выше, мы сначала выбираем наш индекс, а затем устанавливаем время, соответствующее нашему методу времени.

KQL способ поиска:

Выше мы видим, что когда мы используем KQL, большое преимущество заключается в том, что он может помочь нам автоматически запрашивать поля, которые мы хотим найти. Например, когда мы наступим на следующий день, Kibana автоматически откроет варианты, чтобы мы могли выбрать.

Мы даже можем напечатать нужную строку, например Baidu, без использования специального поля:

Мы также можем использовать шаблоны для выполнения нечетких поисков:

Кавычки вокруг поискового запроса инициируют поиск по фразе. Например, сообщение «Быстрый коричневый лис» будет искать фразу «быстрый коричневый лис» в поле сообщения. Без кавычек ваш запрос будет разбит на токены анализатором, настроенным в поле сообщения, и будет сопоставлять документы, содержащие эти токены, независимо от порядка их появления. Это означает, что документы с «быстрой коричневой лисой» будут совпадать, но «быстрая коричневая лиса» также будет совпадать. Если вы хотите найти фразу, не забудьте использовать кавычки. При поиске фразы порядок каждого токена очень важен.

Анализатор запросов больше не будет разбиваться на пустое пространство. Несколько поисковых терминов должны быть разделены явными логическими операторами. Lucene объединяет условия поиска с или по умолчанию. Эти логические операторы являются или, и не и.

Вышеуказанный поиск вернет все документы, для которых dayofWeek равен 1 или OriginCountry имеет значение «DE». Если мы хотим искать документы, которые удовлетворяют обоим этим условиям, мы можем использовать и

Очевидно, в это время мы видели только 23 документа, намного меньше, чем раньше. Мы также можем использовать, чтобы не возвращать неоперации. Например, если мы хотим получить все документы, где OriginCountry не является DE, мы можем напрямую искать не OriginCountry: «DE»

Мы также можем искать поле по диапазону, например:

Поиск Lucene:

Чтобы иметь возможность искать в режиме Lucene, мы должны переключиться в режим Lucence. Таким образом, когда мы вводим поле в поле ввода без запроса, мы не можем помочь нам завершить ввод автоматически.

Мы можем искать ряд документов:

Выше, если мы не хотим включать 3, мы должны написать: dayOfWeek: [0 TO 3>. Вы также можете написать любое значение от 3 и выше:

Мы также можем выполнить поиск всех документов, для которых OriginCountry является США или DE, в соответствии со следующим методом.

Или нечеткий запрос:

Или только одна правкаНечеткий запрос：

Вы также можете использовать подстановочные знаки? Чтобы соответствовать любому письму (обратите внимание, что это не доступно в KQL):

Точно так же мы можем использовать обычный запрос, чтобы иметь 0 или 1 букву:

Вы также можете использовать. * Обычный, чтобы соответствовать 0 или более букв:

Источник

Просмотр архивных логов apache c помощью Logstash+Elastisearch+Kibanа

Нет так давно передо мной встала задача пробежаться по старым логам apache. Надо было сделать выборку по нескольким IP адресам, отыскать некоторые аномалии и попытки SQL-injection’ов. Логов было не так много, порядка миллиона строк и можно было спокойно всё сделать стандартным набором grap-awk-uniq-wc итд.

Поскольку я уже какое-то (больше года) время пользуюсь связкой Logstash-Elasticsearch-Kibana для анализа-просмотра всевозможных логов, то решил ей воспользоваться и в данной ситуации.

Краткое описание основных компонентов системы.

Logstash — бесплатная open-source программа на java для сбора и нормализации логов. Может принимать логи либо с локальных файлов, либо через tcp/udp порты. На момент написания статьи, разных входных (input) фильтров насчитывается 26. Есть даже входной модуль, для сбора сообщений из twitter’а или irc.

Elasticsearch — бесплатный open-source поисковый сервер основанный на Apache Lucene. Быстрый, легко настраиваемый и очень масштабируемый.

Kibana — веб-интерфейс написанный на ruby, для отображения данных из Elasticsearch. Простая настройка, но множество функций — поиск, графики, stream.

1. Elasticsearch

1.1 Скачиваем Elasticsearch (размер 16MB):
Важно заметить, что для Logstash версии 1.1.9 Elasticsearch должен быть именно версии 0.20.2.
# wget download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.20.2.tar.gz

1.3 По большому счёту можно запускать Elasticsearch и с заводскими настройками. Но я всё же меняю некоторые параметры.
Заходим любимым текстовым редакторов в файл настроек:
# vi elasticsearch-0.20.2/config/elasticsearch.yml

Список моих изменений для standalone решения:Перед запуском Elasticsearch убедитесь, что каталоги прописанные в path.data, path.work и path.logs существуют.

Если на вашем сервере появились два tcp порта 9200 и 9300 в режиме LISTEN, то это значит Elasticsearch готов к работе.

2. Logstash

2.1 Скачиваем свежую версию Logstash 1.1.9 (размер 60MB)
# wget logstash.objects.dreamhost.com/release/logstash-1.1.9-flatjar.jar

2.2 Создаём конфигурационный файл (apache.conf) для принятия архивных логов apache, их нормализации и занесением в базу Elasticsearch:

Краткое описание некоторых параметров:
В нашем случае Logstash будет слушать на tcp порту 3338. На него мы будем посылать netcat’м логи apache.

указываем название кластера, которое мы прописали в cluster.name: в настройках Elasticsearch

ip адрес на котором бегает Elasticsearch

в моём случае суточных логов apache не так много около 40000, поэтому месячного индекса достаточно. Если же логов в сутки по 500000 или больше, тогда уместнее создать суточный индекс «apache-%<+YYYY.MM.dd>»

2.5 Пока идёт процесс закачивания логов, можно проверить попадают ли данные в базу Elasticsearch.
Для этого в браузере введите elasticsearch_ip:9200/_status?pretty=true, если вы найдёте там строки подобные этой:
значит всё работает как и требовалось.

3. Kibana

3.2 Конфигурация Kibana
# vi KibanaConfig.rb
Настройки, которые возможно потребуют изменений:

3.3 Запуск Kibana
# ruby kibana.rb

После успешного запуска, на экране делжен появиться подобный текст:

Источник

Система сбора, анализа, уведомлений и визуализации логов на syslog-ng, elasticsearch, kibana, grafana, elasticalert

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

Приступим или добро пожаловать под кат

Небольшое пояснение.
Только кластер elasticsearch можно использовать в production, система из одной ноды просто загнется. В production используем кластер из master ноды и нескольких датанод. Отказоустойчивый кластер здесь рассматривать не будем. Кому интересно — вперед гуглить. Elastic рекомендует использовать одинаковую конфигурацию для нод кластера, так как кластер все равно будет работать со скоростью самой медленной ноды. Я использую ноды по 4 cpu и 12 gb озу и 700 gb ssd.

Наша система логов будет состоять из нескольких виртуальных машин — головного сервера(elasticnode1) и датанод elasticsearch(elasticnode2-9), на которых будут только храниться данные.

Сразу поправим файл /etc/hosts, если у вас нет настроенного dns сервера.

Меняем планировщика — у нас же ssd

Компоненты головного сервера
(elasticnode1):

Компоненты отправителей логов:

На данный момент появилась версия 6 продуктов elasticsearch, kibana и т.д., я же в production использую 5.6.3 — пока не было возможности мигрировать на последнюю версию.

Настраиваем отправители логов.

Устанавливаем syslog-ng последней версии. Ставить будем из репозитория. Здесь установка для Ubuntu 16.04.

Источник

Kibana-мать или Зачем вам вообще нужны логи?

Вы можете сказать, что “иногда бывает нужно. ” Но на самом деле, вы хотите всегда видеть, что у вас в логах, через графический интерфейс. Это позволяет:

Такой use case обещает наполнить вашу жизнь совершенно новыми красками и заставит испытать полную гамму чувств.

Пролог:

«Пойми, на Хабрахабре только и разговоров, что о Kibana и Elasticsearch. О том, как это чертовски здорово — наблюдать, как огромный текстовый лог превращается в красивые графики, а еле видимая нагрузка на CPU горит где-то в глубине top-а. А ты. Что ты им скажешь?»

Матчасть

В жизни каждого нормального пацана возникает момент, когда он решил-таки поставить на своем проекте связку ELK.

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

Мы шлём в Kibana 2 вида логов:

Описываем пути к файлам и добавляем к сообщениям поля, которые нам понадобятся для определения типов логов на этапе фильтрации и при отправке в ES.

В зависимости от формата, прогоняем его через соответствующий кодек.

В случае с nginx, это будут вот такие “необычные” регулярки-полуфабрикаты, предлагаемые фильтрующим модулем “grok” (слева), и названия полей, в которые попадут заматченые данные (справа). Для пущей красоты у нас есть еще фильтр geoip, который определяет локацию клиента. В Кибане можно будет сделать “географию” клиентов. Базу качаем отсюда dev.maxmind.com/geoip/legacy/geolite.

А в случае с json, как видите, ничего делать вообще не надо, что не может не радовать.

Имя индекса и document_type для ES берем из полей, которые в самом начале пути приклеили к сообщениям в filebeat-е.

Связывание событий в логах фронта и бэка

Завязка:

“У нас было 2 типа логов, 5 сервисов в стэке, полтерабайта данных в ES, а также несчетное множество полей в логах приложений. Не то чтобы это был необходимый набор для риалтайм-анализа состояния сервиса, но когда начинаешь задумываться еще и о связывании событий nginx-а и приложения, становится сложно остановиться.

Единственное, что вызывало у меня опасения — Lua. Нет ничего более беспомощного, безответственного и порочного, чем Lua в конфигах Nginx. Я знал, что рано или поздно мы перейдем и на эту дрянь”.

Для генерации request-id на Nginx-е будем использовать Lua-библиотеку, которая генерирует uuid-ы. Она, в целом, справляется со своей задачей, но пришлось немного доработать ее напильником — ибо в первозданном виде она (та-дам!) дуплит uuid-ы.

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

Довольно быстро обнаружилось, что наши “вселенски-уникальные” айдишники не такие уж уникальные. Дело в том, что randomseed библиотека берет из таймстампа на момент запуска nginx-воркера. А воркеров у нас столько, сколько ядер у процессора, и запускаются они одновременно… Не беда! Подмешаем туда pid воркера и будет нам счастье:

P.S. В репозитарии Debian-а есть готовый пакет nginx-extras. Там сразу есть Lua и еще куча полезных модулей. Рекомендую, вместо того чтобы вкомпиливать модуль Lua руками (еще бывает openresty, но я не пробовал).

Группировка ошибок по частоте возникновения.

Kibana позволяет группировать (строить рейтинги) событий на основе одинаковых значений полей.

В логе ошибок у нас есть стэктрейсы, они почти идеально подходят в качестве ключа группировки, но загвоздка в том, что в Кибане нельзя группировать по ключам длиннее 256 символов, а стэки конечно длиннее. Поэтому мы делаем md5-хэши стэктрейсов в bunyan и группируем уже по ним. Красота!

Так выглядит топ 20 ошибок:

И отдельно взятый тип ошибки на графике и списком эпизодов:

Теперь мы знаем, какой баг в системе можно пофиксить когда-нибудь потом, т.к. он слишком редкий. Согласитесь, такой подход куда научнее, чем “за эту неделю было много подобных тикетов в саппорт”.

А теперь — срыв покровов: оно работает, но плохо

Кульминация:

«Я понимаю. Ты нашёл в NoSQL рай: у тебя быстро шла разработка, ведь ты хранил все в MongoDB, и тебе не нужны были такие друзья, как я. А теперь, ты приходишь и говоришь: мне нужен поиск. Но ты не просишь с уважением, ты даже не называешь меня Лучшим Поисковым Движком. Нет, ты приходишь ко мне в дом в день рождения Lucene и просишь меня индексировать неструктурированные логи бесплатно»

Неожиданности

Все ли сообщения из лога попадают в Кибану?

Нет. Не все попадают.

Маппинг запоминает название поля и его тип (число, строка, массив, объект и т.д.). Если мы посылаем в ES сообщение, в котором есть поле, уже существующее в маппинге, но тип не совпадает с тем, что было в этом поле раньше (например, в маппинге — массив, а пришел объект), то такое сообщение не попадет в ES, а в его логе будет не слишком очевидное сообщение:

Имена полей в json-логах

Elasticsearch v2.x не принимает сообщения, в которых есть поля, имена которых содержат точки. В v1.x этого ограничения не было, и мы не можем перейти на новую версию, не переделав все логи, т.к. у нас такие поля уже “исторически сложились”.
Источник

Кроме того, в Kibana не поддерживаются поля имена которых начинаются с подчеркивания ‘_’.

Автоматическое уползание данных в соседние инстансы ES

По-умолчанию в ES включена опция Zen Discovery. Благодаря ей, если вы запустите несколько инстансов ES в одной сети (например, несколько докер-контейнеров на одном хосте), то они друг друга найдут и поделят данные между собой. Очень удобный способ смешать продуктивные и тестовые данные и долго с этим разбираться.

Оно падает и потом долго поднимается. Это еще больнее, когда docker

Реже, но тоже бывает, что падает Elasticsearch. Делает он это “по-английски” (т.е. молча).

Чтобы понять, кто из них двоих упал, делаем http-запрос в ES — если ответил, значит лежит не он. Кроме того, когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные, и в это время они будут недоступны. Данные самой Kibana хранятся там же, поэтому она тоже не работает, пока ее индекс не подхватится. По закону подлости, до нее обычно очередь доходит в самом конце.

Приходится мониторить мониторингом длину очереди в rabbitmq, чтобы оперативно реагировать на инциденты. Раз в неделю они стабильно случаются.

А когда у вас всё в docker-е, и контейнеры слинкованы между собой, то вам нужно перезапустить еще и все контейнеры которые были слинкованы с контейнером ES, кроме него самого.

Большие дампы памяти при OOM

30GB. Сбрасываются они, разумеется, в директорию, где лежат бинарники (а не туда, где данные). Происходит это быстро, мониторинг даже не успевает прислать смс-ку. Отключить это поведение можно в bin/elasticsearch.in.sh.

Производительность

В Elasticsearch существует т.н. “маппинг” индексов. По-сути, это схема таблицы, в которой хранятся данные в формате “поле — тип”. Создается она автоматически на основе поступающих данных. Это значит, что ES запомнит имя и тип данных поля, исходя из того, данные какого типа пришли в этом поле в первый раз.

Например, у нас есть 2 очень разных лога: access-log nginx и production-log nodejs-приложения. В одном стандартный набор полей, он короткий, типы данных никогда не меняются. В другом же, напротив, полей много, они nested, они свои у каждой строчки лога, названия могут пересекаться, данные внутри полей могут быть разных типов, длина строки доходит до 3 и более Mб. В итоге автомаппинг ES делает так:

В общем, оно сильно тормозит как при индексации данных, так и при поиске через Kibana. При этом, чем больше накопилось данных, тем хуже.

Мы пытались бороться с этим закрытием старых индексов c помощью curator. Положительный эффект безусловно есть, но все-таки это анестезия, а не лечение.

Поэтому мы придумали более радикальное решение. Весь тяжелый nested-json в production-логе отныне будет логироваться в виде строки в специально-отведенном одном поле сообщения. Т.е. вот прямо JSON.stringify(). За счет этого набор полей в сообщениях становится фиксированным и коротким, мы приходим к “легкому” маппингу как у nginx-лога.

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

Промежуточный итог

Стэк ELK — классный инструмент. Для нас он стал просто незаменимым. Менеджеры следят за всплесками ошибок на фронтэнде после очередного релиза и приходят жаловаться к разработчикам уже “не с пустыми руками”. Те, в свою очередь, находят корреляции с ошибками в приложении, сразу видят их стэки и прочие важнейшие данные, необходимые для дебага. Есть возможность моментально строить различные отчеты из серии “хиты по доменам сайтов” и т.п. Словом, непонятно как мы жили раньше. Но с другой стороны…

“Robust, Reliable, Predictable” — все это не про ELK. Cистема очень капризная и богатая на неприятные сюрпризы. Очень уж часто приходится копаться во всем этом шатком, извините, Jav-не. Лично я не могу припомнить технологию, которая бы так плохо следовала принципу “настроил и забыл”.

Поэтому за последние 2 месяца мы полностью переделали логи приложения. Как в плане формата (избавляемся от точек в именах, чтобы перейти на ES v.2), так и в плане подхода к тому, что вообще логировать а что нет. Сам по себе этот процесс, имхо, абсолютно нормальный и логичный для такого проекта, как наш — недавно uKit отпраздновал свой первый день рождения.

«В начале пути вы сваливаете в логи как можно больше инфы, т.к. заранее неизвестно, что понадобится, а потом, начав „взрослеть“, постепенно убираете лишнее». (c. pavel_kudinov)

Источник