content-sync, dictionary and formal updates, pick-25

Author: thomaskoslowski

src/common/de/relay.asciidoc

@@ -19,7 +19,6 @@ xref:ports#[Ports]
 
 [#intro]
 == Einleitung
-
 // ES: Abgrenzung von Szenarien mit air-gapped environments wäre wahrscheinlich hilfreich zur Einordnung
 
 ifdef::onprem[]
@@ -37,15 +36,16 @@ können Sie das {CMK} Relay einsetzen, um Monitoring-Daten einzusammeln und zu I
 
 include::include_technical_preview.asciidoc[]
 
+
 [#relaydiffs]
 === Unterschiede zum verteilten Monitoring
 
 Die folgenden Unterschiede verglichen mit xref:glossar#distributed_monitoring[verteiltem Monitoring] sind zu beachten:
 // ES: When to choose which? What are each variant's (dis)advantages?
 // MFS: Das hängt stark von vielen Faktoren wie verfügbare Bandbreite und Aufwand von Änderungen an der Firewall ab, daher müssen unsere Nutzer anhand der Eigenschaften selbst entscheiden. Ist bspw. Bandbreite massig verfügbar, aber Firewall-Konfiguration schwierig, wird man auch bei hunderten Hosts zum Relay greifen, umgekehrt bei geringer Bandbreite und viel Paketverlust auch bei Dutzenden eine eigene Site im betreffenden Netz ausrollen. 
 
-* _Die Kommunikationsrichtung:_ Das Relay xref:ports#relay[sendet Daten] immer zur Monitoring-Instanz.
-* _Der Ort der Datenverarbeitung:_ Das Relay verarbeitet weder Daten, noch speichert es sie – es sammelt nur Monitoring-Daten ein und gibt sie weiter.
+* _Die Kommunikationsrichtung_: Das Relay xref:ports#relay[sendet Daten] immer zur Monitoring-Instanz.
+* _Der Ort der Datenverarbeitung_: Das Relay verarbeitet weder Daten, noch speichert es sie – es sammelt nur Monitoring-Daten ein und gibt sie weiter.
 
 // ES: Aktuell erwähnt der Artikel Multi-Tenancy-Umgebungen gar nicht. Muss dort irgendwas besonderes beachtet werden beim Einsatz des Relays? In jedem Fall wäre eine kurze Erwähnung nützlich, zumindest um klarzustellen, ob das Feature in Ultimate MT verfügbar ist. Evtl kurz beschreiben, wie es sich in ein bestehendes Setup einfügt
 // MFS: Nicht sehr sinnvoll.
@@ -55,6 +55,7 @@ Die Verwendung des Relays in _Kombination_ mit verteiltem Monitoring ist derzeit
 In Umgebungen, die {ME} bestimmungsgemäß einsetzen, gibt es daher derzeit keinen praktischen Nutzen für das Relay.
 endif::[]
 
+
 [#scope]
 === Funktionsumfang
 
@@ -69,15 +70,15 @@ An der Erweiterung der Funktionalität um die Ausführung aktiver Checks arbeite
 Die Priorisierung der hinzugefügten Spezialagenten hängt von Nutzen für die Anwendenden und dem benötigten Aufwand ab.
 Eine Liste der im Relay enthaltenen Spezialagenten kann auf link:https://github.com/Checkmk/checkmk/blob/{current-major}/relay_supported_plugins.bzl[GitHub^] eingesehen werden.
 ifdef::onprem[]
-Spezialagenten, die via xref:mkps#[MKP] zu einer {CMK}-Instanz hinzugefügt wurden, werden _nicht_ auf das Relay übertragen.
+Spezialagenten, die via xref:glossar#mkp[MKP] zu einer {CMK}-Instanz hinzugefügt wurden, werden _nicht_ auf das Relay übertragen.
 endif::[]
 
-// MFS: Discuss hardware requirements with Max and Cristi
 
 [#platforms]
 === Unterstützte Plattformen
 
-Das {CMK} Relay wird link:https://hub.docker.com/r/checkmk/check-mk-relay[als Container^] für die Plattform _x86-64_ bereitgestellt.
+Das {CMK} Relay wird als link:https://hub.docker.com/r/checkmk/check-mk-relay[Container^] für die Plattform _x86-64_ bereitgestellt.
+
 
 [#ossupport]
 ==== Unterstützte Betriebssysteme
@@ -88,7 +89,7 @@ Derzeit unterstützt das Installationsskript Ubuntu Linux 24.04 sowie Red Hat En
 Wir haben uns für Podman entschieden, weil dessen enge Integration mit Systemd automatische Updates des Relay-Containers erleichtert. 
 Das Ausbringen auf anderen Container-Runtimes als Podman, der Betrieb auf anderen als den genannten Distributionen, die Aktualisierung auf anderen Wegen als dem direkten Zugriff auf `hub.docker.com`, die Nutzung mit anderen Podman-Paketen als denen der Distribution oder die Verwendung von mehreren Relays auf einem Linux-Host mag für erfahrene Nutzer funktionieren – allerdings bietet {CMK} keinen Support für derartige Umgebungen an.
 
-.Das Relay auf Windows
+.Das {CMK} Relay auf Windows
 [%collapsible]
 ====
 Wir testen derzeit den Betrieb des Relays auf Windows.
@@ -112,7 +113,7 @@ Wir werden Skripte zur Prüfung und Installation in den Monaten nach Release von
 [#hwrequirements]
 ==== Hardware-Anforderungen
 
-In Standardkonfiguration (13 Fetcher) sollte ein Arbeitsspeicherbedarf von etwa einem Gigabyte und die Auslastung eines Cores aktueller Hardware mit weniger als 20% eingeplant werden.
+In Standardkonfiguration (13 Fetcher) sollte ein Arbeitsspeicherbedarf von etwa einem Gigabyte und die Auslastung eines Prozessorkerns aktueller Hardware mit weniger als 20{nbsp}% eingeplant werden.
 Mit diesem Ressourcenumfang konnten wir problemlos mehr als 50 SNMP-Geräte überwachen.
 Bei einer deutlich höheren Zahl zu überwachender Geräte muss gegebenenfalls die Zahl der Fetcher erhöht werden.
 Nach oben skaliert der Ressourcenbedarf nahezu linear mit der Zahl zu überwachender Geräte.
@@ -126,7 +127,7 @@ Um den Downloadlink für das Installationsskript zu erhalten, navigieren Sie zu
 Klicken Sie dort auf [.guihint]#Add Relay configuration#, um den Einrichtungsassistenten zur Konfiguration eines neuen Relays zu starten.
 
 .Im ersten Schritt wird der Downloadlink des Installationsskripts bereitgestellt
-image::relay_wizard.png[alt="Im ersten Schritt wird der Downloadlink des Installationsskripts bereitgestellt"]
+image::relay_wizard.png[alt="Im Quick Setup für ein neues Relay zeigt der Schritt den Curl-Befehl zum Herunterladen des Installationsskripts."]
 // ES: reminder that the final screenshot should probably show an https download URL
 
 // MFS: Probably not needed anymore, see above
@@ -141,7 +142,7 @@ Beim Ausführen des Skripts wird der Container mit dem Relay heruntergeladen und
 
 [TIP]
 ====
-Die zum Kopieren und Einfügen angebotenen Parameter für Installation und Registrierung enthalten ein One-Time Token.
+Die zum Kopieren und Einfügen angebotenen Parameter für Installation und Registrierung enthalten ein Einmal-Token (_one-time token_).
 Dieses ist nach Erzeugung eine Stunde lang gültig.
 Sollte diese Stunde nicht ausreichend sein, können Sie die Registrierung auch mit Benutzername und Passwort eines Benutzers vornehmen, der ausreichende Berechtigungen für die Registrierung des Relays hat.
 ====
@@ -199,8 +200,8 @@ In der {CMK}-Instanz, zu der Sie eben das Relay hinzugefügt haben, müssen Sie
 [#updates]
 === Updates
 
-Ein mit dem bereitgestellten Installationsskript ausgebrachtes {CMK} Relay hält sich automatisch auf dem neuesten Stand.
-Sobald es erkennt, dass sich die Version der zugehörigen {CMK}-Instanz geändert hat, lädt es das passende Container-Image von Docker Hub herunter und startet ohne manuellen Eingriff neu.
+Ein mit dem bereitgestellten Installationsskript verteiltes {CMK} Relay hält sich automatisch auf dem neuesten Stand.
+Sobald es erkennt, dass sich die Version der zugehörigen {CMK}-Instanz geändert hat, lädt es das passende Container Image von Docker Hub herunter und startet ohne manuellen Eingriff neu.
 Abhängig von Ihrer Netzwerkgeschwindigkeit kann dieser Vorgang bis zu 10 Minuten dauern.
 
 
@@ -215,7 +216,7 @@ Das Relay wird mit der Überwachung der zugeordneten Hosts erst dann beginnen, w
 
 Jedes Relay kontaktiert die ihm zugeordnete {CMK}-Instanz regelmäßig für Konfigurations-Updates.
 Nachdem eine aktualisierte Konfiguration erhalten wurde, führt es die Spezialagenten und andere Checks sofort aus.
-Eine xref:glossar#service_discovery[Service Discovery] für Spezialagenten sollte schnell abgeschlossen sein, bei langsamen SNMP-Geräten kann es jedoch länger dauern.
+Eine xref:glossar#service_discovery[Service-Erkennung] für Spezialagenten sollte schnell abgeschlossen sein, bei langsamen SNMP-Geräten kann es jedoch länger dauern.
 Generell ist die Verzögerung durch das Relay marginal und liegt in den meisten Fällen im Bereich weniger Sekunden.
 
 // MFS: Add monitoring the relay when article on Podman monitoring is available
@@ -230,7 +231,7 @@ Obwohl schon recht stabil, ist es möglich, dass Sie auf den einen oder anderen
 [#version]
 === Prüfung der Version des Relays
 
-Die Version des Relay-Container-Images muss genau mit der Version der {CMK}-Instanz übereinstimmen, der es zugeordnet ist.
+Die Version des Relay Container Images muss genau mit der Version der {CMK}-Instanz übereinstimmen, der es zugeordnet ist.
 Sie können die Version mit dem Befehl `podman images` überprüfen.
 Führen Sie diesen Befehl als Root oder mit vorangestelltem `sudo` aus, um sicherzustellen, dass die Ausgabe alle relevanten Images enthält:
 
@@ -243,7 +244,7 @@ localhost/checkmk_relay           checkmk_sync  72c27637aa5a  5 months ago  428
 docker.io/checkmk/check-mk-relay  {current-major}b2       72c27637aa5a  5 months ago  428 MB
 ----
 
-Bei Deployment über das mitgelieferte Installationsskript richtet das {CMK} Relay einen Dienst ein, der das Container-Image automatisch auf die gleiche Version wie die zugehörige Instanz aktualisiert und den Container anschließend neu startet.
+Bei der Verteilung über das mitgelieferte Installationsskript richtet das {CMK} Relay einen Dienst ein, der das Container Image automatisch auf die gleiche Version wie die zugehörige Instanz aktualisiert und den Container anschließend neu startet.
 
 ////
 ES: Review comments from January 
@@ -267,7 +268,10 @@ TriggeredBy: ● checkmk_relay-update-manager.path
 ----
 
 Hier ist der Dienst geladen, es wurde jedoch noch keine Aktualisierung durchgeführt.
-Da die Aktualisierung selbst erst getriggert wird, wenn eine Datei auftaucht, weist er den (irreführenden) Status _inaktive (dead)_ auf.
+Da die Aktualisierung selbst erst getriggert wird, wenn eine Datei auftaucht, zeigt der Dienst den (irreführenden) Status `inaktive (dead)`.
+
+//This output shows the state of the last update run.
+//Here, success was logged.
 
 ////
 ES: Mein Output (und zwar unabhängig vom Aufruf mit/ohne sudo)
@@ -308,11 +312,12 @@ TriggeredBy: ● checkmk_relay-update-manager.path
 
 Hier zeigt der laufende Prozess `podman pull`, dass gerade ein Update läuft und der neueste Container heruntergeladen wird.
 
+
 [#restart]
 === Neustart des Containers
 
 Wie bereits erwähnt, ist Podman eng mit Systemd integriert.
-Daher sind Neustarts von Containern einfach Neustarts von Systemd-Units.
+Daher sind Neustarts von Containern einfach Neustarts von Systemd Units.
 // As this is a user-owned unit, make sure to run the command as the user used to install the Relay.
 
 [{shell}]
@@ -321,6 +326,7 @@ Daher sind Neustarts von Containern einfach Neustarts von Systemd-Units.
 {c-root} systemctl status checkmk_relay
 ----
 
+
 [#follow_logs]
 === Container-Logs prüfen
 
@@ -366,7 +372,7 @@ The Checkmk Relay has been removed.
 --------------------------------------------------------
 ----
 
-Vergessen Sie nicht, das verbundene Relay in Ihrer {CMK}-Site zu löschen, nachdem Sie das Relay entfernt haben.
+Vergessen Sie nicht, das verbundene Relay in Ihrer {CMK}-Instanz zu löschen, nachdem Sie das Relay entfernt haben.
 
 // ES: Was passiert dann mit dem konfigurierten Relay in meiner Checkmk-Instanz? In der Relays-Übersicht in der Weboberfläche sehe ich ja nirgends sowas wie einen Status. Die Site denkt auch immer noch, dass ich einen neuen Host diesem entfernten Relay zuordnen darf. Wenn ich das tue, hänge ich mit fleißig laufendem Spinner in der Service Discovery fest.
 // Aus meiner Sicht Quatsch, dass das Relay der Site beim Deinstallieren nicht bescheid sagt, dass es jetzt verschwindet.
@@ -384,20 +390,3 @@ mattias@DESKTOP-CJG2U6P:~$ uname -r
 mattias@DESKTOP-CJG2U6P:~$ uname -m
 x86_64
 ////
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-