Централизованное логирование: что это, зачем нужно и как выбрать архитектуру в 2026 году

Централизованное логирование - это сбор журналов со всех серверов, контейнеров, приложений и сетевого оборудования в одно хранилище с единым поиском и едиными правами доступа. Вместо десяти SSH-сессий к десяти хостам вы делаете один запрос и получаете события Nginx, приложения, балансировщика и базы данных в одной выдаче, отсортированные по времени.

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

Архитектуру выбирают из трёх базовых схем: агент на хосте плюс брокер плюс хранилище, прямая отправка по syslog, sidecar-контейнер в Kubernetes. Ниже разбираем каждую с конфигами и командами проверки, затем критерии выбора между self-hosted и облачным сервисом и чек-лист вопросов, которые стоит закрыть до старта. Независимых публичных замеров производительности мы не приводим: цифры в примерах - ориентиры для планирования, их нужно перепроверять на своём профиле нагрузки.

Что такое централизованное логирование и зачем оно нужно

Централизованное логирование - это конвейер, в котором агент или сама служба отправляет журнал с источника в общее хранилище, а инженер работает с ним через веб-интерфейс и API. Источником выступает что угодно: systemd-юнит, контейнер, виртуальная машина, коммутатор, приложение, пишущее в stdout. Хранилище индексирует записи и даёт поиск по полям, а не по тексту файла.

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

Чем централизованное логирование отличается от локального

Разница видна на конкретном сценарии. У вас десять серверов с Nginx, и клиент жалуется на 502. При локальном хранении вы подключаетесь к каждому хосту, грепаете access.log и error.log, вручную сопоставляете время, потому что часы на машинах могут расходиться. При централизованном вы делаете один запрос с фильтром по статусу, временному окну и upstream-адресу.

Параметр	Локальное хранение	Централизованное логирование
Доступ к логам	SSH на каждый хост	Один веб-интерфейс или API
Поиск	grep, awk, zgrep по ротированным файлам	Индекс и запросы по полям
Корреляция	Вручную по времени и IP	По trace_id, request_id, session_id
Сохранность	Теряется вместе с диском хоста	Живёт на отдельном узле или в object storage
Ротация	logrotate на каждой машине	Политики хранения в хранилище
Доступ и аудит	Права root на хосте	Роли на чтение индексов, отдельный журнал доступа

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

Какие задачи закрывает централизованное логирование

Аудит действий. Кто перезапустил сервис, кто менял конфиг Nginx, кто заходил по SSH и с какого адреса. Без единой точки сбора такие вопросы превращаются в переписку с владельцами хостов.

Отладка инцидентов. Ошибка в одном сервисе часто вызвана таймаутом в другом. Если оба пишут в общее хранилище и передают заголовок с идентификатором запроса, вы видите всю цепочку вызовов по одному значению. Готовые критерии по составу событий собраны в материале что логировать, а что нет.

Корреляция событий между сервисами и безопасность. Пример расследования: ночью выросли 401-е ответы на API. В одном хранилище сразу видны логи аутентификации, записи firewall о сканировании портов и сообщения приложения о блокировке аккаунтов, и картина складывается за минуты, а не за сутки.

Соответствие требованиям. 152-ФЗ обязывает оператора при обработке персональных данных принимать правовые, организационные и технические меры для защиты данных от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, предоставления и распространения. К мерам обеспечения безопасности закон относит, в частности, установление правил доступа к персональным данным и обеспечение регистрации и учёта всех действий, совершаемых с ними в информационной системе, а также обнаружение фактов несанкционированного доступа и реагирование на инциденты. Для журналов доступа это означает ограничение круга читающих, защиту от правки и учёт действий с данными. Конкретные сроки и состав журналов определяет ваша политика и отраслевые нормы: сверяйтесь с текстом регламента, а не с пересказом. Требование неизменяемого хранилища или WORM-режима напрямую из текста закона не следует - это одна из возможных технических реализаций, которую стоит отдельно согласовать с вашей политикой и юристом. Текст статьи 19 Федерального закона № 152-ФЗ доступен в справочной правовой системе КонсультантПлюс.

Централизованное логирование - часть observability вместе с метриками и трассировкой. Логи отвечают на вопрос «что именно произошло», метрики показывают «как часто и насколько сильно», трейсы связывают запрос между сервисами.

