elk Миграция логов в ElasticSearch и Kibana в контексте микро-сервисной архитектуры и контейнеризации имеет некоторые нюансы. В большинстве случаев, разработчики привыкли работать и дебажить приложения такими инструментами как ssh && tail -f, но не всегда получается сохранить возможность просматривать логи напрямую в файлах. Возможно ли воспроизвести этот workflow с учетом особенностей нового стека технологий?

Как это было раньше?

Рассмотрим несколько популярных вариантов, как организовывалось логирование до того, как появились такие инструменты как ELK-стек, Graylog, Splunk и другие подобные сервисы.

В подавляющем большинстве случаев в небольших организациях, на небольших проектах логи пишутся прямо на файловую систему сервисами и Вашими приложениями. Если есть необходимость получить доступ к этой информации нам нужно попасть на сервер(ssh в большинстве случаев), найти нужный файл и используя удобный инструмент, к примеру: less,grep,tail,... изучить доступную информацию.

Из необходимых навыков - основы владения командной строкой, из удобств - проста и очевидность подхода и мгновенный отклик. Используя tail -f /opt/my_app/logs/app.log в режиме реального времени видно, что происходит с приложением - любимейшая фича разработчиков и системных администраторов.

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

В проектах побольше использовалось централизованное хранение логов, организованное с помощью, к примеру rsyslogd, хранящееся где-то на выделенном сервере, доступ к которому в большинстве случаев был только у системных администраторов, а логи изучались только в случае проблем на продакшене. Сообразительные администраторы настраивали простенький веб-сервер с доступом к этим данным заботливо вручая его программистам, чтобы те не отвлекали от более приоритетных задач.

Еще слышал, как ребята хранили логи в базах данных, по-моему, это был PostrgreSQL. О причинах возникновения такой архитектуры могу только догадываться… Из предположений - может быть у команды или проекта было очень хорошо с реляционной алгеброй и вместо всем привычным grep, awk, sed ребятам было проще искать необходимую информацию с помощью SQL-запросов…

Как это выглядит на данный момент?

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

Как же тут нам помогает ELK и ему подобные сервисы? Ответ просто, он предоставляет централизованное хранение необходимой информации с единым интерфейсом доступа к ней. Если рассматривать ElasticSearch + Kibana, то мы имеем:

  • ElasticSearch - для хранения и индексации данных
  • Logstash/Filebeats - агенты, доставляющие данные в ElasticSearch
  • Kibana - доступ и выборка необходимых данных посредством Kibana Query Language

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

Как этим пользоваться?

Хороший вопрос, который безпокоит большинство команд, которые впервые сталкиваются с этими технологиями.

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

  • Структуре данных
  • Kibana Query Language

И первоначально это стоит больших усилий и времени, чем ssh && tail -f, но в долгосрочной перспективе это окупается. Открыть 2 вкладки браузера и загрузить уже созданный Вами или другими участниками команды запрос гораздо быстрее, чем логиниться на кучу серверов искать нужные лог-файлы и запускать tail -f.

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

https://kibana.at.your.domain/kibana/app/kibana#/discover/name-of-your-search?_g=(refreshInterval:('$$hashKey':'object:1005',display:'5%20seconds',pause:!f,section:1,value:5000),time:(from:now-1h,mode:quick,to:now))&_a=(columns:!(column1,column2,column3),filters:!(),index:'your-log-index-*',interval:auto,query:(query_string:(analyze_wildcard:!t,query:'filed_name:%20%22your-micro-service%22')),sort:!('@timestamp',desc))

Если быть конкретней, то в данном случае 5 сек = 5000 мили-секунд, значение - value: refreshInterval:('$$hashKey':'object:1005',display:'5%20seconds',pause:!f,section:1,value:5000 В данном случае, нагрузка увеличится не только на серверную инфраструктуру, а и на локальный компьютер, так как Kibana это по большей части клиентское приложение, написанное на JavaScript и использующие ресурсы Браузера.

Послесловие

В большинстве случаев, при грамотном маппинге данных к полям, ELK-стек становится мощным инструментом для выборки нужных данных, который в том числе с легкостью компенсирует любимый tail -f в окне Вашего браузера. Безусловно эти технологии требуют инвестиций с точки зрения времени и усилий на их осваивание, но в будущем они могут помочь сэкономить значительную часть времени, тратящегося впустую.

Ссылки и термины