В этом материале
Collector может терять телеметрию при переполнении очереди, истечении retry window или рестарте без сохранённого buffer. Начните с направления, где перестали проходить данные. Sending queue и memory_limiter защищают разные границы и не обеспечивают бесконечную доставку при отказе backend.
Collector может терять телеметрию при переполнении очереди, истечении retry window или рестарте без сохранённого buffer. Начните с направления, где перестали проходить данные. Sending queue и memory_limiter защищают разные границы и не обеспечивают бесконечную доставку при отказе backend.
Найдите участок потери
Нарисуйте SDK → agent → gateway → backend для фактической среды. У каждого перехода свои queues, timeouts и retry behavior. Сохраните receiver accepted/refused observations, exporter send failures и queue size/capacity с учётом версии metrics. Присутствие Collector process не означает активность нужного pipeline. Проверьте, что компоненты включены в service pipelines и данные действительно проходят выбранный receiver. Успешный локальный debug exporter не подтверждает приём удалённым backend.
Разделите очередь и memory limit
Sending queue буферизует данные перед удалённой отправкой. Её заполнение и исчерпание retry duration создают условия потери. Memory_limiter ограничивает давление на Collector и может приводить к отказу приёма, который upstream должен уметь обработать. Слишком большая очередь способна сама приблизить процесс к container memory limit. Поэтому увеличение capacity нельзя считать независимым от RAM. Зафиксируйте pipeline ordering, настройки retries и реальные ограничения workload до выбора нового объёма buffer.
Проведите ограниченный отказ
В учебной среде отправляйте синтетические пронумерованные события и временно остановите тестовый backend. Наблюдайте накопление queue и реакцию upstream. После возврата получателя сравните созданные и полученные идентификаторы без утверждения exactly-once. Затем отдельно проверьте restart Collector. In-memory queue не сохраняет данные через его аварийное завершение. Persistent sending queue через storage extension меняет поведение, но остаётся ограниченной ёмкостью, retry policy и корректностью хранения.
| Проверка | Наблюдаемое свидетельство |
|---|---|
| Backend недоступен | Export errors и рост queue |
| Queue заполнена | Отказы или потери нового потока |
| Collector перезапущен | Поведение сохранённого backlog |
| Backend вернулся | Догоняющая доставка и пробелы |
Согласуйте допустимый компромисс
Выберите, какую длительность и объём отказа нужно переживать, затем рассчитайте ресурсный бюджет по измеренному потоку. Для критичных переходов рассматривают persistent queue или отдельный messaging слой, учитывая дополнительную эксплуатацию. Это не универсальное требование каждому локальному agent. Слишком сложный канал способен создать новые точки отказа. Сохраните распределение ответственности между exporter retry и upstream retry, чтобы давление не терялось молча на первом же промежуточном компоненте.
Проверьте возвращение к норме
Успешное восстановление включает уменьшение backlog, отсутствие продолжающихся refused/dropped событий и понятный временной диапазон возможных потерь. Не называйте отсутствие новых ошибок полной доставкой истории. Артефакт содержит topology, версии, queue settings и результат синтетического отказа. Повторяйте опыт после изменения memory limit или частоты телеметрии. Так capacity связана с реальным объёмом данных, а Collector остаётся наблюдаемым компонентом, чьи собственные отказы не маскируются состоянием целевого GPU-сервиса.
Связанные разборы: gpu monitoring scorecard; network and uptime.