JIRA module in distributed environment

Icinga Web Modules
, ,
1

Hi,

I have installed and configured JIRA module as documentation found in official sites but it does not wok because in our case IcingaWeb is installed in a different host than masters.
When a notification comes from Icinga, it tried to be resolved in ours “masters” hosts: core1 (192.168.15.3) and core2 (192.168.15.4) but the module is installed in icingaweb host (192.168.15.5), so we got “command not found”.

How can I tell Icinga to execute this notification in my IcingaWeb host?

Command is default.

Jira Notification Template:

template Notification "JIRA ServiceCrit Homolog" {
    command = "JIRA Service Notification"
}

Jira Notification:

apply Notification "JIRA Service Crit" to Service {
    import "JIRA ServiceCrit Homolog"

    times = {
        begin = 5s
    }
    interval = 0s
    assign where match("check*", service.name) && match("*homolog*", host.name)
    states = [ Critical ]
    types = [ Custom, Problem ]
    users = [ "tester" ]
    vars.jira_ack_author = "JIRAUSER"
    vars.jira_description = "Teste de chamado automatico"
    vars.jira_issuetype = "Incident"
    vars.jira_project = "CH"
    vars.notification_useremail = "$user.email$"
}

Thanks.

2

Hi and welcome to the show, @gomesar

You can install Icinga on the Icinga Web host and use it as an agent. You will want to monitor this host anyway so it’s always a good idea to have Icinga running there. Then you can execute the checks on the Icinga Web host.

1 Like
3

Hi @twidhalm, thanks for the reply.

I want to control in which hosts each check runs, so we have a zone called “core” (hosts: core1, core2) and another called “sats” (hosts: sat1, sat2). Icingaweb host actually do not runs checks. Based on your response, is that ok to create a new zone, put icingaweb into this and specify JIRA Notification to run in this zone, right?

4

It’s easier. You can add the Icinga Web host as an agent (basically endpoint, zone and host object with the same name) in your core zone. Then you can just add the checks you want to be run there with command_endpoint set to host.name.

You can find more documentation about this in the official documentation about distributed monitoring/agents.

https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#master-with-agents

1 Like
5

I’m sorry @twidhalm, I would mean to control where notifications are fired.

Icinga Director does not allow to set command_endpoint for Services and Notifications, actually, I cannot insert IcingaWeb into core zone because the host resources are very different: IcingaWeb runs with 2 cores and 4GB RAM, core1 and core2 runs with 12 cores and 16GB RAM. So I can not allow IcingaWeb to receive distributed work charge, and we prefer to maintain IcingaWeb in a separate host (is it conceptually wrong?)

Is there any way to maintain this setup and trigger notifications from icigaweb host?
If it is not possible, how can I grant High Availability to icingaweb?

Thank you

6

Hi.

Notifications always fired on every node where the notification feature is active that gets to know the Notification object and knows about the event that triggers the Notification.

That is normally only masters. If you want, you can activate the feature on Satellites on the way between the Agent and the Masters or on the Agent itself. You can’t “delegate” it to another host.