В этом материале
Один запрос должен иметь одну итоговую запись жизненного цикла; позднее usage уточняет данные, а не создаёт второе завершение.
Почему журналы расходятся
Прокси видит закрытие соединения, движок сообщает завершение генерации, а сборщик получает usage позже. Если каждый компонент самостоятельно увеличивает счётчик успешных запросов, один пользовательский вызов превращается в несколько результатов. Обратная ситуация возникает при потере последнего события: текст уже получен, но журнал считает запрос активным. Поэтому итоговая запись должна описывать жизненный цикл конкретной попытки, а не количество полученных сообщений. Отдельно сохраняют идентификатор логического запроса, идентификатор попытки и источник наблюдения. Повтор запроса через другой движок получает собственную попытку, даже если внешняя операция осталась прежней.
Выбрать владельца перехода
Полезная внутренняя модель содержит состояния accepted, running и terminal с результатом completed, failed либо cancelled. Это проектируемая модель сервиса, а не универсальная схема OpenRouter. Один компонент владеет окончательным переходом; остальные передают факты. В рекомендациях Prometheus разделяются счётчики завершений и измерения текущей работы. Практически это означает увеличение итогового счётчика только после успешной фиксации перехода. Повторная доставка события с тем же ключом не должна повторять изменение. События после terminal могут дополнить запись, но не вернуть её в running без явно описанной корректировки.
Отделить результат от полноты учёта
Минимальная запись включает outcome, основание классификации, время принятия и завершения, факт передачи содержимого, статус полноты usage и версии контракта. Отсутствующий usage нельзя молча заменить нулём. В описании streaming OpenRouter учётные данные приходят отдельным финальным кадром; его обработка должна дополнять учёт, а не повторно завершать генерацию. Поле полноты позволяет отличить измеренное нулевое значение от неизвестного. Также имеет смысл сохранять исходные значения поставщика отдельно от нормализованных, чтобы позднее объяснить расхождение без восстановления текста пользовательского запроса из журналов.
Проверить гонку завершения и отмены
Диагностический сценарий воспроизводит порядок: клиент отключился, движок завершил работу, затем пришёл usage. Сначала фиксируют, что именно означает cancelled: намерение клиента, подтверждение движка или отсутствие результата на клиентской стороне. Это разные наблюдения. Метаданные генерации OpenRouter полезны как пример внешней модели с дополнительными признаками, но не определяют внутренние переходы произвольного провайдера. Тест повторяет события в другом порядке и доставляет финальное сообщение дважды. Итог должен сохранять один результат попытки, объяснимое основание выбора и отдельно отражать несовпадение пользовательского и серверного исхода.
Сверять записи с агрегатами
Периодическая сверка сравнивает число принятых попыток с активными и итоговыми записями за согласованное окно. Запоздавшие сообщения учитывают через установленную задержку сверки, иначе обычный транспортный лаг выглядит потерей данных. Расхождения отправляют в отдельный список с идентификаторами, не в высококардинальные метки метрик. Полезны разбор usage и модель учёта токенов. Такая сверка проверяет непротиворечивость конкретного журнала. Она не доказывает доставку ответа клиенту, точность тарификации сторонней платформы или отсутствие ошибок токенизации; для каждого утверждения нужен самостоятельный источник истины и отдельная проверка.