Главная » Хабрахабр » На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK

На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK

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

Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.


/ Pixabay / picupyourphoto / PD

Минутка теории

При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».

Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.

Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса.

Простота использования и размеры сообщества

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

Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких).

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

Возможность сбора «разнокалиберных» логов

Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.

Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).

Масштабируемость

Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.

Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. Мы в 1cloud изначально использовали для логирования MS SQL. А одной из главных наших задач было сохранение возможности анализа логов из единого места.

Система логирования 1cloud

Как мы уже отметили, для хранения логов в 1cloud раньше использовался MS SQL, а для их записи — log4net. И это начало создавать для нас определенные трудности. Из-за территориально разнесенных компонентов, стало невозможно держать сетевую связанность с БД и обеспечивать единую точку для анализа.

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

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

  • единое место хранения логов;
  • горизонтальное масштабирование системы при необходимости;
  • обработка больших объемов данных;
  • мощная система анализа логов.

Этими четырьмя решениями стали: Fluentd, Graylog, Logalyse и Logstash.

Logstash

Решение имеет 9,2 тыс. звезд на GitHub. Logstash распространяется по лицензии Apache 2.0 и является частью стека ELK. Имеет большое количество плагинов (на GitHub их насчитывается порядка 250 штук). Работает под Windows и Linux и имеет высокую производительность, практически не зависящую от объемов данных.

Это связано с тем, что нет необходимости в «нормализации» событий. Система дает быстро проводить обзор и анализ событий с рабочих станций, файрволов, маршрутизаторов и коммутаторов.

Из других недостатков отметим необходимость ставить Java на все серверы, так как Logstash написан на Ruby (JRuby). Однако стоит понимать, что это «голый» движок, потому он не предоставляет готовых визуализаций.

В сети есть примеры по конфигурации всей системы и API. У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.

Fluentd

6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.

Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности. Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby).

Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Также не рекомендуется устанавливать его на серверы, генерирующие логи.

На официальном сайте проекта есть примеры конфигураций и API. Сообщество большое: имеется канал в Slack, а также тред в Google Groups. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.

Graylog

4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.

Например, в прошлом году возникла ситуация, когда Graylog 2. Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. 1 (на то время последний) работал только с Elasticsearch версии 2. 2. 4, которая считалась устаревшей. 4.

В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.

LOGalyze

Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.

Есть руководство по настройке системы и миграции данных, а также CLI. Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google.

Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.

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

Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать. Такой подход делает продукт гибким и универсальным.

Она «покрывает» все сервисы, логи которых мы будем анализировать. Сейчас готова тестовая среда. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.

При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью.

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

Материалы из нашего корпоративного блога:


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Китайская панель биомаркеров старения

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

Как работает stack trace на ARM

Добрый день! Несколько дней назад столкнулся с небольшой проблемой в нашем проекте — в обработчике прерывания gdb неправильно выводил stack trace для Cortex-M. Поэтому в очередной раз полез выяснять, а какими способами можно получать stack trace для ARM? Какие флаги ...