В 03:00 график Traefik показал всплеск 5xx. Дежурный поднял число реплик backend. Стало хуже: медленный обработчик не успевал завершить исходный запрос, а retry middleware добавлял повторные вызовы. Backoff разносил их по времени, но не отменял уже работающую попытку. Очередь и занятые соединения росли быстрее пропускной способности сервиса. Сначала проверьте access log Traefik с полем RetryAttempts и сопоставьте его с латентностью upstream. Посмотрите traefik_service_requests_total и traefik_service_request_duration_seconds в Prometheus; на узле — ss -s, ss -tan state established, cat /proc/net/sockstat. Если растут активные соединения и p99, а CPU backend не исчерпан, вероятна очередь ожидания, а не нехватка реплик. Снимите конфигурацию retry middleware и проверьте attempts и initialInterval. Ограничьте число повторов, задайте конечный общий timeout запроса и не включайте retry для неидемпотентных операций без ключа идемпотентности. Повтор должен укладываться в бюджет времени клиента, иначе он переживёт исходный запрос и создаст лишнюю работу. Не лечите лавину увеличением пула соединений: это только переносит очередь глубже. Разбор эксплуатационных отказов: https://ftops.space/? utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=traefik-ingress-retry-storms-kak-de
