SRM Orion - All Storage Objects "Group by" options quite limited

In most Orion modules that have an "All {Insert Element Type Here}" resource (like the "All Nodes" Tree or the "All Applications" Tree for example), you can edit them and group by several levels of properties. Those properties are usually system properties like Machine Type or Vendor, or they are Custom Properties that the end-user has created, like "City" or "NodeType". In the All Applications Tree you can group by both Node System/Custom properties as well as Application System/Custom Properties.

However, in SRM the only "Group by" options I'm seeing when I edit the "All Storage Objects" resource is either "Vendor" or "None"... With SRM being the newest Orion module, I am quite surprised to see this functionality missing. Not only that, but as noted in few previous Thwack posts and feature requests I made (Storage Resource Monitor (SRM) Not Respecting Limitations, ‌, ‌) some other basic functionality that has been common to most Orion modules is missing as well, including the ability to filter this and any other SRM resource using a SWQL filter.

I'm not writing this to be a gripey-McGriperson or anything (OK, maybe a little ). I'm putting it out there more to get some discussion around it and also to perhaps engage some SolarWinds staff so that maybe they can explain why these common features are missing (and I don't mean for that to sound mean or anything, I just don't know how else to word it ) and whether this has been something they've discussed internally. For example (and I'm just making this up), maybe they wanted to put those features in but because of the nature of SRM's database schema there isn't a way to provide this functionality for some reason or maybe just that it will take more time to develop the product to allow this.

What I'm having to do for my current client (who has array's at multiple data centers and wanted that resource grouped by Site, Role, and then Vendor) is I'm having to edit the name of each array to include the Site code and description. That way at least when they are looking at the name of an array and it is something obscure, they can still tell where its at and what it does without having to click on it to be able to look at its custom properties. For example: "APM000112345 - NY Array (Prod)". It would obviously be way more ideal (and quite a bit less tedious) if I could just group the "All Storage Objects" by the "SiteCode" and "Role" custom properties I created for their Arrays before realizing that the All Storage Objects resource didn't allow this functionality...

So in summary, I'd like to see the following:

- The Ability to group storage objects in the "All Storage Objects" by more system properties and any custom properties we've created

- The ability to filter the "All Storage Objects" (and all other SRM resources to be honest) via the standard SWQL filters found on most other Orion resources throughout the Orion Web Console ()

- The ability to apply view and account limitations to SRM views at a more granular level than just the Array level ()

- The Active Alerts resource on the "SRM Summary" dashboard to only display storage related alerts (I know, I kind of snuck this one in there. I need to create a feature request for this if it doesn't already exist)

Thanks,

HumeJo

Find more posts tagged with

storage resource monitor

view resources

srm for orion

all storage objects

Accepted answers

All comments

dsbalcau

Hi Jordan,

First of all, no need to apologize. This is a perfectly acceptable feature request and it's through these kinds of details our Product Teams get the information we need to make sure we are building the features you need. So, thanks for the request and the details, this is all helpful!

If I may shed some light on the "why isn't this basic stuff here in SolarWinds newest module?" question: What you are pointing out as basic functionality, is actually quite the opposite. Given how Orion resources are structured in the product, unfortunately there is not really a common object model for "All Nodes" type resources (or any resources for that matter) that other like resources inherit from to get these basic capabilities. For example, the "All Nodes" and "All Applications" resources are actually each entirely independent pieces of code. (Fun Fact: The All Applications resource is actually one of the more complex ones in the product because of all of it's custom filtering capabilities) Now, is the lack of a common inherited object model a good thing? Probably not, but that was a decision made long before this particular resource was developed. Therefore, each development team has to solve the use cases that make the most sense at the time and add additional functionality later. A lot of what we are calling basic grouping functionality in resources across Orion modules has actually been added over time in response to requests like this.

For what it's worth, I don't think there is anything about SRM's DB schema that would prevent the development of this functionality.

Hope that helps!

humejo

Good stuff Balki, thanks for your response! So first, I guess the word "basic" wasn't what I really meant. I used it in place of "common" I think, since it is the functionality we've come to expect from that type of resource and I found it surprising that a new module was lacking this. And while I figured there wasn't a common object model for the All Elements type of resources, I figured they would all be similar at their roots with just different entity's and entity types they were pointing at (so similar web code pointing to different entity's I guess. But even the entities they point at are kind of similar if you think about it since it boils down to grouping/sorting/filtering based on a combination of that entity and its parent entity's system and custom properties.). But, I've never been a .Net developer, or any kind of developer for that matter, so my only point of view is as a user with a very limited comprehension of the SDK API you all provide and the minimal amount of mucking about I've done with the asp files in the InetPub folder from time to time. Thus, I don't know much about what its like from the developer's point of view.

Because of my limited development knowledge I find it fascinating to actually hear about it from that perspective, so I truly appreciate your response as well as the remark about the challenges of the "All Applications" resource. Especially since many of the SAM resources and features are my favorite throughout Orion and make me wish that many of their elements were standards throughout the product. For example:

- Thresholds that include number of polls in addition to the typical greater/less than values

- The Multi-Chart which the SRM team improved upon by allowing certain statistics to expand into more detailed statistics (like Total IOPS expands to show line charts for Read and Write). How cool would it be for interfaces if you could get total utilization in a multi-chart for all interfaces on a node's Node Details page and each interfaces Total Utilization percentage chart expanded to show Transmit and Receive? How much cooler would it be to be able to create your own multi-chart on ANY statistic in Orion (so not just Application Components) as well as have the ability to expand your chosen statistic to reveal even more statistics of your choosing, even if they were completely unrelated (why should the web-code care? We just say parent chart is NPM Value X, expand to reveal SAM Value Y and Orion Core Value Z)?

- The entire concept of alerting against an Applications/Components status instead of the threshold or statistical value itself is great. This kind of refers back the coolness with SAM thresholds in that since not only do you specify a statistical value to threshold against, but also how long that statistic must be surpassed before the threshold is considered warning/critical. If you could do this in all of Orion then you could have one alert that just says Alert Me When Interface Utilization is Critical. Sure you can do that now, but what if on one interface you consider critical utilization to be when its past 90% for 10 minutes, but on another you consider critical to be past 90% for 60 minutes. With the current model you'd have to create two different alerts with the "Condition must exist for X minutes" setting in the trigger condition. If all thresholds used the SAM model you would only need one alert for each type of thing (one Interface Utilization Alert, one Node CPU Utilization Alert, one Node Response Time Alert, one Storage Array High IOPS alert, etc... Heck, if all elements used the SAM model you could just say "Alert Me When An Interface is Critical or Down" and put variables in the alert Email that would decipher what caused the interface to be Critical, like was it high utilization, high latency, high Errors/Discards, or is it just down? Then you could have just one alert for each element type!! One alert for Nodes, one Alert for Interfaces, one Alert for Volumes, etc... That really should be the standard for ALL thresholds in Orion, not just SAM.

dsbalcau

LOL. You made me blush - That SRM Total IOPS expanding into Read and Write. Idea of yours truly ;-)

Yeah, from the outside looking in, it doesn't make much sense. I agree. Hopefully I could shed some light on the matter for you.

These are all great ideas. Thanks for the feedback.

goodzhere

Is there going to be anything coming out for this soon or is there a custom resource to do this somewhere? Please someone point me in the right direction. I really need the ability to group storage objects by location and custom property. I can't believe this isn't in there yet.