云应用程序通常在可靠的正常运行时间方面赢得了良好的声誉。但是，通过持续测试可用性和响应时间来监控您的云托管系统和应用程序仍然很重要。这四个监控技巧可以帮助您依靠云。
云服务提供商通常会提供三个 9 或更好的正常运行时间，但确实会发生中断。即使主要参与者在 Web 架构中内置了所有冗余和其他保护措施，他们的系统仍然会因各种故障而瘫痪。这里有一些例子：
- 过期的 SSL 证书导致大多数 Microsoft Azure 用户的加密存储流量在全球范围内中断 12 小时（对于某些用户，则为 24 小时中断）。
- 一个内部 DNS 错误导致 Apple 每小时损失 200 万美元，而其应用商店、iTunes 和其他服务出现故障。
- 数据中心虚拟网络故障导致 Google Compute Engine 中断了 2 小时 40 分钟。
无声的减速会削弱生产力和销售
中断不应该是您对云服务的唯一关注。减速可能与用户中断的行为相同 - 更糟糕的是，在用户抱怨之前，它们很容易被忽视。或者他们可能不会抱怨，并且经常性的生产力损失或销售来源将不会被发现。
例如，如果您的销售人员使用基于云的 CRM 系统登录需要 15 秒，那么您需要知道。本质上，你付钱让人们等待。如果您的购物车在 8 秒内没有提供完全填充的响应，那么对于大多数潜在买家来说，该系统就像停机一样好。
不要让这些减速没有被发现。监控云应用程序可能很棘手，但您的云应用程序的持续性能和历史记录应该在您的网络管理仪表板上与其他关键系统具有相同级别的可见性。应用程序性能管理工具APM允许开发团队主动监控和改进应用程序性能。APM 工具（例如Stackify Retrace）提供代码级洞察以及集成日志记录，以识别 QA 中的更多问题并持续观察生产环境中的应用程序。
监控云主机应用
除了验证您的云应用程序的当前可用性之外，您的监控工具还应该自动跟踪这些元素：
- 事务步骤：如果需要按顺序执行多个步骤（初始身份验证、数据库调用、中间件步骤等），请确认这些步骤中的任何一个步骤是否处于非活动状态或缓慢。如果是这样，您应该能够确定故障元素对整体可用性的影响。
- 延迟：如果网络延迟严重影响基于 Web 的应用程序，您需要跟踪该延迟并尽可能跟进以解决问题。延迟尤其会导致移动用户的服务延迟，因此如果该平台对您的业务至关重要，您需要能够一眼看出延迟是否会造成或加剧服务问题。
- 响应时间警报：设置页面加载时间的警报级别，对于许多应用程序，响应速度低于 1.5 – 2 秒意味着服务已严重受损。
- 服务器/网络计时：如果您看到的有关云环境性能的数据不够精细，您可能不知道服务问题是否与网络问题、服务器配置甚至页面或脚本设计有关。
拥有让云服务提供商承担责任所需的数据
了解基于云的系统的实时状态可以让您有时间为即将发生的中断的影响做好准备。您可能能够采取纠正措施，或者至少与受影响的用户进行沟通，以便他们了解问题并采取相应措施。
能够一目了然地查看历史信息并生成报告以记录它，这一点也很重要。有了这些数据，您就可以让您的服务提供商承担责任。如果他们没有达到他们承诺的服务水平要求，您需要向他们展示正在发生的事情。
如果您已经完成了将裸机服务迁移到云的艰苦工作，您可能已经看到正常运行时间增加了，这很好。但云在 IT 系统基础设施中的作用显着增加，可能会产生更多的复杂性和更多的服务问题。通过彻底监控云托管的应用程序，立即为处理新出现的云服务问题做好准备。
