Hi there, We recently upgraded to the latest Icinga (2.12.2) and latest Icingaweb2. I have a multi-master configuration with a dedicated Icingaweb2 box. In Icingaweb2, I have acknowledged a host problem, but Icingaweb2 is displaying it as unacknowledged/unhandled: [image] When I click Acknowle…

[image] 0xliam: in the monitoring module of Icinga Web, should I have both of my masters configured as command transports? Just tried that for you :smiley: Yes, put them both in the config. Because if the only one configured isn’t available you won’t be able to issue ‘check now’, ‘acks’ or …

Interesting. Though this does not really make sense to me, as only the first working command transport will/should be used, at least that’s how I understand the documentation: Icinga Web 2 will try one transport after another to send a command until the command is successfully sent. But I just …

That was my understanding too - I was under the impression there were cluster/config sync bugs in ~2.10 which implied the config master should be the one to receive the transport commands, but I could be wrong on that. Perhaps though the transport is unrelated, as I am having other issues with my c…

Do I understand you correctly: You configured API and the local command pipe (cmd-file) also? And after it works? My knowledge was that we should better use the API (only?) instead.

Our Icinga Web is containerized, so only using the API and no local command pipe - I can rule this out being a bug or any weird behaviour, I think it was purely due to the lack of a secondary master being configured in the monitoring module… This is what was happening prior to me adding both master…

@theFeu May I ask you if you or anyone else from the icinga team has an explanation for this “issue” of having only one or both master servers in the command transports? The current behavior noticed is somewhat contradicting the documentation.

good idea @log1c maybe we get the correct way to configure this and also a way to test this better in our setups. Maybe we get also a way to identify it if this is a bug or a normal behavior. If this is a bug we can deliever logs etc.

Hi there! Sorry for the late reply, I was holed up for my holiday :man_technologist: I will ask around :slight_smile:

I guess the monitored object was acked in Icinga 2, but this fact got lost from (or was missing at all in) the IDO DB. I guess because the IDO writing master’s API didn’t accept_config nor accept_commands from the one which acked the checkable.

Thanks for the reply @Al2Klimov (and thanks for asking around @theFeu ). My config master has only accept_commands = true, the second master has both set to true. Afair setting accept_config to true on the config master is not recommended (or doesn’t even work?!). Ack was done while the config mas…

Also thanks from my side @Al2Klimov . In our setup we have both masters configured with accept_config = true accept_commands = true every master has it’s own db. But here it also happens also sometimes.

Acknowledgements not syncing between masters

Icinga 2

sethlyons (Seth Lyons) December 14, 2020, 6:52pm 27

Here is a semi-related issue where this was recommended by a former Icinga team member.