I’d suggest to only include the commands.conf in your icinga2.conf file on the agent then, everything else is not needed (except for templates e.g.).
A better method would be to manage the commands on the master host, and use a global template zone to sync the definition to the agent. The following conditions must be met:
accept_config = true in the agent’s api.conf
global-templates zone is configured, that’s done by default using the setup wizard
global-templates zone and directory exists on the master in /etc/icinga2/zones.d
Note: import plugin-check-command isn’t needed in the latest release, that’s now a default import.
Furthermore, I’d suggest to create check command parameters inside the arguments definition, by using the CheckCommand’s name as prefix for those runtime macros.
With memutil_warn and memutil_crit you can then specify them in the service (or host) object.
apply Service “memory” {
import “generic-service”
check_command = “memutil”
command_endpoint = host.vars.remote_client
vars.memutil_warn = "25%" //different threshold than the default
assign where host.name == “casa-PC”
}
Once this works, your next task is to modify the assign where definition and find a pattern which matches all your Windows clients - assuming that they all should be monitored this way.
Great stuff,
I now start to get it. I will test that config. I will definitely go for the global- template option since I am supposed to Install the agent in around 100 servers and the client does not have any massive software development like sccm, any ideas about that?
If you put all the things into the Director, you may look into its agent setup instructions with using a Powershell script. Or you’ll hack up your own, automating all the setup steps you’ve learned thus far.
Puppet supports Windows as well, still this may be problematic to roll if not there already. I would investigate on whether they have some rollout mechanism already next to WSUS or similar.
Hi,
If I place the commands.conf on /zones.d/global-templates as suggested I keep getting the error
critical/config: Error: Object ‘memutil’ of type ‘CheckCommand’ re-defined: in /etc/icinga2/zones.d/global-templates/commands.conf: 1:0-1:28; previous definition: in /etc/icinga2/zones.d/global-templates/commands.conf: 1:0-1:28
and the service will not start…
I have tried editing icinga2.conf and adding include_recursive “zones.d” but it has not helped.
zones.d is automatically included, there’s no need to do that manually. Remove that entry from your icinga2.conf file, and also ensure that conf.d isn’t included as well.
ok, if i remove the include conf.d on the icinga2.conf on the master then it will obviously not look at the hosts,services,templates conf files that are under conf.d,so it shows nothing on the web.
current icinga2.conf setup
on agent:
/**
* Icinga 2 configuration file
* - this is where you define settings for the Icinga application including
* which hosts/services to check.
*
* For an overview of all available configuration options please refer
* to the documentation that is distributed as part of Icinga 2.
*/
/**
* The constants.conf defines global constants.
*/
include "constants.conf"
/**
* The zones.conf defines zones for a cluster setup.
* Not required for single instance setups.
*/
include "zones.conf"
/**
* The Icinga Template Library (ITL) provides a number of useful templates
* and command definitions.
* Common monitoring plugin command definitions are included separately.
*/
include <itl>
include <plugins>
include <plugins-contrib>
include <manubulon>
/**
* This includes the Icinga 2 Windows plugins.
*/
include <windows-plugins>
/**
* This includes the NSClient++ check commands.
*/
include <nscp>
/**
*I’d suggest to only include the commands.conf in your icinga2.conf file on the agent then,
*everything else is not needed (except for templates e.g.).
*/
include "commands.conf"
/**
* The features-available directory contains a number of configuration
* files for features which can be enabled and disabled using the
* icinga2 feature enable / icinga2 feature disable CLI commands.
* These commands work by creating and removing symbolic links in
* the features-enabled directory.
*/
include "features-enabled/*.conf"
/**
* Although in theory you could define all your objects in this file
* the preferred way is to create separate directories and files in the conf.d
* directory. Each of these files must have the file extension ".conf".
*/
/include_recursive "conf.d"
on master:
/**
* The zones.conf defines zones for a cluster setup.
* Not required for single instance setups.
*/
include "zones.conf"
/**
* The Icinga Template Library (ITL) provides a number of useful templates
* and command definitions.
* Common monitoring plugin command definitions are included separately.
*/
include <itl>
include <plugins>
include <plugins-contrib>
include <manubulon>
/**
* This includes the Icinga 2 Windows plugins. These command definitions
* are required on a master node when a client is used as command endpoint.
*/
include <windows-plugins>
/**
* This includes the NSClient++ check commands. These command definitions
* are required on a master node when a client is used as command endpoint.
*/
include <nscp>
/**
* The features-available directory contains a number of configuration
* files for features which can be enabled and disabled using the
* icinga2 feature enable / icinga2 feature disable CLI commands.
* These commands work by creating and removing symbolic links in
* the features-enabled directory.
*/
include "features-enabled/*.conf"
/**
* Although in theory you could define all your objects in this file
* the preferred way is to create separate directories and files in the conf.d
* directory. Each of these files must have the file extension ".conf".
*/
//include_recursive "conf.d"
//include_recursive "zones.d"
Best practice is to move example config from conf.d into your master’s zone directory underneath zones.d, then everything is fine. You can also move certain common things like templates, commands, groups into the global zone.
This is how the master looks like and when I restart the service I get
[2019-03-19 15:14:37 +0000] warning/ApplyRule: Apply rule ‘memory’ (in /etc/icinga2/zones.d/FGARCIAD-PORT.xxxxxx.local/services.conf: 116:1-116:22) for type ‘Service’ does not mat ch anywhere!
[2019-03-19 15:14:37 +0000] warning/ApplyRule: Apply rule ‘disk’ (in /etc/icinga2/zones.d/FGARCIAD-PORT.xxxxxx.local/services.conf: 122:1-122:20) for type ‘Service’ does not match anywhere!
It already says it - your local Windows client includes conf.d where the example host lies. This needs to be removed in your icinga2.conf. The api/zones/... directory originates from the cluster config sync via the master.
Question aside, do you really want to sync the configuration from the master, or just execute a check on the master via command endpoint?
I want to want to execute a basic set of checks like memory, cpu, disk, and ping for all servers and then based on the type of server role add specific checks for let’s say, IIS servers, Database Server, Application Servers, and so on.
And I would like the second type of checks to be done locally on each server through some type of custom powershell script or a generic script that checks health of processes, databases or IIS Status.
Maybe I should just stick to the first config I pasted…
Why does it not find the global-template zone ?? Why does the configuration not synchrnize from the master? Why does it not find the global-template Zone if it is specified on the C:\ProgramData\icinga2\etc\icinga2\zones.conf file on the Windows client? AND where does the information stored on C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf actually come from?
Please is there not a standard basic setup to monitor serveral machines?
Running command ‘icinga2.exe daemon --validate’ produced the following output:
[2019-03-20 11:46:02 +0100] information/cli: Icinga application loader (version: v2.10.3)
[2019-03-20 11:46:02 +0100] information/cli: Loading configuration file(s).
[2019-03-20 11:46:02 +0100] information/ConfigItem: Committing config item(s).
[2019-03-20 11:46:02 +0100] information/ApiListener: My API identity: FGARCIAD-PORT.axpenet.local
[2019-03-20 11:46:03 +0100] critical/config: Error: Validation failed for object ‘memutil’ of type ‘CheckCommand’; Attribute ‘zone’: Object ‘global-templates’ of type ‘Zone’ does not exist.
Location: in C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf: 1:0-1:28
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(1): object CheckCommand “memutil” {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(2): command = [ PluginDir + “/check_memory” ]
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(3): arguments = {
[2019-03-20 11:46:03 +0100] critical/config: Error: Validation failed for object ‘procsutil’ of type ‘CheckCommand’; Attribute ‘zone’: Object ‘global-templates’ of type ‘Zone’ does not exist.
Location: in C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf: 19:1-19:31
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(17): }
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(18): }
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(19): object CheckCommand “procsutil” {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(20): import “plugin-check-command”
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(21): command = [ “C:\Program Files\ICINGA2\sbin\check_procs” ]
[2019-03-20 11:46:03 +0100] critical/config: Error: Validation failed for object ‘cpuutil’ of type ‘CheckCommand’; Attribute ‘zone’: Object ‘global-templates’ of type ‘Zone’ does not exist.
Location: in C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf: 27:1-27:29
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(25): }
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(26): }
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(27): object CheckCommand “cpuutil” {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(28): import “plugin-check-command”
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(29): command = [ “C:\Program Files\ICINGA2\sbin\check_load” ]
[2019-03-20 11:46:03 +0100] critical/config: Error: Validation failed for object ‘diskutil’ of type ‘CheckCommand’; Attribute ‘zone’: Object ‘global-templates’ of type ‘Zone’ does not exist.
Location: in C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf: 10:1-10:30
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(8): }
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(9):
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(10): object CheckCommand “diskutil” {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(11): import “plugin-check-command”
C:\ProgramData\icinga2\var\lib\icinga2\api\zones/global-templates/_etc/commands.conf(12): command = [ “C:\Program Files\ICINGA2\sbin\check_disk”, “-U” ]
there is a standard with the command endpoint bridge, plus using the wizard defaults. You’ve tried many things now and ended up with a mixed setup. I know that this may be frustrating, but don’t let that influence your writing
The agent doesn’t have the zone global-templates configured anymore, and you’re hitting a long lasting bug where the content of var/lib/api/zones is still included and not ignored (I am working on this, you can follow #6716).
Navigate into the etc directory, and open zones.conf. Verify that it contains something like this:
//definitions for parent zone
//definitions for agent zone
//...
object Zone "global-templates" {
global = true
}
In addition to that, verify that the API feature accepts configuration and commands:
etc/icinga2/features-enabled/api.conf
object ApiListener "api" {
//....
accept_config = true //for receiving configuration from the parent node
accept_commands = true //for executing commands requested by the parent node
}
If both are ok, and the restart still fails, manually purge this directory:
yeah well, it is kind of frustrating not being able to stick to a config profile that fits my needs…
The zones.conf of the client contains the “global-templates” zone, by the way are you sure the directory that contains this file is checked on the client?
reinstalled the windows agent but will not initialialize.
zones.conf is included in icinga2.conf which is the config file read by the icinga2 service on startup, as such this should be read. You can also verify this by doing a more verbose config validation to see which files are actually parsed: icinga2.exe daemon -C -x notice.
To me, it seems that you’ve emptied the zones.conf and just added the global zone in there. The configuration generated by the setup wizard must stay intact in order to trust the parent node on connections.
object Endpoint "FGARCIAD-PORT.axpenet.local" {
}
object Zone "FGARCIAD-PORT.axpenet.local" {
endpoints = [ "FGARCIAD-PORT.axpenet.local" ]
parent = "master"
}
object Endpoint "FQDN of the master" {
host = "IP address of the master"
}
object Zone "master" {
endpoints = [ "FQDN of the master" ]
}
object Zone "global-templates" {
global = true
}
