前端性能监控的监控指标_更加智能的监控：持续的性能监控方法
面向服务和基于云的体系结构建立在现有服务的重用之上。 过去是一个单一的应用程序，可以在单个服务器上轻松地控制和监视，现在是服务器和外部服务的集合，不容易监视。 每个系统或服务可能有自己的日志文件，它们可能在不同格式的多个服务器上。 当您必须搜索这么多文件时，很难确定报告错误的客户端的日志。 将日志收集到通用的集中式日志记录基础结构中以允许快速访问所有相关日志应该是司空见惯的。 使用相关性ID通过系统跟踪单个请求是一种可用的技术，但并不常见。 但是，相关性ID有助于分析错误情况和性能问题。
在“智能监控”方法中，我们添加了更多方面来帮助我们分析和解决性能问题：
- 关联化关联ID
- 参数化性能测量
- 资源分配量度
- 在每个部署，每个环境中的“始终在线”监视
- 绩效工程师角色，将改进反馈到开发中
以下各节介绍了更智能监控的一般方法。 还描述了一种使用“经典”体系结构（例如，具有关系数据库的JEE应用程序）的实现方法，该体系每天处理多达5亿个日志条目。
智慧监控方法
智能监控方法包括技术和运营方面。 作为基本工具，所有日志都收集到数据库或数据存储中。 每个日志条目中的关联ID允许为每个请求关联日志条目。 参数化的秒表日志可提供相关的性能信息。 在操作过程中，性能工程师使用这些工具来测量各种性能特征。 然后将见解反馈到开发中。
基础：收集所有日志
当今的应用程序应将所有日志收集到一个通用的中央日志记录基础结构中。 需要您的运营团队手动搜索日志文件的应用程序已经过时，浪费了您的团队的精力。
现代化的解决方案使您可以搜索和浏览日志，而不必从（可能是多个）服务器和多个计算中心（甚至可能跨共享驱动器）复制文件，因此支持团队可以访问它。 相反，UI允许您根据需要查询和过滤日志，因此您可以快速访问日志信息。
上下文相关ID
访问日志是一方面，但是找到正确的信息甚至更重要。 允许通过系统跟踪每个单个请求的相关性ID是第一步。 通常在客户端或服务器上创建关联ID。 然后将其放入每个原始日志语句中。 将关联ID传递给其他服务也可以将这些服务的日志与请求关联起来。
相关性ID只是第一步。 将ID和请求放在上下文中可以实现更智能的日志记录方法。 上下文信息可以是：
- 用例编号，服务，操作名称或请求进入系统的层
- 请求在相关位置进入系统的通道，例如Batch，EJB或Web Services调用
- 请求的用户标识
- 租户（如果适用）
某些上下文无法更改，但其他部分可以更改，具体取决于您的要求。 例如，承租人在一个系统中可能是不变的，但是如果您的系统已设置为使承租人可以彼此通信，则请求可能会更改其承租人上下文。
通过具有相关性ID的系统和服务跟踪请求已经可以对请求的执行路径进行定性分析。 看到单个请求的日志语句可能会让人大开眼界，特别是当您发现在昂贵的操作中有许多迭代而您没有想到的循环时。 通常，您会发现生产系统中的数据星座与预期不符，从而导致长时间运行的请求，从而导致性能问题。 当与性能测量一起使用时，相关ID的上下文信息变得更加重要，如下所述。
参数化性能测量
日志通常用于写出有关系统在特定时间点发生的情况的信息。 大多数情况下，这是通过手动编码的日志语句完成的。 我们的方法添加了秒表日志，这些日志是自动生成的日志语句，用于描述请求何时输入特定的代码部分以及执行该部分所花费的时间。 在这方面，自动生成意味着将秒表日志写入注入到实际代码中的方面。 例如，这可以在EJB调用周围的拦截器中完成，程序员甚至不必考虑这一点。
除了普通的秒表日志，您还可以向日志条目添加参数。 例如，这允许将执行时间与请求中已处理项目的数量相关联。 结果是分析系统的缩放行为。
将秒表日志与添加的上下文结合起来可以创建一个功能强大的性能问题分析工具。 这在分析功能问题时也很有用。
绩效统计
秒表日志始终被写入。 因此，您可以为每个测量点生成统计信息。 结果统计包括：
- 手段
- 推导
- 随时间变化的最小值和最大值
使用百分位分析时，您可以分析算法的效率。 例如：在我们的应用程序中，我们每天晚上并行运行大量批处理作业以导入文档。 图1显示了这些批处理作业的执行时间的度量（由于它们在后台运行，因此可以以分钟为单位来度量执行时间）。 最大值在5分钟内有一个尖锐的限制。 这意味着批处理作业将达到事务超时限制，应进行调整。
百分位数分析有助于确定离群值，在该离群值中，所有百分位数本质上都是一条带峰值的最大值的平线。 这些异常值通常被证明是由基础设施故障引起的，通常与数据库中的大型写入操作（例如BLOB）或访问存储子系统有关。 这可能表明存储子系统未按约定提供必要的服务级别（如果存在此类协议）。
如果保留了合计值，则可以在更长的时间范围内执行统计分析，如下图所示，该图显示了三年内三个功能的平均执行时间。 从一些性能改进开始，我们看到在2013年8月和2013年12月发布的红色曲线中有一些提升，直到最后，优化方法在2014年7月和2014年8月发布。 同时，我们必须优化蓝色曲线后面的功能。 离群值表明其他问题，通常与基础结构有关。
测量缩放行为
人们在推出系统后对系统进行处理通常令人惊讶。 最终用户通常不完全了解数据星座的类型和大小（例如，购物车中的商品数量或DMS中案例文件夹中的文档数量）。 当您在性能管理中使用其他参数时，可以测量系统的伸缩行为（系统在这种变化的数据星座下的行为方式）。 一方面，这可以确定为什么某些请求比其他请求花费更长的时间； 但它也可以在较大程度上预先预测系统的行为。
图3显示了实时系统中的样本分析。 左上方的图表显示了在参数上绘制的原始执行时间。 在这种情况下，这是此特定交互中处理的文档数。 右上角显示相同的数据，但是每个执行时间除以处理的文档数。 这表明恒定的时间偏移量和随处理的文档数量线性增加的部分。 这使您可以预测与较大的数据集进行交互所花费的时间。
下图显示的数据与右上图相同，但分布在一天中的整个时间。 这样可以将执行时间与其他负载情况相关联。 请注意，有两种类型的交互（很可能取决于某些功能要求），每种交互花费的时间不同。 一种类型似乎每个文档可以运行500毫秒。 另一个似乎至少需要800毫秒。
资源分配量度
不仅有一个请求发生的时间点，而且它的具体持续时间可以进行详细的资源分配测量。 您可以在某个时间点重叠所有正在运行的请求的持续时间，并确定系统中有多少个请求。 通常不清楚系统上有多少用户。 估计是在需求工程期间完成的，但最终很难预测。 开发期间的设计更改会更改每个交互的服务器调用数，依此类推。 智能监控方法可让您轻松测量并行度。
图4显示了一个批处理框架中的示例（数字56、57-60是批处理类型指示符）。 问题在于可以为批处理框架配置一定程度的并行性。 只有通过“智能监控”测量，我们才能看到是否达到了这种并行度。 实际上，我们发现了应用服务器中的配置问题，这些问题阻止了系统达到配置的并行度。 在一种情况下，它是每个JEE应用程序的线程配置，在另一种情况下，它是应用程序服务器的工作负载平衡的设置。
其他类型的分析包括：
- 飞行时间分析-在异步系统中接收一条消息要花费多长时间，并且是否有资源匮乏的迹象，例如意外的等待时间？
- 工作量分析-工作量是否在服务器之间平均分配（或至少在设计方式上）？
- 网络延迟分析-如果在请求退出一个系统时有秒表日志，而在同一请求（相关ID）进入另一个系统时又有秒表日志，则可以测量系统之间的网络延迟。
永远在线的性能工程
性能分析工具通常与应用程序分开。 这意味着在性能问题的情况下，可能需要在测试环境中将工具与生产环境分开设置。 然后，必须重新创建问题，但通常不会成功。
Smarter Monitoring解决方案的一个重要方面是它始终处于打开状态。 它是系统的集成部分。 即使在我们的开发环境中，开发人员也可以启用收集日志语句的日志服务器。 这是因为每个部署都包含日志记录和监视基础结构。 有效的Smarter Monitoring解决方案是部署的质量门。 您可以分析每个部署以及每个环境中的日志。
智能监控的一个重要方面是，无需进行单独的活动即可使其重新创建和分析问题。 每个部署都会训练部署团队执行必要的步骤，因此可以避免部署错误和破坏的部署。
在我们的项目中，开发和测试团队使用智能监控方法来分析性能和功能问题。 它是质量管理过程的宝贵工具。
绩效架构师角色
“更智能的监控是一个无价的工具，因为它“一直在线”。 问题分析的工作量大大减少了。 ”
由于该解决方案可在每种环境中使用，因此可以轻松地用于研究开发的每个阶段中的问题。 绩效架构师是我们创建的用于调查绩效问题的项目角色。 性能架构师不仅关注生产中的性能问题，还关注负载测试，并为开发团队提供有关性能优化的支持并提供建议。 在实际设计和开发之前，性能架构师必须参与项目或变更请求。 由于这种早期参与，他们可以从参数化性能日志中收集的信息中确定关键性能的更改或用例。 这样，就可以及早发现性能风险并快速有效地加以缓解。
实施注意事项
智能监控解决方案的实施可以基于不同类型的技术。 实际上，该解决方案与技术无关。 但是，任何实现都需要考虑一些因素。
数据大小的影响
存储由Smarter Monitoring解决方案生成的日志数量可能是一个挑战。 在我们当前的实现中，我们每天最多写入5亿条性能日志条目，在高峰时间具有更高的吞吐量。 有一些要求：
- 存储子系统必须能够在必要的时间范围内写入大量数据。
- 日志数据库或存储（关系或NoSQL）必须能够管理此数据量。
- 存储系统必须能够存储数据量。
- 旧数据必须及时汇总，并在必要时删除。
异步记录
在标准日志记录框架中写入日志文件通常以同步方式执行。 同步日志写入使应用程序容易受到日志记录和监视基础结构中的吞吐量问题的影响。
因此，与其同步记录日志，不如将日志条目分批收集并异步写入。 为了减轻日志记录基础结构本身的性能问题，可以舍弃不太重要的日志条目，以确保应用程序本身不会变慢。
在我们的应用程序中，日志条目被移交给特定的日志附加程序 （使用log4术语），该程序将它们收集到一批日志条目中，然后在单个请求中将它们异步传输到日志存储中。 附加程序在内存中缓冲一定数量的日志。 当发现日志数量增加到超出可写入数据库的数量时，它将删除日志并添加特定的日志消息警告。 这样，可以调查情况，但不会降低实际生产系统的速度。
注意事项
当我们开始使用秒表日志时，我们为能够测量和了解系统感到兴奋。 因此，我们添加了许多秒表日志。 我们添加了太多东西，以至于日志记录开始淹没我们的日志记录基础结构并减慢了应用程序的速度。 因此，我们学会了将秒表条目（大部分）限制为跨越组件边界。 这样可确保确定导致性能问题的组件。 基本秒表日志是请求进入或退出系统的地方。 尽管如此，秒表日志仍然使用的空间是仍然存在的普通日志的10倍。
即使没有实际问题，也很容易深入了解系统。 确保您专注于实际问题。 例如，在这些图像来自的系统中，存在单个交互作用，该交互作用不是线性的，但是对于较大的数据集，其交互作用呈指数增长。 但是，交互本身很快（最多100毫秒），并且数据集的大小估计有限。 目前，研究和修复算法虽然很诱人，但不值得付出努力。
案例研究—大型DMS项目
此案例研究显示了选择的实施方法。
德国的一个大型公共部门客户在一个电子文档管理系统（DMS）项目中实施了Smarter Monitoring解决方案。 该解决方案有助于满足并保持性能要求，即使在文档导入进行必要的性能改进期间也是如此。 由于新的要求，每晚要导入的文件数量必须增加五倍。 借助Smarter Monitoring进行系统分析有助于实现这一目标。
为了能够对任何性能（甚至通常是其他功能）问题进行即时分析和反馈，重要的是，Smarter Monitoring基础架构应成为标准部署的一部分，并且可在所有环境中使用。
解决方案
下图显示了原始解决方案。
每个与系统的用户交互都会创建一个唯一的关联ID，该ID与请求一起通过系统。 来自客户端，100多个应用程序引擎服务器和本地后端服务器的日志被收集到关系数据库中。 仅当用户自愿接受数据隐私条款和条件时，基于Java的客户端才将其日志上载到服务器。 服务器日志是通过log4j日志服务器写入的，然后将其异步写入关系数据库。
通过JMX客户端收集的度量标准使用有关基础结构运行状况的信息扩展了性能数据。 然后，监视UI允许查询和分析性能数据。 每个日志条目都包含基础结构信息，例如原始服务器名称或记录器名称。 日志条目还包含上下文信息，包括租户，请求源和用户ID。
UI允许导出经过过滤的日志（例如，通过相关性ID），因此可以将特定的经过过滤的日志从运营团队提供给开发团队，以进行进一步的分析和调查。 通过这种方法，我们每天最多可以将5亿条日志条目中的大约70 GB数据记录到日志数据库中。
我们可能会在将来的Smarter Monitoring应用程序中重新考虑的一些体系结构决策包括：
- 日志服务器的使用使应用程序与日志的实际写入脱钩。 也许追加程序可以直接集成到应用程序服务器的日志基础结构中。
- 在日志服务器中使用JDBC附加程序。 在云环境中，HTTPS上传器可能更实用。
- 由于具有可用的技能和工具，因此使用了标准的关系数据库。 当时没有NoSQL数据库或内存数据库。
由于所需的基础架构可能会根据所使用的工具而有很大差异，因此需要谨慎地做出技术决策。 虽然我们只有一个大型数据库，但“如何扩展日志记录基础结构以每天接收十亿条消息”中介绍了另一个NoSQL解决方案？ 与我们的解决方案相比，仅需要大量服务器即可仅监视两倍的日志量。
结论
智能监控方法是一种与技术无关的有价值的性能监控方法。 它以独特的方式结合了许多功能：
- 相关性ID跟踪通过系统的请求，包括微服务。
- 收集来自各种服务的日志并将其聚集到中央日志数据库中。
- 上下文感知和参数化的性能日志允许进行详细的性能分析和扩展行为调查。
- 并行化度量允许跟踪资源使用情况。
- 它从一开始，在测试和生产中就提供了完整的性能指标。
- 绩效工程师的角色将见解反馈给开发团队。
我们的第一个实现将JEE环境与关系数据库一起使用在Intel体系结构分布式环境中，但是您可以在其他环境中实现它，例如Systemp®或Systemz®。
使用这种组合方法，项目可以不断满足其性能和可伸缩性要求，这对于当今更快的开发周期至关重要。
翻译自: https://www.ibm.com/developerworks/library/d-smarter-monitoring-trs/index.html