only-de capitalization and typos

Author: eseyffarth

src/common/de/active_checks.asciidoc

@@ -152,7 +152,7 @@ Voraussetzung ist lediglich, dass das Plugin kompatibel zu Nagios ist.
 Dazu gehört eine einzeilige Ausgabe mit den Details des Status und ein Exit-Code, welcher den Status beschreibt.
 Dieser muss `0` für {OK}, `1` für {WARN}, `2` für {CRIT} oder `3` für {UNKNOWN} sein.
 
-Ein kurzes Beispiel, um die sehr einfache Syntax zu veranschaulichen, zeigt das folgende Skript, dass Sie z.B. im Unterverzeichnis `~/tmp` des Instanzverzeichnisses erstellen können:
+Ein kurzes Beispiel, um die sehr einfache Syntax zu veranschaulichen, zeigt das folgende Skript, das Sie z.B. im Unterverzeichnis `~/tmp` des Instanzverzeichnisses erstellen können:
 
 .~/tmp/myscript.sh
 [{file}]
@@ -162,7 +162,7 @@ echo "I am a self written check and I feel well."
 exit 0
 ----
 
-Legen Sie das Plugin in dem lokalen Pfad ihrer Instanz ab und machen Sie es in einem Rutsch ausführbar:
+Legen Sie das Plugin in dem lokalen Pfad Ihrer Instanz ab und machen Sie es in einem Rutsch ausführbar:
 
 [{shell}]
 ----

src/common/de/agent_linux.asciidoc

@@ -969,7 +969,7 @@ Kopieren Sie die Datei nach `/usr/lib/check_mk_agent/plugins`.
 Achten Sie dabei darauf, dass diese ausführbar ist.
 Falls nicht, verwenden Sie ein `chmod 755`.
 Der Agent wird das Plugin sonst nicht ausführen.
-Insbesondere, wenn Sie die Dateien nicht per `scp` übertragen sondern per HTTP von der Download-Seite holen, geht die Ausführungsberechtigung verloren.
+Insbesondere, wenn Sie die Dateien nicht per `scp` übertragen, sondern per HTTP von der Download-Seite holen, geht die Ausführungsberechtigung verloren.
 
 Sobald das Plugin ausführbar ist und im richtigen Verzeichnis liegt, wird es vom Agenten automatisch aufgerufen und es entsteht eine neue Sektion in der Agentenausgabe.
 Diese trägt üblicherweise den gleichen Namen wie das Plugin.

src/common/de/cmc_differences.asciidoc

@@ -55,7 +55,7 @@ Dieser Mechanismus kann zu schwankenden (_flapping_) Zuständen von Hosts in Inf
 
 [TIP]
 ====
-`icmpreceiver` wird jedes SNMP-Paket ignorieren, da SNMP nicht über TCP sondern UDP kommuniziert.
+`icmpreceiver` wird jedes SNMP-Paket ignorieren, da SNMP nicht über TCP, sondern über UDP kommuniziert.
 ====
 
 

src/common/de/forecast_graphs.asciidoc

@@ -3,7 +3,7 @@ include::global_attr.adoc[]
 = Vorhersagegraphen erstellen
 :revdate: 2021-03-11
 :title: Vorhersagegraphen erstellen
-:description: Mit den Vorhersagegraphen von {CMK} verbessern Sie ihr Capacity Management. Details zur Konfiguration erfahren Sie hier.
+:description: Mit den Vorhersagegraphen von {CMK} verbessern Sie Ihr Capacity Management. Details zur Konfiguration erfahren Sie hier.
 
 {related-start}
 xref:graphing#[Messwerte und Graphing]

src/common/de/graphing.asciidoc

@@ -521,7 +521,7 @@ myserver345:
 Wenn das neue Format eine höhere Auflösung oder zusätzliche
 Konsolidierungsfunktionen hat, werden die bestehenden Daten so gut es geht
 interpoliert, so dass die RRDs mit möglichst sinnvollen Werten gefüllt
