Русский

отчет о неисправности
облачный сервис
инцидент

Отчет о неисправности: Плохой шлюз

Отчет об инциденте для сбоя в работе сервиса Logto 11.01.2024 из-за неудачи при продлении домена.

Gao

Founder

1/12/2024

Хватит тратить недели на аутентификацию пользователей

Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.

Начать

Резюме

11.01.2024 сервисы Logto столкнулись с перебоем в работе, который сопровождался многочисленными ошибками 502 Bad Gateway.

Время начала: Примерно 11.01.2024 в 15:28 по UTC
Время решения: Примерно 12.01.2024 в 00:49 по UTC
Продолжительность: Примерно 9 часов
Затронутые сервисы: Сервис аутентификации Logto, Облачный сервис Logto
Уровень воздействия: Критический
Основная причина: Домен logto.app истек, и продление не было успешно завершено.

Хронология

11.01.2024 15:28 UTC Пользователь сообщает об ошибке 502 Bad Gateway при доступе к сервису аутентификации Logto.
11.01.2024 15:42 UTC Больше пользователей сообщают о той же проблеме.
11.01.2024 15:50 UTC Члены нашей команды начинают расследовать проблему и звонить другим членам команды. Поскольку для некоторых членов команды было поздно ночью, обычные звонки не были достаточно сильными, чтобы их разбудить.
12.01.2024 23:54 UTC Мы выясняем, что облачный сервис отправляет запросы к сервису аутентификации, но запрос завершился ошибкой ERR_TLS_CERT_ALTNAME_INVALID.
12.01.2024 00:36 UTC Мы очистили кэш DNS, чтобы проверить, поможет ли это. Не помогло.
12.01.2024 00:38 UTC Мы повторно выдали TLS-сертификаты, чтобы проверить, поможет ли это. Не помогло.
12.01.2024 00:45 UTC Мы заметили, что домен logto.app мог истечь. Мы проверили у регистратора доменов и обнаружили, что он не был успешно продлен, и домен истек.
12.01.2024 00:49 UTC Продление домена завершено. Сервисы постепенно возвращаются к нормальной работе.

Анализ инцидента

Что произошло?

Наши домены обычно автоматически обновляются через нашего регистратора доменов. Однако в этом случае процесс продления не удался из-за возможной неправильной конфигурации. В результате домен logto.app истек, и DNS-записи были обновлены для указания на парковочную страницу регистратора.

На данный момент сервис аутентификации остается оперативным, но большинство запросов не могут его достичь. Исключением является административный клиент Logto, который привязан к домену auth.logto.io и не затронут истечением.

В дополнение к сервису аутентификации у нас также есть облачный сервис, который управляет клиентами Logto и обслуживает консоль Logto Cloud (frontend-приложение).

Когда пользователь работает с облачной консолью, приложение непосредственно не вызывает сервис аутентификации; вместо этого оно вызывает облачный сервис для всех операций управления.

Для согласования с Logto Management API мы разработали конечную точку "прокси API управления" для делегирования запросов в сервис аутентификации. Весь поток выглядит так:

Поскольку у *.logto.app есть проблема несоответствия сертификата, облачный сервис (Node.js) отклоняет запрос и выдает ошибку.

Обычно ошибки запросов перехватываются, чтобы предотвратить сбой всего сервиса. Однако, поскольку ошибка была распространена от прокси-модуля, существующая логика обработки ошибок не смогла ее поймать, что привело к сбою сервиса.

Хотя у каждого сервиса Logto есть как минимум три реплики, все реплики легко выходят из строя из-за ошибки, происходящей почти в каждом запросе из облачной консоли. Механизму авто-восстановления требуется время, чтобы сработать, вызывая недоступность сервиса на некоторое время.

Это причина, по которой пользователи видят ошибки 502 Bad Gateway (все реплики падают). Как только облачный сервис работает, новые и повторные запросы из облачной консоли приходят, и цикл падения повторяется.

Когда облачный сервис недоступен, это также влияет на сервис аутентификации для определенных конечных точек, в основном /api/.well-known/sign-in-exp. Эта конечная точка используется для получения конфигурации опыта входа, которая включает информацию о соединителе, которую необходимо получить из облачного сервиса.

Решение

Проводить продление домена вручную.

Извлеченные уроки

Всегда настраивайте мониторинг истечения срока действия домена или покупайте на более длительный срок.
Имейте в виду, что разница в часовом поясе может вызвать задержку в реагировании на инцидент.
Убедитесь, что мониторинг охватывает все домены.
Будьте осторожны при взаимодействии с модулями, которые могут выбрасывать ошибки, чтобы гарантировать, что ошибки могут быть пойманы и правильно обработаны.

Коррективные и превентивные меры

✅ Добавить ежемесячный мониторинг для истечения срока действия доменов, когда включено автопродление.
✅ Добавить мониторинг для logto.app.
✅ Обновить логику обработки ошибок в облачном сервисе, чтобы правильно перехватывать и обрабатывать ошибки прокси.
✅ Ввести более сильные оповещения, которые могут разбудить команду для реагирования на инциденты до наличия команды SRE, охватывающей все часовые пояса.

Резюме#

Хронология#

Анализ инцидента#

Что произошло?#

Решение#

Извлеченные уроки#

Коррективные и превентивные меры#

Резюме#

Хронология#

Анализ инцидента#

Что произошло?#

Решение#

Извлеченные уроки#

Коррективные и превентивные меры#

Резюме

Хронология

Анализ инцидента

Что произошло?

Решение

Извлеченные уроки

Коррективные и превентивные меры

Резюме

Хронология

Анализ инцидента

Что произошло?

Решение

Извлеченные уроки

Коррективные и превентивные меры