Сравнение лог-шипперов: только два из шести умеют настоящую дедупликацию строк

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

Подробности

Автор сравнения — Антон Касимов из Gals Software, ведущий телеграм-канала по наблюдаемости «Мониторим ИТ». Он взял шесть известных лог-шипперов: OpenTelemetry Collector, Vector, vlagent, Fluent Bit, Grafana Alloy и Filebeat — и прогнал через них одинаковый поток данных. Результаты оказались неоднородными. Реализации дедупликации сильно расходятся по семантике: - один агент агрегирует повторы и сохраняет их количество; - другой молча оставляет только первую запись, теряя остальные; - третий умеет лишь ограничивать частоту; - четвёртый показывает уникальные строки только в интерфейсе — уже после того, как все дубли попали в хранилище. По итогам теста агентов, которые действительно умеют дедупликацию, оказалось всего два: OpenTelemetry Collector и Vector. У Fluent Bit задачу можно решить скриптом, то есть встроенного механизма нет, но есть обходной путь. А у Filebeat, vlagent и Grafana Alloy встроенного механизма дедупликации не обнаружилось вовсе. Практический вывод из этого прост: выбирая лог-шиппер, нельзя полагаться на наличие слова «дедупликация» в документации или маркетинговых материалах. Нужно понимать, что именно агент делает с повторами: считает их, отбрасывает, ограничивает частоту или просто прячет в UI. От этого напрямую зависят и стоимость хранения, и полнота данных при разборе инцидентов.

Что делать

Если для вашей инфраструктуры критичны объёмы логов и стоимость их хранения, стоит провести собственный тест на реальном потоке данных, а не ориентироваться на общие описания функций. Полезно заранее определить, что для вас важнее: сохранить счётчик повторов для последующего анализа или просто снизить шум. Для сценариев, где нужна именно агрегация с сохранением количества, разумно сразу смотреть в сторону OpenTelemetry Collector или Vector. Если вы уже используете Fluent Bit, Filebeat, vlagent или Grafana Alloy, дедупликацию придётся реализовывать самостоятельно — например, скриптом на стороне агента — либо мириться с лишним трафиком и объёмом хранения. В любом случае перед внедрением имеет смысл проверить поведение агента на тестовом стенде: молчаливая потеря повторяющихся записей может обернуться пробелами в данных при разборе инцидента. Итог: единого стандарта дедупликации среди лог-шипперов нет, поэтому выбор агента должен опираться на проверку его реального поведения, а не на заявленный набор функций.

Источник: Хабр — Системное администрирование