docker, как принято обрабатывать логи?

loki-docker-driver + loki + grafana. быстро и относительно удобно

После перезапуска логи не теряются. Вообще логи лежат в /var/lib/docker/containers/id/id-json.log. Они будут теряться после удаления контейнера (что и логично). Т.е. просто не удаляй контейнеры и всё. К примеру надо использовать docker-compose start/stop вместо up/down.

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

loki-docker-driver + loki + grafana.

слушай, расскажи как это дело работает.
много времени уходит на поддержку ?
плюсы есть в сравнении с efk ?
я почему спрашиваю, у меня много логов. и теперь только для логов стоит кафка из 14 машин + еластик увеличился до 7 машин.

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

плюсы есть в сравнении с efk

kibana пофункциональней и приятней, 100%. на эластик для логов у меня аллергия из-за падучести последнего (я просто не умею его готовить), функциональность fluentd размазана между loki-docker-driver и loki, но мне тем лучше - меньше промежуточных звеньев которые тоже надо мониторить.

для логов стоит кафка из 14 машин + еластик увеличился до 7 машин.

не думаю что Loki готов к такому. у нас всего-то 100-200 записей в секунду, примерно 150гиг в мес, он легко справляется на hdd, хоть памяти и поджирает:

srv_loki_1 2.75% 2.724GiB / 31.33GiB 8.69% 94.6GB / 32.3GB 157MB / 56.8GB 60

для небольшого почтовика или группки серверов, где «вдумчиво погрепать при проблемах» - пойдет, что-то серьезнее на него вешать - имхо, рискованно.

Отправляй в journald. И там уже разберёшься с длительностью хранения

Даже ELK раза в три проще настраивается.

они теряются после перезапуска

После docker-compose down?

Так-то, если ты пишешь в stdout, при перезапуске ничего не теряется. Ты путаешь.

Ну вот, сам же говоришь, что нифига не быстро. Полдня на какую-то примитивщину. Цель — всего-то собрать логи локалтно.

отправлять на хостовый syslog по сети :)

Дык я ж при обновлении сорцов контейнеры заново строю, start-stop не прокатит.

Про отдельный том понял. Буду думать.

Спасибо за подробный ответ!

https://docs.docker.com/config/containers/logging/journald/

Не могу понять - то ли стремно, то ли непривычно все в один лог и с бинарным форматом фигачить.

Но я давно в тему не вникал. Это сейчас так принято, все в systemd заливать, а потом утилитой из общего файла фильтровать?

Не принято. Есть нормальные инструменты.

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

Пробуй fluentd. Он прекрасно дружит с докером, поддержка реализована с обеих сторон, при этом сам демон максимально легковесный и может перенаправлять вывод хоть в файл, хоть в астрал.

https://docs.docker.com/config/containers/logging/fluentd/
https://www.fluentd.org/guides/recipes/docker-logging
https://docs.fluentd.org/output/file

Спасибо, интересная штука.

А как принято многострочные выхлопы логировать? Например, мне надо иногда к сообщениям стектрейс прилепить.

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

Там есть возможность парсить, фильтровать и преобразовывать логи, это реализовано в виде плагинов, причём есть уже готовые под различные ​форматы.

https://docs.fluentd.org/parser#list-of-built-in-parsers

https://docs.fluentd.org/parser/multiline

Но придётся повозиться с регулярками, пока не покроешь каждый случай многострочного лога.

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

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

Насчет плохой практики согласен. А как принято решать вопрос, если надо сообщение об ошибке стектрейсом сопроводить?

Конечно ошибки в основном по месту обрабатываются, и тогда выхлоп однострочный. Но есть глобальный хендлер, на случай если случился непредвиденный трындец. Очень редко, но иногда случается. И там без стектрейса вообще не реально разобраться. Я конечно могу все в джисон однострочный залепить. Будет формально правильно, но не юзабельно. Как в таком случае поступают грамотные пейсатели программ?

Какие-то еще варианты, кроме как натравить плагинов с регулярками, есть?

В структурированном логе, например в json, весь мгогострочный трейс ляжет в строку как значение соответствующего поля.

Для локального использования заморачиваться, конечно, не стоит, как я выше и говорил. Простой текстовый лог удобнее.

Лучшие собаководы советуют ставить в начале строки невидимый юникод-символ. Например \x{200B}. И по нему отлавливать. Таймстамп можно но есть шанс, что он в твоём многострочном выхлопе появится, хотя, конечно, это уже перестраховки.

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

не храни логи в контейнере вообще.. пиши их в stdout, остальное сделает докер демон.