【问题标题】:azure webapps 404 error天蓝色的 webapps 404 错误
【发布时间】:2018-05-19 01:40:19
【问题描述】:

我在 Spring Boot(REST 服务)中开发了 Web 应用程序,该应用程序部署在 Azure webapps(Azure 应用程序服务)上。我的计划是标准:1 小。

应用程序自 2 周以来一直运行顺利。突然间,今天,应用程序崩溃了。调用这些 REST 服务的消费者应用程序开始遇到 404 错误(源服务器没有找到目标资源的当前表示,或者它不愿意透露存在)

当我检查日志时,我没有发现任何会导致整个应用程序崩溃的根本原因。这是第二次发生,这一次我也无法找到根本原因(内存使用率/CPU 使用率似乎很好)。 “始终开启”设置已开启。

我有以下问题:1) 根本原因可能是什么?有没有办法找到它?

2) 有没有办法(在 azure webapps 中)知道应用程序何时出现故障并自动缩放? (我已经为 CPU 使用和内存使用设置了自动缩放规则,但这没有帮助)。

【问题讨论】:

    标签: azure-web-app-service azure-app-service-plans azure-app-service-envrmnt


    【解决方案1】:

    一些想法:

    1. 如果这是一项关键服务,您需要运行 Web 应用的两个实例,即使您没有负载来证明第二个实例的合理性。第二种情况是出于可靠性目的。

    2. 您得到的是 404 而不是 50x 的事实让我认为这不是问题,因为您的服务器太忙并且由于 CPU 利用率、http 队列长度等资源不足而放弃等。

    检查故障排除的地方:

    1. 在 Azure 门户中的 Web 应用管理边栏选项卡上,转到诊断日志菜单项。打开应用程序日志记录、Web 服务器日志记录、详细的错误消息和失败的请求跟踪。

    2. 完成上一步后,您将能够转到诊断和解决问题菜单选项并查看失败的请求跟踪日志。您还可以浏览 Web 服务器日志和应用程序日志。我发现使用 Visual Studio 最容易做到这一点。

    3. 为了好玩,还要检查诊断和解决问题下的每个实例的指标。在您报告的 404 问题期间检查所有类别。这将让您检查 CPU 使用率、内存使用率、线程数、HTTP 队列长度等条件。

    【讨论】:

    • 虽然这个问题是由于西欧地区的Azure中断而发生的,但您的回答是最正确的故障排除方法。我已经启动了两个 webapp 实例,只是为了防止这种情况再次发生。感谢您的详细回答。干杯!!
    • 很高兴知道。尽管如果您在同一个应用服务计划下有两个实例(始终在同一个区域中),一个区域中的问题仍然会破坏您的服务。为了实现高可用性,请考虑使用流量管理器,它可以检测到端点已关闭并将流量重新路由到不同区域的热备用。
    • 嗯。好点子。实际上,中断与存储有关。由于 Webapp 的两个实例将共享相同的存储空间,因此拥有两个实例会有所帮助。我应该考虑一下:(。无论如何,我会研究你在回答中提到的其他措施。
    【解决方案2】:

    报告了 Azure 中断(一个月内发生了两次)。他们说他们正在解决这个问题,上面提到的问题是由西欧地区的停电引起的。

    【讨论】:

    • 我完全忘了提到这一点。如果 Web 应用非常重要,请考虑使用流量管理器,它可以让您检测端点是否关闭,然后自动将流量重定向到另一个区域的热备用。
    猜你喜欢
    • 2015-11-20
    • 2019-02-16
    • 1970-01-01
    • 2015-03-07
    • 2014-10-04
    • 1970-01-01
    • 2021-06-19
    • 2014-03-30
    • 1970-01-01
    相关资源
    最近更新 更多