Hello. Just a random visual question here.
I have the following deployed through custom properties. This is they assigned to groups that is then used to deploy our environment, eg SAM monitoring, alerts, ect.
It's ok, but it's not how a real life environment goes.
You usually have:
Much like the very long and very badly designed example below.
Now I have a way of doing this, but would like a better option.
The only way I can think of is:
Assign a server to a group.
add a group to the individual server somehow.
Assign services, ect to the group inside the server.
The only way I can think is to build and SQL command that does all of this, because if I wanted dynamic groups (which I have already) then I cannot do it in a gui. Well, I can't think how to do it. Though sometimes my brain has moments of having a stroke half way through the day.
Building out the design you are looking at will be a beast to work on but unrelated to that, there is a big gotcha I want to point out to you before you get too far down this road. Dynamic groups in Orion are pretty taxing for the system, depending on how beefy your server is once you get somewhere between 100-400 dynamic groups defined you are going to see significant slowdowns in your web console. You can mitigate this somewhat by raising the time between the group refresh intervals from the default 60 seconds but at the end of the day I try to avoid building large schemes of nested groups because of this limitation.
I did not know that. I only have maybe 10 or 15 dynamic groups at the moment with plans to have no more than 50. My other question is then: How would you design it so that in the very far future, you would have to do very little work and just leave it there to do it's thing?
50 groups is not such a big deal then, but they can be annoying if you want to use logic that they don't support in the GUI for the dynamic queries. I generally do not use the groups resources for anything beside dependencies because i find them to be more work than they are worth when organizing things, but if you want to stick with them then you may end up using the sdk to manage the group memberships. OrionSDK/Groups.ps1 at master · solarwinds/OrionSDK · GitHub
I suggest that because then you can write up any logic you need to determine who goes in what group and then just have it statically assigning the objects instead of using the dynamic query since that doesn't support some of the logic you might want. You would have to figure out the conditions for your scheme but essentially just use the #2 example on that link to populate each group and periodically run the script again to clean out old objects and add new ones.
Otherwise I just stick to custom properties and build my dashboards around those. I do a lot of swql and sql tricks to automate much of the custom property management that I need and tailoring the dashboards and I find that I get what I need from there. Seems like you could also get away with using customized Appstack layouts with a smaller collection of groups to get what you wanted to show from there with a lot less manual intervention
Have you taken a look at the AppStack page and resource in Server & Application Monitor? AppStack was designed with the intention of being a dynamic map correlating Groups, Server & Application Applications and Systems together for a simplified view of how they connect to one another.
You can access the page under Home> Environment.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.