13 Replies Latest reply on Sep 6, 2016 4:04 PM by designerfx

    Idea's for Labelling Multi-Application Servers in Orion

    xtraspecialj

      We are trying to organize our Orion environment using Custom Properties and are really struggling with ways to easily label multi-purpose device, mostly web or database servers that host multiple applications websites or databases.  We would ideally like to have each of our main applications or business services identified and the objects (nodes, app monitors, volumes, and interfaces) labelled as such so that we can easily get to them inside of Orion.  Obviously we could label each of the individual application monitors with a custom property indicating what application group or business service it plays a part in and/or we could create a group for each application and put the node into each of the applications that it hosts a website/database for, but the problem with both of these approaches is we won't be able to sort, search, or filter by an application when looking for a node in Orion.  Groups have limited functionality within Orion and can only be used inside of group resources, alerts, and reports.  We can't go into Manage Nodes and sort or group by Groups (which is kind of silly I think...).   The other answer would be to have a True/False property for each application and business service, but we have dozens and dozens of them.  That would be stupid.  And, if we try to list all of the application groups or business services a node is a part of in one custom property, we will have many nodes that will have multiple values in a single field...  That isn't super helpful either when it comes to grouping or sorting. 

       

      What do you guys and gals do to make things easy to find in Orion and keep things organized.  We need some ideas and I'm pretty stumped on this one.

       

      Thank you for any ideas

        • Re: Idea's for Labelling Multi-Application Servers in Orion
          d09h

          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.

            • Re: Idea's for Labelling Multi-Application Servers in Orion
              xtraspecialj

              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.

            • Re: Idea's for Labelling Multi-Application Servers in Orion
              rschroeder

              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. 

               

              For example:

              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).

                • Re: Idea's for Labelling Multi-Application Servers in Orion
                  xtraspecialj

                  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.

                    • Re: Idea's for Labelling Multi-Application Servers in Orion
                      rschroeder

                      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.