This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Custom Properties - What are you using and why?

What custom properties are you using, and why?

  • We use a lot of custom properties, mostly to mute or redirect alerts and to cause things to appear on different maps.

  • We use them for device location, device ownership including monitoring escalation information, and build state. And we build groups around them, which in turn can be used for alarms and reports.

  • We use the custom properties to help assign an asset to a user and/or a department.  We also use it to put servers in groups (development vs production) for alarms and alerts as well. 

  • alert recipient email addresses--initially because there used to be a limit of approx. 220 characters in alert utility GUI (probably in 2012).  I had to update too many alerts too often so I just started using a custom property

    device type/ team/ regional gateway

  • I treat CPs in two ways:

    1. As a funnel... start with the CPs that split your estate into sensible, logical, chunks, then work down to the specifics. Good CP use is key to getting the most out of Orion, as they are used everywhere!
    2. For specific reporting purposes. For example, if you want to be able to report on all the ADSL circuits your company uses, create an 'interface' CP called something like 'ISP_Link', and assign it to your ATM interfaces!

    It's all about stripping the onion that is your monitored estate down into the logical layers that represent your business areas, and using CPs to represent them emoticons_cool.png

  • As silverbacksays​ mentioned, they are used everywhere.  There are common ones like site name, site number, contact person, alert email address, alert muting, etc.  I've also used ones like volume thresholds, latitude/longitude for automated world map population, patch windows for scheduled unmanagement, etc.  Those are just the ones off the top of my head that I've used in the last couple of months.  I'm sure there are a ton that I am forgetting about.

    It's funny, a recent client I was working with kept asking off the wall questions about ways to do different things.  It seems like all of my answers involved creating a new custom property.  I asked him at the end of the day if he got how powerful custom properties were and his answer was a resounding yes.

  • We use custom properties in many different ways.. here are some examples:

    • Dynamic Alerting
      • Trigger Variables
        • Our alerts are setup with default thresholds such as "90% space remaining" for a volume.. But we expand on that by creating a property "Alert_Vol" which lets us choose to alert anywhere from 80-100% based on the need. This lets us have a single alert for many different cases/system.
        • Similarly we have other fields like "Alert_Suppress" which if set to true will prevent all alerts from firing for that system. This is great because the node can continue to poll and shows its status in the console but we prevents the false positive emails, tickets and even our home pages and NOC views are setup to ignore nodes set to "true".
      • Email Actions
        • We have a Primary (TO), Secondary (CC) and Ticket email address on every node. This lets us direct emails to the appropriate teams and create tickets for the right group. Again all with a single alert.

    These changes let us reduce our number of alerts definitions from well over 50 down to 20. And our alert actions are greatly reduced as well.. This really helped in the management and control of our alerts.

    • Inventory Integration
      • We pull about 20 or so fields from our inventory system into Orion via an automated powershell script.
      • Some of the ways we use these fields are:
        • Alert Trigger Variables
          • Similar to Orion only properties we pull over things from our inventory that let us dynamically adjust alerts. ex. pulling "Patching Day" lets us suppress alerts during a systems patching cycle to prevent false positives.
        • Alert Email Content
          • With these fields available we are able to produce alert emails that have both our Inventory and Orion content together. This greatly assists our tech's in understanding the impact of the alert and often leads to faster resolutions..
        • Grouping
          • We have multiple dynamic groups setup to key off fields from our inventory - One of the big ways we utilized this was to create a Network map showing our Physical rack statuses based on the Rack ID's in our inventory.
        • Reporting
          • The additional information lets us produce reports that combine inventory information with Orion polled information which is invaluable to our various teams and our management.

    Before we used this integration our teams were trying to manually set/update fields in multiple systems.. This streamlined things and reduced the duplication effort. It also gave me as the admin more control since far fewer people needed node management access, etc. We are planning to expand this further to include automated node setup/removal and flowing information back from Orion to our inventory..

    If you are not using custom properties I highly suggest you take a look them - There is countless uses for them and they will undoubted make your Orion monitoring better!!

  • We've used them while migrating peering links from one DC to another. We would mark all the links to be migrated, along with the connection name and AS number. At a pinch we could run a report for all currently connected ports that were marked as to be migrated.

    As we proceeded with the migration the number of ports on the report would keep dropping.

    Our second useful custom property was for transit links, we could record what the commit level was, again for easier reporting.

    Along with this much of the standard location etc, as mentioned above.

  • Geographical location

    Device owner

    Service owner

    Device grouping

    Alert muting

    Finally and probably the most painful NCM scripting. It is only painful because interface custom properties cannot be referenced within NCM which ends up being a huge drawback for me since I I would like to use the interface properties in my remediation scripts.

  • There will be a class on 9/21/16 over custom properties. It will be recorded and posted in the Customer Portal for later viewing. https://thwack.solarwinds.com/events/1878