В этом материале
Синтетическая генерация проверяет выбранный внешний путь; её бюджет и результат нужно отделять от health probes и пользовательского SLO.
Выбрать конкретный внешний путь
Liveness отвечает на вопрос о жизнеспособности процесса, readiness — о готовности получать работу, а synthetic probe выполняет ограниченный пользовательский сценарий через внешний endpoint. Его цель может состоять в проверке DNS, TLS, авторизации, маршрута и завершения короткого ответа. Один запрос не исследует все модели и регионы одновременно. Поэтому manifest проверки перечисляет выбранный endpoint, модель, режим ответа и ожидаемые свойства. Нельзя незаметно заменять тяжёлую рабочую нагрузку слишком простым запросом и затем считать результат доказательством её доступности. При этом synthetic probe не должен становиться настолько большим, что сам заметно меняет состояние очереди и измеряемого сервиса.
Задать бюджет до запуска
Фиксируют максимальный вход, предел вывода, длительность попытки, частоту и общее число одновременно активных проверок. Параметры OpenRouter помогают сверить публичную семантику ограничений генерации; лимит не следует интерпретировать как точный объём реально полученного текста. Для разных моделей учитывают особенности вывода и reasoning, не выбирая заведомо неподходящий предел. Повторы получают общий бюджет, иначе одна неудачная проверка способна породить цепочку дополнительных генераций. Если предыдущая попытка ещё активна, следующую пропускают или классифицируют отдельно по заранее заданному правилу. Пропуск из-за исчерпанного бюджета должен быть виден в отчёте, а не превращаться в успешное наблюдение.
Проверять структуру и завершение
Критерии могут включать допустимый HTTP ответ, корректный envelope, наличие ожидаемого содержимого и terminal signal. Для streaming отдельно проверяют завершение чтения и прикладное завершение, не ограничиваясь первым кадром. Дословное совпадение ответа обычно слишком хрупко; достаточно заранее выбранного проверяемого свойства для конкретного сценария. В практиках Prometheus полезно разделение количества попыток, ошибок и длительности. Секрет авторизации не сохраняют в результате, а payload делают синтетическим. Исходная ошибка остаётся доступной для диагностики с безопасной редакцией данных. Обобщённый флаг failed без стадии отказа затрудняет различение ошибки сети, неверных credentials и неготовой модели.
Не подменять пользовательский SLO
Руководство Google SRE по SLO связывает индикатор с определёнными событиями и знаменателем. Синтетическая выборка является отдельным источником наблюдений: её частота, длина запросов и маршруты отличаются от пользовательского трафика. Успешная короткая генерация не доказывает доступность длинного контекста или tool calling. Если пользовательский error rate растёт, а probe зелёный, проверяют покрытие сценария и сегменты трафика, а не объявляют тревогу ложной. Если падает только probe, исследуют его credentials, окружение и лимиты. Эта развилка позволяет сохранить пользу проверки, не приписывая ей свойства полной картины качества сервиса под реальной нагрузкой.
Сохранить компактный результат
Запись содержит идентификатор сценария, версии, стадию отказа, время выполнения, фактическое использование и причину прекращения повторов. Полезны health и readiness vLLM и проверки пилота. Генерацию запускают по отдельному расписанию, а сбор метрик читает уже сохранённый результат; тяжёлый запрос на каждый scrape способен сам создать нагрузку. Заключение ограничивается выбранным сценарием и окном наблюдения. После изменения маршрута, модели или схемы проверку пересматривают. Стабильный зелёный график имеет смысл только тогда, когда ясно, какую часть внешнего контракта проверяет каждый его образец и какие пути остаются вне покрытия.