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

Логирование в консоль в микросервисной архитектуре

Отличный вопрос о практиках логирования в modern системах! Короткий ответ: зависит от контекста, но в production это НЕ рекомендуется. Позвольме разобраться.

Проблемы с console logging в микросервисах

1. Потеря логов при масштабировании

Traditionnal App (Monolith):
└─ App Instance → Console → Разработчик смотрит в консоль

Microservices (Kubernetes):
├─ Service Pod 1 → Console?
├─ Service Pod 2 → Console?
├─ Service Pod 3 → Console?
├─ Service Pod 4 → Console?
└─ Service Pod 5 → Console?

❌ Куда смотреть? Логи теряются при перезагрузке пода!

2. Форматирование и структурированность

// ❌ Консоль: Неструктурированная информация
public void logToConsole() {
    System.out.println("User login: john at 2024-01-15 10:30:45");
    // Сложно парсить, анализировать, фильтровать
}

// ✅ Structured logging: Легко обрабатывать
public void logStructured() {
    logger.info("User login", 
        "user_id", userId,
        "timestamp", LocalDateTime.now(),
        "ip_address", ipAddress);
    // JSON: {"level": "INFO", "message": "User login", 
    //        "user_id": 123, "timestamp": "2024-01-15T10:30:45"}
}

3. Потеря контекста при трассировке

Request Flow в микросервисах:
├─ API Gateway (логирует в консоль)
├─ Auth Service (логирует в консоль)
├─ User Service (логирует в консоль)
├─ Order Service (логирует в консоль)
└─ Payment Service (логирует в консоль)

❌ Как связать логи из разных сервисов?

Правильный подход: Centralized Logging

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Service
public class OrderService {
    private static final Logger logger = LoggerFactory.getLogger(OrderService.class);
    
    public void processOrder(String orderId, String userId) {
        // ✅ Логируем в файл/централизованное хранилище
        logger.info("Order processing started",
            "order_id", orderId,
            "user_id", userId,
            "trace_id", MDC.get("traceId")  // Для связи логов
        );
        
        // Processing logic
        logger.debug("Calculating total", "items_count", items.size());
    }
}

Stack логирования в production

Java Application
    ↓
SLF4J (API)
    ↓
Logback / Log4j2 (Implementation)
    ↓
┌─────────────────────────────────┐
│ Output Destinations             │
├─────────────────────────────────┤
│ 1. File (local)                 │  ← Рядом с приложением
│ 2. ELK Stack / Datadog          │  ← Централизованный анализ
│ 3. CloudWatch / Stackdriver     │  ← Cloud решение
│ 4. Splunk                       │  ← Enterprise решение
│ 5. (Console)                    │  ← Для debug в разработке
└─────────────────────────────────┘

Примеры конфигурации

Logback конфигурация для production

<!-- logback-spring.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <!-- Dev profile: Console -->
    <springProfile name="dev">
        <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
            <encoder>
                <pattern>
                    %d{yyyy-MM-dd HH:mm:ss} - %msg%n
                </pattern>
            </encoder>
        </appender>
        <root level="INFO">
            <appender-ref ref="CONSOLE" />
        </root>
    </springProfile>
    
    <!-- Production profile: File + ELK -->
    <springProfile name="prod">
        <!-- Файловый аппендер -->
        <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>/var/log/myapp/application.log</file>
            <encoder>
                <pattern>
                    %d{ISO8601} [%thread] %-5level %logger{36} - %msg%n
                </pattern>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <fileNamePattern>
                    /var/log/myapp/application-%d{yyyy-MM-dd}.log
                </fileNamePattern>
                <maxHistory>30</maxHistory>
            </rollingPolicy>
        </appender>
        
        <!-- JSON для ELK Stack -->
        <appender name="JSON_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>/var/log/myapp/application.json</file>
            <encoder class="net.logstash.logback.encoder.LogstashEncoder" />
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <fileNamePattern>
                    /var/log/myapp/application-%d{yyyy-MM-dd}.json
                </fileNamePattern>
            </rollingPolicy>
        </appender>
        
        <root level="INFO">
            <appender-ref ref="FILE" />
            <appender-ref ref="JSON_FILE" />
        </root>
    </springProfile>
</configuration>

Distributed Tracing

import io.micrometer.tracing.Tracer;
import org.springframework.cloud.sleuth.Span;

@Service
public class OrderService {
    private final Tracer tracer;
    
    @Autowired
    public OrderService(Tracer tracer) {
        this.tracer = tracer;
    }
    
    public void processOrder(Order order) {
        // Trace ID автоматически добавляется
        String traceId = tracer.currentSpan().context().traceId();
        
        logger.info("Processing order",
            "order_id", order.getId(),
            "trace_id", traceId
        );
        
        // Вызов другого сервиса
        paymentService.charge(order);  // trace_id будет передан
    }
}

Когда console логирование ДОПУСТИМО

✅ Development окружение
✅ Local тестирование
✅ Docker контейнеры (stdout логи собирает Docker)
✅ Lambda функции (CloudWatch парсит stdout)
❌ Production микросервисы (Kubernetes)
❌ Enterprise системы
❌ Long-running приложения

Docker + Kubernetes логирование

# Dockerfile
FROM openjdk:17
COPY app.jar .

# В контейнере логирование в stdout перехватывается Docker
ENTRYPOINT ["java", "-jar", "app.jar"]

# Docker собирает логи из stdout
docker logs container_id

# Kubernetes собирает логи через stdout
kubectl logs pod_name

Best Practices

// ✅ ПРАВИЛО 1: Используй SLF4J, не System.out
private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
logger.info("Message");  // ✅
// System.out.println("Message");  // ❌

// ✅ ПРАВИЛО 2: Структурированное логирование
logger.info("User login",
    "user_id", userId,
    "ip_address", ipAddress
);

// ✅ ПРАВИЛО 3: Разные уровни для разного контента
logger.error("Critical error", exception);    // Ошибки
logger.warn("Potential issue");               // Предупреждения
logger.info("Business event happened");       // Важные события
logger.debug("Debug information");            // Отладка
logger.trace("Detailed trace info");          // Трассировка

// ✅ ПРАВИЛО 4: Не логируй чувствительные данные
// ❌ logger.info("Password: " + password);
// ✅ logger.info("User authenticated", "user_id", userId);

// ✅ ПРАВИЛО 5: Используй Mapped Diagnostic Context
MDC.put("request_id", UUID.randomUUID().toString());
logger.info("Processing request");  // request_id будет в логе
MDC.clear();

Выводы

1. Console logging НЕ рекомендуется в production
2. Используй файлы или централизованное логирование
3. Структурированное логирование (JSON) — обязательно
4. Distributed tracing для микросервисов — необходимо
5. Docker/Kubernetes собирают stdout логи автоматически
6. ELK/Datadog/CloudWatch — standard для production
7. SLF4J + Logback/Log4j2 — правильный стек