How best should I add a variation to an alert in NPM?

We have numerous alerts from node up/down to interface up/down, etc.

What I now need to do, is find a way to create a new alert or edit these alerts so as to exclude or include certain nodes. I imagine a custom property is the best way, but I'm trying to avoid editing 30+ alerts to exclude this CP whilst at the same time creating a new alert for these excluded nodes.

Here's the detail.

Traditionally we have been a data only team, but with automation, reduction on staff numbers, etc, etc we are having to (like most I guess) broaden our scope. So one of those scopes is voice. At this stage we still have a separate voice team, so for the few nodes we add, we want to have the alerts (node and interface only at this stage) go to the voice team via an eMail.

Currently all our alerts essentially are based on the following principle:

is it in BAU (business as usual - IOW, handed over for day to day support)
e.g.

So, going forward, what would be your suggested and/or best approach to now having voice alerts included in this principle but where their triggered action is completely different to the data ones? As we clearly want:

data alerts to carry on as is but not include voice and
voice alerts to go elsewhere

In my head I'm thinking CP and two new alerts for voice (node and interface) - but that would still mean I have to edit 30+ alerts to exclude that CP.

So my other thought was to extend the Node IN BAU CP (somehow) from true/false to true/false/voice and then set the new alert logic to be is node_in_bau = voice. The issue here is that this CP is a Yes/No answer, and would mess with various reports as well as alerts

Your thoughts please?

Find more posts tagged with

Custom Properties

Alert

editing

npm

Accepted answers

stuartd

Answer:

After all that typing lol I hit upon the answer.

We already have a CP called PRIORITY which exists for nodes and interfaces so I simply added an additional level and called it VOICE. That way I can set the node or interface to a priority of VOICE and then get the alert logic to look for that. As all our other primary alerts are based off of the priority being a 2, 3 or 4 then they won't trigger.

All comments

stuartd

An option could be:

create a new CP and call it say 'voice_support'
leave node_in_bau set to false
create a new alert for node and interface that says:
- if node_in_bau = false AND
- voice_support = yes
- then trigger

This gives me the benefit of not messing around with the node_in_bau CP and none of the current alerts are affected as they're only looking for in bau to trigger.

Yes / No / Messages saying don't be silly ?

christopher.t.jones123

@stuartd, you could take the approach of using a CP to define the email address of the recipient. you would then just need to modify the Trigger/Reset actions to point to that CP, but that can be done in bulk.

stuartd

Answer:

After all that typing lol I hit upon the answer.

stuartd

Thanks Christopher... if the scenario comes up again I'll go that route, as it is I had already hit upon another, equally as good approach that didn't mean adding any more CPs.

bobmarley

You are on the right track. We had a similar issue and we set up some custom properties such as Group, Priority, City, Street, Site Name, Email Group, Alert After Hours, etc. These tie into the alert logic as well as pass variables along onto our ticketing system for automation. So far as the alert logic goes you can use node = down plus Group = Telecom_Voice to separate off the voice nodes.

Some of the other custom properties such as Alert After Hours = no are used to mute alerts for certain sights that are closed in the evening and a tech can't get in to do a repair. Those will trigger in the morning around 7am so the tech can dispatch once the site opens.

The Email Group property can be used as a variable in the Send To field so if you need to sent emails to different groups you can accomplish it with that.

The rest of the properties are passed along to the ticket so the tech knows what site location to go to.

Perhaps you could first update your current alerts and then make copies of them as needed to create the additional alerts for the voice teams and simple make changes to the logic once created.

stuartd

Thank you. All grist for t'mill as they say over in parts of the north of the UK.

As with my reply to Christopher though I solved it by creating a new option in one of our current CPs that is referenced on almost all our alerts. That meant all I had to do was create two new alerts rather than edit 30+ of them.