间歇性Microsoft Azure网站访问失败

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

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

我试图停止并重新启动该站点，它运行了一次，但几分钟后症状又出现了。然后我试图停止并重新启动，但它没有工作

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

重要提示：如果我等待一段时间，网站可能会重新开始独立工作

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

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

其他信息2013年11月25日：

---

当站点出现故障时，IIS日志显示500或502个内部服务错误。我们自己的MVC代码永远不会被命中，甚至应用程序启动也不会被命中。

您可以通过检查日志和远程调试来启动

---

这些应用程序在本地工作吗？

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

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

我在他们的支持下证实了这一点

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

当然，我也向他们证实了这意味着两倍的成本=/

---

如果这不是问题，我将启用RDP并进入机器上查看问题是什么。Microsoft有以下工具来帮助调试问题：

首先，您应该始终使用多个升级域运行web角色的多个实例。这在服务定义（CSDEF）中是可配置的。如果没有这一点，您将无法从Microsoft获得SLA，因此您不能真正抱怨虚拟机宕机

其次，为了弄清楚这些框可能发生了什么，您应该同时拥有这两个日志（我的首选是使用页面blob或表存储滚动我自己的日志），并且您应该始终拥有对预生产环境的RDP访问权限（如果您对安全性不太在意的话，还应该包括生产）。打开该框后，通过事件查看器查看错误

第三，当发生停机时，请查看azure服务仪表板（）以了解停机情况

最后，请与Microsoft支持部门联系。这可能需要几个小时，但它们相当不错

---

如果它重复发生并且持续很长一段时间（超过5分钟），我会发现您的托管服务有问题。再一次，RDP进来，四处闲逛。祝您好运。

要调试您的站点，请尝试启用诊断日志：

查看站点的另一个好方法是使用调试控制台：

---

应用程序在本地正常运行。在azure下交付时，也可以正常工作。我可以把它们锻炼得精疲力竭——一旦我在Azure上有了MVC应用程序的会话，它就不会在工作时退出。只有当我离开一段时间（可能是过期的会话）回来时，应用程序才不会被提供。我来看看远程调试的想法。调试器很酷，我喜欢它，但它对我解决这个问题没有帮助。我自己的代码永远不会被攻击。。。当站点出现故障时，IIS日志会显示500或502个内部服务错误。感谢您在这方面的想法。服务仪表板是一个很好的发现，尽管这似乎不是我们的问题。我不能使用RDP——目前这些应用程序都是Azure网站，并且不驻留在任何我们有控制台访问权限的机器上。因此，我不认为存在web角色或升级域的概念。。。。虽然我可能在这里遗漏了一些关键概念？我们在租金较低的共享Azure网站空间中工作，因此我们无法访问VM to RDP to。。。至少目前是这样。如果我们继续遇到这样的问题，我们可能需要改变这一点，但我们不需要共享环境中不存在的任何功能，并且享受（直到我们遇到这样的错误）不对IT端负责……当站点出现故障时，IIS日志显示500或502个内部服务错误。我们自己的MVC代码从未被点击过，甚至连app_start都没有。这些是免费的网站吗？您是否有可能用完了允许的CPU？你可以在网站的仪表板上查看，我也看到了同样的问题。我在azure中运行一个网站，偶尔会在Web服务器日志中看到500和502个错误。当它收到这些错误时，它甚至从未到达我的webapi代码，因为我在应用程序日志中什么也看不到。有人知道是什么导致azure出现这种情况吗？