granicus.if.org Git - icinga2/blob - doc/16-troubleshooting.md

   1 # <a id="troubleshooting"></a> Icinga 2 Troubleshooting
   2
   3 ## <a id="troubleshooting-information-required"></a> Which information is required
   4
   5 * Run `icinga2 troubleshoot` to collect required troubleshooting information
   6 * Alternative, manual steps:
   7         * `icinga2 --version`
   8         * `icinga2 feature list`
   9         * `icinga2 daemon --validate`
  10         * Relevant output from your main and debug log ( `icinga2 object list --type='filelogger'` )
  11         * The newest Icinga 2 crash log, if relevant
  12         * Your icinga2.conf and, if you run multiple Icinga 2 instances, your zones.conf
  13 * How was Icinga 2 installed (and which repository in case) and which distribution are you using
  14 * Provide complete configuration snippets explaining your problem in detail
  15 * If the check command failed - what's the output of your manual plugin tests?
  16 * In case of [debugging](21-debug.md#debug) Icinga 2, the full back traces and outputs
  17
  18 ## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
  19
  20 Run Icinga 2 in the foreground with debugging enabled. Specify the console
  21 log severity as an additional parameter argument to `-x`.
  22
  23     # /usr/sbin/icinga2 daemon -x notice
  24
  25 The log level can be one of `critical`, `warning`, `information`, `notice`
  26 and `debug`.
  27
  28 Alternatively you can enable the debug log:
  29
  30     # icinga2 feature enable debuglog
  31     # service icinga2 restart
  32
  33 You can find the debug log file in `/var/log/icinga2/debug.log`.
  34
  35 ## <a id="list-configuration-objects"></a> List Configuration Objects
  36
  37 The `icinga2 object list` CLI command can be used to list all configuration objects and their
  38 attributes. The tool also shows where each of the attributes was modified.
  39
  40 That way you can also identify which objects have been created from your [apply rules](19-language-reference.md#apply).
  41
  42     # icinga2 object list
  43
  44     Object 'localhost!ssh' of type 'Service':
  45       * __name = 'localhost!ssh'
  46       * check_command = 'ssh'
  47         % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 5:3-5:23
  48       * check_interval = 60
  49         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 24:3-24:21
  50       * host_name = 'localhost'
  51         % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 4:3-4:25
  52       * max_check_attempts = 3
  53         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 23:3-23:24
  54       * name = 'ssh'
  55       * retry_interval = 30
  56         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 25:3-25:22
  57       * templates = [ 'ssh', 'generic-service' ]
  58         % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 1:0-7:1
  59         % += modified in '/etc/icinga2/conf.d/templates.conf', lines 22:1-26:1
  60       * type = 'Service'
  61       * vars
  62         % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
  63         * sla = '24x7'
  64           % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
  65
  66     [...]
  67
  68 You can also filter by name and type:
  69
  70     # icinga2 object list --name *ssh* --type Service
  71     Object 'localhost!ssh' of type 'Service':
  72       * __name = 'localhost!ssh'
  73       * check_command = 'ssh'
  74         % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 5:3-5:23
  75       * check_interval = 60
  76         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 24:3-24:21
  77       * host_name = 'localhost'
  78         % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 4:3-4:25
  79       * max_check_attempts = 3
  80         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 23:3-23:24
  81       * name = 'ssh'
  82       * retry_interval = 30
  83         % = modified in '/etc/icinga2/conf.d/templates.conf', lines 25:3-25:22
  84       * templates = [ 'ssh', 'generic-service' ]
  85         % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 1:0-7:1
  86         % += modified in '/etc/icinga2/conf.d/templates.conf', lines 22:1-26:1
  87       * type = 'Service'
  88       * vars
  89         % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
  90         * sla = '24x7'
  91           % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
  92
  93     Found 1 Service objects.
  94
  95     [2014-10-15 14:27:19 +0200] information/cli: Parsed 175 objects.
  96
  97 ## <a id="check-command-definitions"></a> Where are the check command definitions?
  98
  99 Icinga 2 features a number of built-in [check command definitions](7-icinga-template-library.md#plugin-check-commands) which are
 100 included using
 101
 102     include <itl>
 103     include <plugins>
 104
 105 in the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
 106 on upgrade, so please send modifications as proposed patches upstream. The default include path is set to
 107 `LocalStateDir + "/share/icinga2/includes"`.
 108
 109 You should add your own command definitions to a new file in `conf.d/` called `commands.conf`
 110 or similar.
 111
 112 ## <a id="checks-not-executed"></a> Checks are not executed
 113
 114 * Check the debug log to see if the check command gets executed
 115 * Verify that failed depedencies do not prevent command execution
 116 * Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
 117 * Make sure the [checker](8-cli-commands.md#features) feature is enabled.
 118
 119 Examples:
 120
 121     # sudo -u icinga /usr/lib/nagios/plugins/check_ping -4 -H 127.0.0.1 -c 5000,100% -w 3000,80%
 122
 123     # icinga2 feature enable checker
 124     The feature 'checker' is already enabled.
 125
 126
 127 ## <a id="notifications-not-sent"></a> Notifications are not sent
 128
 129 * Check the debug log to see if a notification is triggered
 130 * If yes, verify that all conditions are satisfied
 131 * Are any errors on the notification command execution logged?
 132
 133 Verify the following configuration
 134
 135 * Is the host/service `enable_notifications` attribute set, and if, to which value?
 136 * Do the notification attributes `states`, `types`, `period` match the notification conditions?
 137 * Do the user attributes `states`, `types`, `period` match the notification conditions?
 138 * Are there any notification `begin` and `end` times configured?
 139 * Make sure the [notification](8-cli-commands.md#features) feature is enabled.
 140 * Does the referenced NotificationCommand work when executed as Icinga user on the shell?
 141
 142 If notifications are to be sent via mail make sure that the mail program specified exists.
 143 The name and location depends on the distribution so the preconfigured setting might have to be
 144 changed on your system.
 145
 146 Examples:
 147
 148     # icinga2 feature enable notification
 149     The feature 'notification' is already enabled.
 150
 151 ## <a id="feature-not-working"></a> Feature is not working
 152
 153 * Make sure that the feature configuration is enabled by symlinking from `features-available/`
 154 to `features-enabled` and that the latter is included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf).
 155 * Are the feature attributes set correctly according to the documentation?
 156 * Any errors on the logs?
 157
 158 ## <a id="configuration-ignored"></a> Configuration is ignored
 159
 160 * Make sure that the line(s) are not [commented out](19-language-reference.md#comments) (starting with `//` or `#`, or
 161 encapsulated by `/* ... */`).
 162 * Is the configuration file included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf)?
 163
 164 ## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
 165
 166 Icinga 2 allows you to import templates using the [import](19-language-reference.md#template-imports) keyword. If these templates
 167 contain additional attributes, your objects will automatically inherit them. You can override
 168 or modify these attributes in the current object.
 169
 170 ## <a id="troubleshooting-cluster"></a> Cluster Troubleshooting
 171
 172 This applies to anything using the cluster protocol:
 173
 174 * [Distributed and High-Availability](12-distributed-monitoring-ha.md#distributed-monitoring-high-availability) scenarios
 175 * [Remote client](10-icinga2-client.md#icinga2-client-scenarios) scenarios
 176
 177 You should configure the [cluster health checks](12-distributed-monitoring-ha.md#cluster-health-check) if you haven't
 178 done so already.
 179
 180 > **Note**
 181 >
 182 > Some problems just exist due to wrong file permissions or packet filters applied. Make
 183 > sure to check these in the first place.
 184
 185 ### <a id="troubleshooting-cluster-connection-errors"></a> Cluster Troubleshooting Connection Errors
 186
 187 General connection errors normally lead you to one of the following problems:
 188
 189 * Wrong network configuration
 190 * Packet loss on the connection
 191 * Firewall rules preventing traffic
 192
 193 Use tools like `netstat`, `tcpdump`, `nmap`, etc to make sure that the cluster communication
 194 happens (default port is `5665`).
 195
 196     # tcpdump -n port 5665 -i any
 197
 198     # netstat -tulpen | grep icinga
 199
 200     # nmap yourclusternode.localdomain
 201
 202 ### <a id="troubleshooting-cluster-ssl-errors"></a> Cluster Troubleshooting SSL Errors
 203
 204 If the cluster communication fails with SSL error messages, make sure to check
 205 the following
 206
 207 * File permissions on the SSL certificate files
 208 * Does the used CA match for all cluster endpoints?
 209   * Verify the `Issuer` being your trusted CA
 210   * Verify the `Subject` containing your endpoint's common name (CN)
 211   * Check the validity of the certificate itself
 212
 213 Steps:
 214
 215     # ls -la /etc/icinga2/pki
 216
 217     # cd /etc/icinga2/pki/
 218     # openssl x509 -in icinga2a.crt -text
 219     Certificate:
 220         Data:
 221             Version: 1 (0x0)
 222             Serial Number: 2 (0x2)
 223         Signature Algorithm: sha1WithRSAEncryption
 224             Issuer: C=DE, ST=Bavaria, L=Nuremberg, O=NETWAYS GmbH, OU=Monitoring, CN=Icinga CA
 225             Validity
 226                 Not Before: Jan  7 13:17:38 2014 GMT
 227                 Not After : Jan  5 13:17:38 2024 GMT
 228             Subject: C=DE, ST=Bavaria, L=Nuremberg, O=NETWAYS GmbH, OU=Monitoring, CN=icinga2a
 229             Subject Public Key Info:
 230                 Public Key Algorithm: rsaEncryption
 231                     Public-Key: (4096 bit)
 232                     Modulus:
 233                     ...
 234
 235 Try to manually connect to the cluster node:
 236
 237     # openssl s_client -connect 192.168.33.10:5665
 238
 239
 240 Unauthenticated nodes are able to connect required by the
 241 [CSR auto-signing](10-icinga2-client.md#csr-autosigning-requirements) functionality.
 242
 243     [2015-06-10 03:28:11 +0200] information/ApiListener: New client connection for identity 'icinga-client' (unauthenticated)
 244
 245 If this message does not go away, make sure to verify the client's certificate and
 246 its received `ca.crt` in `/etc/icinga2/pki`.
 247
 248
 249 ### <a id="troubleshooting-cluster-message-errors"></a> Cluster Troubleshooting Message Errors
 250
 251 At some point, when the network connection is broken or gone, the Icinga 2 instances
 252 will be disconnected. If the connection can't be re-established between zones and endpoints,
 253 they remain in a Split-Brain-mode and history may differ.
 254
 255 Although the Icinga 2 cluster protocol stores historical events in a replay log for later synchronisation,
 256 you should make sure to check why the network connection failed.
 257
 258 ### <a id="troubleshooting-cluster-command-endpoint-errors"></a> Cluster Troubleshooting Command Endpoint Errors
 259
 260 Command endpoints can be used for clients acting as [remote command execution bridge](10-icinga2-client.md#icinga2-client-configuration-command-bridge)
 261 as well as inside an [High-Availability cluster](12-distributed-monitoring-ha.md#distributed-monitoring-high-availability).
 262
 263 There is no cli command for manually executing the check, but you can verify
 264 the following (e.g. by invoking a forced check from the web interface):
 265
 266 * `icinga2.log` contains connection and execution errors
 267  * `CheckCommand` definition not found on the remote client
 268  * Referenced check plugin not found on the remote client
 269  * Runtime warnings and errors, e.g. unresolved runtime macros or configuration problems
 270 * Specific error messages are also populated into `UNKNOWN` check results including a detailed error message in their output
 271
 272
 273 ### <a id="troubleshooting-cluster-config-sync"></a> Cluster Troubleshooting Config Sync
 274
 275 If the cluster zones do not sync their configuration, make sure to check the following:
 276
 277 * Within a config master zone, only one configuration master is allowed to have its config in `/etc/icinga2/zones.d`.
 278 ** The master syncs the configuration to `/var/lib/icinga2/api/zones/` during startup and only syncs valid configuration to the other nodes
 279 ** The other nodes receive the configuration into `/var/lib/icinga2/api/zones/`
 280 * The `icinga2.log` log file will indicate whether this ApiListener [accepts config](12-distributed-monitoring-ha.md#zone-config-sync-permissions), or not