事件到警报的关系，检查问题并理解 OpsMgr 2012 中 APM 数据的趋势

我一直在与很多用户进行交谈，包括（在 MMS、TechED 和很多其他场合）在线交谈和当面交谈，随着用户计划部署 System Center 2012 – Operations Manager 并希望使用 APM 功能，一个被反复提及的问题是“我需要为 APM 数据留有多少空间？”

就目前而言，这确实是个难题 … 虽然我并不愿意给出这样的回答，但是我的答案就是“需要看情况”。

我们确实在尺寸调整帮助程序电子表格中包含了 APM 因素，但是正如您可能从我的其他早期博文中了解到的，我并不是这类计算的拥护者。我承认他们确实很有用，但是在我的内心深处，我认为他们将产生很多麻烦。这是因为我知道要准确预测某些内容（如事件）的数据量有多么困难，这些内容中将包含众多不同的因素和变量… 因此我们几乎无法在不实际查看数据特定环境流程的情况下准确评估内容的规模。APM 事件也不例外：尺寸调整程序基于我们的测试使用了一些数学运算，并在通常情况下可排除一些错误，但是相比 APM 事件，这仍是一个非常粗略的近似计算。每个环境都是独一无二的，将生成的 APM 事件实际数量（即这些事件将在您的数据库中所占的大小）将取决于您的应用程序在生产过程中的行为、您的用户与这些应用程序交互的方式、交互的时间、数量、以及您所选择的阈值和高级设置。通常情况下，试图预测试就是一个猜测的过程。而我并不认为可完全实现事先准确预测。

根据我的经验，观察和适应（如果您愿意，也可称其为“调谐”）是可能实现，并更为可靠的。简言之，查看包含特定设置的特定应用程序在一段时间内将生成哪些数据，并试图将其作为预测的基线。然后，随着时间的推移和环境的变化，调整基线，并基于此（调谐配置和应用程序自身）重新预测。我在担任首席现场工程师时就一直这样向用户讲解调谐管理包，在已经链接的有关 ACS 的博客中我也是这样写的，而且我正将与此处相同的逻辑应用到 APM 中。

 

那么，理解 APM 数据占据额的数据库空间量的首个步骤是什么呢？

我的流程是：

1. 配置 APM 功能，并开始从您的应用程序中收集数据，这些内容已经显示于此前的一些博文之中。
2. 等待数个业务周期（要获得有关大小的有用内容，通常需要一或两周，尽管您可在更短的时间内在您的应用程序中发现问题！）
3. 查看该类数据实际将占据的空间，我最常用/简单的方式是前往 SQL Management Studio，并使用“按排在前面的表的磁盘使用情况”固有报告；或者，您可在 Kevin 的博客上查看数个您可使用的“排在前面的表”查询
4. 利用我在下面给您的查询查看每天的事件数量
5. 峰值在本质上是可能实现的（而且有可能发生），但是通常情况下，如果您查看“典型的”一周或两周，应该能看到某些“趋势”（即工作日和周末的区别），而且您应能够近似地映射出每天使用的空间量，并理解您的数据使用量将如何随着时间的推移而增长。这个方法虽远不够完美，但是由于这利用了您所选择的实际设置显示出了您的实际应用程序中的实际数据，因此相比任何尺寸调整帮助程序可为您提供的效果，这已经现实了很多！

现在，我们将在此向您介绍第 4 步的查询：（要针对数据仓库执行，请注意这是一个单一查询）：

 

 ---APM Events and Alerts DW Version
