Final documentation how to enable the notifications in Icinga

[one7two99]

Hello Dennis, I have installed the plugin and configured the webex bot so that I can successfully use the plugin to send a webex notification via CLI to make sure everyhing is setup correctly. I am now struggling a bit to setup everything in icinga and I would like to contribute to the documentation here, if its working.

What I did so far:

Checked that the command is working from CLI

    ./main \
      --token <WEBEXTOKEN> \
      --type PROBLEM \
      --description "CRITICAL: This is the demo description" \
      --summary "This is the summary of the demo problem" \
      --host "demohost" \
      --hostname "demonicename" \
      --service "Demoservice" \
      --state DOWN \
      --roomId "<WEBEXROOMID>"

This is working!

Created a new notification command Icinga Director > Commands named "my-webexnotifications" with the type as Notification Plugin Command pointing to your script which I have placed under /etc/icinga2/scripts/main

I am now struggling which variables I need to pass to the arguments, so that everything is working. I think the documenetation could be extended here and I am willing to contribute if I know how it has to be setup. Can you share more insights here or are you available for paid support / hire by teamviewer/webex/teams?

Kind regards

One7two99

[dmueckli]

Hello One7two99,

Thank you for reaching out and offering to contribute to the documentation. I appreciate your effort in setting up the plugin and am glad to hear that it's working well from the CLI.

To integrate the plugin with Icinga and ensure that all necessary variables are passed correctly, I recommend creating separate commands for hosts and services. This approach helps in tailoring the notification content more accurately based on the type of check being performed.

Here's a more detailed guide on setting up the commands and configuring the necessary arguments:

1. Command Configuration: For each command (hosts and services), you need to map the script's arguments to the corresponding Icinga runtime macros. This binding ensures that dynamic data from Icinga checks is passed into your notification script. For example, to pass the host's output as the description, you would configure the argument like this:

   --description => $host.output$

   This mapping uses Icinga's built-in runtime macros, which are thoroughly documented here:

   • Host Runtime Macros
   • Service Runtime Macros

2. Adding the --service Argument: When you include the --service argument in your command, the script automatically adjusts the output to match the service check context. This flexibility is crucial for creating notifications that accurately reflect the specific issues detected by Icinga.

3. Setting Up Notification Components: After configuring the command with the necessary arguments, the next steps involve setting up notification time periods, notification users (where you can specify individual room IDs and tokens), and notification templates. These components are essential for defining when notifications should be sent, who should receive them, and what information they should contain.

I hope this guidance helps clarify the setup process. If there are any specific areas you'd like to contribute to in the documentation or if you require further assistance, please feel free to reach out.

Best regards,

Dennis

[dmueckli]

You can find more information about creating custom variables with the Icinga director (e.g. for roomID) here: https://icinga.com/docs/icinga-director/latest/doc/14-Fields-example-interfaces-array/

Just create a data field (of type string) for webex token and roomId and add it to the user template.

[one7two99]

Amazing, thanks for the hints. We will try this out and then - if needed - add more information to the howto.

[dmueckli]

Hello @one7two99,

I just wanted to check in on your progress. Have you been able to resolve the issue? If you need further assistance, we could arrange a Webex meeting.

[one7two99]

Hello,

we are now continue working on this topic again and this time I am also writing a documentation at the same time to be able to it to our own and - if you want - also to your documentation.

The first step was to check if the script is posting the correct information when launching it manually. Therefore I've setup a WebEx Bot and a room and run it from the CLI:

WebexRoomID=Y2<REMOVED>Ri
WebexToken=NT<REMOVED>32
./main \
  --type "PROBLEM" \
  --description "DESCRIPTION" \
  --roomId $WebexRoomID \
  --token $WebexToken \
  --host "demo.intern.example.com" \
  --description "This is the description of the problem" \
  --state "CRITICAL" \
  --icingaUrl "https://icinga.example.com" \
  --service "demo service" \
  --summary "This is the summary"

unfortunately only some of the information is then viewable in the WebEx room:

[PROBLEM]: This is the description of the problem
This is the summary

All the other information which is sent via the command above seems to be missing.

Question: Any idea what could be the problem and do you see an other result if you test the same?

• O.