- PVSM.RU - https://www.pvsm.ru -

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

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

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

На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK - 1 [2]
/ Pixabay / picupyourphoto [3] / PD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Logstash [10]

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

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

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

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

Fluentd [19]

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

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

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

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

Graylog [28]

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

Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум [31], IRC-канал [32], на официальном сайте проекта есть примеры конфигураций [33] и API [34].), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только [35] с Elasticsearch версии 2.4.4, которая считалась устаревшей.

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

LOGalyze [37]

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

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


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

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

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

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

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

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

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

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

Автор: 1cloud

Источник [47]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/iaas/289706

Ссылки в тексте:

[1] 1cloud: https://1cloud.ru/?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=site

[2] Image: https://habr.com/company/1cloud/blog/420589/

[3] picupyourphoto: https://pixabay.com/en/forest-wood-nature-log-trees-2310309/

[4] там есть java.util.logging: https://dzone.com/articles/writing-your-own-logging

[5] Stack Overflow: https://stackoverflow.com/questions/tagged/logging

[6] например на Reddit: https://www.reddit.com/r/sysadmin/

[7] наподобие таких: https://github.com/ProjectMeniscus/meniscus/wiki/Logging-System-Comparison

[8] мы разместили оборудование в минском ЦОД: https://1cloud.ru/news/novyj-data-centr-v-minske?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=site

[9] добавили поддержку IPv6: https://habr.com/company/1cloud/blog/419405/

[10] Logstash: https://www.elastic.co/products/logstash

[11] GitHub: https://github.com/elastic/logstash/pulse

[12] насчитывается порядка 250 штук: https://github.com/logstash-plugins

[13] дает: https://www.itweek.ru/upload/iblock/140/140e2b01639d62a2ad00a8c206f44a6c.pdf

[14] IRC-канал: https://webchat.freenode.net/#logstash

[15] форум: https://discuss.elastic.co/

[16] конфигурации всей системы: https://www.elastic.co/guide/en/logstash/current/config-examples.html

[17] API: https://www.elastic.co/guide/en/logstash/current/monitoring.html

[18] Используют: https://www.quora.com/Who-uses-Logstash-for-their-logging-mechanism

[19] Fluentd: https://www.fluentd.org/

[20] GitHub: https://github.com/fluent/fluentd/pulse

[21] CNCF: https://github.com/cncf

[22] основан: https://ru.wikipedia.org/wiki/The_Linux_Foundation#Cloud_Native_Computing_Foundation

[23] гибкую систему плагинов: https://www.fluentd.org/plugins/all

[24] канал в Slack: https://fluent-all.slack.com/messages/C0CTT63EE/

[25] тред в Google Groups: https://groups.google.com/forum/#!forum/fluentd

[26] есть примеры конфигураций: https://docs.fluentd.org/v1.0/articles/config-file

[27] API: https://docs.fluentd.org/v1.0/articles/monitoring-rest-api

[28] Graylog: https://www.graylog.org/

[29] GitHub: https://github.com/Graylog2/graylog2-server

[30] экосистема плагинов: https://marketplace.graylog.org/addons?kind=plugin

[31] форум: https://community.graylog.org/

[32] IRC-канал: https://webchat.freenode.net/?channels=%2523graylog

[33] есть примеры конфигураций: http://docs.graylog.org/en/2.4/pages/installation/manual_setup.html

[34] API: http://docs.graylog.org/en/2.4/pages/configuration/rest_api.html

[35] работал только: http://proceedings.spiiras.nw.ru/ojs/index.php/sp/article/download/3590/2090

[36] использует: https://stackshare.io/graylog/in-stacks

[37] LOGalyze: http://www.logalyze.com/

[38] ведут свой блог: http://www.logalyze.com/support/blogalyze

[39] группах Google: https://groups.google.com/forum/#!forum/logalyze-list

[40] по настройке: http://confluence.zuriel.hu/display/LOGDOCEN40/Engine+Configuration

[41] миграции: http://www.logalyze.com/product/feature-details/collectors/database-connectivity

[42] CLI: https://sourceforge.net/projects/logalyze-cli/

[43] Тренировочный стенд для админов: как не наломать дров на «боевой» инфраструктуре: https://1cloud.ru/blog/oblachnyj-server-dlja-praktiki-sysadmina?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=blog

[44] Фотоотчет — обзор наших новинок: Cisco UCS B480 M5: https://1cloud.ru/blog/novyj-server-cisco-ucs-b480-m5?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=blog

[45] Как обеспечивается безопасность данных в облаке: https://1cloud.ru/blog/bezopasnost-dannih-v-oblake?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=blog

[46] Чем арендованная инфраструктура лучше обычного «железа»: https://1cloud.ru/blog/virtualnyj-kompyuter-zapushchennyj-v-oblake-luchshe-schitat-zheleznym?utm_source=habrahabr&utm_medium=cpm&utm_campaign=sys_admin&utm_content=blog

[47] Источник: https://habr.com/post/420589/?utm_source=habrahabr&utm_medium=rss&utm_campaign=420589