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

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

    Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 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 ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.

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

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

    1cloud.ru

    142,20

    IaaS, VPS, VDS, Частное и публичное облако, SSL

    Поделиться публикацией
    Комментарии 10
      +1
      Хотелось бы увидеть (возможно в следующих статьях) сравнение стоимости хранения логов в ES по сравнению с другими БД. Мне соотношение стоимости/сервиса у него кажется далеким от оптимального — тем более что Кибаны нам не хватило как в смысле UI, так и в смысле логики запросов.
        0
        Интересно было бы узнать, для чего вам не хватило кибаны?
          0
          Не хватило видов графиков и не понравился способ их композиции на одном экране.
        0
        Какой у вас объем логов? Я пробовал использовать ELK на версиях 2.x для логирования 7tb в сутки и столкнулся с проблемами масштабирования кластера. В результате пришлось отказаться от ELK.
          +1
          Собираем логи с 10000 коммутаторов. ElasticSearch падает раз в 2 недели примерно. Еще бы GUI для настройки logstash, разобраться с elasticsearch, научиться делать оптимальные индексы через kibana или напрямую и было бы классно
            0
            А можете рассказать о структуре ES? Строили для заказчика ещё на 2.4 версии хранилище для логов и у них, насколько мне известно, всё ещё успешно используется. Сталкивался с проблемой, что нужно отделять HTTP и Мастер/Дата-ноду, в противном случае под нагрузкой ES стабильно падал. Достаточно было просто два сервиса на разных портах поднять и проблема уходила.
            +1

            … Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд...


            И ни слова про легковесный filebeat, который написан на go и для которого не надо тащить jvm на каждую машину

              +1
              На мой взгляд плодить демоны не нужно, потому что Logstash умеет RELP, при помощи которого штатный rsyslog может отсылать логи с гарантированной доставкой на кластер logstash. Но про это в статье тоже ничего не сказано.
              0
              Движок не так важен как системная работа с логами начиная от написания приложения… Например — достаточно прокинуть идентификатор запроса/события по всем микросервисам и анализ сразу становится на порядок проще… Далее — нужно выделить из текста логов типизированные события и сразу можно искать по номеру договора/порту/товару, что опять же дико упрощает поддержку… Но для всего этого нужно вести локальные контексты логгирования и лепить их к каждому сообщению. Это приводит к тому, что сервера логгирования становятся такими же толстыми как и сами сервера приложений. Но для не шибко крупных компаний (где нет серверных кластеров из десятков/сотен машин) это всё-ещё приемлемо, т.к. позволяет расти и держать продакшн под контролем.
                0
                Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.

                Для безопасности в ELK есть штатный пакет X-Pack

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое