Закрыл пробел функциональности: httptap теперь не просто показывает, где деградировал latency, а может фейлить pipeline на нарушении бюджета. Один флаг в команде httptap и latency становится частью CI-gate'а.
Уложились -> exit 0. Деградировали -> exit 4 + полный отчет видно какая фаза убила SLO.
6 сценариев применения (примеры примитивны, важна идея)
1. Smoke-тест после деплоя в
- run: httptap --slo total=2000,tls=300,ttfb=800 https://staging.example.com/
2. Kubernetes readiness probe
Pod принимает трафик, пока реально не отвечает за требуемое время.
3. Synthetic monitoring cron
On duty просыпается когда latency деградировала, до того, как пользователи начнут жаловаться.
4. Замерили нормальную p95-latency один раз (скажем, 450ms), вшили как --slo total=450 в CI и теперь любой PR, который замедлил endpoint, краснеет автоматически, до того как медленный код доедет до прода.
5. Canary-сравнение по регионам
Мгновенно видно, какой регион отваливается от SLO.
6. Dependency health в CI
Когда ваш сервис зависит от внешнего API, то добавьте httptap --slo total=X этого API в мониторинг. Падение upstream'а вы заметите по алертам мониторинга еще до того, как он повлияет на прод.
Что ещe приехало с релизом
• Per-phase budgets --slo dns=50,connect=100,tls=300,ttfb=500,total=1000. Не только total.
• Точная диагностика: total: 723.4ms > 500ms (+223.4ms), видно не просто деградировали, а на сколько именно.
• Совместимость с httpstat: exit 4 и токены slo=pass/fail специально совпадают.
Зачем вам это, если у вас есть APM?
APM показывает что было. SLO-gate блокирует чтобы не стало. Прод не падает из-за того, что метрика красная в APM, прод падает, потому что медленный код доехал до прод-релиза или есть медленные зависимости API. --slo в CI это linting для latency.
PR: https://github.com/ozeranskii/httptap/pull/118
Документация: https://docs.httptap.dev/usage/slo/
Больше постов у меня в Telegram-канале: https://t.me/sergeiozeranskii или через поиск в Telegram по запросу «Сергей Озеранский».