Типовые архитектуры централизованного сбора логов

Три схемы ниже покрывают большинство инфраструктур: от пары виртуальных машин до Kubernetes-кластера. Разбор конвейера целиком, включая агенты Vector и Fluent Bit, есть в статье про архитектуру централизованного сбора логов.

Агент на хосте + брокер + хранилище

Схема: Filebeat, Fluent Bit или Vector читает журналы на хосте, отправляет их в Kafka либо Redis, а отдельный потребитель пишет данные в Elasticsearch, OpenSearch или Loki. Брокер здесь решает две задачи: сглаживает пики при недоступности хранилища и позволяет подключить несколько потребителей без переделки источников.

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

Пример конфигурации Filebeat для отправки логов Nginx в Kafka. Вход filestream требует уникального ID среди всех inputs, а Kafka output принимает список брокеров, версию протокола и параметры повторной отправки при сетевых ошибках. Описание этих параметров приведено в документации Beats по Kafka output и в filebeat.reference.yml:

filebeat.inputs:
  - type: filestream
    id: nginx-access
    paths:
      - /var/log/nginx/access.log
    fields:
      service: nginx
      env: prod

output.kafka:
  hosts: ["kafka-1:9092", "kafka-2:9092"]
  topic: "logs-nginx"
  required_acks: 1
  compression: gzip
  max_message_bytes: 1000000

queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 5s

Проверка результата после запуска потребителя:

curl -s 'http://localhost:9200/_cat/indices?v'
curl -s 'http://localhost:9200/logs-nginx-*/_count'
kafka-topics --bootstrap-server kafka-1:9092 --describe --topic logs-nginx

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

Прямая отправка по syslog

Схема без агентов: rsyslog или syslog-ng на хосте сам отправляет записи на центральный сервер. Подходит для сетевого оборудования, старых приложений и небольших парков, где ставить отдельный демон на каждую машину не хочется.

Плюсы: минимум зависимостей, штатная поддержка в Linux и почти любом сетевом устройстве. Минусы: нет полноценной буферизации при обрыве сети, слабая структурированность сообщений, а UDP-транспорт вообще не гарантирует доставку.

Минимальный вариант на клиенте, отправка по TCP на удалённый сервер:

*.* @@logserver.example.net:514

Рабочий вариант с дисковым буфером, чтобы пережить падение связи:

*.* action(type="omfwd"
            target="logserver.example.net"
            port="514"
            protocol="tcp"
            queue.type="LinkedList"
            queue.filename="fwdq"
            queue.maxdiskspace="1g"
            queue.saveonshutdown="on"
            action.resumeRetryCount="-1")

На стороне сервера включите приём и шаблон раскладки по хостам:

module(load="imtcp")
input(type="imtcp" port="514" ruleset="remote")
template(name="PerHost" type="string"
         string="/var/log/remote/hosts/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")
ruleset(name="remote") {
    action(type="omfile" dynaFile="PerHost")
}

Проверка с любого клиента и на сервере:

