Comments 13
rsyslog отличная штука, только требует наличия root'a в контейнере или включенных capabilities
Какая то боль, есть filebeat, есть ротация docs.docker.com/config/containers/logging/json-file, если какие то проблемы при записи на диск, пишете в рам диск тогда…
Я бы вообще по-другому делал.
Сейчас из существующих драйверов логирования для docker'а только два умеют писать на локальный хост. Это json-file и journald. Json-file — не наш выбор по разным причинам. Остается journald. Он умеет все то же самое, плюс ротация, плюс ретеншн. А еще он позволяет с одного места смотреть все логи через утилиту journalctl.
Остальные — syslog, gelf и пр. драйвера, к сожалению, не сохраняют на локальную машину с докером логи. И что хуже — если отвалится приемник логов, то никто об этом и не узнает.
Далее можно из локальной базы journald вытянуть логи journalbeat'ом или fluent-bit'ом и передать куда-то дальше. Куда — зависит от Вашей фантазии.
Ну, и в кейса автора доклада — я бы рассмотрел возможность развертывания в каждом ДЦ своего инстанса Kafka, а реализовать переброс данных между Kafka — не проблема. Вопрос ширины канала.
Сейчас из существующих драйверов логирования для docker'а только два умеют писать на локальный хост. Это json-file и journald. Json-file — не наш выбор по разным причинам. Остается journald. Он умеет все то же самое, плюс ротация, плюс ретеншн. А еще он позволяет с одного места смотреть все логи через утилиту journalctl.
Остальные — syslog, gelf и пр. драйвера, к сожалению, не сохраняют на локальную машину с докером логи. И что хуже — если отвалится приемник логов, то никто об этом и не узнает.
Далее можно из локальной базы journald вытянуть логи journalbeat'ом или fluent-bit'ом и передать куда-то дальше. Куда — зависит от Вашей фантазии.
Ну, и в кейса автора доклада — я бы рассмотрел возможность развертывания в каждом ДЦ своего инстанса Kafka, а реализовать переброс данных между Kafka — не проблема. Вопрос ширины канала.
И что хуже — если отвалится приемник логов, то никто об этом и не узнает.насколько я знаю, все посыпется, но я так это и не проверил
Ну, может быть два кейса:
— мы стартуем контейнер и он не стартует
— у нас все умерло в процессе работы. Вряд ли это зааффектит уже существующие контейнеры. Но логи мы точно потеряем
Тем более, если шлем по UDP.
— мы стартуем контейнер и он не стартует
— у нас все умерло в процессе работы. Вряд ли это зааффектит уже существующие контейнеры. Но логи мы точно потеряем
Тем более, если шлем по UDP.
Может я что то упустил, но почему приложения сразу не пишут по сети свои логи в какое то место, будь то Graylog, Kafka?
И вопрос по Graylog, почему складывается? На прошлой работе был кейс: 5 серверов Graylog и 6 ElasticSearch (2 мастера без хранения), все это VM. Глотали 350k json в сек в пике и норм.
Да и к проблеме безопасности Kibana, недавно вышел форк от Амазона, где есть рабочий и бесплатный аналог Shield тык: opendistro.github.io/for-elasticsearch
И вопрос по Graylog, почему складывается? На прошлой работе был кейс: 5 серверов Graylog и 6 ElasticSearch (2 мастера без хранения), все это VM. Глотали 350k json в сек в пике и норм.
Да и к проблеме безопасности Kibana, недавно вышел форк от Амазона, где есть рабочий и бесплатный аналог Shield тык: opendistro.github.io/for-elasticsearch
Вопрос не ко мне.
Можете найти автора доклада и спросить у него. Полагаю, что они просто с сайзингом промазали. Грейлог — это ведь не только эластик, но и монга, и веб-морда. Так что да — там чуточку другие требования, чем у ванильного эластика.
Касательно — почему не сами приложения. А почему приложении вообще должны отвечать за доставку своих логов? Это задача инфры, вообще-то. 12 factor, все дела.
Касательно форка эластика. Это, во-первых, дело буквально последних месяцев. См. датировку доклада. Тогда этого даже в проекте не было. Во-вторых, это по сути вендор-лок. На варианте от Амазона.
Можете найти автора доклада и спросить у него. Полагаю, что они просто с сайзингом промазали. Грейлог — это ведь не только эластик, но и монга, и веб-морда. Так что да — там чуточку другие требования, чем у ванильного эластика.
Касательно — почему не сами приложения. А почему приложении вообще должны отвечать за доставку своих логов? Это задача инфры, вообще-то. 12 factor, все дела.
Касательно форка эластика. Это, во-первых, дело буквально последних месяцев. См. датировку доклада. Тогда этого даже в проекте не было. Во-вторых, это по сути вендор-лок. На варианте от Амазона.
Я вас полностью поддерживаю, стейт в контейнере это зло. Я не много не об этом, я про логи которые хранятся в /var/lib/docker/containers/<container-id>/<container-id>-json.log, на хостовой машине, пофакту это stdout/stderr контейнера. Берем эти логи через filebeat, отправляем куда нужно.
Стейт в контейнере — это не зло. Это техническое решение. Если человек понимает, что он делает и что при этом будет (какие ограничения и особенности у конкретного решения) — почему бы и не засунуть БД в контейнер? Тем более, если речь не про продакшн-среду, а просто про прогон тестов
Запись в stdout блокируема в linux, а авторам twelve factor app, надеюсь, ещё придётся ответить за свой неграмотный манифест, который продолжает калечить людей и проекты.
кмк, у вас тут серьезные архитектурные проблемы, если запись в stdout блокирует полностью Вашу экосистему (я не говорю про приложение как конкретный инстанс, т.к. очевидно, что их должно быть столько, сколько обеспечат обработку необходимой нагрузки).
Sign up to leave a comment.
Юрий Бушмелев «Карта граблей на поле сбора и доставки логов» — расшифровка доклада