1 # Icinga 2 Troubleshooting <a id="troubleshooting"></a>
3 ## Required Information <a id="troubleshooting-information-required"></a>
5 Please ensure to provide any detail which may help reproduce and understand your issue.
6 Whether you ask on the community channels or you create an issue at [GitHub](https://github.com/Icinga), make sure
7 that others can follow your explanations. If necessary, draw a picture and attach it for
8 better illustration. This is especially helpful if you are troubleshooting a distributed
11 We've come around many community questions and compiled this list. Add your own
12 findings and details please.
14 * Describe the expected behavior in your own words.
15 * Describe the actual behavior in one or two sentences.
16 * Ensure to provide general information such as:
17 * How was Icinga 2 installed (and which repository in case) and which distribution are you using
19 * `icinga2 feature list`
21 * [Icinga Web 2](https://icinga.com/products/icinga-web-2/) version (screenshot from System - About)
22 * [Icinga Web 2 modules](https://icinga.com/products/icinga-web-2-modules/) e.g. the Icinga Director (optional)
23 * Configuration insights:
24 * Provide complete configuration snippets explaining your problem in detail
25 * Your [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) file
26 * If you run multiple Icinga 2 instances, the [zones.conf](04-configuring-icinga-2.md#zones-conf) file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes.
28 * Relevant output from your main and [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) in `/var/log/icinga2`. Please add step-by-step explanations with timestamps if required.
29 * The newest Icinga 2 crash log if relevant, located in `/var/log/icinga2/crash`
31 * If the check command failed, what's the output of your manual plugin tests?
32 * In case of [debugging](21-development.md#development) Icinga 2, the full back traces and outputs
34 ## Analyze your Environment <a id="troubleshooting-analyze-environment"></a>
36 There are many components involved on a server running Icinga 2. When you
37 analyze a problem, keep in mind that basic system administration knowledge
38 is also key to identify bottlenecks and issues.
42 > [Monitor Icinga 2](08-advanced-topics.md#monitoring-icinga) and use the hints for further analysis.
44 * Analyze the system's performance and dentify bottlenecks and issues.
45 * Collect details about all applications (e.g. Icinga 2, MySQL, Apache, Graphite, Elastic, etc.).
46 * If data is exchanged via network (e.g. central MySQL cluster) ensure to monitor the bandwidth capabilities too.
47 * Add graphs and screenshots to your issue description
49 Install tools which help you to do so. Opinions differ, let us know if you have any additions here!
51 ### Analyse your Linux/Unix Environment <a id="troubleshooting-analyze-environment-linux"></a>
53 [htop](https://hisham.hm/htop/) is a better replacement for `top` and helps to analyze processes
61 If you are for example experiencing performance issues, open `htop` and take a screenshot.
62 Add it to your question and/or bug report.
64 Analyse disk I/O performance in Grafana, take a screenshot and obfuscate any sensitive details.
65 Attach it when posting a question to the community channels.
67 The [sysstat](https://github.com/sysstat/sysstat) package provides a number of tools to
68 analyze the performance on Linux. On FreeBSD you could use `systat` for example.
72 apt-get install sysstat
75 Example for `vmstat` (summary of memory, processes, etc.):
80 // print timestamps, format in MB, stats every 1 second, 5 times
98 `sysstat` also provides the `iostat` binary. On FreeBSD you could use `systat` for example.
100 If you are missing checks and metrics found in your analysis, add them to your monitoring!
102 ### Analyze your Windows Environment <a id="troubleshooting-analyze-environment-windows"></a>
104 A good tip for Windows are the tools found inside the [Sysinternals Suite](https://technet.microsoft.com/en-us/sysinternals/bb842062.aspx).
106 You can also start `perfmon` and analyze specific performance counters.
107 Keep notes which could be important for your monitoring, and add service
110 ## Enable Debug Output <a id="troubleshooting-enable-debug-output"></a>
112 ### Enable Debug Output on Linux/Unix <a id="troubleshooting-enable-debug-output-linux"></a>
114 Enable the `debuglog` feature:
117 # icinga2 feature enable debuglog
118 # service icinga2 restart
121 The debug log file can be found in `/var/log/icinga2/debug.log`.
123 Alternatively you may run Icinga 2 in the foreground with debugging enabled. Specify the console
124 log severity as an additional parameter argument to `-x`.
127 # /usr/sbin/icinga2 daemon -x notice
130 The [log severity](09-object-types.md#objecttype-filelogger) can be one of `critical`, `warning`, `information`, `notice`
133 ### Enable Debug Output on Windows <a id="troubleshooting-enable-debug-output-windows"></a>
135 Open a command prompt with administrative privileges and enable the debug log feature.
138 C:> icinga2.exe feature enable debuglog
141 Ensure that the Icinga 2 service already writes the main log into `C:\ProgramData\icinga2\var\log\icinga2`.
142 Restart the Icinga 2 service and open the newly created `debug.log` file.
146 C:> net start icinga2
149 ## Configuration Troubleshooting <a id="troubleshooting-configuration"></a>
151 ### List Configuration Objects <a id="troubleshooting-list-configuration-objects"></a>
153 The `icinga2 object list` CLI command can be used to list all configuration objects and their
154 attributes. The tool also shows where each of the attributes was modified.
158 > Use the Icinga 2 API to access [config objects at runtime](12-icinga2-api.md#icinga2-api-config-objects) directly.
160 That way you can also identify which objects have been created from your [apply rules](17-language-reference.md#apply).
163 # icinga2 object list
165 Object 'localhost!ssh' of type 'Service':
166 * __name = 'localhost!ssh'
167 * check_command = 'ssh'
168 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 5:3-5:23
169 * check_interval = 60
170 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 24:3-24:21
171 * host_name = 'localhost'
172 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 4:3-4:25
173 * max_check_attempts = 3
174 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 23:3-23:24
176 * retry_interval = 30
177 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 25:3-25:22
178 * templates = [ 'ssh', 'generic-service' ]
179 % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 1:0-7:1
180 % += modified in '/etc/icinga2/conf.d/templates.conf', lines 22:1-26:1
183 % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
185 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
190 You can also filter by name and type:
193 # icinga2 object list --name *ssh* --type Service
194 Object 'localhost!ssh' of type 'Service':
195 * __name = 'localhost!ssh'
196 * check_command = 'ssh'
197 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 5:3-5:23
198 * check_interval = 60
199 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 24:3-24:21
200 * host_name = 'localhost'
201 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 4:3-4:25
202 * max_check_attempts = 3
203 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 23:3-23:24
205 * retry_interval = 30
206 % = modified in '/etc/icinga2/conf.d/templates.conf', lines 25:3-25:22
207 * templates = [ 'ssh', 'generic-service' ]
208 % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 1:0-7:1
209 % += modified in '/etc/icinga2/conf.d/templates.conf', lines 22:1-26:1
212 % += modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
214 % = modified in '/etc/icinga2/conf.d/hosts/localhost/ssh.conf', lines 6:3-6:19
216 Found 1 Service objects.
218 [2014-10-15 14:27:19 +0200] information/cli: Parsed 175 objects.
221 Runtime modifications via the [REST API](12-icinga2-api.md#icinga2-api-config-objects)
222 are not immediately updated. Furthermore there is a known issue with
223 [group assign expressions](17-language-reference.md#group-assign) which are not reflected in the host object output.
224 You need to restart Icinga 2 in order to update the `icinga2.debug` cache file.
226 ### Apply rules do not match <a id="apply-rules-do-not-match"></a>
228 You can analyze apply rules and matching objects by using the [script debugger](20-script-debugger.md#script-debugger).
230 ### Where are the check command definitions? <a id="check-command-definitions"></a>
232 Icinga 2 features a number of built-in [check command definitions](10-icinga-template-library.md#icinga-template-library) which are
240 in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered
241 configuration files and will be overridden on upgrade, so please send modifications as proposed patches upstream.
242 The default include path is set to `/usr/share/icinga2/includes` with the constant `IncludeConfDir`.
244 You should add your own command definitions to a new file in `conf.d/` called `commands.conf`
247 ### Configuration is ignored <a id="configuration-ignored"></a>
249 * Make sure that the line(s) are not [commented out](17-language-reference.md#comments) (starting with `//` or `#`, or
250 encapsulated by `/* ... */`).
251 * Is the configuration file included in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)?
253 Run the [configuration validation](11-cli-commands.md#config-validation) and add `notice` as log severity.
254 Search for the file which should be included i.e. using the `grep` CLI command.
257 # icinga2 daemon -C -x notice | grep command
260 ### Configuration attributes are inherited from <a id="configuration-attribute-inheritance"></a>
262 Icinga 2 allows you to import templates using the [import](17-language-reference.md#template-imports) keyword. If these templates
263 contain additional attributes, your objects will automatically inherit them. You can override
264 or modify these attributes in the current object.
266 The [object list](15-troubleshooting.md#troubleshooting-list-configuration-objects) CLI command allows you to verify the attribute origin.
268 ### Configuration Value with Single Dollar Sign <a id="configuration-value-dollar-sign"></a>
270 In case your configuration validation fails with a missing closing dollar sign error message, you
271 did not properly escape the single dollar sign preventing its usage as [runtime macro](03-monitoring-basics.md#runtime-macros).
274 critical/config: Error: Validation failed for Object 'ping4' (Type: 'Service') at /etc/icinga2/zones.d/global-templates/windows.conf:24: Closing $ not found in macro format string 'top-syntax=${list}'.
277 Correct the custom attribute value to
280 "top-syntax=$${list}"
284 ## Checks Troubleshooting <a id="troubleshooting-checks"></a>
286 ### Executed Command for Checks <a id="checks-executed-command"></a>
288 * Use the Icinga 2 API to [query](12-icinga2-api.md#icinga2-api-config-objects-query) host/service objects
289 for their check result containing the executed shell command.
290 * Use the Icinga 2 [console cli command](11-cli-commands.md#cli-command-console)
291 to fetch the checkable object, its check result and the executed shell command.
292 * Alternatively enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) and look for the executed command.
294 Example for a service object query using a [regex match](18-library-reference.md#global-functions-regex)
298 $ curl -k -s -u root:icinga -H 'Accept: application/json' -H 'X-HTTP-Method-Override: GET' -X POST 'https://localhost:5665/v1/objects/services' \
299 -d '{ "filter": "regex(pattern, service.name)", "filter_vars": { "pattern": "^http" }, "attrs": [ "__name", "last_check_result" ], "pretty": true }'
304 "__name": "example.localdomain!http",
305 "last_check_result": {
307 "check_source": "example.localdomain",
309 "/usr/local/sbin/check_http",
322 "name": "example.localdomain!http",
329 Example for using the `icinga2 console` CLI command evaluation functionality:
332 $ ICINGA2_API_PASSWORD=icinga icinga2 console --connect 'https://root@localhost:5665/' \
333 --eval 'get_service("example.localdomain", "http").last_check_result.command' | python -m json.tool
335 "/usr/local/sbin/check_http",
343 Example for searching the debug log:
346 # icinga2 feature enable debuglog
347 # systemctl restart icinga2
348 # tail -f /var/log/icinga2/debug.log | grep "notice/Process"
352 ### Checks are not executed <a id="checks-not-executed"></a>
354 * Check the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) to see if the check command gets executed.
355 * Verify that failed depedencies do not prevent command execution.
356 * Make sure that the plugin is executable by the Icinga 2 user (run a manual test).
357 * Make sure the [checker](11-cli-commands.md#enable-features) feature is enabled.
358 * Use the Icinga 2 API [event streams](12-icinga2-api.md#icinga2-api-event-streams) to receive live check result streams.
363 # sudo -u icinga /usr/lib/nagios/plugins/check_ping -4 -H 127.0.0.1 -c 5000,100% -w 3000,80%
365 # icinga2 feature enable checker
366 The feature 'checker' is already enabled.
369 Fetch all check result events matching the `event.service` name `random`:
372 $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugchecks&types=CheckResult&filter=match%28%22random*%22,event.service%29'
376 ### Analyze Check Source <a id="checks-check-source"></a>
378 Sometimes checks are not executed on the remote host, but on the master and so on.
379 This could lead into unwanted results or NOT-OK states.
381 The `check_source` attribute is the best indication where a check command
382 was actually executed. This could be a satellite with synced configuration
383 or a client as remote command bridge -- both will return the check source
384 as where the plugin is called.
386 Example for retrieving the check source from all `disk` services using a
387 [regex match](18-library-reference.md#global-functions-regex) on the name:
390 $ curl -k -s -u root:icinga -H 'Accept: application/json' -H 'X-HTTP-Method-Override: GET' -X POST 'https://localhost:5665/v1/objects/services' \
391 -d '{ "filter": "regex(pattern, service.name)", "filter_vars": { "pattern": "^disk" }, "attrs": [ "__name", "last_check_result" ], "pretty": true }'
396 "__name": "icinga2-client1.localdomain!disk",
397 "last_check_result": {
399 "check_source": "icinga2-client1.localdomain",
407 "name": "icinga2-client1.localdomain!disk",
414 Example for using the `icinga2 console` CLI command evaluation functionality:
417 $ ICINGA2_API_PASSWORD=icinga icinga2 console --connect 'https://root@localhost:5665/' \
418 --eval 'get_service("icinga2-client1.localdomain", "disk").last_check_result.check_source' | python -m json.tool
420 "icinga2-client1.localdomain"
424 ### NSClient++ Check Errors with nscp-local <a id="nsclient-check-errors-nscp-local"></a>
426 The [nscp-local](10-icinga-template-library.md#nscp-check-local) CheckCommand object definitions call the local `nscp.exe` command.
427 If a Windows client service check fails to find the `nscp.exe` command, the log output would look like this:
430 Command ".\nscp.exe" "client" "-a" "drive=d" "-a" "show-all" "-b" "-q" "check_drivesize" failed to execute: 2, "The system cannot find the file specified."
437 scp.exe" "client" "-a" "drive=d" "-a" "show-all" "-b" "-q" "check_drivesize" failed to execute: 2, "The system cannot find the file specified."
440 The above actually prints `.\\nscp.exe` where the escaped `\n` character gets interpreted as new line.
442 Both errors lead to the assumption that the `NscpPath` constant is empty or set to a `.` character.
443 This could mean the following:
445 * The command is **not executed on the Windows client**. Check the [check_source](15-troubleshooting.md#checks-check-source) attribute from the check result.
446 * You are using an outdated NSClient++ version (0.3.x or 0.4.x) which is not compatible with Icinga 2.
447 * You are using a custom NSClient++ installer which does not register the correct GUID for NSClient++
449 More troubleshooting:
451 Retrieve the `NscpPath` constant on your Windows client:
454 C:\Program Files\ICINGA2\sbin\icinga2.exe variable get NscpPath
457 If the variable is returned empty, manually test how Icinga 2 would resolve
458 its path (this can be found inside the ITL):
461 C:\Program Files\ICINGA2\sbin\icinga2.exe console --eval "dirname(msi_get_component_path(\"{5C45463A-4AE9-4325-96DB-6E239C034F93}\"))"
464 If this command does not return anything, NSClient++ is not properly installed.
465 Verify that inside the `Programs and Features` (`appwiz.cpl`) control panel.
467 You can run the bundled NSClient++ installer from the Icinga 2 Windows package.
468 The msi package is located in `C:\Program Files\ICINGA2\sbin`.
470 The bundled NSClient++ version has properly been tested with Icinga 2. Keep that
471 in mind when using a different package.
474 ### Check Thresholds Not Applied <a id="check-thresholds-not-applied"></a>
476 This could happen with [clients as command endpoint execution](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint).
478 If you have for example a client host `icinga2-client1.localdomain`
479 and a service `disk` check defined on the master, the warning and
480 critical thresholds are sometimes to applied and unwanted notification
483 This happens because the client itself includes a host object with
484 its `NodeName` and a basic set of checks in the [conf.d](04-configuring-icinga-2.md#conf-d)
485 directory, i.e. `disk` with the default thresholds.
487 Clients which have the `checker` feature enabled will attempt
488 to execute checks for local services and send their results
491 If you now have the same host and service objects on the
492 master you will receive wrong check results from the client.
496 * Disable the `checker` feature on clients: `icinga2 feature disable checker`.
497 * Remove the inclusion of [conf.d](04-configuring-icinga-2.md#conf-d) as suggested in the [client setup docs](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint).
499 ### Check Fork Errors <a id="check-fork-errors"></a>
501 Newer versions of systemd on Linux limit spawned processes for
504 * v227 introduces the `TasksMax` setting to units which allows to specify the spawned process limit.
505 * v228 adds `DefaultTasksMax` in the global `systemd-system.conf` with a default setting of 512 processes.
506 * v231 changes the default value to 15%
508 This can cause problems with Icinga 2 in large environments with many
509 commands executed in parallel starting with systemd v228. Some distributions
510 also may have changed the defaults.
512 The error message could look like this:
515 2017-01-12T11:55:40.742685+01:00 icinga2-master1 kernel: [65567.582895] cgroup: fork rejected by pids controller in /system.slice/icinga2.service
518 In order to solve the problem, increase the value for `DefaultTasksMax`
519 or set it to `infinity`.
522 mkdir /etc/systemd/system/icinga2.service.d
523 cat >/etc/systemd/system/icinga2.service.d/limits.conf <<EOF
525 DefaultTasksMax=infinity
528 systemctl daemon-reload
529 systemctl restart icinga2
532 An example is available inside the GitHub repository in [etc/initsystem](https://github.com/Icinga/icinga2/tree/master/etc/initsystem).
536 * [Fork limit for cgroups](https://lwn.net/Articles/663873/)
537 * [systemd changelog](https://github.com/systemd/systemd/blob/master/NEWS)
538 * [Icinga 2 upstream issue](https://github.com/Icinga/icinga2/issues/5611)
539 * [systemd upstream discussion](https://github.com/systemd/systemd/issues/3211)
541 ### Systemd Watchdog <a id="check-systemd-watchdog"></a>
543 Usually Icinga 2 is a mission critical part of infrastructure and should be
544 online at all times. In case of a recoverable crash (e.g. OOM) you may want to
545 restart Icinga 2 automatically. With systemd it is as easy as overriding some
546 settings of the Icinga 2 systemd service by creating
547 `/etc/systemd/system/icinga2.service.d/override.conf` with the following
553 StartLimitInterval=10
556 Using the watchdog can also help with monitoring Icinga 2, to activate and use it add the following to the override:
560 This way systemd will kill Icinga 2 if does not notify for over 30 seconds, a timout of less than 10 seconds is not
561 recommended. When the watchdog is activated, `Restart=` can be set to `watchdog` to restart Icinga 2 in the case of a
564 Run `systemctl daemon-reload && systemctl restart icinga2` to apply the changes.
565 Now systemd will always try to restart Icinga 2 (except if you run
566 `systemctl stop icinga2`). After three failures in ten seconds it will stop
567 trying because you probably have a problem that requires manual intervention.
569 ### Late Check Results <a id="late-check-results"></a>
571 [Icinga Web 2](https://icinga.com/products/icinga-web-2/) provides
572 a dashboard overview for `overdue checks`.
574 The REST API provides the [status](12-icinga2-api.md#icinga2-api-status) URL endpoint with some generic metrics
575 on Icinga and its features.
578 # curl -k -s -u root:icinga 'https://localhost:5665/v1/status?pretty=1' | less
581 You can also calculate late check results via the REST API:
583 * Fetch the `last_check` timestamp from each object
584 * Compare the timestamp with the current time and add `check_interval` multiple times (change it to see which results are really late, like five times check_interval)
586 You can use the [icinga2 console](11-cli-commands.md#cli-command-console) to connect to the instance, fetch all data
587 and calculate the differences. More infos can be found in [this blogpost](https://icinga.com/2016/08/11/analyse-icinga-2-problems-using-the-console-api/).
590 # ICINGA2_API_USERNAME=root ICINGA2_API_PASSWORD=icinga icinga2 console --connect 'https://localhost:5665/'
592 <1> => var res = []; for (s in get_objects(Service).filter(s => s.last_check < get_time() - 2 * s.check_interval)) { res.add([s.__name, DateTime(s.last_check).to_string()]) }; res
594 [ [ "10807-host!10807-service", "2016-06-10 15:54:55 +0200" ], [ "mbmif.int.netways.de!disk /", "2016-01-26 16:32:29 +0100" ] ]
597 Or if you are just interested in numbers, call [len](18-library-reference.md#array-len) on the result array `res`:
600 <2> => var res = []; for (s in get_objects(Service).filter(s => s.last_check < get_time() - 2 * s.check_interval)) { res.add([s.__name, DateTime(s.last_check).to_string()]) }; res.len()
605 If you need to analyze that problem multiple times, just add the current formatted timestamp
606 and repeat the commands.
609 <23> => DateTime(get_time()).to_string()
611 "2017-04-04 16:09:39 +0200"
613 <24> => var res = []; for (s in get_objects(Service).filter(s => s.last_check < get_time() - 2 * s.check_interval)) { res.add([s.__name, DateTime(s.last_check).to_string()]) }; res.len()
618 More details about the Icinga 2 DSL and its possibilities can be
619 found in the [language](17-language-reference.md#language-reference) and [library](18-library-reference.md#library-reference) reference chapters.
621 ### Late Check Results in Distributed Environments <a id="late-check-results-distributed"></a>
623 When it comes to a distributed HA setup, each node is responsible for a load-balanced amount of checks.
624 Host and Service objects provide the attribute `paused`. If this is set to `false`, the current node
625 actively attempts to schedule and execute checks. Otherwise the node does not feel responsible.
628 <3> => var res = {}; for (s in get_objects(Service).filter(s => s.last_check < get_time() - 2 * s.check_interval)) { res[s.paused] += 1 }; res
635 You may ask why this analysis is important? Fair enough - if the numbers are not inverted in a HA zone
636 with two members, this may give a hint that the cluster nodes are in a split-brain scenario, or you've
637 found a bug in the cluster.
640 If you are running a cluster setup where the master/satellite executes checks on the client via
641 [top down command endpoint](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint) mode,
642 you might want to know which zones are affected.
644 This analysis assumes that clients which are not connected, have the string `connected` in their
645 service check result output and their state is `UNKNOWN`.
648 <4> => var res = {}; for (s in get_objects(Service)) { if (s.state==3) { if (match("*connected*", s.last_check_result.output)) { res[s.zone] += [s.host_name] } } }; for (k => v in res) { res[k] = len(v.unique()) }; res
657 The result set shows the configured zones and their affected hosts in a unique list. The output also just prints the numbers
658 but you can adjust this by omitting the `len()` call inside the for loop.
660 ## Notifications Troubleshooting <a id="troubleshooting-notifications"></a>
662 ### Notifications are not sent <a id="notifications-not-sent"></a>
664 * Check the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) to see if a notification is triggered.
665 * If yes, verify that all conditions are satisfied.
666 * Are any errors on the notification command execution logged?
668 Please ensure to add these details with your own description
669 to any question or issue posted to the community channels.
671 Verify the following configuration:
673 * Is the host/service `enable_notifications` attribute set, and if so, to which value?
674 * Do the [notification](09-object-types.md#objecttype-notification) attributes `states`, `types`, `period` match the notification conditions?
675 * Do the [user](09-object-types.md#objecttype-user) attributes `states`, `types`, `period` match the notification conditions?
676 * Are there any notification `begin` and `end` times configured?
677 * Make sure the [notification](11-cli-commands.md#enable-features) feature is enabled.
678 * Does the referenced NotificationCommand work when executed as Icinga user on the shell?
680 If notifications are to be sent via mail, make sure that the mail program specified inside the
681 [NotificationCommand object](09-object-types.md#objecttype-notificationcommand) exists.
682 The name and location depends on the distribution so the preconfigured setting might have to be
683 changed on your system.
689 # icinga2 feature enable notification
690 The feature 'notification' is already enabled.
694 # icinga2 feature enable debuglog
695 # systemctl restart icinga2
697 # grep Notification /var/log/icinga2/debug.log > /root/analyze_notification_problem.log
700 You can use the Icinga 2 API [event streams](12-icinga2-api.md#icinga2-api-event-streams) to receive live notification streams:
703 $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugnotifications&types=Notification'
706 ## Feature Troubleshooting <a id="troubleshooting-features"></a>
708 ### Feature is not working <a id="feature-not-working"></a>
710 * Make sure that the feature configuration is enabled by symlinking from `features-available/`
711 to `features-enabled` and that the latter is included in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf).
712 * Are the feature attributes set correctly according to the documentation?
713 * Any errors on the logs?
715 Look up the [object type](09-object-types.md#object-types) for the required feature and verify it is enabled:
718 # icinga2 object list --type <feature object type>
721 Example for the `graphite` feature:
724 # icinga2 object list --type GraphiteWriter
727 Look into the log and check whether the feature logs anything specific for this matter.
730 grep GraphiteWriter /var/log/icinga2/icinga2.log
733 ## REST API Troubleshooting <a id="troubleshooting-api"></a>
735 In order to analyse errors on API requests, you can explicitly enable the [verbose parameter](12-icinga2-api.md#icinga2-api-parameters-global).
738 $ curl -k -s -u root:icinga -H 'Accept: application/json' -X DELETE 'https://localhost:5665/v1/objects/hosts/example-cmdb?pretty=1&verbose=1'
740 "diagnostic_information": "Error: Object does not exist.\n\n ....",
742 "status": "No objects found."
746 ## REST API Troubleshooting: No Objects Found <a id="troubleshooting-api-no-objects-found"></a>
748 Please note that the `404` status with no objects being found can also originate
749 from missing or too strict object permissions for the authenticated user.
751 This is a security feature to disable object name guessing. If this would not be the
752 case, restricted users would be able to get a list of names of your objects just by
753 trying every character combination.
755 In order to analyse and fix the problem, please check the following:
757 - use an administrative account with full permissions to check whether the objects are actually there.
758 - verify the permissions on the affected ApiUser object and fix them.
761 ## Certificate Troubleshooting <a id="troubleshooting-certificate"></a>
763 ### Certificate Verification <a id="troubleshooting-certificate-verification"></a>
765 If the TLS handshake fails when a client connects to the cluster or the REST API,
766 ensure to verify the used certificates.
768 Print the CA and client certificate and ensure that the following attributes are set:
771 * Serial number is a hex-encoded string.
772 * Issuer should be your certificate authority (defaults to `Icinga CA` for all CLI commands).
773 * Validity, meaning to say the certificate is not expired.
774 * Subject with the common name (CN) matches the client endpoint name and its FQDN.
775 * v3 extensions must set the basic constraint for `CA:TRUE` (ca.crt) or `CA:FALSE` (client certificate).
776 * Subject Alternative Name is set to a proper DNS name (required for REST API and browsers).
780 # cd /var/lib/icinga2/certs/
786 # openssl x509 -in ca.crt -text
791 Serial Number: 1 (0x1)
792 Signature Algorithm: sha256WithRSAEncryption
795 Not Before: Feb 23 14:45:32 2016 GMT
796 Not After : Feb 19 14:45:32 2031 GMT
797 Subject: CN=Icinga CA
798 Subject Public Key Info:
799 Public Key Algorithm: rsaEncryption
800 Public-Key: (4096 bit)
803 Exponent: 65537 (0x10001)
805 X509v3 Basic Constraints: critical
807 Signature Algorithm: sha256WithRSAEncryption
811 Client public certificate:
814 # openssl x509 -in icinga2-client1.localdomain.crt -text
820 86:47:44:65:49:c6:65:6b:5e:6d:4f:a5:fe:6c:76:05:0b:1a:cf:34
821 Signature Algorithm: sha256WithRSAEncryption
824 Not Before: Aug 20 16:20:05 2016 GMT
825 Not After : Aug 17 16:20:05 2031 GMT
826 Subject: CN=icinga2-client1.localdomain
827 Subject Public Key Info:
828 Public Key Algorithm: rsaEncryption
829 Public-Key: (4096 bit)
832 Exponent: 65537 (0x10001)
834 X509v3 Basic Constraints: critical
836 X509v3 Subject Alternative Name:
837 DNS:icinga2-client1.localdomain
838 Signature Algorithm: sha256WithRSAEncryption
842 Make sure to verify the client's certificate and its received `ca.crt` in `/var/lib/icinga2/certs` and ensure that
843 both instances are signed by the **same CA**.
846 # openssl verify -verbose -CAfile /var/lib/icinga2/certs/ca.crt /var/lib/icinga2/certs/icinga2-master1.localdomain.crt
847 icinga2-master1.localdomain.crt: OK
849 # openssl verify -verbose -CAfile /var/lib/icinga2/certs/ca.crt /var/lib/icinga2/certs/icinga2-client1.localdomain.crt
850 icinga2-client1.localdomain.crt: OK
853 Fetch the `ca.crt` file from the client node and compare it to your master's `ca.crt` file:
856 # scp icinga2-client1:/var/lib/icinga2/certs/ca.crt test-client-ca.crt
857 # diff -ur /var/lib/icinga2/certs/ca.crt test-client-ca.crt
860 On SLES11 you'll need to use the `openssl1` command instead of `openssl`.
863 ### Certificate Signing <a id="troubleshooting-certificate-signing"></a>
867 ### Certificate Problems with OpenSSL 1.1.0 <a id="troubleshooting-certificate-openssl-1-1-0"></a>
869 Users have reported problems with SSL certificates inside a distributed monitoring setup when they
871 * updated their Icinga 2 package to 2.7.0 on Windows or
872 * upgraded their distribution which included an update to OpenSSL 1.1.0.
874 Example during startup on a Windows client:
877 critical/SSL: Error loading and verifying locations in ca key file 'C:\ProgramData\icinga2\etc/icinga2/pki/ca.crt': 219029726, "error:0D0E20DE:asn1 encoding routines:c2i_ibuf:illegal zero content"
878 critical/config: Error: Cannot make SSL context for cert path: 'C:\ProgramData\icinga2\etc/icinga2/pki/client.crt' key path: 'C:\ProgramData\icinga2\etc/icinga2/pki/client.key' ca path: 'C:\ProgramData\icinga2\etc/icinga2/pki/ca.crt'.
881 A technical analysis and solution for re-creating the public CA certificate is
882 available in [this advisory](https://icinga.com/2017/08/30/advisory-for-ssl-problems-with-leading-zeros-on-openssl-1-1-0/).
885 ## Cluster and Clients Troubleshooting <a id="troubleshooting-cluster"></a>
887 This applies to any Icinga 2 node in a [distributed monitoring setup](06-distributed-monitoring.md#distributed-monitoring-scenarios).
889 You should configure the [cluster health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks) if you haven't
894 > Some problems just exist due to wrong file permissions or applied packet filters. Make
895 > sure to check these in the first place.
897 ### Cluster Troubleshooting Connection Errors <a id="troubleshooting-cluster-connection-errors"></a>
899 General connection errors could be one of the following problems:
901 * Incorrect network configuration
903 * Firewall rules preventing traffic
905 Use tools like `netstat`, `tcpdump`, `nmap`, etc. to make sure that the cluster communication
906 works (default port is `5665`).
909 # tcpdump -n port 5665 -i any
911 # netstat -tulpen | grep icinga
913 # nmap icinga2-client1.localdomain
916 ### Cluster Troubleshooting SSL Errors <a id="troubleshooting-cluster-ssl-errors"></a>
918 If the cluster communication fails with SSL error messages, make sure to check
921 * File permissions on the SSL certificate files
922 * Does the used CA match for all cluster endpoints?
923 * Verify the `Issuer` being your trusted CA
924 * Verify the `Subject` containing your endpoint's common name (CN)
925 * Check the validity of the certificate itself
927 Try to manually connect from `icinga2-client1.localdomain` to the master node `icinga2-master1.localdomain`:
930 # openssl s_client -CAfile /var/lib/icinga2/certs/ca.crt -cert /var/lib/icinga2/certs/icinga2-client1.localdomain.crt -key /var/lib/icinga2/certs/icinga2-client1.localdomain.key -connect icinga2-master1.localdomain:5665
937 If the connection attempt fails or your CA does not match, [verify the certificates](15-troubleshooting.md#troubleshooting-certificate-verification).
940 #### Cluster Troubleshooting Unauthenticated Clients <a id="troubleshooting-cluster-unauthenticated-clients"></a>
942 Unauthenticated nodes are able to connect. This is required for client setups.
947 [2015-07-13 18:29:25 +0200] information/ApiListener: New client connection for identity 'icinga2-client1.localdomain' (unauthenticated)
950 Client as command execution bridge:
953 [2015-07-13 18:29:26 +1000] notice/ClusterEvents: Discarding 'execute command' message from 'icinga2-master1.localdomain': Invalid endpoint origin (client not allowed).
956 If these messages do not go away, make sure to [verify the master and client certificates](15-troubleshooting.md#troubleshooting-certificate-verification).
958 ### Cluster Troubleshooting Message Errors <a id="troubleshooting-cluster-message-errors"></a>
960 When the network connection is broken or gone, the Icinga 2 instances will be disconnected.
961 If the connection can't be re-established between endpoints in the same HA zone,
962 they remain in a Split-Brain-mode and history may differ.
964 Although the Icinga 2 cluster protocol stores historical events in a [replay log](15-troubleshooting.md#troubleshooting-cluster-replay-log)
965 for later synchronisation, you should make sure to check why the network connection failed.
967 Ensure to setup [cluster health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks)
968 to monitor all endpoints and zones connectivity.
970 ### Cluster Troubleshooting Command Endpoint Errors <a id="troubleshooting-cluster-command-endpoint-errors"></a>
972 Command endpoints can be used [for clients](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
973 as well as inside an [High-Availability cluster](06-distributed-monitoring.md#distributed-monitoring-scenarios).
975 There is no cli command for manually executing the check, but you can verify
976 the following (e.g. by invoking a forced check from the web interface):
978 * `/var/log/icinga2/icinga2.log` contains connection and execution errors.
979 * The ApiListener is not enabled to [accept commands](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint).
980 * `CheckCommand` definition not found on the remote client.
981 * Referenced check plugin not found on the remote client.
982 * Runtime warnings and errors, e.g. unresolved runtime macros or configuration problems.
983 * Specific error messages are also populated into `UNKNOWN` check results including a detailed error message in their output.
984 * Verify the `check_source` object attribute. This is populated by the node executing the check.
985 * More verbose logs are found inside the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output).
987 * Use the Icinga 2 API [event streams](12-icinga2-api.md#icinga2-api-event-streams) to receive live check result streams.
989 Fetch all check result events matching the `event.service` name `remote-client`:
992 $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugcommandendpoint&types=CheckResult&filter=match%28%22remote-client*%22,event.service%29'
997 ### Cluster Troubleshooting Config Sync <a id="troubleshooting-cluster-config-sync"></a>
999 If the cluster zones do not sync their configuration, make sure to check the following:
1001 * Within a config master zone, only one configuration master is allowed to have its config in `/etc/icinga2/zones.d`.
1002 ** The master syncs the configuration to `/var/lib/icinga2/api/zones/` during startup and only syncs valid configuration to the other nodes.
1003 ** The other nodes receive the configuration into `/var/lib/icinga2/api/zones/`.
1004 * The `icinga2.log` log file in `/var/log/icinga2` will indicate whether this ApiListener
1005 [accepts config](06-distributed-monitoring.md#distributed-monitoring-top-down-config-sync), or not.
1007 Verify the object's [version](09-object-types.md#object-types) attribute on all nodes to
1008 check whether the config update and reload was successful or not.
1011 ### Cluster Troubleshooting Overdue Check Results <a id="troubleshooting-cluster-check-results"></a>
1013 If your master does not receive check results (or any other events) from the child zones
1014 (satellite, clients, etc.), make sure to check whether the client sending in events
1015 is allowed to do so.
1019 > General troubleshooting hints on late check results are documented [here](15-troubleshooting.md#late-check-results).
1021 The [distributed monitoring conventions](06-distributed-monitoring.md#distributed-monitoring-conventions)
1022 apply. So, if there's a mismatch between your client node's endpoint name and its provided
1023 certificate's CN, the master will deny all events.
1027 > [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) provides a dashboard view
1028 > for overdue check results.
1030 Enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) on the master
1031 for more verbose insights.
1033 If the client cannot authenticate, it's a more general [problem](15-troubleshooting.md#troubleshooting-cluster-unauthenticated-clients).
1035 The client's endpoint is not configured on nor trusted by the master node:
1038 Discarding 'check result' message from 'icinga2-client1.localdomain': Invalid endpoint origin (client not allowed).
1041 The check result message sent by the client does not belong to the zone the checkable object is
1045 Discarding 'check result' message from 'icinga2-client1.localdomain': Unauthorized access.
1049 ### Cluster Troubleshooting Replay Log <a id="troubleshooting-cluster-replay-log"></a>
1051 If your `/var/lib/icinga2/api/log` directory grows, it generally means that your cluster
1052 cannot replay the log on connection loss and re-establishment. A master node for example
1053 will store all events for not connected endpoints in the same and child zones.
1055 Check the following:
1057 * All clients are connected? (e.g. [cluster health check](06-distributed-monitoring.md#distributed-monitoring-health-checks)).
1058 * Check your [connection](15-troubleshooting.md#troubleshooting-cluster-connection-errors) in general.
1059 * Does the log replay work, e.g. are all events processed and the directory gets cleared up over time?
1060 * Decrease the `log_duration` attribute value for that specific [endpoint](09-object-types.md#objecttype-endpoint).
1064 ### Cluster Troubleshooting: Windows Agents <a id="troubleshooting-cluster-windows-agents"></a>
1066 #### Windows blocking Icinga 2 with ephemeral port range <a id="troubleshooting-cluster-windows-agents-ephemeral-port-range"></a>
1068 When you see a message like this in your Windows agent logs:
1071 critical/TcpSocket: Invalid socket: 10055, "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."
1074 Windows is blocking Icinga 2 and as such, no more TCP connection handling is possible.
1076 Depending on the version, patch level and installed applications, Windows is changing its
1077 range of [ephemeral ports](https://en.wikipedia.org/wiki/Ephemeral_port#Range).
1079 In order to solve this, raise the the `MaxUserPort` value in the registry.
1082 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
1084 Value Name: MaxUserPort Value
1089 More details in [this blogpost](https://www.netways.de/blog/2019/01/24/windows-blocking-icinga-2-with-ephemeral-port-range/)
1090 and this [MS help entry](https://support.microsoft.com/en-us/help/196271/when-you-try-to-connect-from-tcp-ports-greater-than-5000-you-receive-t).