External Command Transport Configuration

Hi everyone,
I already looked in this forum because of my problem and I also saw some similar issues but they were not solved or be cancelled.

Documentation
Forum-Topic

distribution: Ubuntu 16.04 LTS
icinga2 version: v2.10.5
icingaweb2 version: 2.6.3

In our test-environment we wanted to build a HA setup with icinga2. Therefore we have 2 icinga2 master servers and one database server including icingaweb2.

  • master 1
  • master 2
  • (ido)db server with icingaweb2

It’s already nearly working fine. The only problem is the external command transport configuration I think.
In our productive setup we are using the old method with the local icinga2.cmd file for the transport. In the test-environment I configured it as a API transport. It is working finde for the checks where the master1 is taking control of the checks. But if i want to check a service manually the webinterface get a failure. The message is “icinga2-master1: Can’t send external Icinga command: 404 No objects found.”

The services which are checked by the master1 server are correctly checked without any problems.
In didn’t found a special example for HA setup - external command transport configuration so my intention was to do it like the documentation.
02

My question here is, that I can only insert one IP-Address (what’s happening when this server is down!?) - so I have to add one additional transport configuration?! In the docs it is only used for combining different icinga2 configutrations within one icingaweb2 interface, isn’t it?
I tested it also and I got another failure.

So what’s the point here? How can I configure this setup that both master servers are working properly?

I hope you understand what i want and brought you the informations you need. If something is missing please let me know.

Hi,

welcome to the community :slight_smile:

Yep. This one will be used as fallback whenever the first one is not reachable. By default, Icinga 2 Core synchronizes the commands and events in a HA cluster anyways, so you’ll just need one entry point for the API by default.

When things result in a 404, this means that the current ApiUser does not have the proper permissions to access these objects. You can verify and test the user permissions manually, this is described here.

Cheers,
Michael