申请上云需要注意哪些指标？需要监控的指标数不胜数，有些指标比其他指标更重要。但是，没有放之四海而皆准的策略，因为虽然一个指标可能对一个应用程序至关重要，但它可能对另一个应用程序完全无用。为了制定最佳战略，企业需要首先确定其优先事项。确定优先级可以防止IT团队被监视用户行为、资源可用性、延迟、响应时间等的应用程序性能数据流淹没。除了讨论如何考虑监控指标外，本文还讨论了有关云应用程序管理主题的实用建议。例如，多租户云环境中的嘈杂邻居效应一直是一个问题，尤其是在应用程序性能方面。在云中运行工作负载的一个关键优势是保证这些云资源始终运行。监控和管理云工作负载可能很棘手。不过，这种努力是值得的，尤其是在支出方面。毕竟，使用云服务可能很昂贵。企业应该知道他们将获得每月费用的回报。一、云应用监控重要指标错误率、计算成本、每分钟请求数，云应用监控策略中有很多指标要检查，应该优先考虑哪些？二十多年来，IT团队一直在部署应用程序性能管理工具，以监控和管理本地应用程序和基础架构。但是，这些APM策略需要随着组织迁移到云而进行调整。云APM要求组织跟踪比本地APM更多的指标。在处理基于云的环境时，收集和分析指标数据还有其他权衡取舍。1云中的APM有何不同？乍一看，云和本地环境在应用程序监控方面似乎没有根本区别。云应用程序仍然在服务器上运行，并以与本地应用程序类似的方式进行交易。可以在云中使用某些监控方法。例如，RED方法强调收集与事务率、错误和持续时间相关的指标。什么是RED方法论？RED方法为架构中应测量的每个微服务定义了三个关键指标。这些指标是：速率：您的服务每秒处理的请求数。错误：每秒失败的请求数。Duration：分配每个请求所需的时间。然而，云环境带来了额外的挑战。在规划要监控的指标时，请考虑以下因素：分布式架构：云环境更可能包括数十个甚至数百个单独的服务器，应用程序分布在这些服务器上。这使得不仅监视单个服务器而且监视整个集群变得更加重要。在云中最重要的是集群的健康状况，而不是云中每个单独的服务器。所有权有限：在云环境中，用户通常无法完全控制由云提供商管理的主机服务器和操作系统。这会使收集某些类型的数据变得更加困难。例如，由于无法访问操作系统，因此无法从大多数基于云的无服务器计算服务中提取操作系统日志。·成本：过度配置的云环境会增加云计算费用。这使得除了性能优化之外，使用云监控还有助于支持成本优化。当然，本地成本也很重要，但过度配置在这里不是什么大问题，因为本地成本主要是资本支出而非运营支出。延迟：实现低延迟应该是任何类型应用程序的目标。然而，在处理基于云的应用程序时，延迟可能会带来更大的挑战。如果云可用性区域远离用户，则延迟问题的风险更高。负载平衡：虽然有时可以为本地应用程序使用负载平衡器，但更常见的是在云中使用它来引导应用程序的多个实例之间的流量。这给网络和流量监控增加了另一层复杂性。多云：如果使用多云或混合云架构，可能很难围绕单个工具集整合APM工具链。例如，如果您将资源分布在多个云中，则无法单独使用AWSCloudWatch来监控所有资源。所有这些差异都会影响团队在云中监控和管理应用程序所需的方法。2要跟踪的关键云指标对于几乎任何类型的云环境，都需要跟踪以下类型的指标：每分钟请求数：通过跟踪云应用程序每分钟接收的请求数，您将知道请求率出现偏差的日期从历史基线或一周的天数。这使组织能够更准确地预测何时增加云资源的容量。您还可以使用此类指标来帮助识别问题，例如分布式拒绝服务(DDoS)攻击。平均确认时间：跟踪平均确认时间（基于云的应用程序开始响应请求所需的时间）可能会揭示与负载均衡器相关的问题，这些问题转发请求的速度不够快。缓慢的确认时间也可能表明资源不足并且正在努力处理他们的所有请求。为了获得最佳可见性，监控和比较每个云区域或正在使用的单个云的确认时间指标，而不是仅仅汇总它们。这将有助于识别可能特定于一个云区域或云的延迟问题。比较给定请求在内容分发网络(CDN)处理时的确认时间也有助于了解如何最好地减少延迟。响应持续时间：响应持续时间，或应用程序完成对请求的响应所花费的总时间，也是应用程序是否有足够的资源来处理指向它的流量的指标。此外，响应持续时间的问题可能表明应用程序本身存在错误或内部通信问题，例如一个微服务无法与另一个微服务有效通信。还应按区域和按云跟踪响应持续时间，以最大程度地了解延迟。错误率：请求导致错误的频率是多少？哪些类型的错误最常见？这些指标提供了对应用程序和托管它的云环境的整体健康状况的进一步洞察。错误可能反映了应用程序问题，但它们也可能表明云环境本身存在问题，例如云服务不可用（这通常是云提供商要解决的问题）或在云环境中运行的服务的访问凭证配置错误。可用服务器/节点：对于分布式云环境，应该跟踪集群中有多少服务器或节点在线，作为已部署服务器的可用百分比。虽然云编排和自动化工具可以很好地在服务器出现故障时自动将工作负载从一个节点重新分配到另一个节点，但它们只能在运行健康的服务器之前这样做。需要知道可用服务器的数量是否会减少到总部署的90%以上，这可能表明云服务器实例存在严重问题。平均计算成本：跟踪给定时期内基于云的计算资源（例如虚拟机或无服务器计算）的总平均成本将有助于控制成本。无法用相应的应用程序需求增加来解释的计算成本激增可能预示着过度分配，浪费金钱直到得到纠正。平均存储成本：您还可以跟踪云存储资源的平均成本，包括数据库、对象存储和块存储。同样，与实际应用程序需求相关的存储成本增加可能表明存在问题，例如数据生命周期管理不善或数据存储层的使用效率低下。3要考虑的其他云指标根据应用程序的部署和管理方式，可能还需要考虑以下类型的指标以帮助监控云应用程序和优化最终用户体验：每周（或每天）的部署数量：如果使用CI/CD管道持续将应用程序部署到云端，并测量每周或每天完成多少次部署（如果部署特别频繁）将有助于了解CI/CD操作的整体健康状况。功能发布的时间安排：沿着类似的路线，跟踪团队将新功能从构思到部署需要多长时间，可以了解CI/CD管道的效率。平均解决时间：解决指标的平均时间（衡量工程师对环境中发生的事件做出反应所需的时间）对于在任何类型的环境中进行跟踪都很重要。然而，考虑到云环境的复杂性，它们在处理基于云的应用程序时尤为重要。在每个类别中收集的具体指标将取决于所使用的云服务类型及其暴露的指标。这些指标因云平台而异，但通常由云提供商详细记录。无论摄入APM工具的具体云指标如何，重点都应该放在收集有助于了解复杂分布式云环境状态的信息上。还应该努力关联不同类型的数据，并比较不同云和服务的数据。通过这种方式，您可以全面了解云中可能出现的性能和成本问题。当您详细了解正在发生的事情时，您将能够更好地防止复杂化并提高云部署的性能。多租户环境是否还会产生嘈杂的邻居？吵闹的邻居不仅仅是现实世界的问题。了解嘈杂的邻居如何影响工作负载性能，以及公共云如何改变以解决此问题。每个人都有吵吵闹闹的邻居故事，比如周末早上6点30分在郊区修剪草坪的人。不幸的是，这个问题并不仅限于那些住得很近的人。云用户有时会遇到类似的挫折。在公有云的早期，共享资源的概念很新，提供商还没有解决防止性能下降的难题。今天，那个喧闹的社区已基本成为历史，但它仍然时不时地出现。1吵闹邻居的影响吵吵闹闹的邻居，定义为多租户环境中一方独占共享空间，已成为IT团队的通病。在嘈杂的邻居场景中，一方会根据多租户环境中的预期需求和工作负载行为过度配置计算、网络和存储基础设施。一切都按计划进行，直到工作负载激增并开始超出其典型行为消耗资源容量。因此，共享相同容量的其他工作负载可能会受到性能影响。这个问题自大型机问世以来就一直存在，并且随着企业纷纷涌向公有云，这个问题也随之而来。每个IT组织都有这个问题，不同之处在于有些计划比其他组织更好。2解决了各大云厂商的noisyneighbor和containernoisyneighbor问题。多年来，他们管理运营、转移负载和快速响应性能问题的能力越来越强。此外，对于超大规模提供商，用户可以使用许多专门选项来最大限度地减少这些问题，包括虚拟私有云和专用连接。如果工作负载需要，其他强大的资源（例如更大的实例类型和自动缩放工具）也很容易获得。也许某些地区的其他较小的供应商可能会遇到这种嘈杂的邻居问题，但就超大规模供应商而言，最终用户在过去两年中表达了这种担忧。例如，虽然传统上对多租户环境的担忧集中在实体垄断带宽或CPU周期上，但容器的广泛采用可能会改变这些担忧。与VM模型不同，有了容器，操作系统就被虚拟化了。因此，操作系统的各个部分专用于多个租户，这带来了一系列挑战，尤其是在安全方面。然而，长期缺乏对容器的可见性意味着IT运营和技术团队可能无法识别多租户环境中嘈杂的邻居问题。3.调低音量首先，客户主动监控在公共云中运行的任何应用程序的性能。云提供商保证可用性SLA，但如果用户注意到性能下滑，就会发出危险信号。如果应用程序在公司内部网上使用，用户可能不会担心性能的细微变化。然而，如果它是一个电子商务网站，这些变化可能是一个大问题，并且会支持使用专用或独立机器的论点。然而，这可能不仅仅是一个计算问题。需要查看正在使用的共享资源。例如，可以有专用服务器、物理或虚拟共享AmazonS3存储。在这种情况下，如果有人在做S3繁重的工作，吵闹的邻居可能仍然是个问题。如果您发现这是一个问题，建议与您的云提供商合作，了解访问不同类型的专用基础设施需要什么，您不必担心云中任何潜在的嘈杂邻居。较小的公司，甚至网络托管公司，有时会提供专用基础设施，而公共云供应商也提供裸机服务。3如何在云上选择合适的高可用？您自己的云应用程序真正需要多少个“九”？高可用性仍然是云SLA中的一个重要因素，但每种服务和公司的正常运行时间要求各不相同。当谈到云中的高可用性时，企业往往喜欢不切实际。云供应商在营销SLA时列出了三个、四个和五个“九”，因此IT团队可能很难弄清楚他们实际需要为其应用程序提供多少正常运行时间。谷歌、亚马逊和微软的付费服务都有至少99.9%但不超过99.99%（四个九）的服务水平协议(SLA)。从这个角度来看，99.9%的可用性意味着一年内停机时间少于9小时，而99.99%的可用性意味着一年内停机时间少于1小时。尽管涉及复杂性，但主要的云提供商可以在这些协议中达到相对较高的标准，这要归功于一群才华横溢的工程师和已有数十年历史的既定流程。需要合理合理的SLA来确定应用程序的可用性，而这一切都始于了解应用程序的复杂性。例如，一个简单的静态网站可以很容易地达到四个九或更多的正常运行时间，因为潜在的故障点很少。现在，考虑一个更复杂的单体Web应用程序。虽然四个九仍然是可能的，但随着组件添加到组合中，实现它的压力将会增加，例如数据库和缓存服务器或对象存储。将应用程序分解为微服务也会增加潜在故障点的数量。随着应用程序复杂性的增加，可用性指标缺失9的风险也随之增加。虽然您总是可以增加冗余，但也会增加成本并带来复杂的工程挑战。毕竟，保持数据库的多个副本同步并不是一个小问题。掌握了有关如何实现不同级别的可用性的所有信息后，下一步就是弄清楚在SLA中失去9的后果。例如，如果停机时间为54分钟而不是540分钟或5,400分钟，客户会作何反应？在每个级别，有多少客户会流失？这些是制定SLA时必须考虑的问题类型。高可用性在云计算中很重要，但它不应该消耗所有资源。虽然五九(99.999%)的正常运行时间对于草坪护理电子商务巨头来说可能令人印象深刻，但其客户可能比紧急服务提供商更能容忍停机时间。确保不要在不必要的事情上花费太多时间和精力。参考文档：1.https://searchcloudcomputing.techtarget.com/feature/Metrics-that-matter-in-cloud-application-monitoring2。https://searchcloudcomputing.techtarget.com/tip/Do-multi-tenant-environments-still-create-noisy-neighbors3.https://searchcloudcomputing.techtarget.com/answer/How-much-cloud-uptime-do-你需要4.https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/
