Концепции логирования и сбор логов

Курс: DevOps с нуля: Путь к автоматизации и CI/CD16+

Мы уже научились собирать метрики с помощью Prometheus и визуализировать их в Grafana. Метрики отвечают на вопрос «Что происходит с системой?», показывая загрузку процессора или количество запросов. Но когда возникает ошибка, метрик мало — нужно увидеть детали событий. Для этого используют логирование.

В современной инфраструктуре с микросервисами подход «зайти по SSH и прочитать файл» не работает. Вам нужно централизованное логирование — автоматический сбор логов со всех узлов и контейнеров в единое хранилище с быстрым поиском.

Структурированные логи

Раньше логи были просто строками текста. Чтобы анализировать их автоматически, мы используем структурированные логи. Это сообщения в машиночитаемом формате (обычно JSON), где каждое поле (время, уровень, ID пользователя) четко определено.

Важнейший атрибут сообщения — уровень логирования. Он помогает фильтровать шум:

DEBUG: подробности для разработки.
INFO: штатная работа системы.
WARNING: подозрительное событие, но приложение работает.
ERROR: серьезная проблема, часть функций недоступна.
FATAL/CRITICAL: полный отказ приложения.

Сравните два формата. С объектом JSON инструментам мониторинга работать проще, чем с текстом.

// Плохо: Plain Text
// 2026-05-20 14:00:01 ERROR User 42 failed to upload file image.png: Access Denied

// Хорошо: Структурированный JSON
{
  "timestamp": "2026-05-20T14:00:01Z",
  "level": "ERROR",
  "user_id": 42,
  "action": "upload_file",
  "resource": "image.png",
  "error": "Access Denied",
  "service": "api-gateway"
}

Конвейер сбора логов

Процесс превращения файлов в поток данных состоит из четырех этапов (см. Схему 1).

Генерация: приложение пишет лог в stdout (стандартный вывод).
Шиппинг (Shipping): Docker log driver подхватывает этот вывод.
Агрегация: лог-агрегатор (например, Fluentd) собирает данные, добавляет метаданные (имя контейнера, IP) и фильтрует лишнее.
Хранение: данные уходят в базу (Elasticsearch, Loki) или журнал событий облачного провайдера.

Инструментарий: Docker Drivers и Fluentd

В контейнерах Docker сам управляет потоками вывода. По умолчанию он пишет JSON-файлы на диск хоста, но в продакшене Docker log driver переключают на отправку данных во внешние системы.

Fluentd — это гибкий инструмент для маршрутизации. Он позволяет, например, отправлять логи уровня ERROR в Telegram, а остальные — в архив.

Настроим конфиг Fluentd, который принимает логи по HTTP и выводит их в консоль. Создайте файл fluent.conf:

<source>
  @type http
  port 8888
  bind 0.0.0.0
</source>

<match **>
  @type stdout
</match>

Запустите контейнер: docker run -p 8888:8888 -v $(pwd):/fluentd/etc -e FLUENTD_CONF=fluent.conf fluent/fluentd:v1.16

В другом терминале отправьте тестовый лог: curl -X POST -d 'json={"event":"test_log","status":"ok"}' http://localhost:8888/test.tag

Типичные ошибки

Log Spam: если писать INFO на каждое действие в цикле, место на диске закончится мгновенно, а счета за облако вырастут 💸
Отсутствие ротации: без автоматического удаления старых файлов логи могут забить диск и остановить сервер.
Разные временные зоны: всегда используйте UTC. Если один сервер пишет в MSK, а другой в UTC, вы не восстановите цепочку событий при аварии.

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

Понравился урок?

Сохраните прогресс и получите персональный курс по любой теме — без форм и паролей

Продолжить в Telegram