One of the things that is really great about Orion is that you can be up and running in under an hour with a basic setup. For the most part a small team doesn’t want to spend a lot of time fussing around with the monitoring tools. Set it and forget it.
I sometimes work with clients who haven’t actually logged into their Orion server in a few years and that is exactly what they were hoping for. They are looking for alerts that are to the point and clear, maybe some basic reporting, and we don’t need to get as intricate with the custom properties.
We may not have a use case for every bell and whistle in Orion so we focus on the low hanging fruit, easy to implement with actionable information. The admin team typically knows what is in their environment so just seeing the host name of a problem node gives them most of what they need to know.
On the other hand, the Orion is extremely flexible and you can get as elaborate as your needs dictate. As an organization becomes more complex they find that there are places where they would benefit from spending some time tailoring the products to fit their particular needs.
One example is where different teams will need to be notified if their node goes down. A common mistake people make when they start to get to this point is to just make a copy of their existing Node Down alert and just change the criteria to exclude some of the nodes and set a new recipient for the alert message. The problem with going down this road is you can easily end up with having to build several versions of every alert, which becomes an administrative hassle. It becomes harder to know if any particular node would trigger an alert because there gets to be lots of exceptions and edge cases to try and keep track of.
Instead of hard coding a specific alert recipient into each variation of the Node Down alert you can create a new custom property like Alert_Email and insert the variable for it into the “To:” line of the email action of the single Node Down alert.
Now you can use the custom property editor (YOURSERVER/Orion/Admin/CPE/InlineEditor.aspx?) to set an individual recipient for each node in the environment without having to build several versions of the alert. The network team can get the alerts for their nodes and the Windows team gets theirs and none of them have to get spammed for things that they don’t need to know about.
Custom properties are vital to organizing your monitored objects and grouping them up. Admins works in complex environments will usually end up creating properties to split things by the different teams, production or testing environments, identifying critical WAN interfaces, and any other ways they might need to group things up or filter them.
Marc Netterfield
Field Systems Engineer
