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