Hi @suresh.kumar , since this is likely a Windows “agent”, the zone global-templates is probably not needed there (assuming your Icinga setup is configured in the more common way), so everything should be working correctly apart from the annoying log message.
If you are using the Icinga Director, this should be the case.
As for a workaround, you could lower the severity level of the logger component to “error”.
Assuming these are the zones configured in the zones.conf file of the parent (satellite or master) of the windows agent:
The “global-templates” zone also needs to be configured on the agent as well.
Either run the setup wizard again or manually add it to the zones.conf file on the agent.
If you don’t use the global-templates zones, meaning you have no config under /etc/icinga2/zones.d/global-templates of your config master, you could also remove it from the zones.conf file of the master, if it is also not present on the agents.
Though it should be present on both sides be default, as it is a default zone.
The default global zones generated by the setup wizards are called global-templates and director-global.
While you can and should use global-templates for your global configuration, director-global is reserved for use by Icinga Director. Please don’t place any configuration in it manually.
I have applied the first scenario, where the global-templates zone is not used in my setup. Specifically, I:
Removed the global-templates zone from the zones.conf file on the, satellites, where it was defined.
Restarted the Icinga2 service on all nodes to apply the changes.
I am now monitoring the system to ensure the warning messages related to global-templates no longer appear.
Query for the Additional Issues**
In addition to the original issue with the global-templates zone, I have been encountering the following warnings in the logs since the initial setup. I would greatly appreciate your guidance in resolving these ongoing issues:
Warning 1:
warning/ApiListener: Ignoring config update. 'api' does not accept config.
Details:
This warning appears regularly in the logs across my nodes. Based on my research, it seems to indicate that a configuration update is being sent to an endpoint that doesn’t expect it.
What I Tried:
Verified the zones.conf file on all nodes to ensure that endpoints and zones are properly defined.
Restarted the Icinga2 service on the master, satellites, and agents.
Warning 2:
warning/ApiListener: Removing API client for endpoint 'xxxx'. 0 API clients left.
Details:
This warning appears intermittently in the logs and seems to indicate a disconnection between the master/satellite and an agent.
What I Tried:
Verified network connectivity between the affected agent and its parent (satellite) on port 5665 using telnet. No connectivity issues were observed.
Checked certificates on both the agent and the parent. Certificates appear valid and signed correctly.
Restarted the Icinga2 service on all affected nodes.
Observation:
The warning continues to occur intermittently. Could this be due to connection timeouts or some misconfiguration in the zone/endpoint setup?
Warning 3:
warning/ApiListener: Ignoring config update from endpoint 'xxxx' for unknown zone 'linux-commands'.
Details:
The linux-commands zone exists in the zones.conf file on the satellite server, but it is not defined on the Windows agents. Despite this, the Windows agents are somehow referencing this zone, causing this warning to appear.
What I Tried:
Verified that the linux-commands zone is defined correctly in the zones.conf file on the master and satellite.
Checked the zones.conf file on the Windows agents and confirmed that linux-commands is not defined there (as it is unnecessary).
Restarted the Icinga2 service on all nodes to ensure configuration consistency.
Observation:
The warning persists, suggesting that the Windows agents are receiving a configuration update referencing the linux-commands zone.
Could you please provide guidance or suggest additional troubleshooting steps to resolve these warnings? Any insights into how I can pinpoint the root cause for the linux-commands reference on Windows agents would be especially helpful.
You need to set accept_config = true in /etc/icinga2/features-enabled/api.conf on the receiving node. In case of a Windows client this resides in %Programdata%/icinga2 and then /etc/icinga2/features-available
Example:
/**
* The API listener is used for distributed monitoring setups.
*/
object ApiListener "api" {
accept_commands = true
accept_config = true
}
This is also configureable during Agent setup (via GUI and CLI).
Normal during config deployment or service reloads.
linux-commands is defined as a global zone.
Global zones are synced to all endpoints. And the message appears because the agent does not know this zone.
Solution: Don’t define linux-commands as a global zone.
Also the Windows Eventlog will be spammed with warning messages on each config reload/service restart of the Icinga Agent. To supress those you can change %Programdata%/icinga2/etc/icinga2/features-available/windowseventlog.conf to
I really appreciate the help! Removing the global = true attribute from the *“global-templates” zone has resolved the warnings in the Windows Event Log. Thanks a lot for the guidance—it was a huge help!
Just to confirm for below warning, my updated configuration on the Satellite nodes should be as follows:
warning/ApiListener: Ignoring config update from endpoint 'xxxx' for unknown zone 'linux-commands'.
Before:
object Zone "linux-commands" {
global = true
}
After:
object Zone "linux-commands" { }
Is this the correct way to apply the fix, or do I need to adjust anything else?