-werden. Nur ist natürlich klar, dass wenn Sie z.B ab sofort nicht 2 sondern
+werden. Nur ist natürlich klar, dass wenn Sie z.B ab sofort nicht 2, sondern
 5 Tage mit minutengenauen Werten haben möchten, die Genauigkeit der bestehenden
 Daten nicht nachträglich erhöht werden kann.
 

src/common/de/hosts_setup.asciidoc

@@ -317,7 +317,7 @@ Sie bestimmen nur den Zeitraum, in dem der Service [.guihint]#Check_MK# sich im
 .Hier werden nach 14 Tagen Hosts automatisch entfernt
 image::hosts_rule_automatic_removal.png[alt="Regel zur Festlegung des Zeitraums für das automatische Entfernen von Hosts."]
 
-Um die Hosts nicht nur aus dem Setup sondern auch aus dem Monitoring zu entfernen, werden die Änderungen automatisch aktiviert.
+Um die Hosts nicht nur aus dem Setup, sondern auch aus dem Monitoring zu entfernen, werden die Änderungen automatisch aktiviert.
 Beachten Sie, dass bei der automatischen Aktivierung _alle_ anderen ausstehende Änderungen mit aktiviert werden.
 
 *Tipp*: Diese Regel ist in allen {CMK}-Editionen verfügbar.

src/common/de/hosts_structure.asciidoc

@@ -131,8 +131,7 @@ Für die Konfiguration großer Umgebungen ist es sehr hilfreich, von Beginn an e
 
 Einem Host ordnen Sie Merkmale zu in den Host-Eigenschaften auf der Seite [.guihint]#Properties of host# -- beim Erstellen oder Bearbeiten eines Hosts.
 Viele Attribute finden Sie sowohl in den Eigenschaften eines Hosts als auch in den Ordnereigenschaften wieder -- und genau das trifft auch auf die Host-Merkmale zu.
-// TK: Ist das folgende so ok?
-Das heißt, Host-Merkmale sind nicht nur für Hosts sondern auch für Ordner gültig.
+Das heißt, Host-Merkmale sind nicht nur für Hosts, sondern auch für Ordner gültig.
 Und damit werden auch Host-Merkmale über die Ordnerstruktur in {CMK} vererbt.
 Um zu verhindern, dass es bei der Vererbung zu ungewollten Überraschungen kommt, sollten Sie bei der Festlegung der Host-Merkmalsgruppe auf den Standardwert achten.
 In der Regel ist es sinnvoll, hier einen neutralen Wert festzulegen wie `None` oder `not applicable`.
@@ -164,7 +163,7 @@ Schlüssel und Wert müssen durch Doppelpunkt getrennt sein.
 Ein Host kann beliebig viele Labels haben, aber pro Schlüssel nur einen Wert.
 Also kann ein Host, der das Label `foo:bar` hat, nicht gleichzeitig `foo:bar2` haben.
 
-Übrigens können in {CMK} nicht nur Hosts sondern auch Services Labels tragen.
+Übrigens können in {CMK} nicht nur Hosts, sondern auch Services Labels tragen.
 Allerdings gibt es bei den Service-Labels einige Besonderheiten zu beachten, die im Artikel zu den xref:labels.html#service_labels[Labels] beschrieben sind.
 
 

src/common/de/labels.asciidoc

@@ -215,13 +215,13 @@ Durch diese Vorrangregeln haben Sie stets die letztgültige Kontrolle über die
 
 Eine wichtige Funktion von Labels ist die gleiche wie bei Host-Merkmalen:
 Nämlich ihre Verwendung als Bedingung in Regeln.