--APM Events by day
select CONVERT(VARCHAR(20),UTCEVENTDATE,102) as Day, COUNT(*) as TotalAPMEvents
into #APMEvents
from apm.EVENT
group by CONVERT(VARCHAR(20),UTCEVENTDATE,102)
order by CONVERT(VARCHAR(20),UTCEVENTDATE,102) DESC
--CSM Events by day
select CONVERT(VARCHAR(20),UTCDATE,102) as Day, COUNT(*) as TotalCSMEvents
into #CSMEvents
from apm.CSEVENT
group by CONVERT(VARCHAR(20),UTCDATE,102)
order by CONVERT(VARCHAR(20),UTCDATE,102) DESC
--get count of alerts per day
select CONVERT(VARCHAR(20),a.DBCreatedDateTime,102) as Day, count(*) as TotalAPMAlerts
INTO #APMAlerts
from Alert.vAlert a
left outer join vRule r
on a.WorkflowRowId = r.RuleRowId
left outer join vMonitor m
on a.WorkflowRowId = m.MonitorRowId
where r.ManagementPackRowId in (select ManagementPackRowId from ManagementPack mp with (nolock) where mp.ManagementPackSystemName in ('Microsoft.SystemCenter.Apm.Web','Microsoft.SystemCenter.Apm.Library'))
or m.ManagementPackRowId in (select ManagementPackRowId from ManagementPack mp with (nolock) where mp.ManagementPackSystemName in ('Microsoft.SystemCenter.Apm.Web','Microsoft.SystemCenter.Apm.Library'))
group by CONVERT(VARCHAR(20),a.DBCreatedDateTime,102)
order by CONVERT(VARCHAR(20),a.DBCreatedDateTime,102) desc
--combined table to see ratio
select e.Day, 
CASE WHEN e.TotalAPMEvents IS NULL THEN 0 ELSE e.TotalAPMEvents END as 'Total APM Events',
CASE WHEN ce.TotalCSMEvents IS NULL THEN 0 ELSE ce.TotalCSMEvents END as 'Total CSM Events',
((CASE WHEN e.TotalAPMEvents IS NULL THEN 0 ELSE e.TotalAPMEvents END) + (CASE WHEN ce.TotalCSMEvents IS NULL THEN 0 ELSE ce.TotalCSMEvents END)) as 'Total APM/CSM Events',
CASE WHEN a.TotalAPMAlerts IS NULL THEN 0 ELSE a.TotalAPMAlerts END as 'Total APM Alerts'
from #APMAlerts a
right outer join #APMEvents e
on a.Day = e.Day
left outer join #CSMEvents ce
on a.Day = ce.Day
order by e.Day desc
--cleanup 
drop table #APMAlerts
drop table #CSMEvents
drop table #APMEvents

 

结果集应类似于以下屏幕截图：

 

通过将结果迅速复制、粘贴到 Excel 中，您可得到一个类似于下图的图表，该图表非常明显地向您展示了 APM 事件与基于这些事件所生成的警报的比例：

 

其他有用的查询可获得，并查看诸如以下内容：

• 哪个应用程序将生成最多事件
• 发现最多的常见“问题”是什么？
• 这些问题是否将生成“性能”事件或“异常”

当然，这些也可借助查询实现，但是在开始这一“艰辛历程”之前，您应使用 Application Advisor 提供的报告，该报告已为我们提供了此类信息，这也是此过程的一个较好的起始点：

 

然后您可根据您的调查结果来将问题分类，并进行几个操作：

• 修复运行不正常的应用程序（如有可能，这应始终是首选的方法：运行较为正常的应用程序将生成较少的数据，而您的用户的体验也将更加舒适！）
• 优化收集数据的方式（即提高生成较少数据的阈值，请注意，这可能隐藏一个重要问题，正确的阈值处于一个良好的水平）
• 使用以下两种方式中的一种来更为积极地整理：
  • 按照 https://technet.microsoft.com/zh-cn/library/jj159297 中文档的描述内容，设置容量或基于时间的整理阈值
  • 使用问题管理规则（请注意这些规则仅在事件已经存储于运行数据库中后适用于事件）；而有关如何阻止警报的内容，请阅读我此前发布的有关自定义 APM 规则的博文
• 为代理更改限制设置
  • 这可通过设置（以“.NET 监视代理”为目标的）对“应用 APM 代理配置规则”规则的覆盖来实现。共有 15（没错，十五）个可覆盖的属性来管理一个代理每分钟、每小时和每天可发送的各个类型的事件数量。他们的名称和描述显而易见，但是我们可能考虑在今后记录这些名称和描述，以备其情况发生变化。

 

以下关系图显示了有关如何使用 Advisor 报告的示例流：

 

 

 

希望本文能为您提供有关如何切片和分割 APM 收集的数据的有用提示，以便您能从中获得最大价值，同时控制您的数据库所需的空间量，并最终改善您的应用程序！

 

免责声明

本博文按“原样”提供，且不提供任何担保和授予任何权利。
本文所含实用工具的使用受 https://www.microsoft.com/info/cpyright.htm 所指定的条款制约。