Open for Voting

Custom Properties for Components

I'm loving the new Custom Properties for Applications introduced in SAM 5.5, but sometimes I have a need to be even more granular. For example, we use an Exchange SAM monitor containing about 15 different Components. 14 of those, we only use for historical data, but the one for Mailbox Queue Length is critical. We could really do with being able to tag it with a Custom Property and write an alert for it, like:

Node Status is not equal to Down

Component Status is equal to Down

ComponentImportance is equal to High

We could then have a single alert for all components we care about. It's also crucial to be able to set different property value for the same component on different nodes.

  •  Yes I saw the comment, but I think you don't get it ; this is not relevant for this missing feature

  •  have you seen  's comment? his solution mentioned in line #2, is one that is commonly utilized by long time SAM customers. Also, when customers are getting into scale, they generally tend to start automating these processes via our SDK https://github.com/solarwinds/OrionSDK/wiki/SAM-Application-Monitoring-Templates Is that something you've taken a look at? We are certainly aware that we can provide more flexibility in our workflows, which is why when you look at how we've structured the API poller in the SAM 2019.4 and 2020.2 release, there is better flexibility for a delightful user experience. 

  • 1) I never noticed that we cannot have custom properties on components.  It's odd and yes that should be a feature.

    2) I've always alerted on the application monitor, never really noticed the problem.  Generally if I have a monitor, the same group will get the alerts for all of the components, it just seems odd for it to be any other way, but to each his own. When I want to monitor but not alert then I just delete the components warning/critical thresholds and bam, you have monitoring without alerting.

  •  

    So you split 1 template to 10/20/30 templates, unbelievable

    In a template containing multiple components, changing one component from <on duty> 'No' to 'Yes' means copying it from one template to another, removing it from first template, loosing all history... 

    Custom Properties on application template is a very static model and does not provide enough flexibility


    You REALLY should work on this case

  •  when a feature request like this is being actively worked on, the product manager will change the state from open to voting to "what we're working on" 

    Currently that's not the case for this particular feature request. 

    There are custom properties available at the application template level. Customers who are looking for deeper granularity for component level custom properties have the ability to separate their components out across templates to achieve that effect.