Юрий Бушмелев «Карта граблей на поле сбора и доставки логов» — расшифровка доклада

[khabib]

rsyslog отличная штука, только требует наличия root'a в контейнере или включенных capabilities

[gecube]

Я бы вообще по-другому делал.
Сейчас из существующих драйверов логирования для docker'а только два умеют писать на локальный хост. Это json-file и journald. Json-file — не наш выбор по разным причинам. Остается journald. Он умеет все то же самое, плюс ротация, плюс ретеншн. А еще он позволяет с одного места смотреть все логи через утилиту journalctl.
Остальные — syslog, gelf и пр. драйвера, к сожалению, не сохраняют на локальную машину с докером логи. И что хуже — если отвалится приемник логов, то никто об этом и не узнает.
Далее можно из локальной базы journald вытянуть логи journalbeat'ом или fluent-bit'ом и передать куда-то дальше. Куда — зависит от Вашей фантазии.
Ну, и в кейса автора доклада — я бы рассмотрел возможность развертывания в каждом ДЦ своего инстанса Kafka, а реализовать переброс данных между Kafka — не проблема. Вопрос ширины канала.

[gecube]

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

[AlexeyVi]

Может я что то упустил, но почему приложения сразу не пишут по сети свои логи в какое то место, будь то Graylog, Kafka?
И вопрос по Graylog, почему складывается? На прошлой работе был кейс: 5 серверов Graylog и 6 ElasticSearch (2 мастера без хранения), все это VM. Глотали 350k json в сек в пике и норм.
Да и к проблеме безопасности Kibana, недавно вышел форк от Амазона, где есть рабочий и бесплатный аналог Shield тык: opendistro.github.io/for-elasticsearch

[gecube]

Вопрос не ко мне.
Можете найти автора доклада и спросить у него. Полагаю, что они просто с сайзингом промазали. Грейлог — это ведь не только эластик, но и монга, и веб-морда. Так что да — там чуточку другие требования, чем у ванильного эластика.
Касательно — почему не сами приложения. А почему приложении вообще должны отвечать за доставку своих логов? Это задача инфры, вообще-то. 12 factor, все дела.

Касательно форка эластика. Это, во-первых, дело буквально последних месяцев. См. датировку доклада. Тогда этого даже в проекте не было. Во-вторых, это по сути вендор-лок. На варианте от Амазона.

[gecube]

Стейт в контейнере — это не зло. Это техническое решение. Если человек понимает, что он делает и что при этом будет (какие ограничения и особенности у конкретного решения) — почему бы и не засунуть БД в контейнер? Тем более, если речь не про продакшн-среду, а просто про прогон тестов

[gecube]

Запись в stdout блокируема в linux, а авторам twelve factor app, надеюсь, ещё придётся ответить за свой неграмотный манифест, который продолжает калечить людей и проекты.

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