На рынке представлено огромное количество систем логирования — как открытых, так и проприетарных. У каждой из них своя функциональность, свои достоинства и недостатки.
Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.
/ Pixabay / picupyourphoto / PD
Минутка теории
При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».
Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.
Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов.
Простота использования и размеры сообщества
Простота — один из ключевых компонентов при выборе системы логирования. С лог-фреймворками работают все разработчики в команде, потому опыт использования этого инструмента должен быть положительным и не превращать анализ логов в кошмар. API фреймворка должен быть интуитивно понятным, чтобы все, кто раньше не работал с системой, могли быстро разобраться, как она устроена и настроена.
Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких). Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей.
Что касается выбора проприетарных систем логирования, то здесь в первую очередь стоит смотреть на скорость ответов и адекватность службы поддержки выбираемого решения, а также его цену.
Возможность сбора «разнокалиберных» логов
Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.
Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).
Масштабируемость
Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.
Мы в 1cloud изначально использовали для логирования MS SQL. Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. А одной из главных наших задач было сохранение возможности анализа логов из единого места.
Система логирования 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).
У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. В сети есть примеры по конфигурации всей системы и API. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.
Fluentd
6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.
Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby). Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности.
Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Также не рекомендуется устанавливать его на серверы, генерирующие логи.
Сообщество большое: имеется канал в Slack, а также тред в Google Groups. На официальном сайте проекта есть примеры конфигураций и API. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.
Graylog
4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.
Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только с Elasticsearch версии 2.4.4, которая считалась устаревшей.
В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.
LOGalyze
Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.
Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google. Есть руководство по настройке системы и миграции данных, а также CLI.
Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.
Мы выбрали ELK, так как все три компонента разрабатывает один «производитель», потому они хорошо интегрируются друг с другом. При необходимости мы сможем использовать каждый из этих инструментов в отдельности для решения других задач.
Такой подход делает продукт гибким и универсальным. Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать.
Сейчас готова тестовая среда. Она «покрывает» все сервисы, логи которых мы будем анализировать. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.
Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.
После запуска мы займемся настройкой систем мониторинга, чтобы максимально оперативно реагировать на сбои в работе лог-сервиса. Мы рассчитываем, что новый стек технологий позволит улучшить пользовательский опыт наших клиентов и в дальнейшем быстрее развивать наши сервисы.
Материалы из нашего корпоративного блога:
- Тренировочный стенд для админов: как не наломать дров на «боевой» инфраструктуре
- Фотоотчет — обзор наших новинок: Cisco UCS B480 M5
- Как обеспечивается безопасность данных в облаке
- Чем арендованная инфраструктура лучше обычного «железа»
Автор: 1cloud
