Главная » Хабрахабр » На что обратить внимание при выборе системы логирования, и почему мы остановились на 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 Интересное!

В Германии разработали требования к домашним маршрутизаторам

Продолжительное время в Интернете регулярно появляются статьи об уязвимости маршрутизаторов для SOHO сегмента. Я тоже публиковал статью как обнаружить, что Ваш Микротик взломан. Резкий рост участников нашего канала в Телеграм (@router_os) показал, что проблема крайне остра. Но проблема стоит глобальней. ...

[Перевод] Архитектуры нейросетей

Перевод Neural Network Architectures Давайте рассмотрим историю их развития за последние несколько лет. Алгоритмы глубоких нейросетей сегодня обрели большую популярность, которая во многом обеспечивается продуманностью архитектур. Если вас интересует более глубокий анализ, обратитесь к этой работе. Подробнее здесь. Сравнение популярных ...