telekom_mms.icinga_director.ansible_icinga role – Configure an Icinga instance with Icinga Director
Note
This role is part of the telekom_mms.icinga_director collection (version 2.2.1).
You might already have this collection installed if you are using the ansible
package.
It is not included in ansible-core
.
To check whether it is installed, run ansible-galaxy collection list
.
To install it use: ansible-galaxy collection install telekom_mms.icinga_director
.
To use it in a playbook, specify: telekom_mms.icinga_director.ansible_icinga
.
Entry point icinga_service_apply
– Configure an Icinga instance with Icinga Director
Synopsis
The main entry point includes all tasks for objects that can be created with the role.
Parameters
Parameter |
Comments |
---|---|
PEM formatted certificate chain file to be used for SSL client authentication. This file can also include the key as well, and if the key is included, `client_key’ is not required. |
|
PEM formatted file that contains your private key to be used for SSL client authentication. If `client_cert’ contains both the certificate and key, this option is not required. |
|
HTTP, HTTPS, or FTP URL in the form (http|https|ftp)://[user[:pass]]@host.domain[:port]/path |
|
The password for use in HTTP basic authentication. If the `url_username’ parameter is not specified, the `url_password’ parameter will not be used. |
|
The username for use in HTTP basic authentication. This parameter can be used without `url_password’ for sites that allow empty passwords |
|
Use GSSAPI to perform the authentication, typically this is for Kerberos or Kerberos through Negotiate authentication. Requires the Python library gssapi <https://github.com/pythongssapi/python- gssapi> to be installed. Credentials for GSSAPI can be specified with `url_username’/`url_password’ or with the GSSAPI env var `KRB5CCNAME’ that specified a custom Kerberos credential cache. NTLM authentication is `not’ supported even if the GSSAPI mech for NTLM has been installed. Choices:
|
|
If `no’, it will not use a proxy, even if one is defined in an environment variable on the target hosts. Choices:
|
|
If `no’, SSL certificates will not be validated. icinga_This should only be used on personally controlled sites using selfigned certificates. Choices:
|
Entry point main
– Configure an Icinga instance with Icinga Director
Synopsis
The main entry point includes all tasks for objects that can be created with the role.
Parameters
Parameter |
Comments |
---|---|
A list of Icinga command_templates to configure |
|
Arguments of the command template. |
|
The command Icinga should run. Absolute paths are accepted as provided, relative paths are prefixed with “PluginDir + “, similar Constant prefixes are allowed. Spaces will lead to separation of command path and standalone arguments. Please note that this means that we do not support spaces in plugin names and paths right now. |
|
Plugin Check commands are what you need when running checks against your infrastructure. Notification commands will be used when it comes to notify your users. Event commands allow you to trigger specific actions when problems occur. Some people use them for auto-healing mechanisms, like restarting services or rebooting systems at specific thresholds. Choices:
|
|
Disabled objects will not be deployed. Choices:
|
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the command template. |
|
Apply feature state. Choices:
|
|
Optional command timeout. Allowed values are seconds or durations postfixed with a specific unit (for example 1m or also 3m 30s). |
|
Custom properties of the command template. |
|
Icinga cluster zone. Allows to manually override Directors decisions of where to deploy your config to. You should consider not doing so unless you gained deep understanding of how an Icinga Cluster stack works. |
|
A list of Icinga commands to configure |
|
Arguments of the command. |
|
The command Icinga should run. Required when state is Absolute paths are accepted as provided, relative paths are prefixed with “PluginDir + “, similar Constant prefixes are allowed. Spaces will lead to separation of command path and standalone arguments. Please note that this means that we do not support spaces in plugin names and paths right now. |
|
Plugin Check commands are what you need when running checks against your infrastructure. Notification commands will be used when it comes to notify your users. Event commands allow you to trigger specific actions when problems occur. Some people use them for auto-healing mechanisms, like restarting services or rebooting systems at specific thresholds. Choices:
|
|
Disabled objects will not be deployed. Choices:
|
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the command. |
|
Apply feature state. Choices:
|
|
Optional command timeout. Allowed values are seconds or durations postfixed with a specific unit (for example 1m or also 3m 30s). |
|
Custom properties of the command. |
|
Icinga cluster zone. Allows to manually override Directors decisions of where to deploy your config to. You should consider not doing so unless you gained deep understanding of how an Icinga Cluster stack works. |
|
A list of Icinga endpoints to configure |
|
The hostname/IP address of the remote Icinga 2 instance. |
|
Duration for keeping replay logs on connection loss. Defaults to 1d (86400 seconds). Attribute is specified in seconds. If log_duration is set to 0, replaying logs is disabled. You could also specify the value in human readable format like 10m for 10 minutes or 1h for one hour. |
|
Icinga object name for this endpoint. This is usually a fully qualified host name but it could basically be any kind of string. To make things easier for your users we strongly suggest to use meaningful names for templates. For example “generic-endpoint” is ugly, “Standard Linux Server” is easier to understand. |
|
The service name/port of the remote Icinga 2 instance. Defaults to 5665. |
|
Apply feature state. Choices:
|
|
The name of the zone this endpoint is part of. |
|
A list of Icinga host_templates to configure |
|
Whether the agent is configured to accept config. Choices:
|
|
Host address. Usually an IPv4 address, but may be any kind of address your check plugin is able to deal with. |
|
Host IPv6 address. Usually an IPv64 address, but may be any kind of address your check plugin is able to deal with. |
|
The name of the check command. Though this is not required to be defined in the director, you still have to supply a check_command in a host or host-template. |
|
Your regular check interval. |
|
Disabled objects will not be deployed. Choices:
|
|
Alternative name for this host. Might be a host alias or and kind of string helping your users to identify this host. |
|
Event command for host which gets called on every check execution if one of these conditions matches The host is in a soft state The host state changes into a hard state The host state recovers from a soft or hard state to OK/Up |
|
Hostgroups that should be directly assigned to this node. Hostgroups can be useful for various reasons. You might assign service checks based on assigned hostgroup. They are also often used as an instrument to enforce restricted views in Icinga Web 2. Hostgroups can be directly assigned to single hosts or to host templates. You might also want to consider assigning hostgroups using apply rules. Default: |
|
Whether this host has the Icinga 2 Agent installed. Choices:
|
|
Choose a host-template. |
|
Whether the parent (master) node should actively try to connect to this agent. Choices:
|
|
Icinga object name for this host template. This is usually a fully qualified host name but it could basically be any kind of string. To make things easier for your users we strongly suggest to use meaningful names for templates. For example “generic-host” is ugly, “Standard Linux Server” is easier to understand. |
|
Additional notes for this object. |
|
An URL pointing to additional notes for this object. Separate multiple urls like this “http://url1 http://url2” Maximum length is 255 characters. |
|
Apply feature state. Choices:
|
|
Custom properties of the host. |
|
Set the zone. |
|
A list of Icinga hostgroups to configure |
|
This allows you to configure an assignment filter. Please feel free to combine as many nested operators as you want. |
|
An alternative display name for this group. If you wonder how this could be helpful just leave it blank. |
|
Icinga object name for this hostgroup. |
|
Apply feature state. Choices:
|
|
A list of Icinga hosts to configure |
|
Whether the agent is configured to accept config. Choices:
|
|
Host address. Usually an IPv4 address, but may be any kind of address your check plugin is able to deal with. |
|
Host IPv6 address. Usually an IPv6 address, but may be any kind of address your check plugin is able to deal with. |
|
The name of the check command. Though this is not required to be defined in the director, you still have to supply a check_command in a host or host-template. |
|
Disabled objects will not be deployed. Choices:
|
|
Alternative name for this host. Might be a host alias or and kind of string helping your users to identify this host. |
|
Hostgroups that should be directly assigned to this node. Hostgroups can be useful for various reasons. You might assign service checks based on assigned hostgroup. They are also often used as an instrument to enforce restricted views in Icinga Web 2. Hostgroups can be directly assigned to single hosts or to host templates. You might also want to consider assigning hostgroups using apply rules. Default: |
|
Whether this host has the Icinga 2 Agent installed. Choices:
|
|
Choose a Host Template. Required when state is |
|
Whether the parent (master) node should actively try to connect to this agent. Choices:
|
|
Icinga object name for this host. This is usually a fully qualified host name but it could basically be any kind of string. To make things easier for your users we strongly suggest to use meaningful names for templates. For example “generic-host” is ugly, “Standard Linux Server” is easier to understand. |
|
Additional notes for this object. |
|
An URL pointing to additional notes for this object. Separate multiple urls like this “http://url1 http://url2” The maximum length is 255 characters. |
|
Apply feature state. Choices:
|
|
Custom properties of the host. |
|
Set the zone. |
|
A list of Icinga notifications to configure |
|
Whether this notification should affect hosts or services. Choices:
|
|
The filter where the notification will take effect. |
|
Disabled objects will not be deployed. Choices:
|
|
Importable templates, add as many as you want. Required when state is Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the notification. |
|
The notification interval (in seconds). This interval is used for active notifications. Defaults to 30 minutes. If set to 0, re-notifications are disabled. |
|
Apply feature state. Choices:
|
|
The host or service states you want to get notifications for. |
|
The name of a time period which determines when this notification should be triggered. |
|
First notification delay. Delay unless the first notification should be sent. |
|
Last notification. When the last notification should be sent. |
|
The state transition types you want to get notifications for. |
|
User Groups that should be notified by this notification. |
|
Users that should be notified by this notification. |
|
Custom properties of the notification. |
|
A list of Icinga service_applies to configure |
|
Evaluates the apply for rule for all objects with the custom attribute specified. For example selecting “host.vars.custom_attr” will generate “for (config in host.vars.array_var)” where “config” will be accessible through “$config$”. Note - only custom variables of type “Array” are eligible. |
|
The filter where the service apply rule will take effect. |
|
Check command definition. |
|
Your regular check interval. |
|
The name of a time period which determines when this object should be monitored. Not limited by default. |
|
Check command timeout in seconds. Overrides the CheckCommand’s timeout attribute. |
|
The host where the service should be executed on. |
|
Alternative displayed name of the service apply rule. |
|
Whether to actively check this object. Choices:
|
|
Whether to enable event handlers this object. Choices:
|
|
Whether to send notifications for this object. Choices:
|
|
Whether to accept passive check results for this object. Choices:
|
|
Whether to process performance data provided by this object. Choices:
|
|
Service groups that should be directly assigned to this service. Servicegroups can be useful for various reasons. They are helpful to provided service-type specific view in Icinga Web 2, either for custom dashboards or as an instrument to enforce restrictions. Service groups can be directly assigned to single services or to service templates. |
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Defines after how many check attempts a new hard state is reached. |
|
Name for the Icinga service apply rule. |
|
Additional notes for this object. |
|
An URL pointing to additional notes for this object. Separate multiple urls like this “http://url1 http://url2” Maximum length is 255 characters. |
|
Retry interval, will be applied after a state change unless the next hard state is reached. |
|
Apply feature state. Choices:
|
|
Custom properties of the service apply rule. |
|
A list of Icinga service_templates to configure |
|
Check command definition. |
|
Your regular check interval. |
|
The name of a time period which determines when this object should be monitored. Not limited by default. |
|
Check command timeout in seconds. Overrides the CheckCommand’s timeout attribute. |
|
Disabled objects will not be deployed. Choices:
|
|
Whether to actively check this object. Choices:
|
|
Whether to enable event handlers this object. Choices:
|
|
Whether to send notifications for this object. Choices:
|
|
Whether to accept passive check results for this object. Choices:
|
|
Whether to process performance data provided by this object. Choices:
|
|
Event command for service which gets called on every check execution if one of these conditions matches The service is in a soft state The service state changes into a hard state The service state recovers from a soft or hard state to OK/Up |
|
Service groups that should be directly assigned to this service. Servicegroups can be useful for various reasons. They are helpful to provided service-type specific view in Icinga Web 2, either for custom dashboards or as an instrument to enforce restrictions. Service groups can be directly assigned to single services or to service templates. Default: |
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. Default: |
|
Defines after how many check attempts a new hard state is reached. |
|
Name of the service template. |
|
Additional notes for this object. |
|
An URL pointing to additional notes for this object. Separate multiple urls like this “http://url1 http://url2” Maximum length is 255 characters. |
|
Retry interval, will be applied after a state change unless the next hard state is reached. |
|
Apply feature state. Choices:
|
|
Whether the check command for this service should be executed on the Icinga agent. Choices:
|
|
Custom properties of the service template. Default: |
|
Whether this check is volatile. Choices:
|
|
A list of Icinga sservicegroups to configure |
|
This allows you to configure an assignment filter. Please feel free to combine as many nested operators as you want. |
|
An alternative display name for this group. If you wonder how this could be helpful just leave it blank. |
|
Name for the Icinga servicegroup. |
|
Apply feature state. Choices:
|
|
A list of Icinga services to configure |
|
Check command definition. |
|
Your regular check interval. |
|
The name of a time period which determines when this object should be monitored. Not limited by default. |
|
Check command timeout in seconds. Overrides the CheckCommand’s timeout attribute. |
|
Disabled objects will not be deployed. Choices:
|
|
Whether to actively check this object. Choices:
|
|
Whether to enable event handlers this object. Choices:
|
|
Whether to send notifications for this object. Choices:
|
|
Whether to accept passive check results for this object. Choices:
|
|
Whether to process performance data provided by this object. Choices:
|
|
Service groups that should be directly assigned to this service. Servicegroups can be useful for various reasons. They are helpful to provided service-type specific view in Icinga Web 2, either for custom dashboards or as an instrument to enforce restrictions. Service groups can be directly assigned to single services or to service templates. Default: |
|
Choose the host this single service should be assigned to. |
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. Default: |
|
Defines after how many check attempts a new hard state is reached. |
|
Name of the service. |
|
Additional notes for this object. |
|
An URL pointing to additional notes for this object. Separate multiple urls like this “http://url1 http://url2” Maximum length is 255 characters. |
|
Retry interval, will be applied after a state change unless the next hard state is reached. |
|
Apply feature state. Choices:
|
|
Whether the check command for this service should be executed on the Icinga agent. Choices:
|
|
Custom properties of the service. Default: |
|
Whether this check is volatile. Choices:
|
|
A list of Icinga timeperiods to configure |
|
Alternative name for this timeperiod. |
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the time period. |
|
A dict of days and timeperiods. |
|
Apply feature state. Choices:
|
|
A list of Icinga user_templates to configure |
|
Whether to send notifications for this user. Choices:
|
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the user template. |
|
The name of a time period which determines when notifications to this User should be triggered. Not set by default. |
|
Apply feature state. Choices:
|
|
Custom properties of the user. Default: |
|
A list of Icinga users to configure |
|
Disabled objects will not be deployed. Choices:
|
|
Alternative name for this user. In case your object name is a username, this could be the full name of the corresponding person. |
|
The Email address of the user. |
|
User groups that should be directly assigned to this user. Groups can be useful for various reasons. You might prefer to send notifications to groups instead of single users. |
|
Importable templates, add as many as you want. Please note that order matters when importing properties from multiple templates - last one wins. |
|
Name of the user. |
|
The pager address of the user. |
|
The name of a time period which determines when notifications to this User should be triggered. Not set by default. |
|
Apply feature state. Choices:
|
|
Custom properties of the user. Default: |
|
A list of Icinga zones to configure |
|
Whether configuration files for this zone should be synced to all endpoints. Choices:
|
|
Icinga object name for this zone. This is usually a fully qualified host name but it could basically be any kind of string. To make things easier for your users we strongly suggest to use meaningful names for templates. For example “generic-zone” is ugly, “Standard Linux Server” is easier to understand. |
|
The name of the parent zone. |
|
Apply feature state. Choices:
|