Re: 'groups have limited functionality'
Have you considered creating groups dynamically defined by custom properties? When managing, just manage the custom property assignments to affect the groups. Instead of a True/ False property, use some meaningful name. Not knowing the business use in your case, I'll try to demonstrate--HR_web_server, AccountsReceivable_DB. You can make your group membership on 'HR_' or '_DB" (in my example HR=human resources and DB=database, but by all means invent something relevant to your business).
You can go into Manage Nodes and sort by custom property, which then effectively sorts by your groups if your groups are dynamically defined.
Thank you for your reply. Sorry though, I'm not completely understanding what you mean by "Instead of a True/ False property, use some meaningful name" and "You can go into Manage Nodes and sort by custom property, which then effectively sorts by your groups if your groups are dynamically defined.".
Also, as I stated in my post, creating groups doesn't really help when it comes to finding nodes in Manage Nodes, assigning Application Templates in SAM, sorting, filtering, searching in the Custom Property Editor and almost any screen in Orion that isn't a specific Group resource. The big problem we have is that we have 3,000 nodes, almost all of which are servers, and when we need to do things to a specific subset of them like editing node properties, assigning templates, and many other administrative duties, we really struggle to be able to narrow these down to the ones we want.
For instance, if we have a custom property called "App_Group" and we've labelled all of our Orion servers with "SolarWinds Orion" in their App_Group custom property, the database server can't just simply be labelled with SolarWinds Orion because it houses databases for several other applications, therefor I don't have an easy way of selecting just the Orion nodes when I need to do something with them. With many application groups they are even more complicated. I know there is probably no perfect solution, but I just want to see what others have done in this situation.
What if you had a group with dynamic membership contingent on App_Group custom property containing 'SolarWinds Orion'. Nested inside that group, a separate group 'Multiple including SolarWinds Orion' (for your database server). Also a group 'Only SolarWinds Orion' (for your SolarWinds app servers). As long as these groups were dynamically populated by a custom property, that custom property would be your selection criteria that would be exposed where you were trying to do management.
I think you could benefit from nesting, as long as any up/down status for groups was considered in your nesting strategy (assuming you care about group up/down status now or in the future). I think of these issues in terms of Venn diagrams--you remember those overlapping circles?
Relevant documentation in case it triggers any thoughts you haven't already had. http://www.solarwinds.com/documentation/orion/docs/groupsanddependencies.pdf
Yeah, I think it's what I'm gonna have to do, but it still doesn't help me in non-group resources, which is pretty much most of Orion... I can't use groups in Manage Nodes, Assign Application Templates, or any administrative console at all, so it doesn't really solve my problem.
1 of 1 people found this helpful
Perhaps some inspiration here? https://thwack.solarwinds.com/community/solarwinds-community/announcements/blog/2015/10/01/custom-properties-how-do-you-…
This is great d09h! This is exactly what I was looking for! Good find, lots of good ideas in here.
1 of 1 people found this helpful
A lot can be tied to group membership actually. That's pretty much core for Solarwinds.
Which can be ultimately controlled by custom properties if they are used as a condition for a dynamic group.
Yep, exactly. Dynamic group membership is based on the custom property, thus you can target the custom property for (everything).
I run into the scenario you describe quite a bit, and in that case I often end up with a pair of custom properties to address the issue.
First is a generic ApplicationRole - examples being web, database, application, licensing, whatever roles make sense within that app architecture.
Then I set up another property that is just Applications - this is a list of all the applications the server supports separated by commas
This way I can easily whip up reports/alerts/summary views of all my database servers based on the first custom property and if I want to be more granular I just add a condition where it is a ApplicationRole equals 'Database' and Application contains 'Solarwinds' Or if I just want to see all Solarwinds related servers I can just do Application contains 'Solarwinds'
I'm also a huge fan of using the alerting engine to set your custom properties so you don't have to manually manage them. Example being to write an alert that check if the node IP is in a specific range, and if it is then trigger an action to set the Site custom property to whatever branch office/datacenter uses that IP range. Or if a node has the Appinsight for SQL template applied to it then set the ApplicationRole to Database. The more I automate these alerts the less time I have to spend making sure that everyone else is setting the properties consistently. That consistency is a big part of being able to scale the system out and be able to rely on it. Also, since NPM 12, now that the scheduled discoveries can be more easily set up to automatically import the nodes it finds I try to avoid having users even involved in the whole node discovery/adding/setting custom properties as much as I can because trying to get more than 2-3 people to do it the same way is a pain.
I'll confess I don't envision a great way to do this yet with Orion, but I've seen organizations handle this challenge using taxonomic labels from nature.
All applications are named after species of sea life.
Variations within those applications are named for specific groups or similar kinds--species of sharks, or groupers, etc.
Other kinds of servers have different names, whether mail or web or citrix or domain controllers, etc. Maybe mammals or insects or plants, etc.
In some cases I've seen organizations use city names or country names or presidents' names, but this can become confusing when there is overlap (Washington--is that a state or a president?), so I recommend thinking ahead to avoid potential conflicts when creating naming rules.
Last, I've seen IT departments treat virtual servers or Virtual IP addresses (for load balancers) with imaginary animal names. In this case, if a "real" server's name is "Mute Swan", then the associated virtual server or VIP might be "Cygnus" (a mythical swan that is the name of a constellation).
Further if it's a Test server running on VM, it could have another kind of name, like WoodyWoodpecker. That's still a bird (for keeping with the type of application or server), and it's not "real", so folks recognize it as a cartoon, or play/pretend server.
Get as creative as you want, but document your naming conventions and make rules that prevent confusion due to overlap. Don't get too esoteric or exotic--no one's going to want to use names of lakes for your apps or servers if you choose names that are valid but hard to pronounce or spell (e.g.: Ogishkemuncie or Kabetogama or worse).
I've seen companies that do something like this and to be honest I find it a tremendously horrendous system. Naming conventions like these make everything harder, because now you have to learn the meaning behind the names. In my mind the best way to name devices is to use a clear cut naming scheme where the meaning is easy to discover because each part of the name is a clear-cut code that is predefined in two character sections. So something like NY01B1SVSWWB01 would break down to:
City: NY = New York City (for virtual devices in a multi-site DR environment they would just have VI for Virtual)
Site: 01 = Site 01 (or if the company uses two digit site code abbreviations that could go here instead. Like maybe the Broadway Ave location has a site code of BR)
Building: B1 = Building 1
Device Type: SV = Server (you would also have SW = Switch, RT = Router, FW = Firewall, etc...)
App Group: SW = SolarWinds (or, for non-server devices they could skip this since they wouldn't necessarily be associated with a specific application)
Device Role: WB = Web Server (or DB for Database Server, UT for Utility Server, DC for Domain Controller, etc.)
Device Number: 01 = 1st SolarWinds Web Server
Obviously it wouldn't have to be the above exactly, but something like it where the name clearly defines every part of what the device is, what purpose it serves, and exactly where it is located. When you use something like animal names, team names, or whatever, it makes zero sense except to the people who invented the system, the definitions of what the names mean can be subjective to some people, some people may have no knowledge of the subject (like team names would be meaningless to me as I haven't followed sports in over 10 years). A system like what I mentioned clears all of this up as you can easily have a small chart that defines each two digit code and the possible values they have. You can decipher everything about a device in less than a minute using the chart and less than 10 seconds once you've learned the naming scheme, even if it is a brand new device or a device you've never heard of or seen before.
I, too, have seen more intuitive naming applied. I sometimes wondered at the rationale for creating naming conventions like those I initially described. Some ideas I came up with include:
- The systems are in smaller, home-grown IT shops, with a fun and personalized atmosphere.
- Folks get to personalize their products and take pride in ownership, rather than using stark and plain or complex systems names.
- Referring to a server by it's custom name (e.g. Antartica or Goliath) gives a device some personality and easily-remembered history, increasing the enjoyment of working with it. Like an old friend, you can talk about it by its experiences. "Antarctica's overheating again--call Ops and ask them to move the air conditioning blower to it points back at the server's cooling intake." Or "Goliath has gotten slower in his old age; I think it's time to either give him some new memory or retire him."
- There's a small degree of security that comes from non-descriptive names. If all your Financials are on servers named after highways, and someone intercepts communications about I-94 being backed up or undergoing repairs, you've not shared anything vital. Granted, this is a bit of "security through obscurity", and a dedicated hacker or intruder will get the data they want--but they may not get it as quickly or easily.
Some reasons folks have used to rationalize NOT using descriptive names include:
- More descriptive names can end up being a handful to keyboard in when you're referencing them.
- Bad Guys can use them to more efficiently target your data or systems.
- Descriptive names are often not as easy to remember as other group names (like Northern Pike or Sunfish. Who wants to key in, or try to talk about, a server called NY01B1SVSWWB01, when they could reference names like Gilligan or Barbi or Fred Flintstone or Wolverine?)
- Sometimes IT needs to be fun, and not just harsh and cold and strictly analytical.
For me, I think I'd enjoy immediately knowing every server's impact and supported applications just by seeing its name. If all e-mail servers are named after dinosaurs, and when you hear there's an issue with e-mail, and your Orion NPM says T-Rex is down, you've just done your first level of triage in less than a second. You'll start looking at the server called T-Rex, and maybe you'll find the e-mail problem immediately.
If a Wintel Admin adds another server to the network, and they tell you it's name is Apricot, and you know a fruit name means this server supports the waste management application, you know everything needed to support it on your F5's or firewalls, etc., and you can build your network and firewall environment for it appropriately, without further correspondence or time.
In these cases, those kinds of naming conventions are time savers.
But people are all different. I've seen I.T. leaders who don't like "cutesy" names, thinking them unprofessional or inefficient. While other I.T. leaders appreciate the familiarity and friendliness and intuitivity and ease of naming systems with names from groups of similar things.