SC2012 Operations Manager 中的 APM 代理限制设置和其他 APM 覆盖
APM 向导非常强大。我们付出很大努力来简化最常见的配置场景;但无论如何,在几个位置都会有其他设置被覆盖。本文的目的是提醒您注意其中几个位置。
其中一个位置是名为 [Discovery of APM Agent properties](APM 代理属性的发现)的发现 – 如以下屏幕截图所示,您可以通过查看 [.NET Application Monitoring Agent](.NET 应用程序监控代理)类别找到它。该发现包含一些有趣的覆盖。其中几个覆盖与“全局”监控设置有关,而其中一个覆盖对于事件限制非常重要。
全局每代理 APM 监控设置
其他覆盖的作用是启用监控应用程序的“全局”设置。虽然这并非我们建议使用的方法,但它可能会完全绕过 APM 模板,并使用这些覆盖。有一些注意事项:
- [Enable monitoring all web applications](启用对所有 Web 应用程序的监控)- 启用对 IIS 机器上的所有 w3wp.exe 进程的监控,使用默认设置,不受应用程序池名称和发现的影响。它实际上会打开对 Web 服务器上的所有应用程序的 APM 监控 – 包括当前和今后的应用程序。这种方法的缺点是,由于我们没有运行向导/模板,这些对象没有作为应用程序被 OM 发现,我们无法将数据与警报或状态相匹配,因此数据只能通过 AppDiagnostics 和 Advisor 查看 – 没有任何 OM“视图”或“对象”(请参阅我描述 APM 对象模型的以前的文章 – https://blogs.technet.com/b/momteam/archive/2012/01/14/apm-object-model.aspx )
- [Enable all critical exceptions](启用所有关键异常)- 它的作用与 APM 模板中的同等选项相同。它也作为代理的“全局”设置使用,在使用 [Enable monitoring all web applications](启用对所有 Web 应用程序的监控)时最有用。但无论如何,对于特定应用程序,如果您为这些应用程序运行模板,则在模板中指定的设置更加具体和实用。
- [Performance threshold](性能阈值)– 与前一项相同,它也可从模板进行相同的设置。它也作为代理的“全局”设置使用,在使用 [Enable monitoring all web applications](启用对所有 Web 应用程序的监控)时最有用。对于特定应用程序,在模板中指定的设置更加具体。
- [Sensitivity threshold](敏感度阈值)- 与前一项相同,它也可从模板进行相同的设置。它也作为代理的“全局”设置使用,在使用 [Enable monitoring all web applications](启用对所有 Web 应用程序的监控)时最有用。对于特定应用程序,在模板中指定的设置更加具体。
APM 事件限制
现在,我们将专门讨论有关限制的主题。在上述发现规则中,还有另外一个有用的覆盖:
- [Enable Event Throttling](启用事件限制)- 启用或禁用对代理的事件限制,它是此功能的“全局”打开/关闭开关。请记住,启用限制具有特定的目的 – 即在生成很多事件的情况下,保持代理的低 CPU 利用率。因此,我们不建议更改此设置,除非您只在测试/演示环境下运行,无需担心性能。接下来,我们继续讨论限制。
正如上文所述,事件限制的主要目的是保持低 CPU 利用率。因此,我们不建议完全关闭事件限制,因为它对系统资源的保护非常有用。但即便在打开此功能时,也有一些选项可以调整限制的行为,改变它的力度大小。
所有这些选项都可以通过覆盖 [Apply APM Agent configuration](应用 APM 代理配置)规则进行配置,它也是面向 [.NET Application Monitoring Agent](.NET 应用程序监视代理)的,请参见以下屏幕截图:
运行时,APM 代理不断将监控事件计数与限制进行比较,只有在没有超过限制时,才将这些事件提供给 OpsMgr 工作流,以传输到管理组。如果您的应用程序失控,开始突然引发大量异常,则这种方式使得 APM 代理不会增加过多负载,同时仍然向您报告任何“组”(请参阅下文有关事件组的内容)的第一个异常。
请注意,性能计数器“ % Exception Events / sec”、“ % Performance Events / sec”和“Average Request Time”不会受到影响:它们是在 OM 的监控器中使用的计数器,我们以前在 https://blogs.technet.com/b/momteam/archive/2011/08/23/application-monitoring-working-with-alerts.aspx 中进行过介绍。它们将不断报告在代理上“看到”的事件的实际计数,并且跟踪所有请求,但由于限制,它们不会报告所有事件并包含完整代码级详细信息。
正如我在 https://blogs.technet.com/b/momteam/archive/2012/06/18/event-to-alert-ratio-reviewing-problems-and-understanding-trends-for-apm-data-in-opsmgr-2012.aspx 中所述,有 15 个覆盖管理此行为。它们基本分为 5 个类别,对于每个类别,都有每分钟、每小时和每天的限制。所有请求都由代理计数,并对照这些阈值进行评估。每过一个时段(分钟、小时、天),都会重置与这些限制对应的计数器。
如果您要自定义这些限制,就需要了解这些限制是什么样的,以及应对哪些计数器进行评估以做出限制决定。接下来,我将尝试解释这方面的内容。但无论如何,请注意我们不建议您提高以下任何限制 – 因为这样可能对应用程序的性能产生负面影响。
- 异常事件组 – 此计数器跟踪每个事件组的异常数。事件组中的所有事件都遇到相同的问题,因而具有相同的调用堆栈。它是一个逻辑阈值,不与资源 (CPU) 使用率直接相关,但阻止您重复接收不合理数量的相同事件,防止淹没 Operation Manager 系统和数据库。当达到阈值时,APM 将在配置的时间段内停止报告该组的事件,但会继续递增该组的内部事件计数器。事件组在 AppDiagnostics 中称为“问题”组。当事件显示在 AppDiagnostics 中并按“问题”分组时,“计数”列将显示该组中发生的所有事件的实际计数,但只有第一个事件将在该组中显示。另外还要注意,如果您打开了警报规则(请在 https://blogs.technet.com/b/momteam/archive/2012/01/23/custom-apm-rules-for-granular-alerting.aspx 中查看更多信息),则 OM 中的报警基于这种“问题”或“问题组”概念具有“抑制”(递增“重复计数”)。如果系统配置为收集异常,则异常被视为跟踪对象。如果系统配置为仅收集“关键”异常,则只有“关键”异常被视为跟踪对象。如果系统被配置为收集“所有”异常,并且添加了“自定义处理程序”,则所有异常和自定义处理程序都被视为跟踪对象。
- 每域异常(应用程序域)- 对于开发背景较少的面向基础结构的普通用户,我要明确说明此处所述的是应用程序域,与 DNS 域或 Web 应用程序服务的域毫不相关。应用程序域是一个 .NET 概念和功能,允许在同一个 Windows 进程中运行多个不同应用程序,同时保持逻辑隔离(请参阅概述 https://msdn.microsoft.com/zh-cn/library/2bh4z9hs(v=VS.71).aspx)。在 IIS 中,应用程序域边界通常是虚拟目录或显示在 IIS 配置向导(“配置应用程序”)中的应用程序。因此,此计数器可跟踪在特定 Web 应用程序(应用程序域)中引发的异常数。此阈值可保护您的系统,防止 CPU 使用率和网络流量过高,并防止发送过多数据。在 SQL 服务器出现故障、磁盘已满或内存不足等情况下,可能从某个应用程序引发非正常数量的异常,每个异常来自代码中的不同位置,而且是不同的异常。此阈值可在配置的时间段内停止收集和报告来自该应用程序的异常。因此,如果您在单个进程下运行多个应用程序域,其中一个应用程序域引发过多异常,则只会限制该域,而继续对其他域/应用程序进行正常监控。如果系统配置为收集异常,则异常被视为跟踪对象。如果系统配置为仅收集“关键”异常,则只有“关键”异常被视为跟踪对象。如果系统被配置为收集“所有”异常,并且添加了“自定义处理程序”,则所有异常和自定义处理程序都被视为跟踪对象。
- 性能事件组 – 此计数器跟踪在特定事件组中引发的事件数。事件组在 AppDiagnostics 中称为“问题”组。另外还要注意,如果您打开了警报规则(请在 https://blogs.technet.com/b/momteam/archive/2012/01/23/custom-apm-rules-for-granular-alerting.aspx 中查看更多信息),则 OM 中的报警基于这种“问题”概念具有“抑制”(递增“重复计数”)。
- 每域性能事件 – 跟踪在特定应用程序域中引发的事件数。对于开发背景较少的面向基础结构的普通用户,我要明确说明此处所述的是应用程序域,与 DNS 域或 Web 应用程序服务的域毫不相关。应用程序域是一个 .NET 概念和功能,允许在同一个 Windows 进程中运行多个不同应用程序,同时保持逻辑隔离(请参阅概述 https://msdn.microsoft.com/zh-cn/library/2bh4z9hs(v=VS.71).aspx)。在 IIS 中,应用程序域边界通常是虚拟目录或显示在 IIS 配置向导(“配置应用程序”)中的应用程序。
- 总异常数 – 此计数器跟踪捕获异常的总数。“异常事件组”和“每域异常”适用于“Interesting”事件,而此阈值则适用于引发的所有异常,无论系统是否配置为报告异常。如果出现任何问题,导致应用程序引发过多异常,无论是否监控,此阈值都会让代理忽略所有这些异常,这也是防止 CPU 使用率过高的最后一道防线。我们特别建议您提高此限制。
频发事件/偶发事件优化
如果没有触及那些“偶发”事件,对 APM 限制的任何讨论都是不全面的。以前的 AVIcode 员工 Alex 已经对这个问题进行了非常详尽的描述,因此建议大家参照他的论述,我在这里不再重复,请查看此处 https://gotchahunter.net/2011/10/scom-apm-avicode-what-are-those-light-events/。其他相关信息请参阅 VIAcode 的博客 https://www.viacode.com/blog/2011/12/01/light-requests-optimization-logic-how-does-it-work/
要注意的一个重要问题是此功能在 OM12 中无法关闭。还要注意,在很多 Advisor 报告中,“偶发”事件不会计入“问题”计数。
数据保留
另一个位置是针对 OM 中的特殊数据传输单一对象执行的规则,它负责不断将 APM 数据从 OpsDB 传输到 DW 数据库,执行 APM 数据整理,以下文章介绍了驱动整理机制的保留设置:https://technet.microsoft.com/zh-cn/library/jj159297
敏感数据
还有另一个位置是以下文档中解释如何“处理敏感数据”的段落:https://technet.microsoft.com/zh-cn/library/hh543995.aspx,它还使用覆盖来定义表达式,以便将敏感数据排除在功能参数之外(经常问到的功能)。
发现
适用于发现应用程序的其他有用覆盖在“Operations Manager APM Web IIS 7” MP 的文档 https://technet.microsoft.com/zh-cn/library/hh916929.aspx 中进行了介绍;请记住,对于 SP1 中的 IIS8,有一个同等 MP “Operations Manager APM Web IIS 8” 以及等效的发现/规则。正如文档中所述,这些规则的工作方式是搜索特定文件扩展名,并根据它们的搜索结果(或您要它们搜索的内容)通过这些覆盖发现“ASP.NET 应用程序”或“ASP.NET Web 服务”。
另外,IIS 托管 WCF 端点还有一条规则,在文档中没有介绍,它的工作方式非常相似:查找 *.svc 文件,并使用该文件查找 WCF Web 服务(类型 “IIS Hosted WCF Web Service Endpoint” 的对象),这是另一个 MP 中的单独发现(正因为如此,本文档没有对它进行介绍),但实际上的思路是完全相同的…在此情况下,有一个实际发现(而不是规则),具有 override-able 属性,查找不同于“.svc”的文件扩展名(SP1 内部版本的屏幕截图… 在 RTM I 中,显示名称略有不同,但可在同一个 MP 和同一个目标中找到…)。这样可以在 IIS7 和 IIS8 中查找 WCF 服务。请参阅以下文档:
如果您需要有关各个端点的更多信息,请查看此处的咨询和报告:https://blogs.technet.com/b/momteam/archive/2012/08/22/apm-configured-endpoint-report.aspx
免责声明
在本文结束之前,我要发布免责声明,本文所述的很多覆盖(特别是与限制相关的覆盖)可能导致“不受支持”或“不推荐”的状态 – 提高限制值可能会对应用程序的性能产生影响:我们使用它们的目的是避免开销,而且也认为它们具有这种作用。但这并不保证它们在今后的版本中同样行之有效,在某些情况下甚至可能阻碍升级。另外,本文按“原样”提供,不包含任何保证,而且不授予任何权利。使用文中包含的实用程序受 https://www.microsoft.com/info/copyright.htm 中指定的条款约束。
希望我在本文中对 APM 覆盖的介绍能够帮助您了解它的使用方式!祝您自定义愉快,下次再见!