MikroTik

Hello everybody.

I've been having an issue since Dude 3.4. Now that there is new version, I thought the issue was resolved, but it wasn't. The issue is the following:

When a Device has a service in UP (Green) state, and this service goes down, The Dude triggers the notification and changes the state to DOWN (Red). When I review the outage, then I change the state to ACK (Blue) for the device. When the service is up again, Dude changes the state of the device to UP again. Up to here, everything is OK. The problem arises when the service for that same device goes down again. I would expect that The Dude triggers the notificacion and changes the state to DOWN (Red) as the first time to let me notice the outage and change the state to ACK (Blue) when I take some action. But, the problem is that it changes the state automagically to ACK (Blue) without any notification (currently, there is no Up->Ack transition notification parameter). With this behavior, I can't realize when a device is down again because i don't receive any notification. This erroneus (at least for me) behavior was not present in previous versions of The Dude (2.x).

Please be kind to explain me if this behavior is a bug or if there is a workaround to fix it.

Thanks and best regards.

ACK is designed to work in such way. Do not set ACK, if this service is important for you.

Wow. it's not good for me to read that... I was so comfortable with the dude since version 2.x, and for a long time I've recommended all my partners to use it because it's a good tool. Now, with this new behaviour, it reduces its usefulness for me and many of my partners.

I'll follow your advice, but think about modifying this behaviour or, at least, permit a choice about it... one could choice the expected behaviour of the ACK feature. I've been searching for this topic in some forums and I'm not alone; several people is asking for a fix for this issue.

Thanks again, and best regards.

Where is the problem to leave device as down, when service is down?

For us, ACK means that I noticed the Outage and I'm working on it to get it resolved. I'm not the only one that reviews the system. I have a staff team that monitors from different places. If I'm in place A and notice the outage, I change the state to ACK, so another one in place B knows that I noticed the outage and that I'm working on it. If I don't change the state, maybe two persons (or even more) will work on the same outage at the same time because nobody knows that someone noticed it. For me, this is the usefulness of the ACK state. It's an ACKNOWLEDGE flag. For me, it means that I know what's happening.

Currently the solution to click 'unack', when the issue is resolved.

Currently the solution to click 'unack', when the issue is resolved.

Devices go from up to unstable then to acked, Did you try checking unstable to acked?
At least then if you forget to unack a device you would get an email it changed state and needed looking at again.

edit some other work around ideas removed... some other thoughts.

I agree with rafaelenrike, I like the previous behaviour of The Dude much better. Why:

A device has a problem, it turns orange or red. You notice it, ack it so the scary orange/red is no longer shown and go on to fix the problem. Once fixed, the device goes back to green. Another problem? Please turn red again and do not 'auto-ack' to the non-warning blue. Nobody notices the blue! "Hey, that device turned blue! Is it a 'good' blue or a 'bad' blue?" Who knows?!

Alternatively, make it a choice (per device) if they should auto-ack or not. For unimportant systems (client PC's) auto-ack is great so you can see when they are online or offline, but they don't cause scary orange/red labels. For servers, I never want an auto-ack. Every time there's something wrong, I want to know about it with scary colors!

How am I to know which devices are on 'auto-ack' and which not? Should I have to unack every device once a week, just to be sure I am getting the 'reds' when an error occurs? I mean, who knows what others might have acked? I feel that is the biggest issue with this new behaviour: keeping track of the 'good' auto-acked and 'bad' auto-acked devices.

Dear All,


I fully agree that this a killerfeature. Who is able to track what was already acked 2 month ago!! If you work for yourself maybe but we use it in a team of several members.... It costs me time to track old alarms in another tool to probably get a reason why service a was acked if it was documented!

I would highly appreciate if you could go back to the 2.x state. Or a way to disable the ack/unack mech.


Cheers,
Stephan

If we're wishing here, I would actually prefer the option for it to behave both ways. There are times I'll have a link that is going up and down that I'll want to ack and have it remain acked until I manually turn it off. There are other links where I'd prefer the ack to expire as soon as The Dude detects the unit again. I'd love to have two different ack options that I could pick from with the two different behaviors.

Feature request...think you can do it Mikrotik?

Perhaps a good compromise would be to have an "up-but-acked" state. This would be easily sorted in the device list and visible (maybe with a nice aqua) in the dude view so that if the issue is resolved, you can still easily tell that there is a persistent ack applied to it after the services have come back up.

Perhaps a good compromise would be to have an "up-but-acked" state.

That is a great idea. We are in the same boat where we have a top map view with various submaps so need to ack alarms we are working on so we can instantly see if another alarm occurs in the sam sub map from the top view. If ack'ed fault is resolved it is easy to forget to unack the device and so if another fault happens at a later date we have no way to tell. Either a different colour for up but ack'd or some report that can show all ack'ed devices would be ideal.

Has anyone tried to create a new notification and set ack->up to at least notify your self that you need to Unack a device.

Yes but this is still too easy to miss.