分析指标是所有现代SaaS应用程序的核心。如果不监控SaaS应用程序如何运行、它在内部执行的任务及其实现目标的成功率，就无从谈起”成功”运行SaaS应用程序。
然而，现代应用程序需要监控和查看多种类型的分析指标。这些分析指标的用途、价值、准确性和可靠性相差悬殊，具体取决于如何衡量它们、如何使用它们以及谁在使用它们。
基本上有三类用例全然不同的分析指标。
A类分析指标A类分析指标对应用程序而言是关键指标。如果没有这些分析指标，你的应用程序可能会立即失灵。这类指标用于评估应用程序的运行，调整其运行方式，并进行动态调整以保持应用程序正常运行。
分析指标是反馈回路的一部分，反馈回路可以不断监控和改进应用程序的操作环境。
A类分析指标的一个典例是用于自动扩展的指标。这类指标用于在应用程序负载变化时动态改变基础设施的规模，以满足当前或预期的需求。
一个众所周知的例子是AWS Auto Scaling云服务。该服务可自动监控特定的Amazon CloudWatch指标，寻找触发器和阈值。如果某个特定的指标达到特定标准，AWS Auto Scaling 会为应用程序添加或删除Amazon EC2实例，自动调整用于运行应用程序的资源。需要额外资源时，它会添加实例;指标表明不再需要资源时，它会删除这些实例。
AWS Auto Scaling让你可以创建由任意数量的EC2实例组成的服务，并根据流量和负载需求自动添加或减少服务器。流量较小时，将使用较少的实例。流量较大时，将使用更多的实例。
举例来说，AWS Auto Scaling可能使用CloudWatch指标来测量用于服务的所有实例的平均CPU负载。一旦CPU负载超过某个阈值，AWS Auto Scaling就会向服务池添加额外的服务器。
请注意，如果由于某个原因，这些Amazon CloudWatch指标不可用或不正确，那么算法就无法正常运行。结果是，要么为服务添加过多的实例–这会浪费资金;要么为服务添加过少的实例–这会导致应用程序的速度减慢或彻底失效。
很显然，这些指标确实必不可少。如果它们不可用、不正确，应用程序的运行就会岌岌可危。正因为如此，它们才叫A类指标。
AWS Elastic Load Balancing是另一个典例。AWS可以根据当前进入到每个负载均衡系统的流量大小，自动调整针对特定用例运行流量负载均衡服务所需要的实例大小和数量。随着流量增加，负载均衡系统自动改用更大的实例或更多的实例。随着流量减少，负载均衡系统自动改用更小的实例或更少的实例。这一切都是自动化的，基于使用特定CloudWatch指标的内部算法。如果这些指标不可用或不正确，负载均衡系统将无法调整适当的大小，负载均衡系统处理流量负载的能力可能会受到影响。
B类分析指标B类分析指标不是关键业务型指标，是用来表明即将发生的问题的早期指标，或用于在问题出现时解决问题。B类分析指标对于防止系统故障或出现故障后恢复正常很重要。
B类指标通常便于深入了解应用程序或服务的内部操作，或者便于深入了解运行应用程序或服务的基础设施。你可以主动或被动地利用这种洞察力，改进应用程序或服务的运行。
就主动方面而言，用户可以密切关注B类指标，这类指标表明了应用程序或服务可能不正常的趋势。基于这些趋势，可以利用指标触发警报，提醒运营团队必须检查系统，查看可能出现的问题。
就被动方面而言，在系统故障或性能降级期间，可以检查B指标的以往情况，以确定可能导致故障或性能问题的原因，以便查明解决问题的方法。这类指标常常在站点出现故障期间使用，并在事后检查期间使用。
在出现故障期间，B类指标用于迅速查明出了什么问题以及如何解决问题。之后，它们用于缩短平均检测时间(MTTD)和平均修复时间(MTTR)，前者是指故障期间发现问题所花的平均时间，后者是指故障期间确定解决问题所花的时间。这两个都是高性能SaaS应用程序的关键目标。
这种指标与A类指标的危急程度不一样。如果A类指标失效，你的应用程序可能失灵，但是如果B类指标失效，你的应用程序不会失灵。然而，如果你的应用程序有问题，而且B类指标没有正常运作，你可能需要更长的时间才能找到问题并解决它。
B类指标的例子有很多，许多公司专注于生成这些指标，比如AppDynamics、Datadog、Dynatrace和New Relic。B类指标还包括来自Elastic和Splunk等公司的日志记录及其他指标。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
