应用上云，监控和高可用实战！

应用上云，应关注哪些指标?有无数的指标需要监控，某些指标比其他指标更重要。但是，没有一刀切的策略，因为虽然一个指标可能是一个应用程序的关键，但它对另一个应用程序可能完全毫无用处。

为了制定最佳战略，企业需要首先确定其优先事项。优先级可防止IT团队被监控用户行为、资源可用性、延迟、响应时间等的应用性能数据流淹没。

除了讨论如何思考监控指标外，本文还讨论关于云应用管理主题的实际建议。例如，多租户云环境的嘈杂邻邦效应是持续存在的忧虑，尤其是在应用性能方面。

在云中运行工作负载的一个关键优势是保证这些云资源始终运行。监控和管理云工作负载可能比较棘手。不过，这种努力是值得的，尤其是在支出方面。毕竟，使用云服务可能很昂贵。企业应该知道每月的费用会得到什么回报。

一云上应用监控重要指标

错误率、计算成本、每分钟请求数，云应用监控策略中有许多指标需要查看，应该优先考虑哪些?

二十多年来，IT团队一直在部署应用程序性能管理工具，以监控和管理本地应用和基础设施。但是，当组织迁移到云时，这些APM策略需要适应。

云APM要求组织跟踪比本地APM更多的指标。在处理基于云的环境时，收集和分析指标数据还需要权衡其他因素。

1云上APM有什么不同?

乍一看，就应用监控而言，云环境和本地环境似乎并没有根本不同。云应用程序仍然在服务器上运行，并且以类似于本地应用的方式处理事务。

可以在云中使用某些监控方法。例如，RED方法强调收集与交易速率、错误和持续时间相关的指标。

什么是RED方法?RED 方法定义了在架构中应衡量的每个微服务的三个关键指标。这些指标是：Rate：请求的数量，每秒，你的服务正在服务。Errors：每秒失败请求的数量。Duration：分配每个请求所需的时间。

然而，云环境带来了额外的挑战。在规划要监控哪些指标时，需要考虑以下因素：

· 分布式架构：云环境更有可能包括数十台甚至数百台单个服务器，其应用程序分布在它们之间。这使得不仅监控单个服务器，而且监控整个群集更为重要。云中最重要的是群集的健康状况，而不是云中的每个服务器。

· 所有权有限：在云环境中，用户通常不能完全控制主机服务器和操作系统，而这些服务器和操作系统由云提供商管理。这会使收集某些类型的数据更加困难。例如，无法从大多数基于云的无服务器计算服务中提取操作系统日志，因为无法访问操作系统。

· 成本：过度分配的云环境可能会增加云计算费用。这使得使用云监控除了性能优化之外，还有助于支持成本优化。当然，本地成本也很重要，但这方面过度提供问题较少，因为本地费用大部分是资本支出造成的，而不是业务支出造成的。

· 延迟：实现低延迟应该是任何类型的应用的目标。但是，在处理基于云的应用时，延迟可能会带来更大的挑战。如果云可用区远离用户，则延迟问题的风险较高。

· 负载平衡：虽然有时可能会为本地应用程序使用负载平衡器，但在云中使用它来引导应用程序多个实例之间的流量更为常见。这为网络和流量监控增加了另一层复杂性。

· 多云：如果使用多云或混合云架构，则很难将APM工具链整合到单个工具集周围。例如，如果将资源分散到多个云中，则不能单独使用AWS CloudWatch来监控所有资源。

所有这些差异都会影响团队监控和管理云中应用所需的方法。

2要跟踪的关键云指标

对于几乎任何类型的云环境，需要跟踪以下类型的指标：

· 每分钟请求次数：通过跟踪云应用程序每分钟收到多少请求，将知道请求速率偏离历史基线时的一天或一周中的天数。这使组织能够更准确地预测何时增加云资源的容量。还可以使用这种类型的指标来帮助识别问题，如分布式拒绝服务(DDoS)攻击。

· 平均确认时间：跟踪平均确认时间(指基于云的应用开始响应请求所需的时间)可能会揭示与负载平衡器相关的问题，这些问题无法足够快地转发请求。确认时间过慢也可能表明资源不足，并且正在努力处理其所有请求。

为了获得最佳的可见性，请监控和比较使用的每个云区域或单个云的确认时间指标，而不是仅是聚合分析它们。这将有助于确定可能特定于一个云区域或云的延迟问题。比较给定请求由内容交付网络(CDN)处理时的确认时间也有助于了解如何最好地将延迟降至最低。

