Наблюдаемость Phoenix LLM: Доказать, что следы переживают перезапуск

Феникс может показывать полный след, пока его собственный слой доказательств всё ещё хрупок. Доступная страница доказывает, что веб процесс отвечает прямо сейчас. Да, так и не Доказать, что старый след пережил перезапуск, что сборщик возобновил употребление или что эффективная политика хранения покрывает период, в течение которого ваша команда расследует инциденты. Разумный вариант по умолчанию — упражнение с двумя канарейками для перезапуска: 1. запросить одну трассировку без содержания, созданную до перезапуска; 2. перезапустить сервис Phoenix без изменения кода приложения; 3. запросить тот же трекер снова; 4. излучать и задавать запрос к второму трассёру после перезапуска; 5. Сравните возраст наблюдения и эффективное удержание с явными ограничениями. Старая канарейка проверяет настойчивость. Новые тесты на канарейках возобновили употребление пищи. Тебе нужны оба варианта. Если существует только старый след, хранение может быть в порядке, пока сбор нарушен. Если существует только новая трасса, сервер возвращается на пустое или неожиданное хранилище. Относитесь к Фениксу как к трём слоям доказательств Архитектурная документация Phoenix разделяет систему на веб интерфейс, сборник трасс и бэкенд SQL базы данных. Это различие имеет значение при постановке диагноза: интерфейс может отвечать, когда загрузка OTLP не работает; Коллектор может принять соединение, в то время как трасса никогда не становится доступной для запроса; база данных может быть доступна, пока контейнер указывает на новый рабочий каталог SQLite; Все три могут быть открыты, пока работа по удержанию убирает улики раньше, чем ожидает процесс инцидента. Phoenix поддерживает SQLite и PostgreSQL. Текущая документация позиционирует SQLite для локальной разработки и однопользовательских развертываний, с данными ниже ~/.phoenix/ или PHOENIX WORKING DIR . PostgreSQL является задокументированным выбором для многопользовательских и высокодоступных развертываний. Это не правило, что SQLite всегда нездоров. Один разработчик может запустить надёжный локальный экземпляр с монтированным томом. Провал — оставлять настойчивость неявной. The официальный гид по Docker показывает два контракта напрямую: Для PostgreSQL читает Phoenix PHOENIX SQL DATABASE URL ; в руководстве документируется PostgreSQL 14 или новее. Сохраняйте значение соединения в своей секретной системе, а не в медицинском чеке. Чек требует только класса бэкенда, непрозрачного идентификатора развертывания и результата запросов канарейки. Закрепление изображения — это отдельный элемент управления. latest Может быть удобно для одноразового локального пробного периода, но при перезапуске можно одновременно менять приложение и его требования к базе данных. Запишите неизменный дайджест изображения или явную версию перед тренировкой. Успешный рестарт на фоне неизвестного изображения не является воспроизводимым доказательством. Создайте одну квитанцию с перезапуском без контента Выбирайте канарейку с тем же коллектором и маршрутизацией проекта, что и трафик агента, который вам интересен. Не вставляйте в канарейку настоящий запрос, модельный ответ, аргумент инструмента, учетные данные или идентификатор клиента. Достаточно случайного запуска и временных меток. Задокументированная конечная точка REST в Phoenix может Трассировки списка для проекта с ограничениями по времени старта и опциональными интервалами. Используйте метод аутентификации вашего развертывания, но не допускайте значения авторизации в историю оболочки и сохранённый вывод. Например, установите значения маршрутизации без секретов и запросите узкое временное окно: Поискайте локальный ответ на непрозрачный канарейка trace id ; Не экспортировать тело ответа как общую телеметрию. Если попросите include spans=true , увеличивается размер ответа и задержка запроса, поэтому ссылка Phoenix API рекомендует лениво загружать детали span. Для тренировки на перезагрузку нужна идентификация и время отслеживания, а не содержимое запросов. Минимальный чек может выглядеть так: effectiveRetentionDays это означает политику, связанную с реальным проектом, а не просто деплоймент по умолчанию. Феникс По умолчанию сохраняет данные бесконечно, представлено как ноль дней в своей стандартной политике. Администратор может назначать политики, основанные на времени или подсчёте следов, для отдельных проектов. Стандартная настройка времени развертывания может обновлять новые проекты без изменения существующих, специфичных для проекта. Вот почему намерение конфигурации и эффективное состояние проекта — это разные доказательства. Сравните удержание с вашим рабочим процессом. Если инцидент остаётся незамеченным 14 дней, семидневное окно отслеживания ухудшается, даже если все текущие следы присутствуют. Тридцать дней тоже не являются по своей сути здоровыми; Она здорова только относительно окна обзора, бюджета хранения и решений по управлению данными. Запускайте сверло, не скрывая прерывание Используйте обычную операцию перезапуска во время выполнения. Не совмещайте первое упражнение с обновлением Phoenix, миграцией хранилища, реконфигурацией коллекторов или выпуском приложений. Суть в том, чтобы изолировать персистентность и возобновлённое употребление. Непосредственно перед перезапуском: 1. запишите закреплённую версию или дайджест изображения; 2. подтвердить предполагаемый бэкэнд базы данных и идентификацию надёжного тома или базы данных; 3. фиксировать эффективную политику удержания проектов; 4. выпустить первую канарейку по обычному инструментальному пути; 5. Задайте запрос и сохраните только булевый результат, идентификатор отслеживания и временные метки. После перезапуска: 1. ждать задокументированного поведения службы в готовности, а не использовать произвольный сон; 2. запросить тот же трек до перезапуска; 3. издай другую канарейку после рестарта; 4. запросить новую трассу по тому же маршруту проекта; 5. Поставьте штамп на чеке и оцените его до истечения лимита свежести. Сопутствующий матч к этой статье применяет пятиминутный лимит наблюдения и повторяет девять состояний: Результат таков: 9/9 cases pass . Две конфигурации считаются здоровыми: закрепленный PostgreSQL для многопользовательского развертывания и закреплённый SQLite с надёжным объемом для одного пользователя. Оставшиеся светильники специально производят evidence lost , ingestion failed , waiting , needs human , uncertain , или degraded . Приоритет решения имеет значение: Доказательства Вердикт Решение оператора Миграция идёт по плану waiting Наблюдайте за ограниченной эксплуатацией технического обслуживания; Не называйте это неудачей агента Миграция провалилась needs human Остановите автоматическое восстановление и проверьте границу между базой данных и версией Наблюдение старше предела свежести uncertain Запустите запрос заново перед действиями Старые следы в полисе исчезли evidence lost Сначала сохраняйте текущее хранилище и диагностируйте идентичность монтировки/базы данных Старые следы остались, но новые отсутствовали ingestion failed Проверьте доступность коллекторов, путь экспортера, аутентификацию и маршрутизацию проекта Оба следа существуют, но удержание слишком короткое degraded Согласование эффективной политики проекта с обзором инцидентов Оба следа существуют, улики свежие, а управляющие элементы совпадают healthy Слой улик прошёл через это ограниченное сверло Такой порядок предотвращает маскировку фактической потери данных, появляющееся предупреждением о конфигурации. Незакрепленное изображение важно, но отсутствующий внутри полиса трек — это первый инцидент. Вывести миграции за пределы слепого восстановления Phoenix сообщает, что новые крупные версии могут запускать миграции баз данных во время запуска. Также предупреждается, что откат образа приложения назад даёт не Автоматически понижайте схему базы данных. Это делает «перезапуск старого контейнера» небезопасным универсальным правилом восстановления после неудачного крупного апгрейда. Для Kubernetes Руководство по миграции Рекомендуется запускать миграции в initContainer Поэтому они завершаются до того, как основной контейнер проходит проверку живого характера. Также объясняется, что создание индекса в PostgreSQL может блокировать записи. PHOENIX MIGRATE INDEX CONCURRENTLY=true Избегает удержания блокировки записи, но задокументированный компромисс — миграция примерно в два три раза медленнее, и новый под всё равно ждёт завершения. Переведите эти механики в состояния: Миграция, проходящая в пределах одобренного окна обслуживания, — это waiting ; запрос, выполненный при неизвестном состоянии миграции, выглядит uncertain ; Неудачная миграция, которая могла продвинуться по схеме, — это needs human ; Автоматический откат возможен только при явной поддержке плана совместимости базы данных. Это то же различие, которое нужно надёжным операциям агента в других местах: активность — это не прогресс, ожидание не застревает, а выполнение команды — не желаемый результат. Знайте, чего этот чек не доказывает Проходящий чек о перезагрузке защищает один из путей доказательств. Это не доказывает, что все маршруты модели инструментированы, каждый отсек семантически корректен, что резервное копие можно восстановить или агент доставляет желаемый результат. Он также не валидирует содержание оценки LLM. Это отдельные тесты. Чек специально не содержит контента. Это снижает экспозицию, но также означает, что семантические ошибки требуют ограниченной оценки или человеческой проверки. Рассматривайте недоступные доказательства как недоступные; Не заполняйте его здоровым предположением. Предполагаемая модель здоровья Sidewisp связана с актуальностью доказательств, достижимостью, полезным прогрессом, результатами и безопасными границами восстановления. Операционная схема здесь соответствует этой территории, но это не претензия на внедренную интеграцию. Sidewisp в настоящее время не подключается к Phoenix и не отслеживает это развертывание. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Если вы определяете первый медицинский контракт для стека агентов, храните этот квитанцию о перезапуске рядом с квитанцией о результатах агента. Один из них показывает, сохранились ли диагностические доказательства. Другая подсказывает, действительно ли работа работала.