added anchors and cleaned up a few dashes

(cherry picked from commit 45b3ca5)

Author: sebkir

src/common/de/monitoring_docker.asciidoc

@@ -106,6 +106,7 @@ Eine Vorlage mit ausführlichen Erläuterungen hierzu finden Sie im {CMK} Verzei
 In den kommerziellen Editionen können Sie alle Parameter bequem mit der xref:wato_monitoringagents#bakery[Agentenbäckerei] einstellen.
 
 
+[#monitoring_containers]
 === Container überwachen
 
 ==== Container-Hosts anlegen
@@ -194,6 +195,7 @@ endif::[]
 [#diagnose]
 == Diagnosemöglichkeiten
 
+[#diagnosis_docker_host]
 === Diagnose für einen Docker-Node
 
 Sollte die Einrichtung nicht klappen, gibt es verschiedene Möglichkeiten der Analyse des Problems.
@@ -231,6 +233,7 @@ Prüfen Sie dann gegebenenfalls Ihre Docker-Installation:
 ----
 
 
+[#diagnosis_container_host]
 === Diagnose für einen Container-Host
 
 Falls der Container-Host keine Daten erhält bzw. keine Services erkannt werden, prüfen Sie zuerst, ob die Piggyback-Daten zu diesem Host vorhanden sind.

src/common/en/monitoring_docker.asciidoc

@@ -26,7 +26,7 @@ As necessary as end-to-end and transparent monitoring of containers is, it is al
 But {CMK} monitors not only the general status of the daemon or the container, but also the container itself.
 A full list of the elements that can currently be monitored can be found in the link:https://checkmk.com/integrations[Catalog of check plug-ins^].
 
-Alongside the status and inventory information which {CMK} can determine over the node (docker-jargon for ’the host on which the containers are running’), {CMK} can also determine detailed status information for the containers.
+Alongside the status and inventory information which {CMK} can determine over the node (docker-jargon for 'the host on which the containers are running'), {CMK} can also determine detailed status information for the containers.
 For this every container has to be added as a separate host in {CMK} if the container is to be monitored.
 Its data will be xref:glossar#piggyback[piggybacked] from the node to this host.
 
@@ -105,6 +105,7 @@ A template with detailed explanations can be found in the {CMK} directory `~/sha
 In the commercial editions you can easily configure all parameters with the xref:wato_monitoringagents#bakery[Agent Bakery].
 
 
+[#monitoring_containers]
 === Monitoring the containers
 
 ==== Creating the container hosts
@@ -113,7 +114,7 @@ Of course the interesting aspect is the monitoring of the Docker containers.
 This will be implemented automatically by installing the plug-ins, however the services will not be assigned to the docker node, rather {CMK} assumes a single host per docker container.
 
 The mechanism used here is called xref:glossar#piggyback[piggyback]:
-The plug-in or special agent transports data of other hosts -- ‘piggybacked’ so to speak -- alongside its own data.
+The plug-in or special agent transports data of other hosts—​'piggybacked' so to speak--alongside its own data.
 {CMK} places this data in the `~/tmp/check_mk/piggyback` directory.
 All you have to do in the Setup is to create hosts with the correct names, and the services will then be automatically assigned to them.
 
@@ -135,7 +136,7 @@ However since many services monitored by the agent within the containers actuall
 
 ==== Alternative names for container hosts
 
-By default -- as mentioned above -- the 12-character short ID for the container is used as the name for the container host.
+By default--as mentioned above--the 12-character short ID for the container is used as the name for the container host.
 This can optionally be configured differently.
 To do this, in the configuration file `docker.cfg` (see xref:finetuning[Fine tuning the plug-in]) set the `container_id` option to `long` in order to use the complete container ID as the name, or to `name` in order to use the container name.
 
@@ -154,14 +155,14 @@ See the xref:piggyback#renamehosts[The piggyback mechanism] article for more opt
 ==== Monitoring the host state
 
 ifdef::onprem[]
-Since a container’s xref:monitoring_basics#hosts[host state] cannot really be verified using xref:cmc_differences#smartping[TCP packets or ICMP], this must be determined in another way.
-The [.guihint]#Docker container status# service facilitates this -- in any case it checks whether the container is running, and can thus be used as a secure tool for detecting the host state.
+Since a container's xref:monitoring_basics#hosts[host state] cannot really be verified using xref:cmc_differences#smartping[TCP packets or ICMP], this must be determined in another way.
+The [.guihint]#Docker container status# service facilitates this--in any case it checks whether the container is running, and can thus be used as a secure tool for detecting the host state.
 endif::[]
 ifdef::saas[]
-For monitoring the container’s xref:monitoring_basics#hosts[host state], using the  [.guihint]#Docker container status# service seems obvious -- in any case it checks whether the container is running, and can thus be used as a secure tool for detecting the host state.
+For monitoring the container's xref:monitoring_basics#hosts[host state], using the  [.guihint]#Docker container status# service seems obvious--in any case it checks whether the container is running, and can thus be used as a secure tool for detecting the host state.
 endif::[]
 Define a rule in the [.guihint]#Host check command# rule set for this purpose, and set the [.guihint]#Use the status of the service...# option to the mentioned service.
-Don’t forget to set the conditions so that only containers are affected.
+Don't forget to set the conditions so that only containers are affected.
 In our example all containers are located in a folder with the same name:
 
 image::docker_container_hoststatus.png[alt="Rule for the command to check the host state of the containers."]
@@ -174,7 +175,7 @@ This is especially true for the roll out of agent plug-ins.
 The three plug-ins `mem`, `cpu` and `diskstat` (Disk I/O) work without an agent in the container though, and are analyzed by the {CMK} agent on the node itself.
 
 Especially for self-created Docker images you might want to roll out the agent itself into the container.
-In this case the data is no longer analyzed -- as described above -- by the Docker node’s agent.
+In this case the data is no longer analyzed--as described above--by the Docker node's agent.
 Instead of this a separate agent runs in each container.
 Calling this agent will still be bundled in a piggyback procedure via the Docker node however.
 
@@ -183,21 +184,22 @@ Especially with minimally-built containers based on Alpine Linux it could very w
 In such a situation you should monitor the container from the Docker node.
 
 ifdef::onprem[]
-The use of the [.guihint]#Host check command# rule set will in this case only be required if the container is not pingable -- but it will otherwise function exactly as described above.
+The use of the [.guihint]#Host check command# rule set will in this case only be required if the container is not pingable--but it will otherwise function exactly as described above.
 endif::[]
 
 
 [#diagnose]
 == Diagnostic options
 
+[#diagnosis_docker_host]
 === Diagnosis of a Docker node
 
 Should the setup not be successful, there are a number of options for analyzing the problem.
 ifdef::onprem[]
 If applicable, verify that a {CMK} agent with at least version {v15} or a later version is installed on the host.
 endif::[]
 
-If the version of the agent on the host is suitable, next check if the data is present in the agent’s output.
+If the version of the agent on the host is suitable, next check if the data is present in the agent's output.
 You can download the output as a text file: in a host view in monitoring via the [.guihint]#Download agent output# action menu entry:
 
 image::docker_node_dropdown.png[alt="Action menu of the host in monitoring with the entry for downloading the agent output.", width=65%]
@@ -226,11 +228,11 @@ If necessary, check your Docker installation:
 {c-root} docker info 2>&1
 ----
 
-
+[#diagnosis_container_host]
 === Diagnosis for a container host
 
 If the container host receives no data, or respectively, no services are detected, first check if piggyback data is available for this host.
-The host’s name must be identical to the ID of the container.
+The host's name must be identical to the ID of the container.
 Alternatively, you can also make a manual assignment using the [.guihint]#Host name translation for piggybacked hosts# rule set.
 Here, however, only the [.guihint]#Explicit hostname mapping# option is suitable:
 
@@ -267,7 +269,7 @@ ifdef::onprem[]
 |===
 |File path |Function 
 
-|`~/tmp/check_mk/piggyback/` |{CMK} saves the piggyback data here. For each piggybacked host a subfolder is created with the host’s name -- this subfolder contains a text file with the host’s data. The filename is the name of the piggyback host providing the data.
-|`~/tmp/check_mk/cache/` |Here the most recent agent output from all hosts is saved temporarily. The contents of a host’s file is identical to that from the `cmk -d myserver123` command.
+|`~/tmp/check_mk/piggyback/` |{CMK} saves the piggyback data here. For each piggybacked host a subfolder is created with the host's name--this subfolder contains a text file with the host's data. The filename is the name of the piggyback host providing the data.
+|`~/tmp/check_mk/cache/` |Here the most recent agent output from all hosts is saved temporarily. The contents of a host's file is identical to that from the `cmk -d myserver123` command.
 |===
 endif::[]