-Das ist vor allem bei automatisch erzeugten Labels interessant, weil Sie so ihr Monitoring vollautomatisch aufgrund von Informationen aus AWS, Azure, Kubernetes und Co anpassen können.
+Das ist vor allem bei automatisch erzeugten Labels interessant, weil Sie so Ihr Monitoring vollautomatisch aufgrund von Informationen aus AWS, Azure, Kubernetes und Co anpassen können.
 
 Fügen Sie Bedingungen mit [.guihint]#Add to condition# für die Host- oder die Service-Labels hinzu.
-Wählen Sie nun entweder [.guihint]#is# oder [.guihint]#not# um eine positive oder negative Bedingung zu formulieren und geben Sie dann das Label in der gewohnten Form `Schlüssel:Wert` ein.
+Wählen Sie nun entweder [.guihint]#is# oder [.guihint]#not#, um eine positive oder negative Bedingung zu formulieren und geben Sie dann das Label in der gewohnten Form `Schlüssel:Wert` ein.
 Achten Sie hier auf die exakte Schreibweise einschließlich der Groß-/Kleinschreibung.
 Da Labels ohne Vorgaben festgelegt werden können, kann {CMK} Vertipper nicht erkennen.
-Immerhin: Beim Eintippen eines Labels schlägt {CMK} bereits existierende Labels vor, sofern sie zu ihrer bisherigen Eingabe passen.
+Immerhin: Beim Eintippen eines Labels schlägt {CMK} bereits existierende Labels vor, sofern sie zu Ihrer bisherigen Eingabe passen.
 Bei den Vorschlägen wird nicht nach Host- und Service-Labels unterschieden: es werden alle passenden Labels angeboten.
 Achten Sie auf die korrekte Schreibweise, denn Buchstabendreher, falsche Groß-/Kleinschreibung etc. führen dazu, dass die Regel nicht mehr funktioniert.
 

src/common/de/monitoring_kubernetes.asciidoc

@@ -122,7 +122,7 @@ Sie können aber selbstverständlich auch jeden anderen Namen nutzen:
 
 Wir aktualisieren unsere Helm-Charts immer dann, wenn neue Gegebenheiten in Kubernetes dies erfordern.
 Deshalb lohnt sich von Zeit zu Zeit eine Prüfung, ob im Repository neue Versionen verfügbar sind.
-Wenn Sie ihre lokale Kopie unseres Repositories, wie in dem vorherigen Befehl, mit `checkmk-chart` bezeichnet haben, können Sie sich mit dem folgenden Befehl alle im Repository vorliegenden Versionen der Charts anzeigen lassen:
+Wenn Sie Ihre lokale Kopie unseres Repositorys, wie in dem vorherigen Befehl, mit `checkmk-chart` bezeichnet haben, können Sie sich mit dem folgenden Befehl alle im Repository vorliegenden Versionen der Charts anzeigen lassen:
 // TK: Ichnuwieder: Wie finde ich denn raus, welche Version ich installiert habe? Ja, ist nicht so wichtig...
 // SK: Der Hinweis, wie man herausfinden kann, welche Helm Chart aktuell im eigenen Cluster läuft käme hier verfrührt, weil ja eben noch nix läuft. Es wäre eventuell sinnvoller hier nur einen Verweis auf ein späteres Kapitel einzufügen.
 
@@ -410,8 +410,8 @@ Da das Kommando nicht selbsterklärend ist, bieten wir Ihnen nachfolgend eine Er
 |`helm upgrade --install` |Dieser Teil ist der Basisbefehl, um dem Kubernetes-Cluster die Konfiguration zu übermitteln.
 |`--create-namespace` |In Kubernetes geben Sie immer an, zu welchem _Namespace_ die Konfiguration hinzugefügt werden soll. Diese Option benötigen Sie, falls es den Namespace noch nicht gibt. Helm wird ihn in diesem Fall mit anlegen.
 |`-n checkmk-monitoring` |Diese Option bestimmt den Namespace, zu dem die Konfiguration hinzugefügt werden soll. `checkmk-monitoring` ist dabei nur ein Beispiel, wie dieser heißen könnte.
