Зачем контейнер должен писать логи в stdout/stderr, а не в файл?

Причина 1 — Docker log drivers собирают stdout/stderr автоматически

Всё, что процесс пишет в stdout/stderr, Docker перехватывает и передаёт настроенному log driver:

# Просмотр логов любого контейнера
docker logs --tail 100 -f my-container

# Конфигурация log driver в daemon.json
# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Доступные драйверы: json-file (по умолчанию), journald, syslog, fluentd, awslogs, gcplogs, splunk, loki. Переключение между ними не требует изменения кода приложения.

Зачем писать логи в stdout/stderr, а не в файл?

Это принцип 12-Factor App (фактор XI — Logs). Контейнер не знает, где он запущен, кто его читает и как долго проживёт. stdout/stderr — это единственный универсальный канал вывода.

Причина 2 — Эфемерная файловая система контейнера

Если приложение пишет логи в /var/log/app.log внутри контейнера:

• При удалении контейнера все логи теряются.
• При рестарте (crash) логи до краша могут быть недоступны.
• Диск контейнера (overlay2) ограничен и не предназначен для длительного хранения.

Причина 3 — Централизованный сбор логов

# docker-compose.yml с Loki
services:
  app:
    image: my-app:latest
    logging:
      driver: loki
      options:
        loki-url: "http://loki:3100/loki/api/v1/push"
        loki-batch-size: "400"

Fluentd/Fluent Bit, Filebeat, Vector — все они нативно умеют читать stdout Docker-контейнеров через Docker socket или log files в /var/lib/docker/containers/. Если логи в файле внутри контейнера — нужен дополнительный sidecar или volume.

Причина 4 — Kubernetes и оркестраторы ожидают stdout

# Kubernetes читает логи контейнера из stdout
kubectl logs my-pod -c my-container

# Если логи в файле — kubectl logs ничего не покажет
# Нужен дополнительный sidecar: log-agent читает файл и пишет в stdout

Как настроить приложение на вывод в stdout

# Python (logging)
import logging
import sys

logging.basicConfig(
    stream=sys.stdout,
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s"
)

// Node.js — console.log/error уже пишет в stdout/stderr
// Для production используй pino:
import pino from "pino";
const logger = pino({ level: "info" });  // пишет JSON в stdout

# Nginx: перенаправляем access/error log в stdout/stderr
# /etc/nginx/nginx.conf
http {
  access_log /dev/stdout combined;
  error_log /dev/stderr warn;
}

Ротация логов

При log driver json-file логи хранятся в /var/lib/docker/containers/[id]/[id]-json.log. Без ограничений диск переполнится:

docker run --log-opt max-size=50m --log-opt max-file=5 my-app:latest

Подводные камни

• Буферизация stdout: Python по умолчанию буферизует вывод в stdout — при краше последние логи могут не появиться. Используй PYTHONUNBUFFERED=1 или python -u.
• json-file без max-size заполняет диск хоста при интенсивном логировании — всегда настраивай ротацию в daemon.json или через --log-opt.
• docker logs работает только с json-file и journald драйверами. При переключении на fluentd или awslogs команда docker logs перестаёт работать.
• Смешивание stdout и stderr в одном потоке теряет семантику уровня логирования — INFO в stdout, ERROR/WARN в stderr; это позволяет алертить только по stderr.
• При очень высоком throughput логов json-file становится узким местом (JSON-сериализация, fsync). В этом случае используй journald или прямой вывод в Fluentd через unix socket.
• Sidecar-контейнер для чтения файловых логов увеличивает сложность и создаёт риск потери логов при рестарте sidecar.

• Писать application logs только в файл внутри контейнера.
• Не настраивать rotation для json-file logging driver на single-host Docker.
• Смешивать secrets или PII в stdout без фильтрации и retention policy.

• Объясняет stdout/stderr как runtime logging contract.
• Понимает docker logs и logging drivers.
• Учитывает rotation, centralized logging and privacy.