- PVSM.RU - https://www.pvsm.ru -
Перед каждым относительно крупным продакшном рано или поздно встает вопрос о централизованном сборе и просмотре логов. В настоящее время имеется огромный выбор опенсорсных, платных, online и on-premises решений. Я же постараюсь изложить процесс выбора в нашем конкретном случае.
Эта обзорная статья, суть которой рассказать об основных особенностях Graylog2, почему мы выбрали именно его и как эксплуатируем.
Немного про нашу инфраструктуру (чуть подробнее можно прочитать тут [1]): мы используем 7 дата-центров по всему миру, порядка 500 production-серверов и ещё пара сотен разного рода приложений, с которых хотелось бы собирать логи. Всё это под управлением как Linux, так и Windows, а поверх крутятся разнородные сервисы. У всех сервисов свой формат логов, при этом есть еще и Java, у которой своеобразный StackTrace.
Со стороны программистов и всех заинтересованных требования к логам были простыми:
Тут в целом ничего сложного, всё вполне обычно. Но в нашем случае нужно было еще удовлетворить следующие требования обслуживания сервиса:
Этот набор требований был довольно критичным для того, чтобы новый сервис мог полностью вписаться в существующую инфраструктуру с учетом особенностей наших автоматизаций, раздачи прав и не оказался белой вороной, на которую пришлось бы тратить слишком много времени. Сервис должен быть удобен и для конечных пользователей и удовлетворять их требованиям.
На этом этапе мы поняли, что у нас остались только некоторые коммерческие решения и Graylog2 из opensource.
Если коротко, то никак. Поэтому тут я укажу на основные подходы и нюансы, которые помогли нам в этом деле.
В начале мы взяли и посмотрели количество логов на фокус-группе серверов, замерили динамику изменений за 2 недели. Получившееся число мы умножили на количество серверов. В итоге, среднее количество логов было около 1Тб в день. Хранить эти логи нужно было от 2-х недель до 3-х месяцев.
На этом этапе при подсчете коммерческих решений и собственной инфраструктуры было принято решение использовать Graylog2. Решив, что лучший способ посчитать реальную нагрузку, это завести часть прод трафика на тестовый сервер, мы развернули одну ноду Graylog2 и направили туда трафик с определённой фокус-группы.
Около недели мы видели нагрузку в 10-20к сообщений в секунду и в целом были уже готовы закладываться на эти цифры при развертке боевого кластера. Но в какой-то момент на серверах что-то сломалось, количество логов выросло почти в 10 раз и на одном сервере мы увидели всплеск до 100к сообщений в секунду. При этом ещё и часть StackTrace из Java-приложений не влезло в разрешенный размер лога. В этот момент к нам пришло понимание, что логи нужны как раз для удобной работы в таких критических ситуациях, а все предыдущие подсчеты велись исключительно в нормальных условиях.
Основные выводы:
Основные причины, по которым мы выбрали именно его:
Этот функционал покрыл практически все наши потребности и очень сильно упростил жизнь. Буквально за пару месяцев из тестового сервиса с сомнительным будущим он превратился в довольно важный business-critical юнит и уже полгода замечательно справляется со своими задачами.
Конечно, внедрение подобных решений не самый прозрачный процесс. Мы столкнулись с довольно большим количество нюансов и подводных камней как при первоначальной настройке, так и при дальнейшей эксплуатации. В следующей статье я расскажу, как именно мы настраивали и тюнили Graylog2 и его компоненты такие как MongoDB и Elasticsearch.
Автор: Владимир
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/265786
Ссылки в тексте:
[1] тут: https://habrahabr.ru/company/pixonic/blog/325040/
[2] FreeIPA: https://habrahabr.ru/company/pixonic/blog/325546/
[3] Источник: https://habrahabr.ru/post/340168/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.