Логи приложения в облаке: как найти причину сбоя на DADA Cloud

Сначала фаза приложения, потом логи

Операция со статусом Committed значит только одно: описание приложения принято и записано. Контейнер при этом может падать и подниматься снова. Поэтому первый взгляд идёт на фазу приложения, и открываете логи, когда фаза остаётся ниже Healthy.

В консоли фаза видна на странице приложения. Агент читает её вызовом listApps.

Логи приложения: окно, поиск, Live

Блок «Логи» стоит на странице приложения. Он открывается на окне в 24 часа, а выбор окна даёт 15 минут, час, 6 часов, сутки и 7 суток. Строка поиска принимает произвольный текст: впишите error, имя пользователя или идентификатор запроса.

Кнопка Live обновляет выдачу каждые 5 секунд и смотрит на последние 15 минут. Включайте её, когда сами повторяете сбойный запрос и ждёте, что появится в логе. Кнопка «Скачать .log» отдаёт текстовый файл с найденными строками, новые сверху.

Логи приложения на VM или в Compose-стеке ищутся тем же способом, только по имени сервера: в запросе указывают vm в паре с именем сервера. Каждый сервис из Compose-стека становится отдельным приложением со своими логами, о чём подробнее в руководстве по Compose в облаке.

Логи сборки идут отдельно

Если приложение собирается из репозитория, упасть может сама сборка, и тогда в логах приложения пусто: запускать там нечего. Лог сборки открывается на странице деплоя: нажмите на сборку в списке, и строки пойдут прямо во время работы сборщика.

Пока сборка идёт, на странице есть кнопка отмены. Кнопки «Повторить» нет. Чтобы собрать заново, нажмите Deploy ещё раз или отправьте коммит: сборка возьмёт текущий HEAD ветки и не повторит упавший коммит. Подробности в разделе про сборки.

Как разобрать сбой по порядку

Порядок короткий, и каждый шаг отсекает половину причин.

Начните с окна в 15 минут: в нём лежит последний запуск контейнера. Если строки обрываются на полуслове, расширьте окно и найдите первую строку с error: она стоит раньше остальных и обычно называет причину. Если после старта в логах тишина, проверьте, что код пишет в стандартный вывод и слушает порт из настроек приложения.

Пустое окно значит одно из двух: код ничего не пишет, или вы смотрите не то приложение. Имя в запросе проверяется на принадлежность проекту, поэтому опечатка не откроет чужие логи, а вернёт отказ.

Те же логи для агента

Агент по MCP читает логи теми же правами, что и вы. Инструмент searchLogs требует имя приложения или сервера и принимает текст для поиска, окно и число строк. Окна те же, что в консоли.

$ listApps(projectId, envId)# читаем фазу приложения$ searchLogs(projectId, app="shop-api", since="1h", size=200)$ searchLogs(projectId, app="shop-api", q="error", since="6h")$ getBuild(projectId, buildId)# только если причина похожа на сборку

На платформе есть готовый промпт diagnose-app: он идёт по этой последовательности и ничего не меняет без вашего согласия. Его удобно отдать агенту, который уже начал гадать. Как подключить агента и какие у него права, описано в руководстве про управление облаком из Claude Code и Cursor, а рецепты вызовов лежат в справочнике по MCP.

Частые вопросы

Почему в логах приложения пусто, а приложение не работает?

Чаще всего упала сборка и контейнер не создан, поэтому смотрите лог сборки на странице деплоя. Если сборка прошла, проверьте, что код пишет в стандартный вывод и что выбрано то приложение.

Как скачать логи в файл?

Кнопка «Скачать .log» в блоке логов отдаёт файл с теми же окном и фильтром, что вы выбрали, до 10 000 строк, новые сверху. Тот же файл отдаёт API по адресу /projects/{id}/logs/download.

Можно ли дать агенту читать логи без права менять приложение?

Да. Поиск логов только читает данные. Сам searchLogs помечен как read-only и ничего не меняет, а права агента ограничивает грант, как описано в руководстве про MCP.

Нужно ли подключать мониторинг, чтобы видеть логи?

Для логов приложения нет: блок «Логи» есть на странице приложения. Мониторинг с метриками и алертами подключается отдельно и вручную, он описан в документации по мониторингу.