前面一篇文章说到为了省事,而且在Authoring guide中的workflow composite 里就说,为了让效率更高,最好让脚本支持Cookdown.然后我的脚本就返回多个Property bags.

为了支持cookdown,我设计了一个自定义datasource,定义如下,简单的来说就是定期执行前面文章中说到的powershell 脚本,这个脚本输出多个Property bags ,为了复用module,我加了一个conditionDetection,使用正则表达式对property bag 进行过滤,这样只需要简单的过滤特定属性,就可以监控不同的属性值。

直接上图吧。DS定义

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

 

下面是Monitor配置,鉴于以上DS的设计,我可以使用VSAE中的Snippet Template 很快生成多个Monitor

我的Monitor type 定义

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

Snippet Data

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

生成的Monitor 的XML代码之一。

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

其实以上的DS设计时使用MatchedWildCard可以使用通配符匹配有另外一个私心的。因为我了解到System.Performance.DataGenericMapper支持把多个Property Bags 一次性转换成多个Performance data,所以我的这个Datasource 如果在对属性进行比较时,输入*,那么返回的就是所有监控的属性的值,然后通过一个System.Performance.DataGenericMapper 全部转成perf data,然后一个rule 就可以直接写入DB,DWDB。想法是好的,代码能编译,导入MP后也不出错。

 

但是当我使用performance widget 时,只看到一个性能计数器的选项。我可是有8个计数器的。

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

 

查了下搜索引擎,说perf Widget 使用的数据是DWDB里面的,我看看有没有数据。

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

性能数据写入DWDB时,CounterName全变成一样了,但是Value正确。我以Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData batching 为关键字进行搜索,找到下面这么一个链接。

多年巨坑依旧。

http://www.systemcentercentral.com/forums-archive/topic/multi-value-rule-data-not-published-to-data-warehouse/

 

SCOM Console里的perf view数据使用的是OperationMangerDB中的数据,而Perf Widget 使用的OperationmangerDWDB中的数据,而Microsoft.SystemCenter.CollectPerformanceData写入OperationMangerDB的时候支持一次性写入多个perf data,而Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData写入OperationmangerDWDB却不支持。

我原来的rule 写成这样,看来要拆成多个了。

 

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

好在DS当时设计的比较好,拆不是问题。使用snippet template 很快可以搞定。

 

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags

这样很快就生成8个Rule。

那些SCOM 管理包开发中遇到的坑2–Multiple Property Bags