В этом материале
HTTP 200 не определяет успех stream. Сначала задайте событие, критерий полноты и политику исключений, затем считайте good/total.
Сервис может вернуть HTTP 200, затем завершить поток ошибкой. Если SLO считает только status, такой запрос попадёт в успехи, хотя пользователь не получил полный результат. Обратный случай — клиент отменил работу по собственному решению. Его нельзя автоматически приравнивать к сбою провайдера без выбранной политики. Надёжный SLI начинается с определения наблюдаемого события и знаменателя, а не с желаемого процента на панели.
Определите границу операции
Google SRE о SLO рекомендует связывать показатели с полезным пользовательским результатом. Для streaming нужно решить, что считается одной операцией: принятый запрос, завершённая попытка или логический запрос с несколькими попытками. Эти единицы дают разные знаменатели и не должны незаметно меняться между отчётами.
Запишите момент начала учёта и область сервиса. Если запрос отклонён до генерации, он может оставаться важным для доступности, хотя не вошёл в engine queue. Исключить его из метрики допустимо только по явному определению, а не потому, что так показатель выглядит лучше.
Разделите terminal outcomes
Полезна классификация completed, failed, cancelled и incomplete, отдельно от accepted и rejected на входе. Состояния должны быть взаимоисключающими в выбранной итоговой записи. Если запрос меняет состояние, счётчик результата увеличивается один раз, а переходы сохраняются как диагностические события.
Prometheus об instrumentation подчёркивает согласованность подсчёта операций, ошибок и latency. Начатые и завершённые запросы могут расходиться в коротком окне. Поэтому denominator должен соответствовать выбранному способу измерения, иначе всплеск новых обращений будет выглядеть как изменение качества без достаточного основания.
Проверьте полноту stream
Документация OpenRouter показывает, что ошибка после committed response приходит внутри SSE и не меняет уже отправленный HTTP-статус. Это делает status-only проверку недостаточной. Нужны прикладной итог, корректное framing и ожидаемые обязательные данные конкретного endpoint.
Не требуйте одинакового terminal marker для всех API. Схема Chat Completions отличается от других интерфейсов. В SLI-записи должны сохраняться endpoint и версия проверки, чтобы миграция не сделала все новые события неизвестными либо автоматически успешными из-за слишком общего fallback в parser.
Задайте политику отмен
Разберите клиентскую отмену, превышение серверного deadline и принудительную остановку экземпляра. Внешне соединение может закрыться во всех трёх случаях, но ответственность и полезность различаются. Если причину нельзя установить, используйте отдельный unknown outcome вместо удобного предположения о действиях клиента.
Частичный текст может быть полезен приложению, но это не делает операцию полной автоматически. Продуктовая политика определяет, включается ли такой исход в good events. Сохраните правило и примеры рядом с метрикой, чтобы инженер и владелец продукта одинаково понимали результат.
Испытайте знаменатель на fixtures
Создайте небольшой набор: полный успех, отказ допуска, ошибка до headers, ошибка внутри stream, отмена и обрыв без итога. Для каждого задайте expected outcome и участие в denominator. Затем проверьте, что итоговые счётчики совпадают с вручную подготовленной таблицей.
Связанные материалы — ошибки stream и отчёт о работе. Итогом является проверяемое определение SLI, а не обещание конкретного SLA. Без такой семантики даже точная арифметика good/total может измерять удобную внутреннюю активность вместо пользовательского результата.