logger -n logserver.example.net -P 514 -T "test message from $(hostname)"
tail -f /var/log/remote/hosts/*/*.log

Флаг -T заставляет logger использовать TCP, флаг -n задаёт адрес сервера. Если сообщение появилось в файле на сервере, транспорт работает; дальше настраивайте ротацию для каталога /var/log/remote и следите за размером.

Sidecar-модель в Kubernetes

Схема: рядом с основным контейнером работает контейнер-агент, который читает общий volume с файлами журналов и отправляет их в хранилище. Официальная документация Kubernetes описывает два подхода: сбор на уровне узлов, когда лог-агент запускается на каждом узле и ему доступна директория с файлами логов всех контейнеров приложений (для этого его рекомендуют запускать как DaemonSet), и sidecar-контейнер с лог-агентом, который считывает логи из файла, сокета или journald и пишет их в собственный поток stdout/stderr. Sidecar оправдан там, где приложение пишет не в stdout, а в собственный файл, либо где нужны отдельные права и отдельный пайплайн для одного сервиса. Оба подхода описаны в документации Kubernetes по архитектуре для сбора логов.

Плюсы: изоляция настроек по сервису, независимое масштабирование, доступ к файлам, которые не попадают в stdout. Минусы: лишний контейнер на каждый под, расход памяти, риск дублирования записей, если то же самое уже собирает нодовый DaemonSet. Документация Kubernetes отдельно предупреждает, что работа лог-агента в sidecar-контейнере может привести к значительному потреблению ресурсов, а доступ к этим журналам через kubectl logs будет невозможен, поскольку они не контролируются kubelet.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: app
      image: nginx:1.27
      volumeMounts:
        - name: varlog
          mountPath: /var/log/nginx
    - name: fluent-bit
      image: fluent/fluent-bit:3.1
      volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: fb-config
          mountPath: /fluent-bit/etc/
  volumes:
    - name: varlog
      emptyDir: {}
    - name: fb-config
      configMap:
        name: fluent-bit-sidecar-conf

Версии образов в примере (nginx:1.27, fluent/fluent-bit:3.1) приведены как ориентир и не подтверждены release notes проектов: перед применением сверьте актуальные теги в реестрах образов.

Проверка, что sidecar читает файл и не падает с ошибкой прав:

kubectl logs app-with-sidecar -c fluent-bit --tail=50
kubectl exec -it app-with-sidecar -c fluent-bit -- ls -l /var/log/nginx

Если в логе sidecar видны строки вида «error opening file», проверьте, что оба контейнера монтируют один и тот же volume и что uid агента хватает прав на чтение файла. Практика по контейнерным пайплайнам и готовые конфиги для Kubernetes собраны в статье сравнение ELK, Loki и Graylog с конфигами для Kubernetes.

Как выбрать между self-hosted и облачным решением

Выбор сводится к трём переменным: сколько логов приходит в сутки, сколько вы готовы тратить и что требуется от хранения. Всё остальное - производные. Ниже критерии и таблица, а готовые docker-compose для быстрого старта лежат в материале про выбор стека от Elastic Stack до Grafana Loki.

Критерии выбора: объём, бюджет, требования к хранению

Объём. Считайте не только текущий поток, но и рост: он обычно идёт вместе с числом сервисов и включением отладочных уровней. Elastic рекомендует начинать сайзинг кластера для логов и метрик именно с объёма сырых данных в ГБ в сутки и срока хранения. В их примерах: при поступлении 1 ГБ в сутки и хранении данных 9 месяцев для малого кластера достаточно 8 ГБ памяти на ноду, а для крупного развёртывания при 100 ГБ в сутки и хранении 30 дней в hot-зоне и 12 месяцев в warm-зоне приводится расчёт числа нод по объёму данных. Там же отмечено, что в крупном развёртывании безопаснее добавить ноду для отказоустойчивости, а среднее наблюдаемое соотношение размера индекса к сырому объёму составляет 1.2 - это значение стоит пересчитать на своих данных, разделив размер индекса без реплики на сырой объём. Конкретные пороги вроде «до 10 ГБ в сутки - одна нода» или «от 1 ТБ в сутки - tiered storage» в этих материалах не приводятся, поэтому используйте их только как грубые ориентиры и проверяйте расчётом по своей нагрузке. Методика сайзинга описана в блоге Elastic Benchmarking and sizing your Elasticsearch cluster for logs and metrics.

Бюджет. У облака основная статья - плата за приём и хранение, у self-hosted - серверы, диски, резервные копии и время инженера. В TCO self-hosted входят дни-недели инженеров на первый запуск, обновления, бэкапы, масштабирование и дежурство по самому мониторингу. Прикидка простая: если облачный тариф берёт оплату за каждый гигабайт, умножьте суточный объём на срок хранения и сравните с ценой сопоставимого по ресурсам сервера плюс оценкой инженерного времени. Тарифы меняются, поэтому финальное сравнение делайте по актуальному прайсу провайдера. Разбор TCO self-hosted и облачного мониторинга приведён в статье Self-hosted или облачный мониторинг: что выбрать. Для размещения self-hosted стека подойдёт облачная инфраструктура с виртуальными машинами, хранилищем и Kubernetes, например Timeweb Cloud, где ресурсы можно менять по мере роста потока логов.

Требования к хранению. Срок (30 дней, 90 дней, год), шифрование при передаче и на диске, геолокация данных, неизменяемость журналов, разделение доступа по командам. Если нужна гарантированная неизменяемость и политики жизненного цикла, self-hosted с объектным хранилищем даёт больше контроля, чем арендованный сервис с фиксированными настройками.

Наличие команды. On-call на self-hosted кластер ложится на вас: обновления, диски, шардирование, восстановление после сбоя. Облачный сервис снимает эту работу, но забирает часть контроля и привязывает к провайдеру.

Таблица сравнения self-hosted и облачных решений

Параметр	Self-hosted	Облачный сервис
Стоимость	Серверы, диски, резервные копии, часы инженера; предсказуема	Оплата за объём приёма и хранения; растёт вместе с логами
Время запуска	Дни: развернуть, настроить шардирование, роли, бэкапы	Часы: включить агент, получить ключ доступа
Масштабирование	Ручное, нужны скилл и план по шардам	Автоматическое, лимиты задаёт тариф
Поддержка	Своя команда или платный контракт	Входит в сервис, SLA на стороне провайдера
Безопасность и соответствие	Полный контроль: шифрование, WORM, своя сеть	Зависит от сертификатов и региона провайдера
Кастомизация	Плагины, парсеры, любые источники	Ограничена возможностями платформы
Привязка к вендору	Низкая, стек можно перенести	Высокая: выгрузка и миграция требуют работы

Практическое правило: на старте и в малых командах облачный вариант почти всегда выгоднее по TCO, а на очень больших объёмах self-hosted может окупаться - при условии, что у вас есть инженеры на его обслуживание. Порог «до 10 ГБ в сутки» как граница между облаком и self-hosted в проверенных источниках не подтверждается, поэтому решайте по расчёту TCO и требованиям к хранению. Гибрид тоже рабочий вариант: горячие логи за 7-14 дней в облаке для быстрого поиска, архив в self-hosted объектном хранилище.

Чек-лист вопросов перед внедрением централизованного логирования

Ответы на эти вопросы до старта экономят переделку схемы после первого серьёзного инцидента.

Какие источники логов? Перечислите типы: Linux-хосты, Nginx, контейнеры, базы данных, сетевое оборудование, приложения. От этого зависит выбор агента и парсеров.
Какой объём и скорость роста? Считайте в гигабайтах в сутки и документах в секунду. Умножьте на срок хранения, добавьте запас на индексацию.
Какие требования к хранению? Срок, шифрование, геолокация, неизменяемость, кто и как может удалить данные.
Кто администрирует систему? Есть ли дежурный, который починит упавший консьюмер в три часа ночи, или проще взять сервис.
Какой бюджет на год? Считайте и подписку, и железо, и время инженера. Дешевле на старте часто оказывается не тот вариант, что дешевле на третий год.
Нужна ли связка с метриками и трейсами? Если да, выбирайте стек, который умеет сквозные идентификаторы запросов и переходы из метрики в лог.
Как организован доступ? Роли на чтение по командам, отдельная роль для безопасности, аудит самого доступа к логам.
Как проверять работоспособность? Заранее определите команды: подсчёт документов в индексе, лаг консьюмера, тестовое сообщение через logger.
Что делать при недоступности хранилища? Дисковый буфер у агента, очередь в брокере, лимит на размер буфера и поведение при его переполнении.
Как масштабировать? План на рост в два и в десять раз: добавить ноду, расширить шарды, поменять тариф.
Есть ли правила фильтрации? Что нельзя писать в логи: пароли, токены, номера карт, персональные данные. Маскирование настраивается на агенте.

Пункты 8 и 11 стоит закрыть в первый же день: без проверки и без маскирования система либо окажется нерабочей в момент инцидента, либо превратится в канал утечки.

Заключение

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

Начинайте с простого шага: syslog на центральный сервер для инфраструктуры и Filebeat или Fluent Bit для приложений. Когда упрётесь в поиск и корреляцию, добавьте брокер и полноценный индекс. Перед этим пройдите чек-лист выше и определитесь с объёмом и сроком хранения: эти два числа чаще всего и решают спор между self-hosted и облаком. Пошаговые конфигурации для отказоустойчивой схемы собраны в руководстве про отказоустойчивое логирование для DevOps.