Централизованный сбор и хранение логов в небольшой инфраструктуре

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

Для небольшой инфраструктуры можно рассмотреть rsyslog или Vector как приёмник и обработчик, а VictoriaLogs — для поиска с собственным веб-интерфейсом. Приёмник и поиск допустимо разместить в одной виртуальной машине (VM) при согласованных ограничениях. Сохранность очереди после аварии проверяют отдельно: дисковый буфер сам по себе её не гарантирует. На выходе должны быть карта источников, правила полей и доступа, сроки хранения и результаты испытаний отказов. Руководство помогает подготовить такой контур; параметры конкретной установки уточняют по потоку и требованиям.

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

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

Карта источников

Для интеграций заранее согласуйте смысл статусов и идентификаторы: один текст «успешно» не объясняет, было ли сообщение только принято или уже обработано.

Минимальные поля события

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

Различие исходного времени и времени наблюдения явно предусмотрено в модели логов OpenTelemetry ↗. При восстановлении или повторной загрузке нельзя незаметно заменять время события временем новой записи.

Для событий мобильного клиента отдельно согласуйте безопасный диагностический контекст и способ связать его с серверной операцией.

Логи и метрики решают разные вопросы. Ошибки доставки, задержку и заполнение очереди нужно контролировать по метрикам; подробности событий — искать в журнале.

Источник должен переживать согласованный разрыв связи: сохранять локальные файлы или использовать подходящий буфер. Приёмник получает поток, проверяет и преобразует поля, затем отправляет записи в нужные назначения. Поиск обеспечивает быстрые запросы; архив сохраняет согласованный набор событий для более длительного доступа или восстановления.

Вариант для небольшой VM

На схеме приёмник и поиск находятся в общей VM, а архив — за её пределами. Это вариант размещения, который нужно проверить на своих источниках. Ветви поиска и архива должны иметь явно настроенное поведение при отказе каждого назначения.

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

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

Как подтвердить доставку

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

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

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

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

rsyslog и Vector

В rsyslog очередь, которая использует диск при определённых условиях, и очередь с требуемой устойчивостью к аварии — разные настройки. Сохранение при штатной остановке не доказывает сохранность при отключении питания. Режим, контрольные точки и синхронизацию выбирать по документации очередей rsyslog ↗, затем испытывать на выбранной файловой системе и хранилище.

В Vector буферы настраиваются для выходов. Дисковая буферизация имеет собственные условия записи и синхронизации; поддержка сквозных подтверждений зависит от источника и приёмника. При отправке в несколько назначений поведение подтверждений и обратного давления нужно проверить для всей схемы. Основание — модель буферизации Vector ↗ и подтверждения доставки ↗.

Поэтому выбор между ними не сводится к «какой современнее». Для syslog-приёмника может быть достаточно rsyslog; при разнообразных источниках и преобразованиях стоит оценить Vector. Использование обоих оправдано, когда понятно разделение функций.

VictoriaLogs, Loki и OpenSearch

VictoriaLogs имеет собственный веб-интерфейс, поэтому для первого поиска отдельная Grafana не обязательна. Начало работы описано в VictoriaLogs Quick Start ↗. VictoriaMetrics относится к хранению метрик и не заменяет VictoriaLogs.

Loki можно рассматривать при подходящей модели источников и меток в существующем Grafana-контуре. Для нового внедрения нужно выбирать поддерживаемый агент: поддержка Promtail завершена ↗. OpenSearch с Dashboards уместен, когда нужны его поисковые возможности и команда готова поддерживать индексы, схемы и восстановление. Это альтернативы по требованиям, а не обязательные следующие стадии после VictoriaLogs.

Logstash стоит рассматривать при нужном плагине или уже работающей обработке. Уязвимости требуют допуска конкретной версии и конфигурации; наличие зарегистрированных уязвимостей (CVE) само по себе не запрещает весь продукт. Не включайте тяжёлую цепочку обработки только потому, что она встречается в чужой архитектуре.

SIEM нужен для обнаружения и расследования угроз. Wazuh или OpenSearch Security Analytics добавляют собственные правила и эксплуатацию, а не только ещё один экран поиска. Их внедрение требует согласованных источников, тестовых действий и владельца реакции.

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

Условный расчёт очереди

Предположим, измеренный входящий поток — 300 событий в секунду, средний размер записи — 800 байт, а приёмник должен выдерживать 30 минут недоступности назначения. Полезный объём составит 300 × 800 × 1800 = 432 000 000 байт, то есть 432 МБ в десятичной системе.

Это нижняя оценка для данного постоянного потока. Фактический буфер дополнительно хранит служебные данные; размер записи меняется, а ошибки могут увеличить поток. В примере удвоение даёт 864 МБ, но коэффициент два — только исходное предположение для пилота, не гарантия. Окончательный размер подтверждают пиковым потоком и испытанием остановки нужной длительности. Также проверяют, успевает ли очередь разгрузиться при продолжающейся записи.

Сроки и объём хранения

Допустим, команда выбрала 14 дней для быстрого поиска и 90 дней для архива, потому что типовой разбор завершается за две недели, а повторные обращения требуют более длинной истории. Это условные сроки, не норматив. Если вход составляет 2 ГБ в день, исходный поток за эти интервалы — 28 и 180 ГБ соответственно.

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

Что делать с секретами и персональными данными

Можно ли отправлять в логи полные запросы? Только после проверки состава полей и необходимости. Пароли, токены, ключи, cookie сессии и избыточные персональные сведения исключают до записи в общий поиск и архив. Маскирование только в интерфейсе не удаляет уже сохранённый секрет. Практические проверки описаны в OWASP Logging Cheat Sheet ↗.

Кому давать доступ? Разделите отправку, чтение, администрирование и удаление. Право агента писать события не должно позволять читать весь архив. Доступ к чувствительным событиям и действия администраторов также требуют контроля.

Что происходит после окончания срока? Удаление должно охватывать согласованные назначения и копии по их политике. Простое исчезновение записи из поисковой выдачи ещё не доказывает удаление из архива. Для приостановки удаления значимых доказательств нужен отдельный согласованный порядок.

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

Порядок первого запуска

1. Согласуйте источники, поля, запрещённые данные и сроки хранения.
2. Выберите приёмник и поиск, зафиксируйте версии и права.
3. Подключите один источник и найдите его контрольную запись.
4. Настройте очереди, повторную доставку и каждое направление архивации.
5. Включите мониторинг потока, задержки, ошибок, очередей и диска.
6. Испытайте отказы, восстановление, дубли и истечение срока.
7. Подключайте остальные источники после устранения найденных отклонений.

Проверки перед рабочим запуском

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

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