Page Comparison

Run the following command: 

rpm -i jsm-nagios-<your_version>.rpm

Before rpm upgrades, back up your configuration files.

The rpm package does not overwrite the existing configuration during upgrades. It saves the new default configuration file as integration.conf.rpmnew. To Add the-- force parameter to upgrade from version 201X-XX-XX to 2.X.X, add the --force parameter. For example: rpm -U --force jsm-nagios-<your_version>.rpm

Learn more about config file handling for rpm upgrades.

Configure by entering flags to command in the jsm.cfg file. Use -apiKey flag for your apiKey and -ns flag for the nagios_server name. If you don't have multiple Nagios servers, you don't have to define the Nagios server. Using flags overwrites all the other configuration methods mentioned earlier.

Configure the apiKey from the jsm.cfg file as follows (in JSON format):

define command {
    command_name    notify-host-by-jsm
    command_line    /home/jsm/jec/scripts/send2jsm -apiKey="apiKey1" -entityType=service ...
}

When apiKey is added to the cfg file, it overrides the apiKey in the integration.conf file.

To send additional custom arguments, add them after the flags. For example, customArgName1 customArgValue1 customArgName2 customArgValue2. Parse custom arguments by adding {{_payload.customArgName}} to wherever is needed in the input fields. To learn more about using raw parameters, see dynamic fields.

Run the following test command from the shell and check if a test alert is created in Jira Service Management: 

/home/jsm/jec/scripts/send2jsm -entityType=host -t=PROBLEM -hs=DOWN -hn=test_host

• If you get a "Trace/breakpoint trap" error, the send2jsm plugin isn't compatible with the server distribution. Rebuild send2jsm.go according to the specific server environment as described in the “Source and recompiling send2jsm” section in this article.

• If the alert is created in Jira Service Management, the integration is configured correctly. Nagios is probably not notifying the Jira Service Management contact for alerts. Check your Nagios alert notifications log.

• If the alert is not created in Jira Service Management, check the logs at /var/log/jec/send2jsm.log.
  Look for the following errors in the log file:

  • If you see "RestException[Could not authenticate.]" in the logs, Jira Service Management couldn't identify the API key. Check if the API key is set correctly per the steps outlined in the “Configure the Jira Service Management plugin in Nagios” section of this article.

  • If unsure of the problem, set the plugin's log level to debug and try again. Contact us and share the logs.

• If there is no /var/log/jec/send2jsm.log file or there are no logs in it, check the following:

  1. Check if the Nagios user has permission to write to /var/log/jec directory. The installation package should automatically do this for you. If you face issues, run the following command: 
     chown -R nagios:jsm /var/log/jec

  2. Check the Nagios server logs at /opt/nagios/log/zeneventd.log. See if there are error logs regarding send2jsm. Contact us with the logs as if needed.

Set send2jsm plugin's log level to DEBUG

Set the send2jsm plugin's log level to DEBUG. Open the /home/jsm/jec/conf/integration.conffile and change the line send2jsm.logger=warning to nagios2jsm.logger=debug.

Check the alert logs.

• If "Posted [Acknowledge] action to Nagios.." is not present in the log, Jira Service Management didn't send the Acknowledge action to Nagios. Check the integration configuration, it might not have a matching the alert action.

• If only the "Posted [Acknowledge] action to Nagios.." log occurs followed by no related logs, it might mean JEC is having connection problems. Check the logs.