-|`myrelease` |`myrelease` bezeichnet hier das Release. Jede Instanz einer Helm-Chart, die in Ihrem Kubernetes-Cluster läuft wird als Release bezeichnet. Diesen Namen können Sie frei wählen.
-|`checkmk-chart/checkmk` |Der erste Teil dieser Option beschreibt das Repository, welches Sie xref:setup_helm_repo[zuvor] angelegt haben. Der zweite Teil -- nach dem Schrägstrich -- ist das _Paket_, in dem die notwendigen Informationen liegen, um die Konfiguration ihres Kubernetes-Monitoring erstellen zu können.
+|`myrelease` |`myrelease` bezeichnet hier das Release. Jede Instanz einer Helm-Chart, die in Ihrem Kubernetes-Cluster läuft, wird als Release bezeichnet. Diesen Namen können Sie frei wählen.
+|`checkmk-chart/checkmk` |Der erste Teil dieser Option beschreibt das Repository, welches Sie xref:setup_helm_repo[zuvor] angelegt haben. Der zweite Teil -- nach dem Schrägstrich -- ist das _Paket_, in dem die notwendigen Informationen liegen, um die Konfiguration Ihres Kubernetes-Monitoring erstellen zu können.
 |`-f values.yaml` |Zuletzt geben Sie die Konfigurationsdatei an, die Sie zuvor erstellt bzw. angepasst haben. Sie enthält alle Anpassungen, die in den Konfigurationsdateien berücksichtigt werden sollen, die mit `helm` erstellt werden.
 |===
 

src/common/de/monitoring_logfiles.asciidoc

@@ -329,12 +329,12 @@ Dies geschieht mithilfe der Regel [.guihint]#Logwatch Event Console Forwarding#
 
 Im Monitoring unterscheidet sich die Darstellung je nach verwendetem Check-Plugin.
 
-Verwenden Sie entweder `logwatch` oder `logwatch_groups`, finden Sie - nach der notwendigen Service-Erkennung - pro Log-Datei bzw. pro Gruppierung von Log-Dateien (siehe xref:logfile_grouping[Gruppierung von Log-Dateien]) einen Service der mit `Log` beginnt.
+Verwenden Sie entweder `logwatch` oder `logwatch_groups`, finden Sie - nach der notwendigen Service-Erkennung - pro Log-Datei bzw. pro Gruppierung von Log-Dateien (siehe xref:logfile_grouping[Gruppierung von Log-Dateien]) einen Service, der mit `Log` beginnt.
 Darauf folgt der vollständige Pfad der Datei bzw. der Gruppenname.
 
-Wenn Sie ihre Log-Meldungen hingegen and die Event Console weiterleiten, sehen Sie je nach Einstellung der Regel [.guihint]#Logwatch Event Console Forwarding# pro Weiterleitung einen Service, der Sie über die Zahl der weitergeleiteten Log-Meldungen informiert.
+Wenn Sie Ihre Log-Meldungen hingegen an die Event Console weiterleiten, sehen Sie je nach Einstellung der Regel [.guihint]#Logwatch Event Console Forwarding# pro Weiterleitung einen Service, der Sie über die Zahl der weitergeleiteten Log-Meldungen informiert.
 Bei der gebündelten Weiterleitung durch das Plugin `logwatch_ec` heißt dieser Service [.guihint]#Log Forwarding#.
-Wenn Sie die Option [.guihint]#Separate check# und damit das Plugin `logwatch_ec_single` verwenden, beginnt der Service-Name auch wieder mit `Log` gefolgt von dem Pfad der Log-Datei.
+Wenn Sie die Option [.guihint]#Separate check# und damit das Plugin `logwatch_ec_single` verwenden, beginnt der Service-Name auch wieder mit `Log`, gefolgt von dem Pfad der Log-Datei.
 Auch dieser Service informiert Sie dann über die Anzahl der weitergeleiteten Meldungen und darüber, wenn eine Log-Datei nicht gelesen werden kann.