A problem state may be opened which will never be closed by detection

[hmpf]

There is another issue which may need to be discussed, related to my experience with NAV.

A problem state may be opened which will never be closed by detection. E.g.:

• If an admin physically removes a piece of hardware from a router, NAV will detect this and flag the problem.
• However, the hardware was removed on purpose and will never be re-inserted. NAV will only consider the problem resolved once it detects the hardware as having been re-inserted, so the problem will stay open indefinitely.
• The NAV admin solves this by manually resolving the problem from NAV's status UI.
• However, this closes the problem state in NAV, but never sends an event/alert through the system.
• This would cause the problem state to stay open in AAS, while it's closed in NAV, and the two systems will be out of sync.

So, what would be the best way to ensure the updated problem state in NAV is propagated to AAS? That's a discussion we need to have...

Originally posted by @lunkwill42 in #45 (comment)

[lunkwill42]

While I'm thinking about possible suggestions, I might add that the same issue would arise if the resolving alert never reaches AAS for some reason (server errors, network errors, whatever issues). We could always make NAV generate the corresponding alert to trigger dispatch to AAS - but the generic issue remains - a resolving alert may never reach AAS and it will become out of sync

[hmpf]

Looks like we need both an ack-function and an stay-dead-function I'd say. UI-wise... the turn-off button needs be less comfortable to use so it isn't triggered by accident.

[lunkwill42]

Yes, we need a function for manually closing an alert by a human using the frontend. This would be logged to the Event table, associated with that user, as the event is closed, so you can see the difference between an alert that was resolved by message from the alert source, and one that was closed manually. NAV has this same function.

[hmpf]

We now have a manual way for a human to close an incident.

I wonder: could we also have an agent that can close "old" incidents? Maybe if we decommission a source, we could ask that agent to close everything from that source. Which reminds me, some logic only in the api needs to move to the models/queryset.

[lunkwill42]

Adding a note from an old discussion concering the glue service for NAV: We expect to make the glue service itself able to sync pre-existing NAV problems to Argus - making it able to do it the other way around might be just as interesting - i.e. make it able to see which of its active Argus incidents have already been closed in NAV, and update the Argus Incidents.

[katsel]

• Argus has a manual method for closing issues now.
• Automatically closing old issues is a different issue Automatically close old incidents #252