我们正在与 Microsoft Azure 支持团队发生争执。我希望 Serverfault 社区能够参与进来，因为支持团队之前曾给我们带来麻烦。
以下是正在发生的事情。
作为我们在 Azure 上托管的大型 SaaS 服务的一部分，我们有一个前端应用服务，它接受基本的 HTTP 请求，执行一些小的验证，然后将繁重的工作交给后端服务器。此过程不占用大量 CPU、内存或网络资源，我们根本不会接触磁盘子系统。
定价等级为“基本：2 中等”，这对于我们施加的负载来说已经足够了。CPU 和内存图表显示系统大部分处于休眠状态，内存使用率约为 36%。
由于我们在服务器学校非常重视，因此我们使用 Azure 的标准监控设施积极监控整体解决方案的各个层。我们跟踪的计数器之一是“磁盘队列长度”，它是 Azure 应用服务上可用的极少数计数器之一，因此它一定很重要。
在服务器学校，我们被告知磁盘队列长度理想情况下应为零，如果它持续高于 1，则需要采取一致行动（某些 RAID 配置有一些例外）。过去几年一切都很好，磁盘队列长度 99% 的时间都为零，微软在维护系统时偶尔会飙升至 5。
几个月前，事情开始突然发生变化（因此在我们推出更改后没有发生）。磁盘队列警报开始大量涌入，平均队列长度为 30 多秒。
我们让它运行了几天，看看问题是否会消失（性能没有明显影响，至少在当前负载下没有）。由于问题没有消失，我们认为底层系统可能存在问题，因此我们实例化了一个全新的 Azure 应用服务并迁移到该服务。问题依旧。
因此我们联系了 Azure 支持。他们自然而然地要求我们运行一些无意义的测试，希望我们能摆脱这个问题（他们要求进行网络跟踪……以解决磁盘队列问题！）。我们不会轻易放弃，所以我们运行了他们的无意义的测试，最终被告知只需将队列长度的警报设置为 50（超过 10 分钟）。
虽然我们无法控制底层硬件、基础设施和系统配置，但这听起来不对。
他们的完整回复如下
我利用此案收集到的信息联系了我们的产品团队。
他们调查了您为磁盘队列长度指定的警报触发频率比预期更频繁的问题。
此警报设置为在 5 分钟内磁盘队列长度平均值超过 10 时通知您。此指标是采样间隔期间所选磁盘排队的读取和写入请求的平均数量。对于 Azure 应用服务基础结构，以下文档链接讨论了此指标： https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor
对于部署的任何类型的应用程序来说，10 这个值都非常低，因此您可能会看到误报。这意味着警报触发的频率可能比确切的连接数更高。
例如，我们在每个虚拟机上运行反恶意软件服务来保护 Azure 应用服务基础设施。在此期间，您将看到建立的连接，如果警报设置为较低的数字，则可以触发警报。
我们没有发现任何此反恶意软件扫描实例影响您的网站可用性。Microsoft 建议您考虑将磁盘队列长度指标设置为 10 分钟内至少 50 的平均值。
我们相信此值应允许您继续监控应用程序的性能。它还应较少受到反恶意软件扫描或我们为维护目的运行的其他连接的影响。
有谁想加入讨论吗？
答案1
对我来说，这听起来也很高，因为 Azure 处于共享池环境中。我敢打赌，您的后端磁盘正在受到其他客户端的攻击。根据其他帖子，听起来 Azure 以此而闻名。我会看看他们是否可以将您的后端磁盘重新定位到使用较少的存储中，或者尝试这些帖子或其他帖子中的建议。