Nagios XI and Servicenow Integration problem

[capgemtools]

Hello Support,

We have Nagios XI servers integrated with Enterprise Service Now. We are using the PULL method where in Service Now has a Nagios connector which connects Nagios XI alert DB and fetches the alerts every two minutes. We are having a problem generating a ticket in Service Now based on Nagios Critical alerts.
For e.g. for some services we have a frequency of 5-5-3. first 5 being the check interval, second 5 being the retry interval and last 3 is for max check attempts. In this case Nagios generates first two alerts as soft1 and soft2 and the third alert will be hard3.
Ideally we should have a ticket auto generated on hard3 type of alert but service now is generating it on every type of alert.

is there a way we can differentiate these alerts and make ticketing tool easy to understand on what alert the ticket should be created.

[cdienger]

We don't have a servicenow system so you'll want to probably check this with servicenow support, but I believe what you want to do is create an event rule to handle the Nagios events so that service now only triggers for hard states - https://docs.servicenow.com/bundle/pari ... rules.html.

[capgemtools]

Hello Support,

We want to understand how Nagios is differentiating between soft and hard alert so that we can only pull hard alert instead of soft alert.

[cdienger]

It uses the $HOSTSTATETYPE$ and $SERVICESTATETYPE$ macros to indicate a SOFT or HARD state: https://assets.nagios.com/downloads/nag ... olist.html

You can see this macro in use in the /usr/local/nagios/var/nagios.log.

[capgemtools]

Hello Cdienger,

Thanks. We tried disabling log_hosts_retries and log_host_retries parameters in main Nagios config file, but it stops logging only event logs. The data is still being updated in hostchecks and servicechecks tables of Nagios DB.

Is there a workaround to stop putting soft alert data in these databases so that service Now only pulls hard alerts. Please remember we would still want to use the number of checks being done using maximum check attempts to recover the alert before it reaches hard state.

[cdienger]

The database cannot be altered this way. The query that service now uses would need to be changed.