#google-cloud-run
#google-cloud-run
Вопрос:
Мы расследуем проблему с развернутой облачной службой запуска, когда запросы, отправленные в службу, иногда завершаются с StatusCodeError: 500 ошибкой, в то время как журнал указанных запросов не отображается при облачном запуске.
Обработанные запросы обычно выдают две строки журнала с подробным описанием запроса, маршрута и кода выхода ( POST 200 on https://service-name.a.run.app/route/... )
- Один с именем журнала
projects/XXX/logs/run.googleapis.com/stdoutсоздается нашим приложением для регистрации выполнения каждого запроса - Один с именем журнала
projects/XXX/logs/run.googleapis.com/requestsавтоматически создается облачным запуском при каждом запросе
Когда происходит инцидент, ни один из них не регистрируется. Клиент (работающий в модуле gke в том же проекте) имеет единственный журнал неудачных запросов со следующим сообщением:
StatusCodeError: 500 - "n<html><head>n<meta http-equiv="content-type" content="text/html;charset=utf-8">n<title>500 Server Error</title>n</head>n<body text=#000000 bgcolor=#ffffff>n<h1>Error: Server Error</h1>n<h2>The server encountered an error and could not complete your request.<p>Please try again in 30 seconds.</h2>n<h2></h2>n</body></html>n"
Приблизительная временная шкала последнего инцидента:
- 14:41 — Служба обслуживает запросы, как и ожидалось, каждый раз создавая обе строки журнала
- с 14:44 до 14:56 — Журналы облачного запуска пусты, каждый запрос, отправленный в службу (~ 30), выдает сообщение об ошибке 500
- 14:56 — Облачный запуск завершает текущий запущенный экземпляр контейнера (например, после некоторого бездействия), который правильно регистрируется приложением (
[INFO] Handling signal: term) - 14:58 — Облачный запуск создает экземпляр нового экземпляра контейнера и начинает обслуживать входящие запросы (которые обычно регистрируются)
Отсутствие журналов во время инцидента затрудняет расследование его причины, и на данном этапе мы были бы благодарны за любую информацию.
У нашего сервиса есть еще одна известная проблема, которая может быть или не быть связана. Служба предназначена для предотвращения множественных реплик, поскольку одна из них должна быть способна обрабатывать нагрузку и обслуживать одновременные запросы (одновременность облачного запуска = 80), но имеет относительно длительное время холодного запуска (~ 30 секунд). Это приводит к 429 ошибкам, когда поступает всплеск запросов, когда реплика недоступна (из-за жесткого ограничения параллелизма облачного запуска до 1 во время холодного запуска). Эта проблема была несколько смягчена, разрешив некоторую репликацию (в настоящее время maxScale = 3), поскольку каждая реплика может приостановить запрос во время холодного запуска, но для правильной обработки потребуется некоторая работа на стороне клиента (простые повторные попытки после холодного запуска).
Комментарии:
1. Можете ли вы поделиться своим кодом и как вы регистрируетесь?
2. К сожалению, сам код является частным. Это приложение python gunicorn, выводимое как через стандартную печать для целей отладки, так и
loggingчерез пакет для строки журнала, представленной в сообщении. Обратите внимание, что вторая строка журнала генерируется облачным запуском, а не нашим приложением, и также пропадает во время инцидента.3. Конечно, ваш код является частным! Но можете ли вы очистить его и получить минимально воспроизводимый пример? Ваша проблема странная, потому что, даже если есть проблема с вашими журналами, журналы платформы облачного запуска должны продолжать работать, это не зависит от вашего кода!
4. Видите ли вы «журналы запросов», которые облачный запуск обычно регистрирует для любого контейнера при получении запроса на указанные инциденты?
5. @guillaumeblaquiere Я не фокусировался на коде приложения, потому что, насколько я знаю, он не выполняется при возникновении инцидента (не обслуживает запрос и не выводит журнал). Минимальным примером может быть приложение gunicorn с режимом ожидания (30) при инициализации и режимом ожидания (0,1) при обслуживании запросов… Как вы говорите, мне показалось, что проблема не зависит от самого приложения…
Ответ №1:
Я нашел эту ЯМУ, которая описывает вышеупомянутое поведение. Похоже, это происходит потому, что часть облачного запуска считает, что уже есть подготовленные экземпляры, обрабатывающие трафик, но их нет. В настоящее время эта проблема решается внутри компании, но на данный момент нет ETA для исправления.
Текущий обходной путь — установить максимальное количество экземпляров не менее 4.
Комментарии:
1. Спасибо за эту ссылку! Я попробую увеличить maxScale до 4 и посмотрю, произойдет ли это снова.
2. Нет проблем, не стесняйтесь принять ответ, если вы убедитесь, что проблема устранена. Таким образом, другие пользователи с той же проблемой будут лучше осведомлены об обходном пути, пока проблема будет устранена.