This is yet another call for SCOM Management Pack developers: never ever try to implement dynamic object and counter names for performance collection rules! This has been explained billion times by many people (including myself), but I have faced (and successfully terminated) another attempt to do that again.
The reason for not implementing dynamic object and counter names for performance collection rules is simple and straightforward: this kind of implementation is not supported by OpsMgr data warehouse. Take a look at dbo.PerformanceRule table and note that CounterName and ObjectName columns are stored there, RuleRowId is a primary key. That means that one and only one object\counter pair can be stored for a given rule. One. No exceptions.
You may say that dynamic object and counter names works well in SCOM performance views, that this is your design, that you don’t care about the date warehouse. My answer will be: you never know how the user will access the data. It could be generic performance report or dashboard widget (which read data from data warehouse as well). So writing a messy stuff into user’s data warehouse is absolutely not an option. “By design” argument doesn’t work here. Just because the MP’s design should be aligned with SCOM architecture, otherwise it is a bad design.
P.S.: I’ll be updating and re-publishing this post every time I note that someone try to implement dynamic object and counter names.
P.P.S. This worst practice was discussed first among others not because it is most important, but because a) the idea of discussing worst practices emerged from the recent case and b) there are a lot of numbers “1” in this post 🙂