· 响应持续时间：响应持续时间，或应用程序完成对请求的响应所需的总时间，也是应用程序是否有足够的资源来处理针对它的流量的指标。此外，响应持续时间的问题可能表明应用程序本身存在错误或内部通信问题，如一个微服务无法与另一个微服务有效通信。响应持续时间还应按区域和每云跟踪，以便最大限度地了解延迟。

· 错误率：请求多久导致一次错误?哪些类型的错误最常见?这些指标可进一步了解应用的整体健康状况以及托管它的云环境。错误可能反映了应用程序问题，但它们也可能表明云环境本身存在问题，例如云服务不可用(这通常是云提供商需要解决的问题)或在云环境中运行的服务配置不当的访问凭据。

· 可用服务器/节点：对于分布式云环境，应该跟踪群集中有多少服务器或节点已上线，作为已部署服务器器的可用百分比。虽然云编排和自动化工具可以很好地在服务器出现问题时自动将工作负载从一个节点重新分配到另一个节点，但他们只能在运行健康服务器之前这样做。需要知道可用服务器的数量是否会减少到总部署的90%以上，这可能表明云服务器实例存在严重问题。

· 平均计算成本：在给定时期内跟踪基于云的计算资源(如虚拟机或无服务器计算)的总平均成本将有助于控制成本。计算成本的激增无法解释为应用需求的相应增长，这可能预示着过度分配，在纠正之前会浪费金钱。

· 平均存储成本：还可以跟踪云存储资源的平均成本，包括数据库、对象存储和块存储。同样，与实际应用需求相关的存储成本增加可能表明存在问题，例如数据生命周期管理不当或数据存储层使用效率低下。

3需要考虑的其他云指标

根据应用部署和管理方式，可能还需要考虑以下类型的指标，以帮助监控云应用程序并优化最终用户体验：

· 每周(或一天)部署数量：如果使用CI/CD流水线将应用程序持续部署到云中，则衡量每周或每天完成多少部署(如果特别频繁地部署)将有助于了解 CI/CD 操作的整体健康状况。

· 功能发布的时间：按照类似的思路，跟踪团队从想法到部署需要多长时间才能获得新功能，这为了解 CI/CD 流水线的效率提供了可见性。

· 平均解决时间：解决指标的平均时间(衡量工程师对环境中发生的事件的反应需要多长时间)对于在任何类型的环境中进行跟踪都很重要。但是，鉴于云环境的复杂性，在处理基于云的应用时，它们尤其重要。

在每个类别中收集的具体指标将取决于使用的云服务类型及其暴露的指标。这些指标因云平台而异，但通常由云提供商提供充分记录。

无论APM工具中摄入什么特定的云指标，重点应该是收集有助于了解复杂分布式云环境状态的信息。

还应努力关联不同类型的数据，并比较不同云和服务的数据。这样，可以全面了解云中可能出现的性能和成本问题。

当详细了解正在发生的事情时，将处于更好的位置，以防止复杂情况并提高云部署的性能。

二多租户环境是否仍会创建嘈杂的邻居?

吵闹的邻居不仅仅是一个现实世界的问题。了解吵闹的邻居如何影响工作负载性能，以及公有云如何更改以解决此问题。

每个人都有一个嘈杂的邻居故事，比如居住在郊区的人，他在周末早上6：30修剪草坪。不幸的是，这个问题并不只保留给那些彼此住得很近的人。云用户有时会处理类似的挫折感。

在公有云的早期，共享资源的概念是新的，供应商尚未制定出防止性能下降的难题。今天，这个喧闹的邻居大部分是历史，但它仍然是时不时地可能出现的东西。

1吵闹的邻居的影响

吵闹的邻居被定义为一方在多租户环境中垄断共享空间，这个问题对于IT团队来说已经司空见惯。

在嘈杂的邻邦情景中，一方根据多租户环境中的预期需求和工作负载行为过度提供计算、网络和存储基础设施。一切都按计划执行，直到工作量激增，并开始消耗超出其典型行为的资源容量。因此，共享相同容量的其他工作负载可能会受到性能影响。

这个问题自大型机问世以来就一直存在，随着企业向公有云飞奔，这个问题也随之而来。每个IT组织都有这个问题，不同的是，有些计划比其他组织更好。

2嘈杂的邻居和容器

