Proxy Monitor: Журналы запросов, фильтрация, восстановление деталей и экспорт
Вы уже запустили локальный обратный прокси, но как только возникают 401/429/500, прерывания потока или «вдруг изменилась учётная запись/модель», устранение неполадок легко превращается в слепые догадки.
В этом уроке будет рассказано только об одном: использовать Proxy Monitor чтобы превратить каждый вызов в «воспроизводимые доказательства», чтобы вы знали, откуда пришёл запрос, на какую конечную точку он попал, какой учётной записью и моделью использовался, а также примерно сколько было потрачено токенов.
Что вы сможете сделать после изучения
- Открыть/приостановить запись на странице
/monitor, и понять, повлияет ли это на Token Stats - Использовать окно поиска, быструю фильтрацию, фильтрацию учётных записей, чтобы быстро найти одну запись запроса
- В модальном окне деталей просмотреть и скопировать Request/Response payload, чтобы проанализировать причину сбоя
- Знать место сохранения данных Proxy Monitor (
proxy_logs.db) и поведение очистки - Понять реальные границы возможностей «экспорт журналов» текущей версии (GUI vs команды бэкенда)
Ваша текущая проблема
- Вы видите только «вызов неуспешен/тайм-аут», но не знаете, сбой произошёл на вышестоящем уровне, в прокси или в конфигурации клиента
- Вы подозреваете, что сработала маршрутизация моделей или ротация учётных записей, но нет цепочки доказательств
- Вы хотите воспроизвести полный payload запроса (особенно потоковый/Thinking), но в журналах его не видно
Когда использовать этот подход
- Вы устраняете: сбой аутентификации 401, ограничение частоты 429, ошибка вышестоящего провайдера 5xx, прерывание потока
- Вы хотите подтвердить: какой учётной записью была использована конкретная запись запроса (
X-Account-Email) - Вы настраиваете стратегию маршрутизации моделей, хотите подтвердить «имя модели клиента → сопоставленная физическая модель»
🎒 Подготовка перед началом
Предварительные требования
Proxy Monitor записывает «запросы, полученные службой обратного прокси». Поэтому сначала пройдите:
- Служба обратного прокси запущена и может достигать
/healthz - Вы знаете текущий Base URL и порт обратного прокси
Если ещё не пройдено, сначала посмотрите Запуск локального обратного прокси и подключение первого клиента.
Что такое Proxy Monitor?
Proxy Monitor — это встроенная «панель журналов запросов» Antigravity Tools. Каждый раз, когда запрос попадает в локальный обратный прокси, он записывает время, путь, код состояния, затраченное время, модель и протокол, и по возможности извлекает потребление токенов из ответа; вы также можете открыть отдельную запись для просмотра payload запроса и ответа, чтобы проанализировать причину сбоя и результат выбора маршрутизации/учётной записи.
Место сохранения данных
Журналы Proxy Monitor записываются в SQLite в каталоге данных: proxy_logs.db. Как найти каталог данных и выполнить резервное копирование, рекомендуется сначала пересмотреть Первый запуск: Каталог данных, журналы, трей и автозапуск.
Основная идея: 6 полей, за которыми нужно следить
В одной записи Proxy Monitor (структура ProxyRequestLog на стороне бэкенда) самые полезные — это следующие поля:
| Поле | На какой вопрос оно отвечает |
|---|---|
status | Успешен или неуспешен этот запрос (200-399 против остальных) |
url / method | На какую конечную точку вы действительно попали (например, /v1/messages, /v1/chat/completions) |
protocol | Это протокол OpenAI / Claude(Anthropic) / Gemini |
account_email | Какой учётной записью в конечном итоге использовался этот запрос (из заголовка ответа X-Account-Email) |
model / mapped_model | Было ли имя модели, запрошенное клиентом, «маршрутизировано/сопоставлено» с другой моделью |
input_tokens / output_tokens | Потребление токенов этого запроса (можно извлечь, только если есть) |
Сначала используйте «сводку», при необходимости откройте «детали»
На странице списка отображается только сводка (без request/response body), открывать одну запись, чтобы загрузить полные детали с бэкенда, чтобы избежать однократного получения слишком больших полей списком.
Следуйте за мной: выполните один вызов, чтобы пройти «замкнутый цикл мониторинга»
Шаг 1: Сначала создайте запрос, который «вы точно знаете, что появится»
Почему Proxy Monitor записывает только запросы, полученные службой обратного прокси. Сначала самым простым запросом подтвердите, есть ли запись, затем можно говорить о фильтрации и деталях.
## 1) Проверка работоспособности (конечно существующая конечная точка)
curl "http://127.0.0.1:PORT/healthz"
## 2) Ещё раз запросите models (если вы включили аутентификацию, не забудьте добавить заголовок)
curl "http://127.0.0.1:PORT/v1/models"## 1) Проверка работоспособности (конечно существующая конечная точка)
curl "http://127.0.0.1:PORT/healthz"
## 2) Ещё раз запросите models (если вы включили аутентификацию, не забудьте добавить заголовок)
curl "http://127.0.0.1:PORT/v1/models"Вы должны увидеть: терминал возвращает {"status":"ok"} (или похожий JSON), а также ответ /v1/models (успех или 401, всё равно).
Шаг 2: Откройте страницу Monitor и подтвердите «статус записи»
Почему У Proxy Monitor есть переключатель «запись/пауза». Вам нужно сначала подтвердить текущий статус, иначе вы можете постоянно отправлять запросы, но список всегда пустой.
В Antigravity Tools откройте в боковой панели API мониторинг (маршрут /monitor).
В верхней части страницы будет кнопка с точкой:
┌───────────────────────────────────────────┐
│ ● Запись [Поиск] [Обновить] [Очистить] │
└───────────────────────────────────────────┘Если вы видите «На паузе», нажмите один раз, чтобы переключиться на «Запись».
Вы должны увидеть: статус кнопки становится «Запись»; в списке начинают появляться только что сделанные записи запросов.
Шаг 3: Используйте «поиск + быстрая фильтрация», чтобы найти одну запись
Почему При реальном устранении неполадок вы обычно помните только фрагмент: в пути есть messages, или код состояния 401, или в имени модели есть gemini. Окно поиска как раз предназначено для такой памяти.
Поиск Proxy Monitor будет использовать ваш ввод как «ключевое слово нечёткого поиска», и на стороне бэкенда с помощью SQL LIKE сопоставлять эти поля:
urlmethodmodelstatusaccount_email
Вы можете попробовать несколько типичных ключевых слов:
healthzmodels401(если вы как раз создали 401)
Также можно нажать кнопку «Быстрая фильтрация»: Только ошибки / Chat / Gemini / Claude / Генерация изображений.
Вы должны увидеть: в списке остаются только ожидаемые вами запросы.
Шаг 4: Откройте детали, чтобы восстановить «payload запроса + payload ответа»
Почему Списка достаточно, чтобы ответить на «что произошло». Чтобы ответить на «почему», обычно нужно увидеть полный payload запроса/ответа.
Откройте любую запись, появится модальное окно деталей. Вы можете сосредоточиться на проверке:
Протокол(OpenAI/Claude/Gemini)Используемая модельиСопоставленная модельИспользуемая учётная записьПотребление токенов (ввод/вывод)
Затем используйте кнопку для копирования:
Payload запроса (Request)Payload ответа (Response)
Вы должны увидеть: в деталях есть два блока JSON (или текст) для предпросмотра; после копирования вы можете вставить в рабочий билет/заметку для анализа.
Шаг 5: Когда вам нужно «воспроизвести с чистого листа», очистите журналы
Почему При устранении неполадок страшнее всего «старые данные мешают суждению». После очистки воспроизведите один раз, успех/неуспех будет очень ясным.
Нажмите кнопку «Очистить» в верхней части, появится диалоговое окно подтверждения.
Это необратимая операция
Очистка удалит все записи в proxy_logs.db.
Вы должны увидеть: после подтверждения список очищается, статистика возвращается к 0.
Контрольная точка ✅
- [ ] Вы можете видеть в
/monitorтолько что сделанные вами записи/healthzили/v1/models - [ ] Вы можете отфильтровать определённую запись с помощью окна поиска (например, ввести
healthz) - [ ] Вы можете открыть одну запись, чтобы просмотреть payload запроса/ответа, и скопировать его
- [ ] Вы знаете, что очистка журналов напрямую удалит все исторические записи
Напоминания о возможных ошибках
| Сценарий | Как вы можете понять (❌) | Фактическое поведение (✓) |
|---|---|---|
| "На паузе" = полностью отсутствуют накладные расходы мониторинга | Считаете, что после паузы запросы не будут анализироваться | Пауза влияет только на «записывать ли в журнал Proxy Monitor». Однако анализ запроса/ответа (включая анализ поточных данных SSE) всё ещё происходит, просто проанализированные данные не сохраняются. Token Stats всё ещё будет записывать (независимо от того, включён ли мониторинг). |
| Журналы двоичных/больших пакетов пусты | Считаете, что мониторинг сломан | Двоичные запросы/ответы будут отображаться как [Binary Request Data] / [Binary Response Data]. Тело ответа свыше 100MB будет помечено как [Response too large (>100MB)]; тело запроса свыше ограничения не записывается. |
| Хотите использовать Monitor, чтобы найти «кто инициировал запрос» | Считаете, что можно追溯到 имя процесса клиента | Monitor записывает информацию на уровне HTTP (метод/путь/модель/учётная запись), не включает «имя процесса вызывающей стороны». Вам нужно объединить это с собственными журналами клиента или с сетевым перехватом системы, чтобы определить источник. |
| Данные Token Stats аномальны при включённом мониторинге | Считаете, что статистика неверна | При включённом мониторинге данные Token Stats могут быть записаны дважды (один раз в начале функции мониторинга, один раз при асинхронной записи в базу данных). Это поведение исходного кода текущей версии. |
Экспорт и долгосрочное сохранение: сначала чётко определите границы возможностей
1) Что можно сделать в текущем GUI
В текущем UI Monitor (ProxyMonitor.tsx) вы можете:
- Искать/фильтровать/просматривать страницы
- Открывать детали для просмотра и копирования payload
- Очистить все журналы
Но не найдено кнопки «экспорт» (в исходном коде не видно соответствующего UI).
2) Какие возможности экспорта уже есть на стороне бэкенда (подходит для вторичной разработки)
Команды Tauri на стороне бэкенда предоставляют два способа экспорта:
export_proxy_logs(file_path): экспортировать все журналы из базы данных в файл JSONexport_proxy_logs_json(file_path, json_data): красиво записать переданный вами массив JSON в файл (требуется, чтобы ввод был форматом массива)
Если вы хотите выполнить вторичную разработку GUI или написать собственный скрипт вызова, можно напрямую использовать эти команды.
3) Самый простой «экспорт»: напрямую создать резервную копию proxy_logs.db
Так как Proxy Monitor по сути является SQLite, вы также можете рассматривать proxy_logs.db как «пакет доказательств устранения неполадок» и создавать резервные копии вместе (например, вместе с token_stats.db). Расположение каталога данных см. Первый запуск.
Рекомендуемая литература
- Хотите разобраться в маршрутизации моделей: Маршрутизация моделей: Пользовательские маппинги, приоритеты подстановок и предустановленные стратегии
- Хотите устранить проблемы аутентификации: 401/Сбой аутентификации: auth_mode, совместимость заголовков и контрольный список конфигурации клиента
- Хотите объединить Monitor со статистикой затрат: в следующем разделе будет рассказано о Token Stats (
token_stats.db)
Краткое содержание урока
- Ценность Proxy Monitor — «воспроизводимость»: запись кода состояния/пути/протокола/учётной записи/маршрутизации моделей/потребления токенов и предоставление деталей запросов
- Поиск и быстрая фильтрация — это вход в устранение неполадок: сначала сузьте диапазон, затем откройте детали для просмотра payload
- Очистка журналов — необратимая операция; экспорт в данный момент больше склонен к «возможностям вторичной разработки» и «резервному копированию файла базы данных»
Предварительный просмотр следующего урока
Следующий урок мы изучим Token Stats: Статистические показатели с точки зрения затрат и интерпретация графиков, превращая «чувство, что это дорого» в количественную оптимизацию.
Приложение: Ссылка на исходный код
Нажмите, чтобы развернуть и просмотреть местоположение исходного кода
Дата обновления: 2026-01-23
| Функция | Путь к файлу | Номер строки |
|---|---|---|
| Вход на страницу Monitor (монтирование ProxyMonitor) | src/pages/Monitor.tsx | 1-12 |
| UI Monitor: таблица/фильтрация/модальное окно деталей | src/components/proxy/ProxyMonitor.tsx | 13-713 |
| UI: чтение конфигурации и синхронизация enable_logging | src/components/proxy/ProxyMonitor.tsx | 174-243 |
| UI: переключение записи (запись в config + set_proxy_monitor_enabled) | src/components/proxy/ProxyMonitor.tsx | 254-267 |
| UI: прослушивание событий в реальном времени (proxy://request) и дедупликация | src/components/proxy/ProxyMonitor.tsx | 273-355 |
| UI: очистка журналов (clear_proxy_logs) | src/components/proxy/ProxyMonitor.tsx | 389-403 |
| UI: загрузка одной детали (get_proxy_log_detail) | src/components/proxy/ProxyMonitor.tsx | 505-519 |
| Промежуточное ПО мониторинга: захват запроса/ответа, анализ токенов, запись в monitor | src-tauri/src/proxy/middleware/monitor.rs | 13-337 |
| ProxyMonitor: переключатель enabled, запись в БД, отправка событий | src-tauri/src/proxy/monitor.rs | 33-194 |
| Серверная сторона: монтирование промежуточного ПО мониторинга (layer) | src-tauri/src/proxy/server.rs | 183-194 |
| Команды Tauri: get/count/filter/detail/clear/export | src-tauri/src/commands/proxy.rs | 180-314 |
| SQLite: путь к proxy_logs.db, структура таблицы и SQL фильтрации | src-tauri/src/modules/proxy_db.rs | 1-416 |
| Описание дизайна мониторинга (может отличаться от реализации, см. исходный код) | docs/proxy-monitor-technical.md | 1-53 |
Ключевые константы:
MAX_REQUEST_LOG_SIZE = 100 * 1024 * 1024: максимальный размер тела запроса, который может прочитать промежуточное ПО мониторинга (превышение приведёт к сбою чтения)MAX_RESPONSE_LOG_SIZE = 100 * 1024 * 1024: максимальный размер тела ответа, который может прочитать промежуточное ПО мониторинга (используется для больших ответов, таких как изображения)
Ключевые функции/команды:
monitor_middleware(...): на уровне HTTP собирает запрос и ответ, и вызываетmonitor.log_request(...)ProxyMonitor::log_request(...): запись в память + SQLite, и отправка сводки через событиеproxy://requestget_proxy_logs_count_filtered(filter, errors_only)/get_proxy_logs_filtered(...): фильтрация и разбиение на страницы в спискеget_proxy_log_detail(log_id): загрузка полного тела запроса/ответа одной записи журналаexport_proxy_logs(file_path): экспорт всех журналов в файл JSON (в текущем UI кнопка не открыта)