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.


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.

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.


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.