ipify-проба отвечает на «узел жив вообще», а сбор Авито с 02.08 (#2637) ходит через
сайдкар браузером: camoufox стартует С ЭТИМ прокси, потом навигация. Это разные
свойства узла, и до сих пор они писались в ОДИН счётчик: боевой /fetch репортил
mark_health(ok=False), а следующая (≤30 мин) успешная ipify-проба делала
consecutive_fails=0 + enabled=true. Дешёвая проба стирала вердикт дорогого тракта —
узел, мёртвый для браузера, выходил из карантина каждые полчаса и снова забирал прогон.
Разведено тем же приёмом, что #2711 (scrape_runs.ban_kind) — поле РЯДОМ, а не новое
значение существующего флага. Миграция 228: browser_fail_streak / browser_unfit_since /
browser_check_at. Успешная ipify их не трогает, провал браузерной пробы не трогает
enabled/consecutive_fails.
Проба: POST /fetch (одна навигация) на robots.txt Авито через сайдкар с прокси узла в
теле. /fetch, а не /fetch-json — последний сначала грузит главную площадки. source=
'generic', чтобы не забирать лок боевого инстанса и не релончить его.
Такт решён замером на проде: одна браузерная проба = 8.3с и один запуск camoufox,
боевая нагрузка сайдкара = ~1000 /fetch и ~190 запусков camoufox в сутки. Каждым
прогоном healthcheck по 4 узлам это +192 запуска (удвоение), поэтому такт 360 мин:
+16 запусков (+8%). Неподтверждённый провал такт не двигает — второе подтверждение
приходит на следующем прогоне (~30 мин), не через 6 часов.
Пометка НЕ выводит узел из пула (пул 4 узла, #2638): acquire отдаёт его последним
(ORDER BY) и громко логирует, если пригодных не осталось. Путь обратно — успешная
браузерная проба (browser_refit). Отказ, принадлежащий сайдкару или площадке, узлу не
засчитывается — иначе одна упавшая общая зависимость пометила бы весь пул (#2686).
Refs #2723
