Как формируются логи в одном месте из запущенных реплик?

Организация централизованного логирования для реплицированных приложений

В микросервисной архитектуре или при горизонтальном масштабировании приложения (когда запущено несколько реплик одного сервиса) критически важно организовать сбор логов в едином централизованном хранилище. Это позволяет:

• Агрегировать данные со всех инстансов
• Обеспечивать единый интерфейс для поиска и анализа
• Сохранять целостность логов при падении отдельных нод
• Видеть полную картину работы распределённой системы

---

Основные подходы и архитектурные паттерны

1. Агентское логирование (Logging Agent)

На каждой виртуальной машине или контейнере устанавливается легковесный агент, который:

• Мониторит указанные файлы логов или stdout/stderr
• Обогащает метаданными (имя сервиса, реплика, окружение)
• Отправляет в центральную систему

Пример с Filebeat (Elastic Stack):

# docker-compose.yml для сервиса с агентом
version: '3.8'
services:
  app:
    image: my-php-app:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    
  filebeat:
    image: docker.elastic.co/beats/filebeat:8.12.0
    volumes:
      - ./filebeat.yml:/usr/share/filebeat/filebeat.yml
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - /var/run/docker.sock:/var/run/docker.sock

2. Прямая отправка из приложения (SDK/Client Library)

Приложение самостоятельно отправляет логи через библиотеку:

// Пример с Monolog и отправкой в Elasticsearch
use Monolog\Logger;
use Monolog\Handler\ElasticsearchHandler;
use Elastic\Elasticsearch\ClientBuilder;

$client = ClientBuilder::create()
    ->setHosts(['elasticsearch:9200'])
    ->build();

$handler = new ElasticsearchHandler(
    $client,
    [
        'index' => 'php-app-logs',
        'type' => '_doc',
    ]
);

$log = new Logger('app');
$log->pushHandler($handler);

// Обогащение контекстом реплики
$log->info('User authenticated', [
    'replica_id' => getenv('HOSTNAME') ?: 'unknown',
    'service' => 'auth-service',
    'trace_id' => $request->getTraceId()
]);

3. Sidecar-контейнер в Kubernetes

Для контейнеризированных приложений в Kubernetes используется паттерн Sidecar:

# Kubernetes Pod с sidecar для логирования
apiVersion: v1
kind: Pod
metadata:
  name: php-app-with-logging
spec:
  containers:
  - name: php-app
    image: my-php-app:latest
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app
  
  - name: log-shipper
    image: fluent/fluentd:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app
    - name: config-volume
      mountPath: /etc/fluentd
  
  volumes:
  - name: shared-logs
    emptyDir: {}
  - name: config-volume
    configMap:
      name: fluentd-config

---

Ключевые компоненты стека логирования

Транспорт и буферизация

• Message Brokers: RabbitMQ, Apache Kafka, Redis Streams
• Буферизация: предотвращает потерю данных при сбоях бэкенда

// Использование Redis для буферизации логов
$redisHandler = new Monolog\Handler\RedisHandler(
    new Redis(),
    'log_queue',
    Logger::DEBUG
);

// Асинхронная обработка через очередь
$workerHandler = new Monolog\Handler\BufferHandler(
    $redisHandler,
    100, // буфер 100 сообщений
    Logger::DEBUG,
    true, // флаг flushOnClose
    true  // использовать bubble
);

Обогащение метаданными

Каждая запись должна содержать:

• timestamp - точное время события
• service_name - идентификатор сервиса
• replica_id - уникальный идентификатор реплики
• environment - staging/production/etc
• trace_id - для сквозной трассировки
• log_level - error/warning/info/debug

Хранение и индексация

• Elasticsearch: полнотекстовый поиск, агрегации
• Loki: эффективное хранение логов от Grafana Labs
• ClickHouse: для аналитических запросов по логам

Практические рекомендации для PHP+Backend

1. Используйте PSR-3 и Monolog как стандарт де-факто
2. Структурированные логи (JSON) вместо plain text:

$logger->info('Request processed', [
    'method' => $request->getMethod(),
    'url' => $request->getUri(),
    'duration_ms' => $duration,
    'user_id' => $user->getId(),
    'replica' => $_SERVER['HOSTNAME'] ?? 'local'
]);

1. Контекстно-зависимое логирование:

// Создаем логгер с общим контекстом
$requestLogger = $logger->withRecord([
    'request_id' => uniqid(),
    'session_id' => session_id(),
    'ip' => $_SERVER['REMOTE_ADDR']
]);

1. Динамический уровень детализации:

// В development - DEBUG, в production - ERROR
$logLevel = getenv('APP_ENV') === 'prod' 
    ? Logger::ERROR 
    : Logger::DEBUG;

1. Ротация и политики хранения:

# Пример конфигурации logrotate
/var/log/php-app/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        kill -USR1 $(cat /var/run/php-fpm.pid)
    endscript
}

Мониторинг и алертинг

1. Дашборды в Grafana/Kibana для визуализации
2. Alert Rules на основе паттернов в логах
3. SLO/SLA мониторинг через анализ логов ошибок
4. Автоматический парсинг стектрейсов для группировки ошибок

Распространённые ошибки и их решение

Важно: Централизованное логирование должно быть отказоустойчивым и не создавать bottleneck для основного приложения. Всегда тестируйте нагрузку на систему логирования при пиковых значениях и имейте fallback-механизмы (локальное сохранение с последующей синхронизацией).