first of all im new to solarwinds, have only been using the product for roughly 3 months, so please be nice LOL-
This a loaded, yet, very vague question. Im just looking for general guidance/suggestions/tips. I have been tasked with organizing all nodes our agency currently has in SAM. They have alerts set up and have been configured properly. I have no idea how to even start or where to begin although I have done a little bit of research on the subject. We are likely going to start at the top being the "IT Services and business services" , then work our way down to application, then to environment (PRD,DR,QA) etc.
What are some ways that you all have structured your organizations nodes ?
What are some ways that you all have structured nodes under different teams within your organization?
Any tips or advice would be greatly appreciated.
I'd suggest to use Custom Properties as powerfull tool for control and manage of many SolarWinds software functions and features. Each company uses own set of Custom Properties following it's needs and internal procedures so it is difficult to settle specific proposals. So I can advise to use Custom Propoerties as control matrix.
You can use Custom Properties for nodes, alerts, reports, applications, interfaces, volumes and groups as steering console. Combination of use of different Custom Properties and ability to dynamically change of values within Custom Properties allow precise selection, categorizing, grouping etc. of relevant elements.
Not sure if this is detailed enough, but here is part of how we group things.
At a high level we group by location, then application. (using custom properties and dynamic queries to add things in the future automatically.) Then I have three groups under the "ApplicationName_Group" called "ApplicationName_NODES", "ApplicationName_OS", and "Application_SA". In the Node group I add just the phyical nodes for an up/down status of the hardware. In the "Application_OS" group I add only basic SAM application/component monitors that will affect the OPERATIONAL STATUS of the application. In the "Application_SA' group I add my more in depth SAM components that the only the SYSTEM ADMINISTRATOR would care about. This structure allows me to Alert more granularity on the severity of an issue. We also use SolarWinds for some of our SLA metrics using the "Application_OS" group to reflect only issues that affect availability to our customers.
So when youre actually grouping them, how do groups and custom properties tie together? do assign a custom property to a node, then assign it to a group ? or vice versa ?
In my case, the groups follow the custom properties. We are planning on creating dynamically assigned groups, and then having the conditions be based on the values in the custom properties. That way, whenever a node is given a certain custom property, it's automatically added to the group.
Custom Properties are your lifeline. Use them for these type of categorizations so you can easily search, report, and create context specific alerts.
Our environment uses:
Contact_Email (Node Contact Email Address - Use a Team Email)
Contact_EmailCC (Used for CC Fields in Email Alerts)
Contact_Name: (Contact Name)
Environment: (Logical Environment - Prod, STG, TST, Etc)
IgnoreCPUThresholds (Ignore CPU Thresholds in Alerts. Will not trigger High CPU alert)
IgnoreMemoryThresholds (Ignore Memory Thresholds in Alerts. Will not trigger High Memory alert.)
Latitude: (Lat/Long coordinates of the Node)
Longitude: (Lat/Long coordinates of the Node)
NodeCustomAlertNotes: (Node Custom Alert Notes)
Notes: (General Notes about the node)
PhysLocation: (Physical Location City)
Primary_Purpose: (Node Primary Purpose)
Primary_Support: (Node Support Team)
RunBook Service Name: (URL to Runbook)
SLA: (Tier Level)
Question, do you have your custom properties limited to specific types (like nodes, interfaces, alerts, etc.)?
Your list is very similar to what I'm proposing we use, but I'm kind of unsure how far to let duplicate custom properties sprawl, as it were.
Yes, we limit custom properties usually to Nodes, but that is more of a feature on how we grew with the product suite. We started with NPM and designed the alerting based on custom properties to ones linked to nodes. As the suite has matured the ability to add custom properties to other element types has also grown. It all depends on how you want it structured.
We use custom properties on other elements for excluding things from alerting. On the Interfaces tables, for example, we have an IgnoreUtilizationThresholds and an IgnoreUtilizationReason. We do the same thing for for Applications, Volumes and Groups to keep the same logic in the alerts.
Use the ability to force important properties using the "Required property" and "Restrict values" to a drop-down list whenever possible to limit bad data accidentally getting added in.
can there be multiple properties assigned to one node ? if I have a node that falls under a business service, then go under a type of business service, then under an application ? then maybe view them like that ? so I can select have a node then view which categories it falls under ?
I have some nodes that are currently being reported under multiple groupings, I would prefer not to change the scheme up.
Example of question-
Child Support Service - 1st grouping
CAMS - 2nd Grouping
CAMS - PRD 3rd Grouping
CAMS - PRD(QA,DEV,BW) 4th grouping
CSPCPRD01 - Node Name
I was told by another solarwinds admin at a different state agency that custom properties are going to be crucial in organization, im starting to see why.
So I have seen that our BSM (HP's monitoring tool that solarwinds is taking place of) has a "tree" style organization structure. Once custom properties are assigned to our nodes, is there a place to "view" all the assigned custom properties in a "layout" type view ? More specifically so I could assign certain users to the appropriate custom property, etc?
thanks for your help, I hope im making sense.
Yes, there are several places you can see what nodes are assigned to what property.
The one we use all the time is the Manage Nodes screen (Settings - Manage Nodes). Change the "Group By" to the Custom Property you are looking for or add in a custom property column in the display to show what you are looking for.
Another way would be to create a report which what you are looking for and export that to excel. You could also manipulate mass amounts of nodes directly in the Custom Property Setting (Settings, All Settings, Manage Custom Properties)
You can even export the BSM custom properties into a csv, txt, or spreadsheet and import them into Orion.
Good Overview in the Success Center
im sure ill have another question about the above answer, but first comes to mind, is there a widget that you can put on your dashboard to be able to see the custom properties in a laid out format ? so I can have certain users only see what they need to see, via their appropriately assigned custom property for the team they are on ?
One way you can restrict views is to use one of the custom properties. For example, we use the Primary_Support custom property to designate which node is "owned" by a particular IT Support Team. We use AD to create groups per IT Team, then assign a custom default homepage per Team and restrict their homepage to a custom property.
If you want to just show particular values with a widget you can use the Custom Table widget and select whatever datasource you desire.
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.