---
title: "Мониторинг вывода развёртывания"
id: "582"
type: "page"
slug: "deploy-output"
published_at: "2026-06-03T14:29:15+00:00"
modified_at: "2026-06-13T00:52:52+00:00"
url: "https://pastukhov.com/code/docs/validation/deploy-output"
markdown_url: "https://pastukhov.com/code/docs/validation/deploy-output.md"
excerpt: "Мониторинг вывода развёртывания ловит ошибки runtime, которые не может валидация во время сборки. В то…"
---

# Мониторинг вывода развёртывания

[https://pastukhov.com/code/docs/validation/deploy-output.md](https://pastukhov.com/code/docs/validation/deploy-output.md)

Мониторинг вывода развёртывания ловит ошибки runtime, которые не может валидация во время сборки. В то время как сборки ловят ошибки компиляции, несоответствия типов и нарушения lint перед запуском кода, мониторинг развёртывания ловит ошибки, которые появляются только когда ваше приложение фактически обслуживает запросы — необработанные исключения, отказы подключения к базе данных, HTTP 500 ошибки и сбои запуска.

![Deploy output control](https://pastukhov.com/wp-content/uploads/2026/06/deploy-output-control.png)## Методы развёртывания

Pastukhov Code поддерживает два метода развёртывания, каждый с разными характеристиками мониторинга:

### Debug Deploy (Локальный)

Debug развёртывания запускают ваше приложение как локальный процесс. С включённым `shallowCopy` (по умолчанию), изменённые файлы копируются во временный каталог перед запуском процесса, предоставляя изоляцию от вашего исходного дерева и позволяя перестроить приложение без проблем с блокировкой файлов. Потоки вывода передаются строка за строкой через stdout/stderr, записываются немедленно в `.pastukhov/deploy/{name}.log` и транслируются в реальном времени в UI через SignalR.

- **Управление процессом** — PID-файлы отслеживают запущенные процессы. При запуске устаревшие процессы от предыдущих сессий автоматически очищаются
- **Лимит размера лога** — Логи развёртывания ограничены 500 МБ. Когда превышено, лог очищается и развёртывание перезапускается автоматически
- **Наблюдение за сборками** — Развёртывания могут следить за именами сборок. Когда все наблюдаемые сборки завершаются успешно, развёртывание перезапускается с новым кодом

### Docker Deploy (Удалённый)

Docker развёртывания отправляют ваше приложение на удалённый сервер через SSH и rsync, затем собирают и запускают его как контейнер. Процесс развёртывания выполняется как серия пронумерованных шагов, каждый зарегистрирован с stdout/stderr, и финальное состояние контейнера проверяется с помощью проверок здоровья.

**⚠️ Экспериментальная функция** — Docker Deploy ещё не тщательно протестирован. Используйте его с осторожностью и пожалуйста сообщайте о багах, если есть. Автор использует только debug развёртывания в изолированных контейнерах Docker, что легче управлять и не менее безопасно, чем Docker развёртывания.

- **SSH + rsync** — Исходные файлы передаются на удалённый сервер, исключая паттерны вроде `.git`, `node_modules` и `.pastukhov`
- **Жизненный цикл контейнера** — Вытягивает базовый образ, удаляет существующий контейнер, собирает новый образ и запускает его с настроенными портами, томами, сетями и переменными окружения
- **Проверки здоровья** — После развёртывания проверяет, что контейнер запущен и опционально проверяет endpoint здоровья через HTTP
- **Тайм-аут на команду** — Каждый шаг развёртывания имеет настраиваемый тайм-аут. Если шаг превышает его, процесс убивается

## Парсинг вывода развёртывания

Вывод runtime парсится в реальном времени с использованием `.pastukhov/deploy.parser`, который использует тот же формат блоков `[ERROR]`/`[/ERROR]`, что и парсер сборки. Паттерны покрывают общие категории ошибок runtime:

- **Необработанные исключения** — Полные стековые трассировки, начинающиеся с “Unhandled exception.”
- **Системные исключения** — Отступные стековые трассировки для .NET, Java и других фреймворков
- **Ошибки уровня лога** — Строки, начинающиеся с `crit:`, `fail:` или `err:` (формат Serilog/ILogger)
- **HTTP ошибки** — Ответы с кодом состояния 500
- **Отказы подключения** — “Connection refused”, ECONNREFUSED, тайм-ауты
- **Исключения базы данных** — SqlException, NpgsqlException с отступными стековыми трассировками
- **Отказы запуска приложения** — “Application startup exception” с продолжением строк

### Формат парсера

⚠️ Не пытайтесь редактировать файлы парсера вручную — попросите ИИ-модель сделать это за вас. Самый простой способ: выберите любой непарсенный текст в выводе развёртывания (Панель статуса или диалог развёртывания) и кликните на плавающую кнопку **Fix parser** — она отправляет выбранный текст ИИ с правильно отформатированным промптом для обновления `deploy.parser`. В качестве альтернативы, используйте `.pastukhov/README.md` как ссылку в чате.

- **Строки комментариев**, начинающиеся с `#`, игнорируются
- **Однострочные паттерны** — Регулярное выражение, которое должно точно соответствовать одной строке вывода
- **Многострочные паттерны** — Обёрнуты в `{{...}}`, соответствуют нулю или более последовательным строкам, следующим за внутренним регулярным выражением

```
# Необработанные исключения со стековыми трассировками
[ERROR]
Unhandled exception.*
{{^\s+at\s+}}              # Соответствует нулю или более строк, начинающимся с пробелов
[/ERROR]

# Уровни ошибок Serilog/ILogger
[ERROR]
(crit|fail|err):.*
[/ERROR]

# Предупреждения
[WARNING]
(warn|warning):.*
[/WARNING]
```

Парсер работает последовательно: на каждой строке вывода он пытается применить паттерны каждого блока по порядку. Когда все паттерны в блоке соответствуют последовательно, те строки извлекаются как одна ошибка, и парсер продвигается мимо них. Ранние блоки имеют приоритет — как только найдено соответствие, более поздние блоки пропускаются для тех строк.

Предупреждения парсятся аналогично — предупреждения уровня лога, уведомления об устаревании и использование устаревших API. Чтобы добавить пользовательские паттерны для специфического формата ошибок вашего приложения, попросите ИИ-модель обновить `deploy.parser`. Парсер автоматически перезагружается при сохранении.

## Отображение вывода развёртывания

Вывод развёртывания может стать очень большим — болтливое приложение или длинный процесс могут производить мегабайты данных лога. Без безопасных мер, рендеринг всего этого в браузере вызвал бы вялую прокрутку, высокое использование памяти и в конечном итоге сбои вкладок. Несколько мер применяются как на уровне сервера, так и на уровне клиента для сохранения отзывчивости UI независимо от объёма вывода.

### Меры на стороне сервера

- **Ограничение файла лога** — Логи debug развёртывания ограничены 500 МБ. Когда лимит достигнут, лог очищается и развёртывание перезапускается автоматически, предотвращая неограниченный рост диска
- **Усечение вывода** — При чтении файлов лога (например, при загрузке страницы или открытии диалога), обслуживаются только последние 100 КБ. Ранний содержимое отбрасывается из ответа с маркером усечения, поэтому браузер никогда не получает полную историю
- **Дросселирование SignalR** — Вывод в реальном времени буферизируется и транслируется с интервалами 100 мс, а не отправляется каждая отдельная строка по мере её прибытия. Это уменьшает количество сообщений SignalR и избегает затопления браузера крошечными обновлениями
- **Инкрементальная передача** — Во время активных развёртываний вывод отправляется строка за строкой по мере его производства, а не как полные снимки. Клиент добавляет новые строки к существующему буферу вместо замены всего вывода при каждом обновлении

### Меры на стороне клиента

- **Лимит встроенной панели** — Панель статуса показывает только последние 200 строк вывода развёртывания. Это сохраняет панель лёгкой и отзывчивой, даже когда полный лог намного больше
- **Лимит диалога** — Диалог вывода развёртывания показывает до 2000 строк (последняя часть лога). Это достаточно для просмотра последних ошибок и контекста без напряжения браузера
- **Лимит отправки чата** — При отправке вывода развёртывания в чат для анализа ИИ содержимое ограничивается 20 КБ. Это предотвращает чрезмерные сообщения от потребления чрезмерного контекста в разговоре
- **Инкрементальное добавление** — Клиент добавляет новые строки вывода к существующему буферу вместо замены всего вывода при каждом обновлении SignalR, минимизируя DOM-обновления и реактивные перерасчёты
- **Кэширование спарсенного вывода** — Выделения ошибок и предупреждений предварительно вычисляются в lookup map и повторно используются, поэтому парсер не пересканирует весь вывод при каждом рендеринге

## Диалог развёртывания

Диалог вывода развёртывания показывается, когда вы кликаете на имя развёртывания на Панели статуса, предоставляя три вкладки для обзора вывода развёртывания:

- **Лог** — Необработанный, нефильтрованный вывод runtime. Показывает последние 2000 строк для debug развёртываний или полный пошаговый лог для Docker развёртываний
- **Ошибки** — Спарсенные записи ошибок, выделенные красным, извлечённые из парсера развёртывания
- **Предупреждения** — Спарсенные записи предупреждений, выделенные жёлтым

Каждая вкладка имеет действия копирования и отправки в чат. Отправка ошибок развёртывания в чат обёртывает их в кодовый блок `build.log`, чтобы ИИ мог анализировать отказы runtime и предлагать исправления. Выбор текста на любой вкладке раскрывает плавающую кнопку **Fix parser** для быстрого обновления `deploy.parser` для нераспознанных форматов ошибок.

## Автоматический конвейер перезапуска

Развёртывания перезапускаются автоматически, когда все наблюдаемые сборки завершаются успешно, создавая непрерывный конвейер сборка-развёртывание-мониторинг:

1. ИИ модифицирует файлы проекта
2. Изменения файлов запускают соответствующие сборки после их настроенных задержек
3. Парсер сборки извлекает ошибки и предупреждения из вывода сборки
4. [AutoFix](/code/docs/autofix) направляет любые ошибки обратно ИИ для исправления (цикл повторяется, пока сборки не пройдут)
5. Когда все сборки проходят, служба развёртывания уведомляется и перезапускает приложение
6. Вывод развёртывания парсится в реальном времени для ошибок runtime

Этот конвейер работает без вмешательства. Вы можете мониторить его на Панели статуса или проверить позже для обзора результатов. Для debug развёртываний необязательное поле `url` в конфигурации показывает кликабельную кнопку, которая открывает развёрнутое приложение напрямую. Таким образом вам не нужно запоминать адрес или порт debug-экземпляра.

## Эффективные паттерны валидации

- **Используйте мониторинг развёртывания вместе со сборками** — Сборки ловят статические ошибки; мониторинг развёртывания ловит ошибки runtime. Оба необходимы для полного покрытия
- **Добавьте специфичные для приложения паттерны парсера** — Если ваше приложение логирует ошибки в пользовательском формате, добавьте паттерны в `deploy.parser`, чтобы они появлялись на вкладке Ошибки
- **Отправляйте ошибки runtime в чат** — Когда вы видите ошибки развёртывания, кликните Отправить, чтобы ИИ проанализировал стековую трассировку и предложил исправление
- **Мониторинг размера лога** — Логи debug развёртывания ограничены 500 МБ. Если ваше приложение очень болтливое, рассмотрите настройку уровней лога или увеличение лимита

Для полной справки по функциям развёртывания см. [Сборка и развёртывание](/code/docs/build-deploy)
. Для цикла обратной связи автоматических ошибок см. [AutoFix](/code/docs/autofix)
. Для предотвращения ручных перезапусков развёртывания см. [Хуки: Управление поведением модели](/code/docs/validation/hooks-control)
.

**[← Валидация звуковым откликом](/code/docs/validation/sound-feedback)**

**[Управление моделью и навыками →](/code/docs/validation/model-skills)**