Checkmk
diff --git a/‎src/includes/de/include_common_aws_azure.asciidoc‎
Lines changed: 1 addition & 1 deletion b/‎src/includes/de/include_common_aws_azure.asciidoc‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎src/includes/en/include_common_aws_azure.asciidoc‎
Lines changed: 1 addition & 1 deletion b/‎src/includes/en/include_common_aws_azure.asciidoc‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎src/onprem/de/ec.asciidoc‎
Lines changed: 21 additions & 21 deletions b/‎src/onprem/de/ec.asciidoc‎
Lines changed: 21 additions & 21 deletions
@@ -108,7 +108,7 @@ Da die Wege der xref:intro_notifications#[Benachrichtigungen] in {CMK} vielfält
 
 Auch der vollständige Verzicht auf ein lokales E-Mail-System ist möglich, falls Sie ausschließlich die xref:notifications#syncsmtp[nachvollziehbare Zustellung von HTML-E-Mails per SMTP] aktivieren wollen oder auf Benachrichtigungs-Plugins für Plattformen wie xref:notifications_teams#[Microsoft Teams] oder xref:notifications_slack#[Slack] setzen.
 
-Beachten Sie aber, dass in dieser Konfiguration keine xref:notification_rules#bulk[Bulk-Benachrichtigungen] möglich ist.
+Beachten Sie aber, dass in dieser Konfiguration keine xref:notification_rules#bulk[Bulk-Benachrichtigungen] möglich sind.
 
 [#simple_mta]
 ==== Relay-only oder vollwertiger Mail Transport Agent (MTA)
 
@@ -95,7 +95,7 @@ Since the paths for xref:intro_notifications#[notifications] in {CMK} are many a
 
 It is also possible to completely dispense with a local email system if you only want to enable xref:notifications#syncsmtp[trackable delivery of HTML emails via SMTP] or rely on notification plug-ins for platforms such as xref:notifications_teams#[Microsoft Teams] or xref:notifications_slack#[Slack].
 
-Note, however, that xref:notification_rules#bulk[bulk notifications] is not possible in this configuration.
+Note, however, that xref:notification_rules#bulk[bulk notifications] are not possible in this configuration.
 
 
 [#simple_mta]
 
@@ -4,7 +4,7 @@ include::global_attr.adoc[]
 = Die Event Console
 :revdate: 2021-12-02
 :title: Die Event Console - Logs und SNMP-Traps in {CMK} verarbeiten
-:description: Egal, ob Syslog, weitergeleitete Text-Logs oder Traps über SNMP - hier erfahren Sie, wie Sie diese Ereignisse in der {CMK} Event Console verarbeiten können.
+:description: {CMK} kann auf Ereignisse diverser Arten mit bestimmten Aktionen reagieren. Lesen Sie hier, wie Sie dafür die Event Console konfigurieren und nutzen.
 
 {related-start}
 xref:monitoring_basics#[Grundlagen des Monitorings mit {CMK}]
@@ -89,7 +89,7 @@ Das Einrichten der Event Console ist sehr einfach, da die Event Console  fester
 
 Falls Sie jedoch über das Netzwerk Syslog-Meldungen oder SNMP-Traps empfangen möchten, so müssen Sie dies separat aktivieren.
 Der Grund ist, dass beide Dienste einen UDP-Port mit einer jeweils bestimmten bekannten Portnummer öffnen müssen.
-Und da dies pro System nur eine {CMK} Instanz machen kann, ist der Empfang über das Netzwerk per Default abgeschaltet.
+Und da dies pro System nur eine {CMK}-Instanz machen kann, ist der Empfang über das Netzwerk per Default abgeschaltet.
 
 Die Port-Nummern sind:
 
@@ -140,7 +140,7 @@ Nun ist es leider so, dass die meisten Meldungen -- egal ob aus Textdateien, dem
 Und da hilft es auch nichts, wenn Meldungen seitens des Verursachers bereits voreingestuft sind.
 
 Zum Beispiel gibt es in Syslog und im Windows Event Log eine Klassifizierung der Meldungen in etwas Ähnliches wie OK, WARN und CRIT.
-Aber was jetzt WARN und CRIT ist, hat dabei der jeweilige Programmierer subjektiv festgelegt.
+Aber was jetzt WARN und CRIT ist, wurde bei der Programmierung dieser Klassifizierung subjektiv festgelegt.
 Und es ist noch nicht einmal gesagt, dass die Anwendung, welche die Meldung produziert hat, auf diesem Rechner überhaupt wichtig ist.
 Kurzum: Sie kommen nicht drumherum, selbst zu konfigurieren, welche Meldungen für Sie nach einem Problem aussehen und welche einfach verworfen werden können.
 
@@ -198,7 +198,7 @@ Klicken Sie zuerst rechts oben auf der Seite auf die Zahl der aufgelaufenen Änd
 
 image::ec_activate_changes.png[]
 
-Klicken Sie anschließend auf [.guihint]#Activate on selected sites# um die Änderung zu aktivieren.
+Klicken Sie anschließend auf [.guihint]#Activate on selected sites#, um die Änderung zu aktivieren.
 Die Event Console ist so konstruiert, dass diese Aktion absolut _unterbrechungsfrei_ abläuft.
 Der Empfang von eingehenden Meldungen wird zu jeder Zeit sichergestellt, so dass durch den Prozess keine Meldungen verlorengehen können.
 
@@ -262,7 +262,7 @@ Als Status wird zur Sicherheit {CRIT} angenommen:
 {c-user} echo 'This is no syslog message' | nc -w 0 -u 10.1.1.94 514
 ----
 
-Innerhalb der {CMK} Instanz, auf der die EC läuft, gibt es eine _named Pipe_, in die Sie Textmeldungen lokal per `echo` schreiben können.
+Innerhalb der {CMK}-Instanz, auf der die EC läuft, gibt es eine benannte Pipe (_named pipe_), in die Sie Textmeldungen lokal per `echo` schreiben können.
 Dies ist eine sehr einfache Methode, um eine lokale Anwendung anzubinden und ebenfalls eine Möglichkeit, das Verarbeiten von Meldungen zu testen:
 
 [{shell}]
@@ -306,7 +306,7 @@ Grundsätzlich gilt bei per Syslog empfangenen Meldungen, dass der in der Meldun
 Dies erreichen Sie durch Verwendung des _fully qualified domain name_ (FQDN) / _fully qualified host name_ (FQHN) sowohl in Ihrer Syslog-Konfiguration als auch in der Benennung der Hosts in {CMK}.
 In Rsyslog erreichen Sie dies über die globale Direktive `$PreserveFQDN on`.
 
-{CMK} versucht die Host-Namen aus den Events denen aus dem aktiven Monitoring so gut es geht xref:hostmatching[automatisch zuzuordnen.]
+{CMK} versucht, die Host-Namen aus den Events denen aus dem aktiven Monitoring xref:hostmatching[automatisch zuzuordnen], so gut es geht.
 Neben dem Host-Namen wird auch der Host-Alias ausprobiert.
 Steht hier der per Syslog übertragene Kurzname, erfolgt die Zuordnung korrekt.
 
@@ -412,7 +412,7 @@ Das Kommando [.guihint]#Change State# erlaubt den manuellen Zustandswechsel von
 
 Mit dem Kommando [.guihint]#Custom Action# können Sie auf Events frei definierbare xref:actions[Aktionen] ausführen lassen.
 Zunächst ist nur die Aktion [.guihint]#Send monitoring notification# verfügbar.
-Diese sendet eine {CMK} Benachrichtigung, die genauso behandelt wird wie die von einem aktiv überwachten Service.
+Diese sendet eine {CMK}-Benachrichtigung, die genauso behandelt wird wie die von einem aktiv überwachten Service.
 Diese durchläuft die xref:notification_rules#[Benachrichtigungsregeln] und führt dann entsprechend zu E-Mails, SMS oder was auch immer Sie konfiguriert haben.
 Einzelheiten zur Benachrichtigung durch die EC erfahren Sie xref:notifications[weiter unten].
 
@@ -547,7 +547,7 @@ image::ec_matching_criteria.png[]
 
 Bei allen Bedingungen, die Textfelder betreffen, wird der Vergleichstext grundsätzlich als xref:regexes#[regulärer Ausdruck] behandelt.
 Der Vergleich findet hier immer _ohne Unterscheidung von Groß-/Kleinschreibung_ statt.
-Letzteres ist eine Ausnahme von {CMK} Konventionen in anderen Modulen.
+Letzteres ist eine Ausnahme von {CMK}-Konventionen in anderen Modulen.
 Es macht aber das Formulieren der Regeln robuster.
 Auch sind gerade Host-Namen in Events nicht unbedingt konsistent in ihrer Schreibweise, falls diese nicht zentral, sondern auf jedem Host selbst konfiguriert werden.
 Daher ist diese Ausnahme hier sehr sinnvoll.
@@ -686,7 +686,7 @@ Meldungen, die direkt per Syslog empfangen wurden, enthalten eine von acht per R
 |`debug` |7 |{OK} |Debug-Meldung
 |===
 
-Neben Syslog-Meldungen bieten auch Meldungen aus dem Windows Event Log und Meldungen aus Textdateien, die bereits mit dem {CMK} Plugin xref:logwatch[Logwatch] auf dem Zielsystem klassifiziert wurden, vorbereitete Zustände.
+Neben Syslog-Meldungen bieten auch Meldungen aus dem Windows Event Log und Meldungen aus Textdateien, die bereits mit dem {CMK}-Plugin xref:logwatch[Logwatch] auf dem Zielsystem klassifiziert wurden, vorbereitete Zustände.
 Bei SNMP-Traps gibt es diese leider nicht.
 
 Eine ganze andere Methode ist, die Einstufung der Meldung anhand des Texts selbst zu machen.
@@ -1027,7 +1027,7 @@ Die Event Console bietet drei Arten von Aktionen, welche Sie entweder manuell od
 
 * Ausführen von selbst geschriebenen Shell-Skripten
 * Versenden von selbst definierten E-Mails
-* Erzeugen von {CMK} xref:notifications[Benachrichtigungen]
+* Erzeugen von {CMK}-xref:notifications[Benachrichtigungen]
 
 
 === Shell-Skripte und E-Mails
@@ -1048,8 +1048,8 @@ Eine vollständige Liste der verfügbaren Umgebungsvariablen erhalten Sie in der
 image::ec_define_action.png[]
 
 Ältere Versionen von {CMK} haben neben Umgebungsvariablen auch Makros wie `$TEXT$` erlaubt, die vor Ausführung des Skriptes ersetzt wurden.
-Wegen der Gefahr, dass ein Angreifer über ein eigens angefertigtes UDP-Paket Befehle einschleusen kann, die mit den Rechten des {CMK} Prozesses ausgeführt werden, sollten Sie von Makros keinen Gebrauch machen.
-Makros sind derzeit noch aus Kompatibilitätsgründen erlaubt, jedoch behalten wir uns die Entfernung in einer künftigen {CMK} Version vor.
+Wegen der Gefahr, dass ein Angreifer über ein eigens angefertigtes UDP-Paket Befehle einschleusen kann, die mit den Rechten des {CMK}-Prozesses ausgeführt werden, sollten Sie von Makros keinen Gebrauch machen.
+Makros sind derzeit noch aus Kompatibilitätsgründen erlaubt, jedoch behalten wir uns die Entfernung in einer künftigen {CMK}-Version vor.
 
 Das Beispielskript aus dem Screenshot legt im Instanzverzeichnis die Datei `tmp/test.out` an und schreibt dort einen Text mit den konkreten Werten der Variablen zu dem jeweils letzten Event:
 
@@ -1083,7 +1083,7 @@ echo "$OMD_ROOT/local/bin/myaction '$HOST$' '$TEXT$' | at now
 ==== Versenden von E-Mails
 
 Der Aktionstyp [.guihint]#Send Email# versendet eine einfache Text-E-Mail.
-Eigentlich könnten Sie das auch über den Umweg mit einem Skript erreichen, in dem Sie z.B. mit dem Kommandozeilenbefehl `mail` arbeiten.
+Eigentlich könnten Sie das auch über den Umweg mit einem Skript erreichen, indem Sie z.B. mit dem Kommandozeilenbefehl `mail` arbeiten.
 Aber so ist es komfortabler.
 Beachten Sie, dass auch in den Feldern [.guihint]#Recipient E-Mail address# und [.guihint]#Subject# Platzhalter erlaubt sind.
 
@@ -1131,7 +1131,7 @@ Dadurch kann es dazu kommen, dass der Host-Name in der Benachrichtigung nicht ex
 Die Anpassung auf die Schreibweise des aktiven Monitorings vereinfacht aber das Formulieren von einheitlichen Benachrichtigungsregeln, welche Bedingungen auf den Host-Namen enthalten.
 
 Die Zuordnung geschieht in Echtzeit durch eine xref:glossar#livestatus[Livestatus]-Abfrage an den Monitoring-Kern, welcher in der gleichen Instanz wie die EC läuft, die die Meldung empfangen hat.
-Das klappt natürlich nur, wenn die Syslog-Meldungen, SNMP-Traps usw. immer an diejenige {CMK} Instanz gesendet werden, auf der der Host auch aktiv überwacht wird!
+Das klappt natürlich nur, wenn die Syslog-Meldungen, SNMP-Traps usw. immer an diejenige {CMK}-Instanz gesendet werden, auf der der Host auch aktiv überwacht wird!
 
 Falls die Abfrage nicht klappt oder der Host nicht gefunden werden kann, werden Ersatzdaten angenommen:
 
@@ -1283,7 +1283,7 @@ image::ec_config_traps.png[width=360]
 // Hier muss entweder die EC angepasst werden oder wir müssen klar sagen:
 // Wir machen es aus Sicherheitsgründen nicht!
 // Dieses Feature ist für künftige Versionen geplant, genießt aber keine Priorität!
-Da auf jedem Server der UDP-Port für die Traps nur von einem Prozess verwendet werden kann, darf das pro Rechner nur in einer einzigen {CMK} Instanz gemacht werden.
+Da auf jedem Server der UDP-Port für die Traps nur von einem Prozess verwendet werden kann, darf das pro Rechner nur in einer einzigen {CMK}-Instanz gemacht werden.
 Beim Start der Instanz können Sie in der Zeile mit `mkeventd` kontrollieren, ob der Trap-Empfang eingeschaltet ist:
 
 [{shell}]
@@ -1378,7 +1378,7 @@ image::ec_trap_event_translated2.png[]
 
 === Hochladen eigener MIBs
 
-Leider haben sich die Vorteile von Open Source bei den Autoren von MIB-Dateien noch nicht herumgesprochen, und so sind wir vom {CMK} Projekt leider nicht in der Lage, herstellerspezifische MIB-Dateien mit auszuliefern.
+Leider haben sich die Vorteile von Open Source bei den Autoren von MIB-Dateien noch nicht herumgesprochen, und so sind wir vom {CMK}-Projekt leider nicht in der Lage, herstellerspezifische MIB-Dateien mit auszuliefern.
 Nur eine kleine Sammlung von freien Basis-MIBs ist vorinstalliert und sorgt z.B. für eine Übersetzung von `sysUpTime`.
 
 Sie können aber in der Event Console im Modul [.guihint]#SNMP MIBs for trap translation# mit dem Menü-Eintrag icon:icon_new[] [.guihint]#Add one or multiple MIBs# eigene MIB-Dateien hochladen, wie das hier mit einigen MIBs von _Netgear Smart Switches_ geschehen ist:
@@ -1398,7 +1398,7 @@ Hinweise zu den MIBs:
 == Überwachen von Log-Dateien
 
 // TK: Die beiden Absätze sind verwirrend als Einleitung: Ist Logwatch-Plugin = mk_logwatch? Was sind denn die "alle drei"? Und viel klarer geht es auch nicht weiter... 
-Der {CMK} Agent ist in der Lage, Log-Dateien über das _Logwatch_-Plugin auszuwerten.
+Der {CMK}-Agent ist in der Lage, Log-Dateien über das _Logwatch_-Plugin auszuwerten.
 Dieses Plugin bietet zunächst einmal eine eigene von der Event Console unabhängige Überwachung von Log-Dateien -- inklusive der Möglichkeit, Meldungen direkt im Monitoring zu quittieren. 
 Es gibt aber auch die Möglichkeit, die vom Plugin gefundenen Meldungen 1:1 in die Event Console weiterzuleiten.
 
@@ -1480,7 +1480,7 @@ image::ec_check_remote.png[]
 In diesem Fall kann es dann Sinn machen, mehr als einen Events-Check auf einem Host zu haben und die Checks nach Anwendungen zu trennen.
 Damit sich diese Services vom Namen unterscheiden, benötigen Sie dabei dann noch die Option [.guihint]#Item (used in service description)#, welche einen von Ihnen festgelegten Text in den Namen des Services einbaut.
 
-Falls Ihre Event Console nicht auf der gleichen {CMK} Instanz läuft, von der auch der Host überwacht wird, brauchen Sie unter [.guihint]#Access to Event Console# einen Remote-Zugriff per TCP:
+Falls Ihre Event Console nicht auf der gleichen {CMK}-Instanz läuft, von der auch der Host überwacht wird, brauchen Sie unter [.guihint]#Access to Event Console# einen Remote-Zugriff per TCP:
 
 image::ec_events_check.png[]
 
@@ -1754,7 +1754,7 @@ Falls Sie einen Wert mit [.guihint]#...create overflow event# aktiviert haben, w
 
 image::ec_overflow_event.png[]
 
-Falls Sie zusätzlich einen Wert mit [.guihint]#...notify contacts# aktiviert haben, werden passende Kontaktpersonen per {CMK} Benachrichtigung informiert.
+Falls Sie zusätzlich einen Wert mit [.guihint]#...notify contacts# aktiviert haben, werden passende Kontaktpersonen per {CMK}-Benachrichtigung informiert.
 Die Benachrichtigung durchläuft die xref:notification_rules#[Benachrichtigungsregeln] von {CMK}.
 Diese Regeln müssen sich nicht unbedingt an die Kontaktauswahl der Event Console halten, sondern können diese modifizieren.
 Folgende Tabelle zeigt, welche Kontakte ausgewählt werden, falls Sie [.guihint]#Notify all contacts of the notified host or service# eingestellt haben (was der Default ist):
@@ -1817,7 +1817,7 @@ Daneben gibt es noch etliche weitere Diagramme.
 
 == Verteiltes Monitoring
 
-Wie Sie die Event Console in einer Installation mit mehreren {CMK} Instanzen einsetzen, erfahren Sie im xref:distributed_monitoring#ec[Artikel über das verteilte Monitoring].
+Wie Sie die Event Console in einer Installation mit mehreren {CMK}-Instanzen einsetzen, erfahren Sie im xref:distributed_monitoring#ec[Artikel über das verteilte Monitoring].
 
 [#statusinterface]
 == Die Statusschnittstelle
@@ -1875,7 +1875,7 @@ Folgende Kommandos sind verfügbar:
 |`var/log/mkeventd.log` |Log-Datei der Event Console.
 |`etc/check_mk/mkeventd.d/wato/global.mk` |Die globalen Einstellungen der Event Console in Python-Syntax.
 |`etc/check_mk/mkeventd.d/wato/rules.mk` |Ihre ganzen konfigurierten Regelpakete und Regeln in Python-Syntax.
-|`tmp/run/mkeventd/events` |Eine Named Pipe, in die Sie mit `echo` oder anderen Befehlen direkt Meldungen schreiben können, um diese an die EC zu übergeben. Achten Sie darauf, dass zu jedem Zeitpunkt nur eine einzige Anwendung in diese Pipe schreibt, da sich die Texte der Meldungen sonst vermischen können.
+|`tmp/run/mkeventd/events` |Eine _named pipe_, in die Sie mit `echo` oder anderen Befehlen direkt Meldungen schreiben können, um diese an die EC zu übergeben. Achten Sie darauf, dass zu jedem Zeitpunkt nur eine einzige Anwendung in diese Pipe schreibt, da sich die Texte der Meldungen sonst vermischen können.
 |`tmp/run/mkeventd/eventsocket` |Ein Unix-Socket, das die gleiche Aufgabe wie die Pipe erfüllt, aber ein gleichzeitiges Schreiben mehrerer Anwendungen ermöglicht. Zum Hineinschreiben benötigen Sie den Befehl `unixcat` oder `socat`.
 |`tmp/run/mkeventd/pid` |Die aktuelle Prozess-ID des Event Daemons während dieser läuft.
 |`tmp/run/mkeventd/status` |Ein Unix-Socket, das die Abfrage des aktuellen Status und das Senden von Kommandos erlaubt. Die Anfragen der GUI gehen zunächst zum Monitoring-Kern, der dann auf diesen Socket zugreift.