Моя команда и я занимаемся этим уже 4 полных дня, анализируя каждый доступный нам журнал, Azure Application Insights, назовите его, мы проанализировали его. И мы не можем понять причину этой проблемы.
У нас есть клиент, который интегрирован с нашим API для выполнения поисковых вызовов, и они жалуются на периодические, но постоянные ошибки 502.3 Bad Gateway.
Вот поток нашей архитектуры:
Все ресурсы находятся в Azure. Конечная точка, которую вызывают наши клиенты, - это. NET Framework 4.7 Web App Service в Azure, которая действует как обработчик без сохранения состояния для всех вызовов и ответов API.
Это приложение API отправляет вызовы в Azure Service Fabri c Cluster - этот кластер балансирует нагрузку на входе и распределяет вызовы API для нашего приложения службы поиска. Затем приложение службы поиска генерирует запрос ElasticSearch из вызова API и отправляет этот запрос в наш кластер ElasticSearch.
ElasticSearch затем отправляет результаты обратно в Service Fabri c, и оттуда процесс переворачивается до тех пор, пока результаты не будут отправлены обратно клиенту из конечной точки API.
Что может отделить наш процесс из типичного API является то, что наша полезная нагрузка ответа может быть относительно большой, основываясь на поиске. В среднем за последние несколько дней полезная нагрузка одного ответа может составлять от 6 до 12 МБ. Наши поиски просто возвращают много данных из ElasticSearch. В любом случае обычный поиск обычно выполняется и возвращается через 15 секунд или меньше. На данный момент мы уже увеличили наше время ожидания до 5 минут, просто чтобы попытаться обработать происходящее и уменьшить количество ошибок времени ожидания, поскольку их поиск занимает так много времени. Однако мы увеличили время ожидания с помощью следующего кода в Startup.cs:
services.AddSingleton<HttpClient>(s => {
return new HttpClient() { Timeout = TimeSpan.FromSeconds(300) };
});
В некоторых местах я читал, что у вас есть , чтобы сделать это в файле web.config в отличие от здесь, или, по крайней мере, в дополнение к этому. Не уверен, правда ли это?
Итак, клиент, получивший ошибки 502,3, значительно увеличил объемы, которые он нам отправляет за последнюю неделю, но мы считаем, что мы полностью масштабированы, чтобы справиться с этим. Они все еще пытаются решить эту проблему, но после многих дней исследований я начинаю задумываться, действительно ли проблема на их стороне. Возможно ли, что они не оборудованы, чтобы принять увеличенную полезную нагрузку на их стороне. Может ли быть так, что их архитектура интеграции недостаточно масштабирована, чтобы получить полезную нагрузку от увеличенных объемов? Когда мы наблюдаем использование наших ресурсов (CPU / RAM / IO) во всех вышеперечисленных приложениях, они все нормальные - все ниже 50%. Это также заставляет меня задаться вопросом, если это на их стороне.
Я знаю, что это немного субъективный вопрос, но я надеюсь на некоторую информацию от кого-то, кто мог испытать это раньше, но что еще более важно, от кого-то, кто имеет опыт работы с Net приложением API в Azure, которое возвращает большие наборы данных в своих ответах.
Любые блоки кода нашего приложения API или снимки экрана из Application Insights доступны для публикации по запросу - просто не уверен, что именно кто-то еще хотел бы увидеть, пока я набираю это.