Централизованное логирование: Часть 1 — Зачем собирать логи в одном месте

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

Пока сервер один, логи можно читать прямо на нём. Когда серверов и сервисов становится несколько, такой подход перестаёт работать, и логи собирают в одно место.

Чем плохи логи, разбросанные по серверам

• Их трудно собрать. Чтобы разобрать один сбой, приходится заходить по SSH на несколько машин и искать нужные файлы.
• События нельзя сопоставить. Запрос прошёл через балансировщик, приложение и базу данных, но записи о нём лежат в трёх разных местах и в трёх разных форматах.
• Поиск медленный. grep по файлам на десятке серверов работает, пока логов немного; с ростом объёма он становится непрактичным.
• Логи теряются. Файлы ротируются и удаляются, а если сервер вышел из строя или его взломали, записи на нём могут пропасть или быть изменены именно тогда, когда они нужнее всего.

Что даёт централизованный сбор

Централизованное логирование — это сбор логов со всех серверов и сервисов в общее хранилище, где по ним можно искать, строить графики и настраивать оповещения.

• Одна точка доступа. Все записи доступны в веб-интерфейсе, на отдельные серверы заходить не нужно.
• Быстрый поиск. Фильтры по времени, серверу, сервису, уровню важности и содержимому.
• Связь событий. Записи разных компонентов видны на одной временной шкале; если приложение передаёт идентификатор запроса, его путь прослеживается целиком.
• Сохранность. Копия логов хранится отдельно от серверов, которые их породили.
• Оповещения. Сообщение приходит, когда растёт число ошибок или появляется подозрительная запись, например серия неудачных входов.

Из чего состоит система

Любая система централизованного логирования выполняет одни и те же шаги:

1. Сбор. Агент на сервере читает файлы логов, системный журнал или вывод контейнеров. Примеры агентов: Filebeat, Fluent Bit, Grafana Alloy, Vector.
2. Передача. Записи отправляются в хранилище по syslog, HTTP или собственному протоколу системы.
3. Обработка. Строки разбираются на поля, лишнее отбрасывается, добавляются имя хоста, окружение, название сервиса.
4. Хранение и индексация. Записи сохраняются так, чтобы по ним можно было быстро искать за нужный период.
5. Поиск и визуализация. Запросы, дашборды, отчёты.
6. Оповещения. Правила, по которым система сообщает о проблеме.

Для сбора логов с удалённых клиентов можно обойтись и без полноценного стека — такой вариант разобран в статье «Как организовать сбор логов с удалённых клиентов по HTTP».

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

Больше всего времени при внедрении уходит на разбор строк. Строку вида

2026-09-22 10:15:03 ERROR Payment failed for order 1842: timeout

приходится разбирать регулярными выражениями, и любое изменение формата ломает разбор. Если приложение сразу пишет лог в JSON, поля уже выделены:

{"time":"2026-09-22T10:15:03Z","level":"error","service":"payments","order_id":1842,"msg":"payment failed","error":"timeout"}

По такой записи можно отфильтровать все ошибки сервиса payments или найти всё, что относится к заказу 1842, без дополнительной настройки. Практические правила:

• одно событие — одна строка;
• время в UTC и в формате ISO 8601;
• постоянные имена полей во всех сервисах: level, service, msg, request_id;
• идентификатор запроса передаётся между сервисами и попадает в каждую запись.

Уровни важности

Стандарт syslog (RFC 5424) определяет восемь уровней — от 0 (emergency, система неработоспособна) до 7 (debug, отладочные сообщения). В приложениях обычно используют сокращённый набор: debug, info, warning, error, critical.

Уровень debug в рабочей среде лучше выключать: он увеличивает объём логов в разы, а с ним и стоимость хранения. Если отладочные записи нужны для разбора конкретной проблемы, их включают временно.

Сколько хранить

Срок хранения определяется задачей, а не свободным местом на диске:

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

Во всех системах из этого цикла срок хранения задаётся политикой: старые данные удаляются автоматически. Без такой политики хранилище рано или поздно переполнится.

Персональные данные в логах

В логи легко попадают данные пользователей: адреса электронной почты, телефоны, имена, содержимое форм. Если лог содержит персональные данные, его сбор и хранение становятся обработкой персональных данных, и на неё распространяются требования 152-ФЗ. В частности, по ч. 7 ст. 5 закона персональные данные хранятся не дольше, чем этого требуют цели обработки, если срок не установлен федеральным законом или договором.

Практически это означает:

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

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

• Логи без единого формата. Каждый сервис пишет по-своему, и для каждого приходится писать свой разбор.
• Нет политики хранения. Хранилище растёт, пока не кончится диск, после чего перестаёт принимать новые записи.
• Отладочный уровень в рабочей среде. Объём логов растёт в разы без пользы.
• Секреты в логах. Токены и пароли, попавшие в лог, доступны каждому, кто имеет доступ к системе логирования.
• Хранилище на том же сервере. Если сервер вышел из строя, вместе с ним пропадают и логи, которые нужны для разбора.

Какую систему выбрать

В этом цикле разобраны четыре распространённые системы:

• ELK Stack (Elasticsearch, Logstash, Kibana) — полнотекстовый поиск и развитая аналитика, но высокие требования к ресурсам.
• OpenSearch — открытый форк Elasticsearch и Kibana с похожими возможностями.
• Graylog — готовая платформа для логов с потоками, правилами обработки и разграничением доступа.
• Loki и Grafana — экономичное хранение за счёт индексации только меток, удобно рядом с Prometheus.