Files
SQS-service/doc/thinking/nubes-network-bug-plan-v4-opus.md
T

133 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# План: доказать, что таймауты — в пути/шлюзе Nubes — v4 (ОПУС 4.8)
> ✅ **ПОМЕТКА: план от Claude Opus 4.8** (пользователь передал ответ Опуса,
> который изучил репозиторий и три предыдущих плана).
> Сохранено 2026-08-15. Ниже — план Опуса + ответы основного агента на его
> уточняющие вопросы.
## TL;DR
Доказательство — изоляцией слоёв. «Виновата платформа» = таймауты
воспроизводятся БЕЗ нашего кода (port-forward чист, echo/сырой TCP таймаутит)
+ tcpdump с клиента ловит потерю сегмента, когда nginx/под ответили за
миллисекунды.
**Два РАЗНЫХ явления — раздельно:**
- **A. Большие POST ~51с** — локализовано: MSS=1448 → пакет 1488 > underlay
1450 → дроп при DF, PMTUD мёртв. Осталось зафиксировать порог ping-зондом.
- **B. Малые тела 512б, ~1 таймаут/37с** — MTU не объясняет. Регулярность =
таймер (шлюз VIP / ARP-флап kube-vip / conntrack GC). Главная нераскрытая часть.
## Ответы Опуса на вопросы
1. **Echo vs сырой TCP.** Сырой TCP недостаточен (только SYN/ACK; потери в
фазе данных). Самое дешёвое доказательство невиновности приложения —
`kubectl port-forward` мимо шлюза, а не echo. Echo — позже, только если
port-forward+логи не закрыли вопрос (он внутри кластера, а подозрение на шлюзе).
2. **Поймать таймаут.** tcpdump на клиенте, корреляция по TCP seq/ack: ретрансмиты
SYN → потеря на установлении; тишина после ACK → потеря после nginx; ICMP
frag-needed → PMTUD; кто и через сколько шлёт RST → чей таймер; интервал
между таймаутами → подтвердить ~37с.
3. **Через kubectl.** nginx access-log request_time/upstream_response_time:
499+большой request_time = клиент ушёл; 200+малый upstream без ответа клиенту
= потеря nginx↔клиент; записи нет = потеря до nginx. cilium monitor --type
drop — на cilium-ПОДЕ нужной ноды (не operator). externalTrafficPolicy
Cluster/Local.
## Шаги (дешевле → дороже)
- **Фаза 0 (бесплатно):** nginx access-log за прошлый тест → логи kube-vip
(флапы) → тикет Nubes (A и B раздельно).
- **Фаза 1 (клиент, ~30 мин):** PMTUD-зонд ping -M do (fallback mtr --tcp) →
tcpdump + повтор теста через long_compare_local.py с логом timestamp каждого
таймаута → контрольный канал YMQ во всех прогонах.
- **Фаза 2 (kubectl, без деплоя):** port-forward ПЕРВЫМ (невиновность приложения)
→ cilium monitor drop параллельно → проверка externalTrafficPolicy/nodePort.
- **Фаза 3 (echo, если 0–2 не хватило):** Go echo без ingress на NodePort →
таймаутит → nginx и код исключены → потом echo через ingress (изоляция nginx).
- **Фаза 4 (тикет):** одновременный tcpdump + nginx-log + cilium monitor,
корреляция по seq → pcap+логи+ping в тикет.
**Что считается доказательством:** echo-NodePort таймаутит тем же паттерном →
nginx+код исключены; nginx 200/upstream<100мс без ответа клиенту → потеря
nginx↔клиент; pcap показывает недоставленный сегмент; ping-порог → MTU;
cilium drop → внутри кластера; port-forward чист + внешний IP таймаутит →
приложение невиновно; стабильный интервал ~37с → таймер шлюза.
---
## Уточнения Опуса и ответы основного агента
1. **Второй клиент с другого ISP?** НЕТ. В распоряжении только ВМ
(5.172.178.213), но она рядом с платформой — с неё таймаутов нет, как
«второй клиент из другого сегмента» не подходит. Частичная замена уже есть:
контрольный канал YMQ с той же локали — 1 ошибка на 959 при 49 таймаутах на
Nubes (виноват локальный интернет → YMQ страдал бы так же). Полагаемся на
YMQ-канал; второй ISP — если появится доступ к VPS.
2. **Debug-под с NET_RAW?** Не проверяли; платформа managed, ноды недоступны,
привилегии урезаны — с высокой вероятностью запрещено. Под — alpine без
NET_RAW, серверный tcpdump не получится. Ограничиваемся nginx access-log +
cilium monitor + echo А/Б. Возможность kubectl debug проверяется одной
попыткой.
3. **Echo сразу?** НЕТ — только если фазы 0–2 не дадут однозначного ответа.
Доп. риск: новый NodePort для echo на managed может быть недоступен.
## Поправка основного агента
port-forward идёт через API-сервер (не тот сетевой путь) — он доказывает
только невиновность приложения, а не вину шлюза. Использовать формулировку
Опуса из таблицы доказательств (она корректна).
---
## ФИНАЛ (обновление Опуса с зафиксированными решениями, 2026-08-15)
**TL;DR.** Изоляция слоёв. «Виновата платформа» = два несмешиваемых вывода:
(1) приложение невиновно — port-forward через API-сервер чист (иной путь,
шлюз этим НЕ обвиняется); (2) виноват путь/шлюз — echo/сырой TCP таймаутит тем
же паттерном И tcpdump с клиента ловит потерю сегмента, когда nginx/под
ответили за миллисекунды.
**Зафиксированные решения:**
1. Второго ISP нет; ВМ рядом с Nubes → не «другой сегмент». Опора — контрольный
канал YMQ (49 таймаутов Nubes vs 1/959 YMQ уже исключают локальный интернет).
2. Серверный tcpdump практически недоступен (managed, exec только в alpine-под
без NET_RAW). kubectl debug с NET_RAW — одна проверочная попытка. Замена:
nginx access-log + cilium monitor + echo А/Б.
3. Echo — не сразу, только если фазы 0–2 неоднозначны; доп. риск — новый
NodePort для echo может быть закрыт на managed.
4. port-forward доказывает ТОЛЬКО невиновность приложения, НЕ вину шлюза.
**Шаги (дешевле → дороже):**
- Фаза 0 (бесплатно): nginx access-log за прошлый тест → логи kube-vip →
тикет Nubes (A и B раздельно).
- Фаза 1 (клиент, ~30 мин): PMTUD-зонд ping -M do (fallback mtr --tcp) →
tcpdump + long_compare_local.py с timestamp каждого таймаута → YMQ-канал
во всех прогонах.
- Фаза 2 (kubectl): port-forward первым → cilium monitor drop параллельно →
externalTrafficPolicy/nodePort. Одна попытка kubectl debug NET_RAW.
- Фаза 3 (echo, если 0–2 не хватило): Go echo без ingress на NodePort →
затем через ingress (изоляция nginx).
- Фаза 4 (тикет): tcpdump клиента + nginx-log + cilium monitor, корреляция
по seq → pcap+логи+ping.
---
## Сравнение ответов ЧЕТЫРЁХ агентов на один промпт (основной агент)
Условия НЕ равны: Соннет читал планы Flash и Pro; Опус читал все три плана и
весь репозиторий. Это «накопленный контекст», а не чистый тест моделей.
| | Flash | Pro | Sonnet | Opus |
|---|---|---|---|---|
| Вклад | первым заметил: 512б-таймауты не объясняются MTU | инструменты изоляции: PMTU-зонд, второй ISP, port-forward, таблица доказательств | концептуальная структура: A/B, 51с=экспонента RTO, 1/37с=таймер, port-forward первым | интеграция: синтез всего + факты репозитория + фиксация решений |
| Ошибки | cilium через operator; echo переоценён | «51с = прикладной таймер» (хуже экспоненты RTO) | нет | нет |
| Итог | черновик | сильный методолог | лучший аналитик | лучший интегратор |
Вывод основного агента: ключевые идеи распределились по всем четырём —
даже слабый Flash увидел главное (второе явление), Pro дал инструменты,
Sonnet построил структуру, Opus всё собрал. Конвергенция четырёх моделей на
одной цепочке (nginx-логи → PMTU → tcpdump → port-forward → cilium → echo) —
признак устойчивости плана. Плюс поправки основного агента приняты Опуса
в финал (port-forward). Итоговый план — продукт всех участников, исполнять.