Как организовать логирование в микросервисе?

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

Ключевые принципы

• Структурированное логирование: Вместо строк формата "Error at line X" используйте JSON-объекты с полями: timestamp, level, message, correlationId, serviceName, userId и т.д. Это позволяет системам автоматически индексировать и фильтровать логи.
• Сквозная идентификация (correlation ID): Каждый входящий HTTP-запрос получает уникальный идентификатор, который передаётся между всеми сервисами в цепочке. Все логи, связанные с этим запросом, помечаются этим ID, что позволяет восстановить полную историю его обработки.
• Централизованное хранение: Логи с каждого инстанса сервиса должны отправляться в общее хранилище. Популярные решения: ELK-стек (Elasticsearch для хранения и поиска, Logstash/Fluentd для сбора, Kibana для визуализации) или Grafana Loki (более лёгкий вариант, интегрированный с Grafana).
• Уровни логирования: Используйте стандартные уровни (DEBUG, INFO, WARN, ERROR, FATAL) осмысленно. DEBUG — для деталей отладки в development, ERROR — для критических сбоев, требующих внимания.

Практический пример на Node.js с Winston

Рассмотрим настройку логгера для сервиса на Express, который генерирует correlation ID и отправляет логи в консоль в структурированном виде, а также в файл ошибок.

const express = require('express');
const winston = require('winston');
const { v4: uuidv4 } = require('uuid');

const app = express();

// Middleware для добавления correlation ID к каждому запросу
app.use((req, res, next) => {
  req.correlationId = req.headers['x-correlation-id'] || uuidv4();
  res.setHeader('X-Correlation-ID', req.correlationId);
  next();
});

// Настройка логгера Winston
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json() // Структурированный вывод в JSON
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'error.log', level: 'error' })
  ]
});

// Маршрут с логированием
app.get('/api/data', (req, res) => {
  // Логируем начало обработки с correlation ID
  logger.info('Processing request', { 
    correlationId: req.correlationId,
    path: req.path,
    method: req.method
  });

  try {
    // Имитация бизнес-логики
    const data = { result: 'success' };
    logger.info('Request completed successfully', { correlationId: req.correlationId });
    res.json(data);
  } catch (error) {
    logger.error('Request failed', { 
      correlationId: req.correlationId,
      error: error.message 
    });
    res.status(500).send('Internal error');
  }
});

app.listen(3000, () => logger.info('Service started on port 3000'));

В продакшене консольный транспорт можно заменить на отправку в Logstash через транспорт winston-logstash или в syslog. Для сбора логов с Docker-контейнеров часто используют драйвер журналирования docker, который направляет stdout контейнеров в центральный агрегатор.

Где применяется

Такой подход к логированию применяется во всех микросервисных системах, особенно в облачных средах (AWS, GCP, Azure), где сервисы масштабируются и запускаются в множестве контейнеров. Он является основой для:

• Отладки сложных сбоев, затрагивающих несколько сервисов.
• Мониторинга производительности и поиска узких мест.
• Анализа пользовательских сценариев и аудита действий.
• Автоматических алертов при появлении ошибок определённого уровня.

Вывод: Организованное логирование с использованием структурированных логов, сквозных идентификаторов и централизованного сбора необходимо для поддержания наблюдаемости и отказоустойчивости микросервисной архитектуры. Применяйте этот подход, когда ваша система состоит из более чем одного независимо развёртываемого сервиса.