What are your favorite Custom Properties?

What are your favorite Custom Properties? We have our equipment divided into types and I'm working on adding branch numbers. Does any one use a field to descript the purpose of the equipment?

Parents
  • If I'm tracking what you mean by the 'purpose of the equipment' I will often see something along the lines of a device type, although sometimes that gets a little tricky when vendors release new hardware that crosses multiple niches, but we eventually figure out how we want to categorize those devices.  

    When it comes to properties the way I generally train people is that if they can ever think of a way they would need to break things up then there needs to be a custom property for it.  So if you need to know physical locations then a property for the Site, or if the device needs its tickets to go toward a different specialist team, or whatever logical groupings you ever come up with a need for.  It's kind of a never ending process because people will always be coming asking for a dashboard or report to show just their particular area of interest.

Reply
  • If I'm tracking what you mean by the 'purpose of the equipment' I will often see something along the lines of a device type, although sometimes that gets a little tricky when vendors release new hardware that crosses multiple niches, but we eventually figure out how we want to categorize those devices.  

    When it comes to properties the way I generally train people is that if they can ever think of a way they would need to break things up then there needs to be a custom property for it.  So if you need to know physical locations then a property for the Site, or if the device needs its tickets to go toward a different specialist team, or whatever logical groupings you ever come up with a need for.  It's kind of a never ending process because people will always be coming asking for a dashboard or report to show just their particular area of interest.

Children
  • I have custom properties for

    email_on_critical, email_on_warning.  These send an email if the node or SAM monitor is in those states. It's a comma separated list of email addresses, so you can set it to anyone... muhahahaha.

    OnCall_Group and OnCall_Hours.  The group is forwarded to our ticketing software so they know what group to assign it to.  The hours is used to limit when SolarWinds will create the tickets.  These are the only custom properties that are "required".  They also exist on SAM monitors, but not required as they will default to match the node, if they are null.  I wish the hours were more flexible so I could set it to actual times like "8:00am-5:00pm M-F" but that was too hard, so I just have 3 values "24 hours", "business hours", and "do not call".  This was setup many many moons ago... today I would probably handle this part inside the ticketing software... maybe.

    I use some of the built in ones like city, state, zip.  They are auto-populated from other sources of information.

    Priority (no longer used) was used to show what order it would come up in a disaster recovery situation.

    Static_Poller: This one is mostly for my internal use, I know some systems use IP restrictions to a single specific IP of the polling engine.  Though this is becoming less used.  Everything without this set I can move willy-nilly to balance things out.

    Documentation.  a link to the documentation for that node.  We never started using this one, but the custom property is still out there, and there is even still a widget that shows this link on the node summery.  It's been there for over a decade... still unused, maybe I should delete it.

  • Sometimes you can think of blank custom properties as a to do list.  Not sure your role in that organization, but if there is a gap in documentation its potentially a good project to plug those holes, but we all know documentation is like that last thing most companies actually allocate time to actually get done.