One-click alarm generation

Can you explain your “ticket” use case? Is it in relation to Openticket or do you have a notification rule set to directly create tickets?

Are you looking at “forcing” notification regardless of your resource status?

Or is this a matter of notification being sent only when a hard state is reached?

We do not use Openticket, we just use notifications rule (email) to create a ticket to our ticketing system.

Yes - exactly, I would like to have a option to force notification so that it will ignore what is configured as first notification delay to the host/service and it does not have reach the hard state.

I’m not sure how i can see a use to “force notification”, isn’t the “force check” enough in that case ?

Force check is not generating a alarm, it just forces quicker check.

I can give you an example:

Usually firewalls generate a ticket/alarm after they have been down for 15min. 

We receive a call from customer that nothing is working and firewall does not have any lights on (device is dead) and at the same time we see in our monitoring that device has been down only 5 min. With the one-click-alarm button I could generate an alarm/ticket right away and I down have to wait 10 more minutes for the system to generate a ticket or waist time manually creating the ticket in ticketing system.

​@katska I see what you mean with that use case, but in here then the issue has been raised manually by your user, not by the platform, so the ticket should have been made outside of the use of the platform, directly on the ticket system.

Maybe i don’t see this correctly, but meaning to create a ticket from the centreon platform early on as a third party raised a concern regarding an equipement feels like a workaround of the features of centreon.

Only my opinion.

I think we shouldn't focus on the word "ticket" in Katska's example.
I agree with her idea of forcing a notification regardless of the resource's status (soft-hard) and notification delay configuration (firstime, resent, ...).

Hi,

I don’t know all of your context, but if a user raises an alarm after 15mn of firewall breakdown, why not simply adjust your retry/check interval configuration, on this host, to match with the right criticity ? 

For example, with 5mn Normal Check Interval, 1mn Retry Check Interval and 2 Max Check Attempts, in case of downtime, you will be alerted in Centreon in less than 8mn, and will not have to force anything.

Maybe i forgot something ?

What is (and why) your current check/retry configuration for this host ?

This firewall issue was just as an example (Usually we have 15min for first notification).

But there are more example where we could use it: to test that the host/service is even able to send notifications (I know it is possible to test with 0 also, but that means I again have to change config); If engineer has by mistake broken a device with incorrect config, then we could generate a ticket right away and not wait until the first notification is reached (with some devices it can be so that device priority is 4 and by contract it means 2h first notification time).

Yes, there is always a possibility to generate a alarm/ticket in our ticketing system manually, but if I generate the alarm from Centreon, then the ticket will right away have all correct contracts, contacts and also CMDB info attached, and that will make sure there are no manual errors.

And I do understand, that this solution/idea is not for everybody as we all might have slightly different setups and ideas how something should work.