Централизованные логи: как собирать и быстро искать

Сначала определите, что именно вы хотите найти

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

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

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

Схема сбора: от процесса до поиска

Типовой конвейер состоит из трёх частей: приложение пишет события, агент или коллектор забирает их с узла, хранилище принимает и индексирует данные. Интерфейс поиска подключается к хранилищу. Для новых систем стоит опираться на OpenTelemetry Collector как на промежуточный слой: он принимает, обрабатывает и экспортирует телеметрию. Конкретные компоненты и конфигурацию выбирайте по документации установленной версии.

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

Кардинальность¹ — число уникальных значений поля. Например, у метки service обычно десятки значений, а у request_id — потенциально миллионы.

Два подхода к поиску

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

Что заложить до подключения агентов

• Единый формат. Зафиксируйте обязательные поля: время события в UTC, уровень, сервис, окружение и текст или код события.
• Идентификатор запроса. Передавайте его через сервисы и записывайте в каждое сообщение, связанное с обработкой запроса. Тогда можно перейти от ошибки на входном сервисе к событиям соседних компонентов.
• Ограниченные метки. Подходят сервис, окружение, регион или стабильный тип события. Не добавляйте в метки адреса клиентов, токены и уникальные идентификаторы запросов.
• Политика хранения. Разделите оперативные логи и архив. Для каждого источника определите срок хранения и причину, по которой его нужно сохранять.
• Защита данных. Удаляйте секреты и персональные данные до отправки в хранилище. Доступ к поиску логов тоже ограничивайте: в сообщениях могут оказаться сведения, которые не должны видеть все сотрудники.

Как выбрать подход под нагрузку

Выбирайте Loki, если

Основные вопросы звучат так: «Что происходило в сервисе оплаты около 14:10?» или «Найдите ошибки этого приложения в тестовом окружении». Для таких запросов хорошо подходят стабильные метки, а подробности можно искать в тексте после первичного отбора. Начинайте с малого числа меток и проверяйте, что типовые запросы не сканируют слишком большой объём данных.

Выбирайте Elasticsearch или OpenSearch, если

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

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

Что ломается первым

• Время событий не совпадает. Синхронизируйте часы узлов и сохраняйте временную зону однозначно. Иначе соседние события окажутся в неверном порядке.
• Агент теряет данные при недоступности хранилища. Проверьте поведение очереди и буфера при сбое сети, перезапуске процесса и заполнении диска. Буфер не бесконечен: задайте предел и мониторьте его заполнение.
• Поиск становится дорогим. Слишком широкий диапазон времени, запрос без ограничивающих меток или поле с высокой кардинальностью может резко увеличить объём обработки.
• Логи содержат секреты. Фильтрацию нужно тестировать на реальных путях ошибок и отладочных сообщениях. Маскировка только в интерфейсе не удаляет данные из хранилища.
• Метрики доставки отсутствуют. Следите за задержкой между событием и появлением в поиске, ошибками экспорта, размером очередей и потерянными записями. Само отсутствие сообщений может означать и тишину в приложении, и поломку конвейера.

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

1. Сформулируйте пять реальных вопросов, которые команда задаёт при сбое: по сервису, времени, уровню и идентификатору запроса.
2. Отправьте тестовые события с каждого типа источника и проверьте, что поля и время отображаются одинаково.
3. Отключите хранилище на короткое время в тестовой среде. Убедитесь, что агент ведёт себя ожидаемо, а после восстановления данные доставляются либо потеря фиксируется.
4. Проверьте права доступа, маскирование секретов и срок удаления данных на тестовом наборе.
5. Измерьте задержку доставки и стоимость хранения при ожидаемом потоке, затем повторите тест с пиковым объёмом.

Следующий шаг — не добавлять новые источники, а запустить систему на одном-двух сервисах и записать время ответа на типовые запросы, потери доставки и расход диска за сутки. После этого будет понятно, какие метки и сроки хранения действительно нужны. Трассировки и метрики связаны с логами, но требуют отдельной настройки.

¹ Высокая кардинальность увеличивает число отдельных комбинаций индексируемых значений. В Loki это может раздуть число потоков, а в поисковых движках — размер и сложность индекса.