Integration with Service Now

• Introduction and operation
• Integration configuration
• Plugin options

Introduction and operation

This plugin enables the automatic creation, update and closure of Service Now incidents from Pandora FMS. 

Creation of incidents

In case an altered status (e.g. Critical, Warning) is detected for the modules configured in Pandora, the integration plugin will be executed to create an incident in Service Now, or to update it in case it already exists.

The information used to create the incidents in Service Now is:

• Name of the failed asset. Must match the name specified in Service Now. It is recommended to use the agent's alias or name for this. 

• In case a valid asset with that name is not found, the incident will be generated with a generic asset “PandoraAPI”.

• Title of the incident, indicating the names of the affected agent and module.

• Descriptive message of the error. Fully customizable, being able to indicate, among others:

• Name of agent.

• Name and ID of the affected module.

• Condition and value of the affected module.

• Date and time of the problem.

• Indication that the incident has been generated with a generic asset, if so.

• Other data necessary for the generation of the incidence, such as:

• Prioritizing advocacy

• The opening group 

• If applicable, data required by the SN itself, such as environment, object and operational type. 

When the incident is created, Pandora stores its ID in the custom_id field of the affected module for its later use in updates or for its closing. This implies that each module can only have one open incident in Service Now.

Update of incidences

In case the plugin acts on a module that already has an issue registered in its custom_id, this reference is taken to update the open ticket, which can:

• Add an internal note to the ticket with the relevant changes in the module (e.g. change of status from Critical to Warning).

• Change the priority of the issue

Closing of incidents

The integration can also be used to close incidents associated to modules, as long as they have an incident ID in their custom_id. In this case the purpose of such execution is the validation of the issue in Service Now. For this purpose the plugin:

• Acquires the ID of the open issue for the module in its custom_id field.

• Remotely closes the Service now incident, adding a resolution epilogue to indicate that the incident has been closed automatically from Pandora FMS.

• It empties the custom_id of the affected module in Pandora FMS, so a new problem in this module will start the process from the beginning, with a new incident.

The flow for creating and updating requests is shown in the diagram below.

 

Integration configuration

Pandora FMS prerequisites

For the integration to work properly:

• The Pandora server must have connectivity with the Service Now server web.

• The Service Now API must respond within the maximum times set in the plugin (5 seconds).

• Pandora FMS must be provided with a user in Service Now with sufficient permissions to create and close incidents via API.

The Pandora FMS user used must have, at least, AW access (Agent Write) on the group of agents that are going to trigger the alerts.

Plugin options

• Action (--Action '<create/close>'): With the "create" option, the plugin creates or updates tickets. The "close" option is used to close them.

•  

  Asset (--Asset '<cmdb_asset>'): The name of the asset that will be used in the incident. If the asset is not found, a generic one will be used.

•  

  Agent (--Agent '<pandora_agent_name>'): The name of the Pandora agent that generated the alert.

•  

  Module (--Module '<pandora_module_name>'): The name of the module that generated the alert.

•  

  Module ID (--IdModule '<pandora_module_id>'): The numerical ID of the module that generated the incident.

•  

  ServiceNow URL (--Host '<login_url>'): Base URL of ServiceNow.

•  

  ServiceNow Incident Integration URL (--HostAPIUrl <sn_integration_url>): URL for ServiceNow incident integration (e.g., /api/customer/incident_integration/).

•  

  Authentication Type (--Auth '<basic/oauth>'): This integration uses "basic," but OAuth is included as an option.

•  

  ServiceNow User (--User '<sn_user>'): Username for accessing ServiceNow.

•  

  ServiceNow Password (--Pass '<sn_pass>'): Password for the ServiceNow user specified in --User.

•  

  Proxy URL (--ProxyUrl ‘<proxy_url>’): URL for proxy access. Optional.

•  

  Proxy User (--ProxyUser ‘<proxy_user>’): Username for proxy access. Optional.

•  

  Proxy Password (--ProxyPass ‘<proxy_pwd>’): Password for the proxy user specified in --ProxyUser. Optional.

•  

  Pandora API URL (--PandoraAPI '<pandora_api_url>'): URL for accessing the Pandora FMS API (e.g., https://pandoraserver/pandora_console/include/api.php).

•  

  Pandora API Password (--PandoraAPIPass '<pandora_apipass>').

•  

  Pandora Access User (--PandoraUser '<pandora_user>'): User for accessing Pandora FMS. Must have at least AW permissions.

•  

  Pandora Access Password (--PandoraPass '<pandora_pass>’): Password for the user specified in --PandoraUser.

•  

  Assignment Group (--Group '<ticket_assignment_group>’): ServiceNow group to which the created incident will be assigned.

•  

  Impact (--Impact '<ticket_impact>’): Priority of the incident created in ServiceNow.

•  

  Title (--Title '<ticket_short_description>’): Title of the incident in ServiceNow. Only required when opening incidents.

•  

  Description (--Message '<ticket_description>’): Description of the incident in ServiceNow.

•  

  Incident State (--State '<ticket_state>’): Numeric code for the incident state. Only required when closing incidents.

•  

  Log File (--Log '<log_file>’): Full path to the log file where the plugin execution data will be stored. Optional.
  

Complete example of a manual call to open (or update) incidents:

pandora_sn_ticket.64 --Action 'create' --Auth 'basic' --Host 'https://my-service-now.com:1234' –-HostAPIUrl '/api/customer/incident_integration/' --PandoraAPI 'http://192.168.1.1/pandora_console/include/api.php' --User 'sn-user' --Pass 'sn-pass' --PandoraUser 'pandora_user' --PandoraPass 'pandora_pass' --PandoraAPIPass 'pandora_apipass' --Asset 'MYSERVER' --Agent 'MYSERVER' --Module 'CPU Load' --IdModule '12345' --Group 'infrastructure' --Impact '1' --Title 'Host MYSERVER is overloaded' --Message '2024/10/22 09:16:53 - Host MYSERVER CPU usage is too high - Data: 97% - Module status: critical' --Log '/tmp/pandora_sn.log'

Complete example of manual call for incident closure:

/pandora/pandora_sn_ticket.64 --Auth 'basic' --Host 'https://my-service-now.com:1234' –-HostAPIUrl '/api/customer/incident_integration/' --PandoraAPI 'http://192.168.1.1/pandora_console/include/api.php' --User 'sn-user' --Pass 'sn-pass' --PandoraUser 'pandora_user' --PandoraPass 'pandora_pass' --PandoraAPIPass 'pandora_apipass' --Module 'CPU Load' --IdModule '12345' --Message '2024/10/22 14:04:17 - Host MYSERVER CPU usage is OK now - Data: 24% - Module status: normal' --State '1' [--Log '/tmp/pandora_sn.log']

Examples of alerts

Below are a couple of examples of alert configuration: opening and closing of events, which will be separated into two commands and two different actions.

In order to make the integration more flexible, it is recommended to use macros in the fields of the commands that need dynamic information. In this case, macros for agent, module and module ID aliases (_agent_, _module_, _id_module_) are used, as well as alert-specific macros (_fieldx_) to facilitate the customization of actions.

Creation/updating of incidents (high priority)

Command

Ejemplo de comando de alerta para crear incidencias

Action

Example of alert action to create incidents

Closing of incidents

Command

Example of alert command to close incidents

Action

Example of alert action to close incidents