Перед каждым относительно крупным продакшном рано или поздно встает вопрос о централизованном сборе и просмотре логов. В настоящее время имеется огромный выбор опенсорсных, платных, online и on-premises решений. Я же постараюсь изложить процесс выбора в нашем конкретном случае.

Эта обзорная статья, суть которой рассказать об основных особенностях Graylog2, почему мы выбрали именно его и как эксплуатируем.

Немного про нашу инфраструктуру (чуть подробнее можно прочитать тут): мы используем 7 дата-центров по всему миру, порядка 500 production-серверов и ещё пара сотен разного рода приложений, с которых хотелось бы собирать логи. Всё это под управлением как Linux, так и Windows, а поверх крутятся разнородные сервисы. У всех сервисов свой формат логов, при этом есть еще и Java, у которой своеобразный StackTrace.

Наши требования и что мы хотели получить в итоге

Со стороны программистов и всех заинтересованных требования к логам были простыми:

• агент отправки логов не должен сильно грузить систему;
• возможность добавления кастомных полей в произвольный момент времени, на произвольных серверах;
• поиск, сортировка и так далее;
• возможность отправлять логи POST запросами или чем-то похожим (для отправки логов, например, с мобильных устройств).

Тут в целом ничего сложного, всё вполне обычно. Но в нашем случае нужно было еще удовлетворить следующие требования обслуживания сервиса:

• аутентификация в openLDAP (в нашем случае это FreeIPA);
• удобное разграничение прав;
• удобное конфигурирование клиентов (желательно из одного места);
• возможность автоматизированной установки агентов на все используемые варианты систем;
• возможность удобного мониторинга как работоспособности сервисов, так и необходимых метрик;
• наличие community и документации, либо коммерческой поддержки;
• простое масштабирование.

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

На этом этапе мы поняли, что у нас остались только некоторые коммерческие решения и Graylog2 из opensource.

Как считать количество логов и нагрузку

Если коротко, то никак. Поэтому тут я укажу на основные подходы и нюансы, которые помогли нам в этом деле.

В начале мы взяли и посмотрели количество логов на фокус-группе серверов, замерили динамику изменений за 2 недели. Получившееся число мы умножили на количество серверов. В итоге, среднее количество логов было около 1Тб в день. Хранить эти логи нужно было от 2-х недель до 3-х месяцев.

На этом этапе при подсчете коммерческих решений и собственной инфраструктуры было принято решение использовать Graylog2. Решив, что лучший способ посчитать реальную нагрузку, это завести часть прод трафика на тестовый сервер, мы развернули одну ноду Graylog2 и направили туда трафик с определённой фокус-группы.

Около недели мы видели нагрузку в 10-20к сообщений в секунду и в целом были уже готовы закладываться на эти цифры при развертке боевого кластера. Но в какой-то момент на серверах что-то сломалось, количество логов выросло почти в 10 раз и на одном сервере мы увидели всплеск до 100к сообщений в секунду. При этом ещё и часть StackTrace из Java-приложений не влезло в разрешенный размер лога. В этот момент к нам пришло понимание, что логи нужны как раз для удобной работы в таких критических ситуациях, а все предыдущие подсчеты велись исключительно в нормальных условиях.

Основные выводы:

• подсчёт логов в нормальных условиях не дает картины происходящего в случае аварий. А сбор логов нужен именно для оперативного решения этих ситуаций;
• разные сервисы и языки пишут сообщения по-своему и учитывать такие ситуации надо заранее;
• производительность кластера должна позволять обрабатывать в разы больше сообщений от нормальной нагрузки.

Небольшое описание функционала Graylog2

Основные причины, по которым мы выбрали именно его:

• Хорошо зарекомендовавший себя ранее продукт. С хорошей документацией и освещенностью основных проблем.
• Возможность конфигурировать агентов через веб-интерфейс через Collectors.
• Простая и функциональная интеграция с OpenLDAP, в том числе синхронизация групп.
• Удобное горизонтальное масштабирование.
• Огромный выбор разных вариаций инпутов для получения логов.
• Наличие плагинов и расширений.
• Довольно простой и удобный язык запросов и построения выборок.
• Наличие дашбордов и возможности уведомлений.

Этот функционал покрыл практически все наши потребности и очень сильно упростил жизнь. Буквально за пару месяцев из тестового сервиса с сомнительным будущим он превратился в довольно важный business-critical юнит и уже полгода замечательно справляется со своими задачами.

Конечно, внедрение подобных решений не самый прозрачный процесс. Мы столкнулись с довольно большим количество нюансов и подводных камней как при первоначальной настройке, так и при дальнейшей эксплуатации. В следующей статье я расскажу, как именно мы настраивали и тюнили Graylog2 и его компоненты такие как MongoDB и Elasticsearch.