Comments 16
У докера есть возможность указать диспетчер логов. По умолчанию — json-file, то есть, докер складывает вывод из контейнера в json-file на хосте. Если мы выбираем диспетчер логов, который будет отправлять записи куда-то по сети, то мы больше не сможем использовать команду docker logs. Если stdout/stderr контейнера был выбран единственным местом для записи логов приложения, то в случае сетевых проблем или проблем у единого хранилища, быстро извлечь записи для дебага может не получиться.
Добавлю. В docker-ce таких драйверов два: json-file и journald. Рекомендую присмотреться ко второму, т.к. он не отменяет использование docker logs, но зато позволяет пользоваться всеми прелестями journalctl (включая автоматический тротлинг, если место кончилось, и ротацию логов). Дополнительно в docker-ee можно использовать команду docker logs и для остальных драйверов:
Users of Docker Enterprise can make use of “dual logging”, which enables you to use the docker logs command for any logging driver. Refer to Reading logs when using remote logging drivers for information about using docker logs to read container logs locally for many third party logging solutions, including:
https://docs.docker.com/config/containers/logging/configure/
но из-за особенности php-fpm в официальном образе docker получаем в docker logs
7.3 спешит на помощь, не?
Согласно 12 факторному приложению, писать нужно в stdout, stderr среды выполнения приложения.
Люди бездумно продолжают ссылаться на правила конфигурирования приложений для облачной платформы heroku как на эталон. Если вы разворачиваете приложение не на heroku, то не стоит пытаться следовать всем этим злополучным «12 factor».
Почему heroku говорит, что надо отправлять логи исключительно в stdout? У heroku просто нет другого нормального способа сохранить логи, так как файловая система при любом перезапуске может сбросится в чистое состояние. Если вы разворачиваете приложение на одной единственной машине, то можете писать логи куда вам удобно, не оглядываясь, как это надо делать на heroku.
О том, что можно писать в файлы и собирать их, я тоже упомянул.
С файлами вообще очень интересно. Сейчас мода на то, чтобы все засовывать в докер. Так вот. При прочих равных файл внутри контейнера всегда пишется в эфемерную файловую систему суть есть последний слой запущенного контейнера докера (который можно превратить в образ путем docker commit). Так вот. В одной из дискуссий обратили внимание, что вообще желательно все файлы, которые генерирует приложение ЛИБО класть в tmpfs, ЛИБО в VOLUME (заранее определенный в Dockerfile, либо ключами -v/--mount при запуске контейнера) — они тогда, во-первых, персистируют между перезапусками контейнера (tmpfs же чистится) и, во-вторых, это дешевле по iops и нагрузке на cpu, чем писать в эфемерную ФС (внезапно, ога?).
Поэтому писать в stdout/stderr — вполне норм рекомендация, тем более, что тот же systemd по умолчанию логи тоже в таком же виде ждет от приложения (можете сами проверить).
В общем, мойте руки перед едой.
p.s. с stdout/stderr есть другие нюансы, о которых мне указали мои коллеги, но которые выходят за обсужденные выше моменты.
getId https://habr.com/ru/post/450098/#comment_20105786
Например, это
Ну, и, вообще, добро пожаловать в профильную группу по логам в Телеграм: @ru_logs
Мое мнение, что это отстой. Но сколько людей — столько мнений.
У записи в удаленное хранилище логов приложением есть свои плюсы. Например, можно более удобно контролировать, что должно попасть в логи. Можно сразу писать структурированные логи (json), не боясь, что по дороге кто-то их порежет или криво сконвертирует. В минусах — это не решает проблему гарантированной доставки. Если шлете в условный эластик, а он "прилёг", то Ваше приложение легко может заблокироваться на записи в него. Но здесь больше играют более системные вопросы — а допустимо ли, чтобы логи иногда терялись. ИБшники, например, скорее будут топить за целостность системы, а не за ее доступность (оно и понятно — мало ли в логах что интересное будет, а по закону Мерфи именно их и пролюбили). Ops'ы же будут, напротив, за доступность и отказоустойчивость. Для них логи — это очень приятное дополнение для расследования проблем и мониторинга отказов
Логирование в распределенном php-приложении