What are your favorite Custom Properties?

Here are a few we use in our org for Nodes:

• Cust_VIP - Denotes if the "customer" or users are considered VIPs. This establishes priority for alerting, outage response, etc. If Cust_VIP = True then Device_Priority = 1.
• Device_Category - Usually denotes the overall category of a device such as Network or Server
• Device_Function - The specific function of the device. For example, "Exchange"
• Device_Model - Hardware model of the device
• Device_OSType - OS type (Windows, Linux, Cisco IOS, etc.)
• Device_Priority - This is a scale of 1-4. Priority 4 does not receive alerts. Priority 1-3 receive alerts, but have varying degrees of response (immediate, next day, next business day)
• Device_Vendor - Vendor of the equipment
• Loc_Site - Site name where the equipment resides
• Loc_Bldg - Bldg number or name
• Loc_Floor - Floor of the building in which the device lives
• Loc_Room - Room of the building in which the device lives
• Resp_Org - Organization/work center that is responsible for troubleshooting the device
• Resp_Phone - Phone number/contact info for the responsible organization

I'd love to build out CPs for e-mailing in the To: and CC: lines of e-mails, but this would be a huge architectural shift in how we currently handle alerting so I haven't been able to implement these just yet, but it would help us cut down on our hundreds of configured alerts and streamline these tremendously.

We also have an organizationally-defined node naming convention, which helps a lot. It makes it easy to identify where things are, what purpose they serve on the network, and if redundancy exists. 

Here are a few we use in our org for Nodes:

• Cust_VIP - Denotes if the "customer" or users are considered VIPs. This establishes priority for alerting, outage response, etc. If Cust_VIP = True then Device_Priority = 1.
• Device_Category - Usually denotes the overall category of a device such as Network or Server
• Device_Function - The specific function of the device. For example, "Exchange"
• Device_Model - Hardware model of the device
• Device_OSType - OS type (Windows, Linux, Cisco IOS, etc.)
• Device_Priority - This is a scale of 1-4. Priority 4 does not receive alerts. Priority 1-3 receive alerts, but have varying degrees of response (immediate, next day, next business day)
• Device_Vendor - Vendor of the equipment
• Loc_Site - Site name where the equipment resides
• Loc_Bldg - Bldg number or name
• Loc_Floor - Floor of the building in which the device lives
• Loc_Room - Room of the building in which the device lives
• Resp_Org - Organization/work center that is responsible for troubleshooting the device
• Resp_Phone - Phone number/contact info for the responsible organization

I'd love to build out CPs for e-mailing in the To: and CC: lines of e-mails, but this would be a huge architectural shift in how we currently handle alerting so I haven't been able to implement these just yet, but it would help us cut down on our hundreds of configured alerts and streamline these tremendously.

We also have an organizationally-defined node naming convention, which helps a lot. It makes it easy to identify where things are, what purpose they serve on the network, and if redundancy exists. 

Ours are very similar. 

The two fields that have always had a lot of importance are the Severity of the alerts as well as the Group field which is the Assignment Group within our ticketing system for that device. Have used three different ticketing systems and these are always parameters needed to passed on to the ticketing system.

Additionally we do send emails from the alerts as well so each device also has a team distribution list for the team that owns that type of device.