OTRS implements a basic interface to system monitoring suites.
Note
A network monitoring system, such as Nagios, Icinga2, HP OpenView or similar, capable of sending out events via email is required to use this feature.
Control Flow for Nagios
For Nagios, it works by receiving email messages sent by a network monitoring suite. New tickets are created in case of component failures. Once a ticket has been opened messages regarding the effected component are attached to this ticket. When the component recovers, the ticket state can be changed or the ticket can be closed. If an open ticket for a given host and service combination exists, all mails concerning this particular combination will be attached to the ticket until it’s closed.
The following control flow illustrates how mails are handled by this module and in which cases they trigger which action. Pretty much all checks are configurable using the regular expressions given by the parameters listed below.
-
Mail matches
FromAddress?-
NO → Continue with regular mail processing
-
YES → Does a ticket with matching host and service combination already exist in OTRS?
-
NO → Does
State:matchNewTicketRegExp?-
NO → Stop processing this mail (silent drop)
-
YES → Create new ticket, record host and service, attach mail
-
-
YES → Attach mail to ticket. Does
State:matchCloseTicketRegExp?-
NO → Continue with regular mail processing
-
YES → Change ticket type as configured in
CloseActionState
-
-
-
Besides of a few additional sanity checks this is how the system monitoring module treats incoming mails. By changing the regular expressions it should be possible to adopt it to different monitoring systems.
Icinga2 Acknowledge
For Icinga2, it works by specifying a host and a service in ticket dynamic fields. This combination of host and service is used after a ticket lock is set to generate a HTTP request which is send to the configured Icinga2 host. In Icinga2, this request is used to create or to confirm new incidents.
A new ticket is created with values in the specified dynamic fields which are needed as combination of host and service for the communication to the Icinga2 host. After this newly created ticket is locked to an agent, a HTTP request is send to the configured Icinga2 host. In the Icinga2 host a new acknowledge is created or an existing one is confirmed.
System Configuration for System Monitoring
There are two useful functions, which can be used to automatize the workflow based on the messages from the system monitoring suites. However, both functions are turned off by default, and they can be enabled in the system configuration.
Note
The OTRS Configuration Management feature is required to use these functions.
Link Incident Ticket with Configuration Item
An already opened incident ticket can be linked with the affected configuration item. This is only possible when a subsequent system monitoring email arrives.
The setting SystemMonitoring::LinkTicketWithCI needs to be enabled to use this feature.
This feature has no agent interface, but in case the incident ticket linking with configuration item and the incident state setting are enabled, the list of configuration items and the list of services can be changed based on the incident tickets.
For more information, read the Services and the Configuration Items chapters in the OTRS::ITSM manual.
Set Incident State
It is possible to set the incident state of a configuration item automatically when a system monitoring email arrives.
The setting SystemMonitoring::SetIncidentState needs to be enabled to use this feature.
See also
External programs to be run by OTRS are blocked by default due to security reasons. You have to add the program to the allow list as described in the Allow Program Safe to Run chapter.
