Я пытался спросить на StackOverflow, но безуспешно, поэтому надеюсь, что это сообщество поможет мне отследить эту проблему. У нас есть веб-приложение, к которому многим людям в компании нужен доступ. Иногда веб-приложение, похоже, перестает отвечать на запросы.
Например, если страница индекса ресурсов (например, таблица заказов) пытается обновить список ресурсов во время сбоя, она запросит данные через API, но запрос через некоторое время молча откажет. Приложение становится недоступным из-за длительных запросов практически ко всем в компании одновременно в течение нескольких минут, но доступ к приложению во время этого сбоя/медленного периода из другой сети (например, мобильные данные) работает. Другие веб-сайты также, похоже, не затронуты в этот период.
Вкладка сети браузера показывает запросы как неудачные через 20-40 секунд, но нет кода статуса. Текст статуса при выборе запроса - failed net::ERR_CONNECTION_TIMED_OUT. Похоже, что если не щелкнуть запрос во время его обработки и открыть подробности позже, вкладка времени скажет, что он застрял на фазе Stalled. Но если открыть подробности запроса во время его обработки, вместо этого будет сказано, что он застрял на фазе Initial connection. Это делает вкладку времени подробностей запроса ненадежной, поскольку то, что она показывает, похоже, зависит от того, проверял ли я запрос во время его обработки или нет.
Настройка сервера:
Сервер, похоже, не показывает большой перегрузки в это время - максимум 30% использования ЦП/памяти. Сервер работает на дроплете Digital Ocean и использует nginx для размещения приложения Laravel.
Что я рассматривал/пробовал: Подключения компании происходят с того же IP. Но хотя само приложение и имеет включенное регулирование, оно привязано к идентификатору пользователя, возвращает сообщение об ошибке «Слишком много попыток» и код статуса 429. Если это случай регулирования, то оно не должно быть на уровне приложения, поскольку регулирование там распознается по сообщению об ошибке и коду статуса.
Я пытался проверить конфигурации nginx, чтобы найти включенное ограничение, но, похоже, оно не включено явно, если только nginx не применяет какое-то значение по умолчанию. Но даже если включено, nginx также должен возвращать 429/503, насколько я понимаю из того, что я прочитал. Но в нашем случае, похоже, никаких ошибок или кодов не возвращается.
Я пытался связаться и с DigitalOcean, и с интернет-провайдером компании, и они оба утверждают, что не используют никаких механизмов дросселирования/ограничения скорости. Администратор сети компании также говорит, что такой механизм не работает.
Что я могу сделать для отладки / исследования источника проблемы? Насколько я понимаю, проблема может быть где угодно: от конфигурации nginx до регулирования со стороны провайдера ISP. Я думаю, что это какое-то регулирование на данный момент, но может я что-то упускаю.
решение1
Используйте диагностические инструменты для выявления узких мест или ошибок в различных частях вашей инфраструктуры (nginx, Digital Ocean, внутренняя сеть). Записывайте данные во время сбоя для последующего анализа.
# nginx logs
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
# Network diagnostics (replace x.x.x.x with server IP)
traceroute x.x.x.x
mtr --report --report-cycles=10 x.x.x.x
# Laravel logs
tail -f /path/to/laravel/storage/logs/laravel.log
# Digital Ocean droplet metrics
# Check droplet metrics via Digital Ocean dashboard
Это поможет вам определить, связана ли проблема с настройкой nginx, дроплетом Digital Ocean, внутренней сетью или чем-то еще. Журналы и сетевая диагностика могут предоставить подсказки.
Ответить на комментарий
• Чтобы проверить, применяются ли с помощью tcкоманды какие-либо правила формирования или регулирования трафика, которые могут влиять на поток сетевого трафика:
# Display all the traffic control (qdisc) settings on all interfaces:
tc qdisc show dev [interface-name]
# Example for eth0 interface:
tc qdisc show dev eth0
Если применяются особые правила управления трафиком, они будут перечислены здесь. Их можно проанализировать дополнительно, чтобы определить, способствуют ли они сообщенным тайм-аутам.