Как диагностировать потерю логов (часть событий не долетает до централизованного хранилища) и какие типичные точки отказа нужно проверить?

Короткий ответ

Нужно последовательно проверить: не ротируется ли файл лога быстрее, чем агент успевает его прочитать; не упирается ли агент сбора логов в лимиты ресурсов (CPU/память) под нагрузкой; не возникает ли backpressure или отбрасывание (drop) на стороне приёмника при превышении его пропускной способности; не теряются ли данные на сетевом уровне между агентом и хранилищем.

Как это работает подробнее

агент сбора логов (Fluent Bit, Promtail) отслеживает позицию чтения файла (offset); если файл ротируется и удаляется быстрее, чем агент успел прочитать последнюю часть, эти строки теряются безвозвратно. Если приёмник (Elasticsearch, Loki) перегружен и отвечает ошибками или таймаутами, агент либо ставит данные в очередь (буфер), либо, при превышении буфера, начинает отбрасывать данные — это обычно видно по собственным метрикам агента (fluentbit_output_dropped_records_total, promtail_dropped_entries_total).

Пример кода

query.promqlКопировать

# Метрика потерь на агенте Fluent Bit
rate(fluentbit_output_dropped_records_total[5m])
# Метрика отказов приёмника (Loki, пример)
rate(loki_distributor_bytes_rejected_total[5m])

Что использовать на практике

• Практика. для диагностики сравнивают количество "отправленных" записей на агенте с количеством "принятых" на стороне хранилища за тот же период — системная разница указывает на потерю на конкретном участке. Также полезно включить мониторинг самого конвейера логирования как отдельного observability-объекта (метрики агента, метрики приёмника), а не считать его "невидимой инфраструктурой".
• Практика. Если fluentbit_output_dropped_records_total растёт одновременно с кодами 429 от Loki, причина — приёмник не успевает принимать поток данных (например, после всплеска трафика), и решение — увеличить пропускную способность приёмника или ограничить скорость отправки (rate limiting) на стороне агента, а не считать потерю логов случайной.

Подводные камни

• Частые ошибки. не мониторить метрики самого log pipeline, обнаруживая потерю логов только постфактум при расследовании инцидента, когда нужных логов не оказалось; настраивать слишком агрессивную ротацию/retention на узле без учёта реальной скорости обработки агентом; игнорировать коды ошибок хранилища (429 Too Many Requests в Elasticsearch/Loki) как временные, хотя они означают систематическую потерю данных при устойчивой перегрузке.