Why use custom properties in NPM?

Custom properties are user-defined fields (such as country, building, asset tag, or serial number) that you can associate with monitored network objects.

Every object you monitor includes a list of default properties used to describe the device, such as IP address, host name, MAC address, and so on. You can also create custom properties and use them to create special alerts, reports, views, and groups. Applications can also have custom properties.

Frequently used custom properties include:

Site

While the Location property is available by default and returns the city specified in the device’s settings, you may need to include additional details about the location.

Examples: Rack_Number, Closet_Location, Building_Name, Building_Floor, Building_Acronym

Use: Create groups of items in the same location, build maps, or route alerting information.

Function or Type

SolarWinds recommends organizing your objects by type or function.

Examples: Core_Network, WAN_Interface, Wireless, Server, Domain_Controller, VPN, Windows Servers, Linux Servers, Email Service

Use: Apply special alerting criteria depending on the type of element. For example, if any Core_Network element has problems, escalate the case immediately.

Owner

You can use multiple custom properties to specify who is responsible for an element to help route alerts or create reports.

Examples: A group owner name, such as Networking, SQL_Admins, AD_Admins, or a specific owner.

Uses:

• Define a Contact Email and On_Call_Phone for owners. If there is a problem with a node, the alert can be routed to the correct person.
• Provide a custom view for owners to see their devices and create custom reports, showing only devices they are responsible for.
  
  

Service level

Some monitored elements (such as core routers, switches, and applications) may be important enough for someone to be notified any time of the day when there is a problem.

Examples:

• Mark nodes as Critical, and configure alerts to notify.
• With service levels, this custom property can help you specify whether it is 24x7, a business day, or test node, and alert appropriately.

Customization checklist

Before you customize your environment, answer the following questions:

	How would you like to logically organize your devices? For example, Location, Site, Lab, and Rack? Function?
	What data type is each custom property? For example, boolean, integer, drop-down options only, free-entry text?
	What are your owner groups? For example, who is responsible for the Windows servers, Linux servers, devices, applications, and so on?
	What are the sites and locations you want to report and alert on?
	Do you need to distinguish between high impact objects that must be addressed first (for example, production) and low impact objects that are of lesser priority (for example, development)?
	Are there any overrides for specific objects you require for alerting?
	Are there any devices, servers, applications, and so on that you want muted (continue to collect data but not see alerts)? Do you want to stop alerts during different periods of the day or night?
	Do you want to associate any assets with a purchase date, PO number, vendor contact information, and so on?
	Are there any fields you will need to add to allow for integration with other systems? This Orion SDK post provides more information.

Tips

• You can use custom properties to define alerts, reports, and web console views. Use multiple properties together with 'AND' and 'OR' operators for powerful filtering and definition options.

• For each custom property, decide how you are going to use it and how it will work in your environment. For example, instead of a comment on an interface that reads "WAN Link interface - critical interface," try two different Yes/No values, such as "Critical Interface" and "WAN link," which could each apply to multiple interfaces. This approach makes it easier for you to filter reports and alerts. When used together (Critical = true AND WAN link = True), it still applies to that interface.