Registry: the "last result" column now also shows, per level (egress,
ingress), how many of the recorded checks of the latest cycle succeeded, split
by check family (tcp-22 and tcp-443 are both "tcp"). One grouped query per
chunk of addresses; new fields last_cycle_id, egress, ingress in
GET /admin/registry; the dashboard renders them under the verdict.
Verdict integrity (migration 0010):
- the prober is handed an address once per site and attempt, not on every
poll, so results are no longer overwritten by later probe rounds;
- UpsertCheckIfOpen refuses writes once the address is aggregating or has its
verdict, or for an older attempt; senders get {"ok":true,"ignored":N} and a
result_dropped event is recorded;
- the checking window counts from checking_started_at, not from assigned_at;
- checks.recorded_at (server clock) and checks.after_verdict (flag for rows
written after the verdict in existing data);
- the verdict rule is a pure function (computeVerdict) and the aggregated
event carries the egress/ingress check counts.
Rebuilt bin/control-api and bin/admin-dashboard to match. Plans and summaries
are in docs/changes; README, API, USAGE, DASHBOARD and DIAGRAMS are updated.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
Реестр: уровни Egress и Ingress — итог
План: 2026-10-03_16-24_registry-egress-ingress-levels-plan.md.
Что сделано
В колонке «Последний результат» таблицы «Реестр» под вердиктом показаны два уровня последнего цикла:
Egress и Ingress в виде «успешно из всего» (например, «5 из 5»), а под каждым — то же по типам проверок
(https, icmp, ssh, tcp, tls; новый тип появляется сам).
Правила
- Цикл — наибольший
cycle_idс записанными проверками адреса. - Уровень по
checks.source:egress→ Egress,inbound-site-N→ Ingress (все площадки вместе). Прочие источники не считаются. - Тип —
check_typeдо первого дефиса:tcp-22иtcp-443→tcp. - «Всего» — число записанных проверок. Вердикт (
last_result) учитывает ещё и недостающие результаты, поэтому может быть хуже, чем «N из M». В таблице это отмечено подсказкой.
Изменённые файлы
internal/db/models.go—CheckLevel,CheckFamily, константы уровней.internal/db/queries_registry.go—TypeStat,LevelResult, поляLastCycleID/Egress/IngressвRegistrySummary;fillRegistryLevels— один сгруппированный запрос на порцию до 500 адресов вместо запроса на адрес (используютListRegistry,ListRegistryPage,GetRegistryByAddress). Миграция не нужна, запрос идёт поidx_checks_registry_cycle.internal/httpapi/dto_admin.go,handlers_registry.go— поляlast_cycle_id,egress,ingress(только добавление, старые клиенты не ломаются).internal/dashboard/dto.go,render.go(функция шаблонаdict),templates/registry.html,static/dashboard.css— отображение.- Документация:
docs/API.md,docs/USAGE.md,docs/DASHBOARD.md,README.md.
Не менялось
Фильтр по вердикту (lastResultCond), расчёт last_result, страница деталей /registry/{ip}, схема БД.
Тесты и проверка
- Новые:
internal/db/queries_registry_levels_test.go(разбор уровней и типов, нулевые счётчики, последний цикл, несколько адресов, после удаления строки очереди),TestRegistryLevelsQueryUsesIndex(план запроса без полного перебораchecks),TestAdminRegistryLevels(API),TestRegistryPageShowsEgressIngressLevels(дашборд). TestScaleSmoke6440дополнен проверками (30 на адрес): страница из 100 адресов — около 0,18 с.go build ./... && go vet ./... && go test ./...— без ошибок.- Не проверено вручную на локальном стенде (
scripts/run-local-e2e.sh) и в браузере: вид колонки на узком экране проверен только по разметке.
Ограничения
- Пока цикл идёт, счётчики отражают частично пришедшие проверки.
- Фильтра и сортировки по уровням нет — отдельное изменение, если понадобится для аналитики.