嘈杂的邻居问题已经为主要云供应商解决了。多年来，他们越来越有能力管理运营、转移负载和快速应对性能问题。此外，对于超大规模提供商，用户可以访问许多专门选项，以最大限度地减少这些问题，包括虚拟专用云和专用连接。其他强大的资源，如较大的实例类型和自动缩放工具，如果工作负载需要它们，也很容易获得。

也许某些地区的其他规模较小的提供商可能会有这种嘈杂的邻居问题，但就超大规模提供商而言，在过去两年中，最终用户表示过这种担忧。

例如，虽然对多租户环境的传统关注集中在垄断带宽或 CPU 周期的实体上，但容器的广泛采用可能会改变这些担忧。

与VM模型不同，使用容器时，操作系统是虚拟化的。因此，操作系统的切片专用于多个租户，这带来了一系列挑战，特别是在安全方面。

然而，长期缺乏对容器的可见性意味着IT运维和技术团队可能无法识别多租户环境中嘈杂的邻居问题。

3调低音量

首先，客户要积极监控在公有云中运行的任何应用程序的性能。云提供商保证可用性SLA，但如果用户注意到性能下滑，则提出了危险信号。

如果是公司内部网使用的应用，用户可能并不担心性能略有变化。但是，如果它是一个电子商务网站，这些变化可能是一个大问题，将支持使用专用或独立的机器的论点。

但是，它可能不仅仅是一个计算问题。需要查看正在使用何种共享资源。例如，可以有一个专用的服务器，物理或虚拟共享亚马逊S3存储。在这种情况下，如果有人在做S3重压力工作，吵闹的邻居可能还是个问题。

如果发现有问题，建议与您的云提供商合作，了解访问不同类型的专用基础设施需要什么，在那里不必担心云中任何潜在的嘈杂邻居。较小的公司，甚至网络托管公司，有时提供专用的基础设施，公有云厂商也提供裸金属服务。

三如何选择云上合适的高可用性?

自己的云应用真正需要多少个"九"?高可用性仍然是云SLA中的一个重要因素，但每个服务和公司的正常运行时间需求各不相同。

当谈到云计算的高可用性时，企业往往喜欢不切实际。云供应商在营销SLA时列出了三、四和五个"九"，因此 IT 团队可能很难确定他们实际需要为自己的应用程序提供多少上线时间。

谷歌、亚马逊和微软的付费服务都有至少99.9%的服务级协议(SLA)，但不超过99.99%(4个9)。从这个角度来看，99.9%的可用性意味着一年内只有不到9小时的停机时间，99.99% 的可用性意味着一年内停机时间少于 1 小时。

主要的云提供商可以满足这些协议中相对较高的标准，尽管涉及复杂性，这要归功于大量才华横溢的工程师和数十年的既定流程。

需要一个合理合理的SLA来决定应用程序的可用性，这一切都始于了解应用的复杂性。例如，一个简单的静态网站可以很容易地期望实现四个九或更多的正常运行时间，因为很少有潜在的故障点。

现在，考虑一个更复杂、更单一的 Web 应用程序。虽然四个九可能仍然是可能的，但实现它的压力会随着向组合添加组件(如数据库和缓存服务器或对象存储)而增加。将应用分解为微服务，潜在故障点的数量也会增加。

随着应用程序复杂性的增加，在可用性指标中丢失 9 的风险也会增加。虽然你总是可以抛出更多的冗余的问题，你也会增加你的成本，并创造复杂的工程挑战。毕竟，保持数据库的多个副本同步并不是一个微不足道的问题。

手头的所有信息，你可以做什么，以实现不同的可用性水平，下一步是找出失去一个九在你的SLA的后果。例如，如果有54 分钟的停机时间与 540 分钟或 5，400 分钟的停机时间，客户会有什么反应?在每个级别上，将损失多少客户?

这些是制作 SLA 时必须考虑的问题类型。高可用性在云计算中很重要，但它不应该消耗所有的资源。而五九(99.999%)对于草坪护理电子商务巨头来说，正常工作时间可能令人印象深刻，其客户对停机时间的容忍度可能远高于紧急服务提供商。确保不会在不必要事情上花费过多的时间和精力。

参考文档：

1. https://searchcloudcomputing.techtarget.com/feature/Metrics-that-matter-in-cloud-application-monitoring

2. https://searchcloudcomputing.techtarget.com/tip/Do-multi-tenant-environments-still-create-noisy-neighbors

3. https://searchcloudcomputing.techtarget.com/answer/How-much-cloud-uptime-do-you-need

4. https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/