Nail/IoT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: HISTORY — длительный wss-тест: обрыв на 173с (лимит соединений платформы ~150с?), план диагностики

Browse Source
This commit is contained in:
“Naeel”
2026-08-16 08:29:55 +04:00
parent a857753cfd
commit 11352a4fb3
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
HISTORY/2026-08-16-session-log.md
+35
View File
@@ -169,3 +169,38 @@ WebSocket upgrade — wss для устройств возможен, путь
- скрипт `/tmp/ws-stability-test.py`: соединение 10 мин, echo каждые 10с, - скрипт `/tmp/ws-stability-test.py`: соединение 10 мин, echo каждые 10с,
ping/pong обе стороны (клиент ping_interval=25, сервер ping 20с), ping/pong обе стороны (клиент ping_interval=25, сервер ping 20с),
лог с таймстемпами. Результат будет дописан ниже. лог с таймстемпами. Результат будет дописан ниже.
### РЕЗУЛЬТАТ длительного теста (16.08, обрыв на 173.1с) — ПРОБЛЕМА
Соединение оборвалось на **173.1с** (08:29:03 по `date` = 07:29 GMT+03).
Хронология (полный лог выше в терминале, 08:26:10–08:29:03):
| t (с) | Событие |
|---|---|
| 0.4 | CONNECTED |
| 10–120 | echo 1..12 — все возвращаются ✓ |
| 20.4–140.4 | PING сервера каждые 20с — доходят ✓ |
| 50.5–125.5 | PONG сервера на ping клиента каждые 25с — доходят ✓ |
| ~150 | ping клиента (25с-каденс) — БЕЗ pong; echo 16–17 пропали; PING сервера 160.4 не пришёл |
| 170.1 | клиент: ERROR ping/pong timed out |
| 173.1 | CLOSED; итог sent=17, echoed=15 |
**Анализ:** первые 140с — идеально (двусторонний обмен, ping/pong обе стороны).
Деградация началась ~145–155с, обрыв ~150–173с. Похоже на платформенный
**лимит жизни соединения на внешнем пути ~150с** (перекликается с квирком
shared-sqs: «GET /ui через ingress не закрывает соединение ~150с»).
**Что это значит:** если лимит подтвердится — wss-устройства будут отваливаться
каждые ~2.5–3 мин независимо от MQTT keepalive (обрыв при активном трафике,
не по idle). Миграция на контейнер НЕ отменяется, но перед стартом нужно
выяснить и снять лимит (тикет Nubes).
**Следующие диагностические шаги (предложены, ждут «делай»):**
1. Повторить тест 3 раза — воспроизводимость и точное время обрыва.
2. Логи пода пробника на платформе (`kubectl logs` на ВМ) — что видит сервер
в момент обрыва (read error / ping error).
3. Тест WS изнутри кластера на внутренний `containerk8s.<uuid>.svc.cluster.local:8080`
— если держится >10 мин: обрыв на внешнем шлюзе/ingress; если тоже рвётся:
проблема ближе к поду.
4. Держать обычное HTTP-соединение через ingress >150с — сравнение с WS.
5. По результатам — тикет в Nubes (лимит соединений на ingress/шлюзе).