间歇性 Microsoft Azure 网站访问失败答案

【问题标题】：Intermittent Microsoft Azure Web Site access failure间歇性 Microsoft Azure 网站访问失败
【发布时间】：2013-11-21 16:41:57
【问题描述】：

我有许多小型 MVC 应用程序部署为 Microsoft Windows Azure 网站。这已经工作了几个月。

昨天我推出了一个新的，部署并不起眼，一切正常。但几个小时后，该网站无法访问。症状是，当浏览器尝试导航到该站点的 URL 时，它会尝试加载几分钟，然后放弃一个完全空白的页面。

我尝试停止并重新启动站点，它运行了一次，但几分钟后症状又出现了。然后我尝试停止重启，还是不行。

我将相同的应用程序部署到另外三个 URL。同样，在部署时，它们都可以正常工作，但是，它们在未来的某个时间间隔会失败。他们似乎不是一次都失败了。有时重新启动站点会解决问题，有时则不会。

重要提示：如果我等待一段时间，该网站可能会自行重新开始运行。

但是，部署四个版本的应用程序以便我们的用户可以在主版本不工作时转到备用版本并不是最佳选择。

关于我如何调试这个有什么智慧的话吗？

附加信息 2013 年 11 月 25 日：当站点出现故障时，IIS 日志会显示 500 或 502 内部服务错误。我们自己的 MVC 代码永远不会被命中，甚至 app_start 也不会。

【问题讨论】：

我看到了同样的问题。我在 azure 中运行一个网站，有时我开始在网络服务器日志中看到 500 和 502 错误。当它收到这些错误时，它甚至从未到达我的 webapi 代码，因为我在应用程序日志中什么也看不到。有没有人弄清楚是什么导致了天蓝色？

【解决方案1】：

你可以从检查日志和远程调试开始

应用程序是否在本地运行？

【讨论】：

应用程序在本地运行良好。在 azure 下交付时，也可以正常工作。我可以锻炼它们——一旦我在 Azure 上对 MVC 应用程序进行了会话，它就永远不会在工作时退出。只有当我离开一段时间后（可能是会话过期）回来时，才不会提供该应用程序。我去看看远程调试思路。
调试器很酷，我喜欢它，但它并不能帮助我解决这个问题。我自己的代码永远不会受到攻击...当站点出现故障时，IIS 日志会显示 500 或 502 内部服务错误。

【解决方案2】：

可能不是同一个问题，但我们的 Azure 实例有时会收到死亡的蓝色问号作为状态。

我们发现的原因是微软会不时对实例进行升级。如果您在云服务/角色中只有一个实例，那么他们会不时进行维护，在此期间它将死。

我已经在他们的支持下确认了这一点。

据我所知，解决这个问题的唯一方法是创建两个实例。然后 Microsoft 保证约 99% 的可用性。

当然，我也向他们确认，这意味着成本是两倍。 =/

【讨论】：

我们在租金较低的共享 Azure 网站空间中工作，因此至少目前我们无法访问 RDP 的 VM。如果我们继续遇到这种问题，我们可能需要改变它，但我们不需要共享环境中不存在的任何功能，并且享受（直到我们遇到这样的错误）不负责IT 方面....

【解决方案3】：

首先，您应该始终使用多个升级域运行您的 Web 角色的多个实例。这可以在服务定义 (CSDEF) 中进行配置。没有这个，您就不会从 Microsoft 获得 SLA，因此您不能真正抱怨 VM 出现故障。

其次，要弄清楚这些盒子可能发生了什么，您应该拥有两个日志（我的偏好是使用页 blob 或表存储来滚动我自己的日志），并且您应该始终拥有对预生产的 RDP 访问权限环境（如果您不太关心安全性，也可以用于生产）。进入框后，通过事件查看器查看错误。

第三，当发生中断时，请查看 azure 服务仪表板 (http://www.windowsazure.com/en-us/support/service-dashboard/) 是否存在中断。

最后，请联系 Microsoft 支持。这可能需要几个小时，但它们非常好。

如果它反复发生并持续很长时间（超过 5 分钟），我会认为您的托管服务有问题。再次，RDP 进入并四处寻找。祝你好运。

【讨论】：

感谢您的想法。服务仪表板是一个很好的发现，尽管这似乎不是我们的问题。我不能 RDP - 目前这些应用程序是 Azure 网站，并且不驻留在我们可以访问控制台的任何机器上。因此，我认为没有网络角色或升级域的概念......虽然我可能在这里遗漏了一些关键概念？

【解决方案4】：

查看站点的另一种好方法是使用调试控制台： https://github.com/projectkudu/kudu/wiki/Kudu-console

【讨论】：