From: Michael Friedrich <michael.friedrich@icinga.com>
Date: Thu, 4 Apr 2019 13:29:45 +0000 (+0200)
Subject: Troubleshooting docs: Add Windows agents without NodeName constant
X-Git-Tag: v2.11.0-rc1~164^2
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=refs%2Fpull%2F7082%2Fhead;p=icinga2

Troubleshooting docs: Add Windows agents without NodeName constant
---

diff --git a/doc/15-troubleshooting.md b/doc/15-troubleshooting.md
index 7c62d3bb4..dcbffd389 100644
--- a/doc/15-troubleshooting.md
+++ b/doc/15-troubleshooting.md
@@ -1067,6 +1067,33 @@ Check the following:
 
 ### Cluster Troubleshooting: Windows Agents <a id="troubleshooting-cluster-windows-agents"></a>
 
+#### Windows Agents consuming 100% CPU <a id="troubleshooting-cluster-windows-agents-cpu"></a>
+
+Icinga 2 requires the `NodeName` [constant](17-language-reference.md#constants) in various places to run.
+This includes loading the TLS certificates, setting the proper check source,
+and so on.
+
+Typically the Windows setup wizard and also the CLI commands populate the [constants.conf](04-configuring-icinga-2.md#constants-conf)
+file with the auto-detected or user-provided FQDN/Common Name.
+
+If this constant is not set during startup, Icinga will try to resolve the
+FQDN, if that fails, fetch the hostname. If everything fails, it logs
+an error and sets this to `localhost`. This results in undefined behaviour
+if ignored by the admin.
+
+Querying the DNS when not reachable is CPU consuming, and may look like Icinga
+is doing lots of checks, etc. but actually really is just starting up.
+
+In order to fix this, edit the `constants.conf` file and populate
+the `NodeName` constant with the FQDN. Ensure this is the same value
+as the local endpoint object name.
+
+```
+const NodeName = "windows-client1.domain.com"
+```
+
+
+
 #### Windows blocking Icinga 2 with ephemeral port range <a id="troubleshooting-cluster-windows-agents-ephemeral-port-range"></a>
 
 When you see a message like this in your Windows agent logs: