Updated to .NET Framework 4.7.2 due to platform limitations, added email cc, bcc and some fixes.
This commit is contained in:
+532
-349
@@ -1,349 +1,532 @@
|
||||
# Dokumentation – Host Availability Monitor (.NET Framework 4.8)
|
||||
|
||||
## 1. Zielbild
|
||||
|
||||
Die Anwendung überwacht auf einem Windows Server 2019 in festen Intervallen die netzwerktechnische Verfügbarkeit definierter Ziele. Typische Einsatzzwecke:
|
||||
|
||||
- interne Fileshares
|
||||
- externe HTTPS-Endpunkte
|
||||
- SFTP-Gegenstellen
|
||||
- TCP-Dienste
|
||||
- Hosts per Ping
|
||||
|
||||
Der Betrieb erfolgt typischerweise über den **Windows Task Scheduler** alle 30 Minuten.
|
||||
|
||||
## 2. Unterstützte Zieltypen
|
||||
|
||||
### 2.1 UNC / SMB
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
\\internerserver1\share1
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
1. TCP-Check auf Port 445 (oder überschriebenen Port)
|
||||
2. Optional zusätzliche Pfadvalidierung mit `Directory.Exists(...)` / `File.Exists(...)`
|
||||
|
||||
Hinweis:
|
||||
|
||||
- `ValidateUncPathAccess=false` ist robuster, wenn es nur um Erreichbarkeit geht.
|
||||
- `ValidateUncPathAccess=true` ist strenger, weil Berechtigungen, Namensauflösung und tatsächlicher Share-Zugriff geprüft werden.
|
||||
|
||||
### 2.2 HTTP / HTTPS
|
||||
|
||||
Beispiele:
|
||||
|
||||
```text
|
||||
https://host1.de/url
|
||||
http://intranet.local/health
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
- Standardmäßig `HEAD`
|
||||
- Fallback auf `GET`, wenn `HEAD` nicht unterstützt wird (`405` / `501`) oder der HEAD-Request fehlschlägt
|
||||
- Jede empfangene HTTP-Antwort zählt als **netzwerktechnisch erreichbar**
|
||||
|
||||
### 2.3 SFTP
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
sftp://partner.example.local/inbound
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
- TCP-Port-Prüfung, standardmäßig Port 22
|
||||
- kein Login, keine Dateioperation
|
||||
|
||||
### 2.4 TCP
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
tcp://host2.example.local:8443
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
- reiner Verbindungsaufbau auf dem Zielport
|
||||
|
||||
### 2.5 ICMP
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
icmp://server01
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
- Ping über `System.Net.NetworkInformation.Ping`
|
||||
|
||||
### 2.6 Plain Hostnames
|
||||
|
||||
Beispiele:
|
||||
|
||||
```text
|
||||
server01
|
||||
partner-gateway
|
||||
```
|
||||
|
||||
Verhalten:
|
||||
|
||||
- wenn `Port` gesetzt ist: TCP-Check
|
||||
- wenn kein `Port` gesetzt ist: ICMP-Check
|
||||
|
||||
## 3. Konfigurationsmodell
|
||||
|
||||
Die Konfiguration erfolgt in `appsettings.json`.
|
||||
|
||||
### 3.1 Runtime
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
| `MaxConcurrency` | Maximale parallele Checks |
|
||||
| `DefaultValidateUncPathAccess` | Default für UNC-Pfadzugriffsprüfung |
|
||||
| `NonZeroExitCodeOnAnyFailure` | Exit Code 2 bei mindestens einem fehlgeschlagenen Check |
|
||||
| `NonZeroExitCodeOnExecutionError` | Exit Code 1 bei technischen Fehlern |
|
||||
| `StateDirectory` | Verzeichnis für Statusdatei |
|
||||
|
||||
### 3.2 Logging
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
| `LogDirectory` | Verzeichnis der Logdateien |
|
||||
| `FilePrefix` | Präfix des Tageslogs |
|
||||
| `RetentionDays` | Anzahl Tage zur Aufbewahrung |
|
||||
|
||||
### 3.3 EventLog
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
| `Enabled` | Aktiviert Event Log |
|
||||
| `LogName` | Standard: `Application` |
|
||||
| `Source` | Event Source |
|
||||
| `CreateSourceIfMissing` | Optionaler Versuch, die Source anzulegen |
|
||||
| `WriteSuccessEntries` | Erfolgreiche Einzelchecks schreiben |
|
||||
| `WriteSummaryEntries` | Laufzusammenfassung schreiben |
|
||||
|
||||
### 3.4 Email
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
| `Enabled` | Aktiviert SMTP-Benachrichtigung |
|
||||
| `SmtpHost` / `SmtpPort` | SMTP-Ziel |
|
||||
| `UseSsl` | SSL/TLS für SMTP |
|
||||
| `Username` / `Password` | Optionale Credentials |
|
||||
| `From` | Absender |
|
||||
| `To` | Empfängerliste |
|
||||
| `SubjectPrefix` | Präfix im Betreff |
|
||||
| `SendOnFailure` | Mail bei Fehler |
|
||||
| `SendOnRecovery` | Mail bei Wiederherstellung |
|
||||
| `OnlyOnStateChange` | Nur bei Statuswechsel |
|
||||
| `CooldownMinutes` | Minimaler Abstand zwischen Benachrichtigungen |
|
||||
| `TimeoutSeconds` | SMTP-Timeout |
|
||||
|
||||
### 3.5 Targets
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
| `Name` | Anzeigename |
|
||||
| `Endpoint` | UNC, URL, SFTP, TCP, ICMP oder Hostname |
|
||||
| `TimeoutSeconds` | Timeout je Ziel |
|
||||
| `Port` | Optionaler Zielport |
|
||||
| `ValidateUncPathAccess` | Optional pro UNC-Ziel |
|
||||
| `HttpMethod` | `HEAD` oder `GET` |
|
||||
| `Enabled` | Ziel aktiv/inaktiv |
|
||||
|
||||
## 4. Logging-Verhalten
|
||||
|
||||
### 4.1 Dateilog
|
||||
|
||||
Pro Tag entsteht genau eine Logdatei:
|
||||
|
||||
```text
|
||||
logs\host-availability-monitor-2026-04-16.log
|
||||
```
|
||||
|
||||
Format:
|
||||
|
||||
```text
|
||||
2026-04-16 08:00:00.123 +02:00 | INFO | Lauf gestartet.
|
||||
2026-04-16 08:00:00.532 +02:00 | SUCCESS | Name=Externe Webseite | Kind=Https | Endpoint=https://host1.de/url | DurationMs=278 | Status=Reachable | Detail=HTTP-Antwort erhalten (200 OK). | Host=host1.de | Port=443 | HttpStatus=200
|
||||
2026-04-16 08:00:01.003 +02:00 | FAIL | Name=SFTP Partner A | Kind=Sftp | Endpoint=sftp://partner.example.local/inbound | DurationMs=10005 | Status=Unreachable | Detail=TCP-Verbindung fehlgeschlagen: A connection attempt failed... | Host=partner.example.local | Port=22 | ErrorType=SocketException
|
||||
```
|
||||
|
||||
### 4.2 Retention
|
||||
|
||||
Beim Start eines Laufs werden alte Tageslogs bereinigt.
|
||||
|
||||
Standard:
|
||||
|
||||
- aktueller Tag + 4 vorherige Tage bleiben erhalten
|
||||
- ältere Logs werden gelöscht
|
||||
|
||||
## 5. Event Log
|
||||
|
||||
Es wird in das Windows Application Event Log geschrieben.
|
||||
|
||||
Typische Events:
|
||||
|
||||
- Fehler bei Einzelchecks: Warning
|
||||
- technische Fehler: Error
|
||||
- Laufzusammenfassung: Information oder Warning
|
||||
|
||||
Wichtig:
|
||||
|
||||
- Das Erzeugen einer Event Source benötigt erhöhte Rechte.
|
||||
- Im produktiven Betrieb sollte die Source einmalig per Skript registriert werden.
|
||||
- Falls Event Log nicht verfügbar ist, fällt die Anwendung auf Dateilogging zurück und läuft weiter.
|
||||
|
||||
## 6. Benachrichtigungslogik
|
||||
|
||||
Die Anwendung speichert je Ziel einen Status in `state\monitor-state.json`.
|
||||
|
||||
Gespeicherte Informationen pro Ziel:
|
||||
|
||||
- `IsUp`
|
||||
- `ConsecutiveFailures`
|
||||
- `LastCheckedUtc`
|
||||
- `LastChangedUtc`
|
||||
- `LastNotificationUtc`
|
||||
- `LastDetail`
|
||||
|
||||
### 6.1 Benachrichtigung bei Fehler
|
||||
|
||||
Es wird benachrichtigt, wenn:
|
||||
|
||||
- `Email.Enabled=true`
|
||||
- `SendOnFailure=true`
|
||||
- das Ziel aktuell fehlschlägt
|
||||
- und je nach Einstellung entweder
|
||||
- ein Statuswechsel vorliegt oder
|
||||
- der Cooldown abgelaufen ist
|
||||
|
||||
### 6.2 Benachrichtigung bei Recovery
|
||||
|
||||
Es wird benachrichtigt, wenn:
|
||||
|
||||
- `Email.Enabled=true`
|
||||
- `SendOnRecovery=true`
|
||||
- das Ziel aktuell erfolgreich ist
|
||||
- und der vorherige bekannte Zustand `down` war
|
||||
|
||||
### 6.3 Anti-Spam
|
||||
|
||||
Mit `OnlyOnStateChange=true` werden bei Dauerfehlern nicht bei jedem Lauf erneut Mails versendet.
|
||||
|
||||
Mit `CooldownMinutes > 0` kann zusätzlich ein Zeitfenster definiert werden.
|
||||
|
||||
## 7. Exit Codes
|
||||
|
||||
| Exit Code | Bedeutung |
|
||||
|---|---|
|
||||
| `0` | Lauf erfolgreich abgeschlossen |
|
||||
| `1` | technischer Fehler / Konfigurations- oder Laufzeitproblem |
|
||||
| `2` | mindestens ein Ziel fehlgeschlagen und `NonZeroExitCodeOnAnyFailure=true` |
|
||||
|
||||
## 8. Task Scheduler Empfehlung
|
||||
|
||||
### 8.1 Allgemein
|
||||
|
||||
- Trigger: alle 30 Minuten
|
||||
- Benutzerkonto: dediziertes Servicekonto, falls UNC-Zugriffe Berechtigungen benötigen
|
||||
- "Start in": Installationsverzeichnis setzen
|
||||
|
||||
### 8.2 Beispiel
|
||||
|
||||
**Aktion**
|
||||
|
||||
- Program/script:
|
||||
|
||||
```text
|
||||
C:\Tools\HostAvailabilityMonitor\HostAvailabilityMonitor.exe
|
||||
```
|
||||
|
||||
- Add arguments:
|
||||
|
||||
```text
|
||||
C:\Tools\HostAvailabilityMonitor\appsettings.json
|
||||
```
|
||||
|
||||
- Start in:
|
||||
|
||||
```text
|
||||
C:\Tools\HostAvailabilityMonitor
|
||||
```
|
||||
|
||||
## 9. Betriebshinweise
|
||||
|
||||
### 9.1 UNC-Prüfung
|
||||
|
||||
Wenn echte Share-Verfügbarkeit geprüft werden soll:
|
||||
|
||||
- Task mit geeignetem Servicekonto ausführen
|
||||
- `ValidateUncPathAccess=true` für das betreffende Ziel setzen
|
||||
|
||||
Wenn nur der Zielserver bzw. SMB-Port relevant ist:
|
||||
|
||||
- `ValidateUncPathAccess=false` belassen
|
||||
|
||||
### 9.2 HTTP/HTTPS
|
||||
|
||||
Die Anwendung prüft Erreichbarkeit, nicht Business-Logik. Für Applikations-Health kann eine dedizierte Health-URL sinnvoller sein.
|
||||
|
||||
### 9.3 SFTP
|
||||
|
||||
Da nur der Port geprüft wird, eignet sich der Check für "Ist die Gegenstelle erreichbar?", nicht für "Kann ich mich anmelden und Dateien lesen?".
|
||||
|
||||
### 9.4 TLS
|
||||
|
||||
Die Anwendung aktiviert zusätzlich gängige SecurityProtocol-Werte, damit HTTPS-Ziele in älteren .NET-Framework-Umgebungen robuster funktionieren.
|
||||
|
||||
## 10. Build und Deployment
|
||||
|
||||
### 10.1 Voraussetzungen
|
||||
|
||||
- Windows Build Host
|
||||
- Visual Studio oder Build Tools mit MSBuild
|
||||
- .NET Framework 4.8 Targeting/Developer Pack
|
||||
|
||||
### 10.2 Build
|
||||
|
||||
```powershell
|
||||
msbuild .\HostAvailabilityMonitor.sln /p:Configuration=Release /p:Platform="Any CPU"
|
||||
```
|
||||
|
||||
### 10.3 Artefakte
|
||||
|
||||
Relevant für Deployment:
|
||||
|
||||
- `HostAvailabilityMonitor.exe`
|
||||
- `HostAvailabilityMonitor.exe.config`
|
||||
- `appsettings.json`
|
||||
- weitere referenzierte .NET-Assemblies aus `bin\Release`
|
||||
|
||||
## 11. Sicherheits- und Resilienz-Aspekte
|
||||
|
||||
Die Anwendung ist bewusst defensiv aufgebaut:
|
||||
|
||||
- Fehler einzelner Checks stoppen nicht den Gesamtlauf
|
||||
- Event Log Ausfälle führen nicht zum Abbruch
|
||||
- Statusdatei wird atomar aktualisiert
|
||||
- Log-Bereinigung blockiert den Lauf nicht
|
||||
- Mailversand markiert Benachrichtigungen nur bei echtem Erfolg
|
||||
|
||||
## 12. Empfohlene nächste Ausbaustufen
|
||||
|
||||
Optional könnte das Projekt später erweitert werden um:
|
||||
|
||||
- CSV- oder HTML-Report pro Lauf
|
||||
- pro Target eigene Empfängergruppen
|
||||
- zusätzliche Protokolle wie FTP oder LDAP-Portchecks
|
||||
- Performance Counter oder Windows Service statt Task Scheduler
|
||||
- Gitea CI-Workflow für Windows Runner
|
||||
# Dokumentation
|
||||
|
||||
## Überblick
|
||||
|
||||
Dieses Repository ist für den Betrieb in einer **Gitea-Repo-Struktur** vorbereitet und enthält zwei Anwendungen:
|
||||
|
||||
### 1. HostAvailabilityMonitor
|
||||
|
||||
Der Monitor prüft technische Erreichbarkeit und schreibt:
|
||||
|
||||
- Rolling-Dateilog
|
||||
- Windows Application Event Log
|
||||
- E-Mail-Benachrichtigungen bei Ausfall, Recovery und täglichem Status
|
||||
- Statusdatei für Zustandswechsel, Cooldown-Logik und die tägliche Summary-Mail
|
||||
|
||||
### 2. BizTalkMonitorConfigGenerator
|
||||
|
||||
Der Generator liest BizTalk-Artefakte aus und erzeugt daraus eine Monitor-Konfiguration.
|
||||
|
||||
Ziel ist, dass die Ziel-Liste nicht manuell gepflegt werden muss, sondern direkt aus BizTalk stammt.
|
||||
|
||||
---
|
||||
|
||||
## Repository-Struktur für Gitea
|
||||
|
||||
```text
|
||||
.
|
||||
├── .editorconfig
|
||||
├── .gitignore
|
||||
├── Documentation.en.md
|
||||
├── Dokumentation.md
|
||||
├── HostAvailabilityMonitor.sln
|
||||
├── README.md
|
||||
├── installers/
|
||||
│ ├── README.md
|
||||
│ ├── powershell/
|
||||
│ │ ├── Install-BizTalkMonitorConfigGenerator.ps1
|
||||
│ │ ├── Install-Both.ps1
|
||||
│ │ ├── Install-HostAvailabilityMonitor.ps1
|
||||
│ │ ├── Uninstall-BizTalkMonitorConfigGenerator.ps1
|
||||
│ │ └── Uninstall-HostAvailabilityMonitor.ps1
|
||||
│ └── wix/
|
||||
│ ├── BizTalkMonitorConfigGenerator.wxs
|
||||
│ ├── HostAvailabilityMonitor.wxs
|
||||
│ └── build-msi.ps1
|
||||
├── scripts/
|
||||
│ ├── build-release.ps1
|
||||
│ ├── generate-monitor-config.ps1
|
||||
│ ├── install-generator-on-server.ps1
|
||||
│ ├── install-on-server.ps1
|
||||
│ ├── package-deployment.ps1
|
||||
│ └── register-event-source.ps1
|
||||
└── src/
|
||||
├── BizTalkMonitorConfigGenerator/
|
||||
│ ├── App.config
|
||||
│ ├── BizTalkMonitorConfigGenerator.csproj
|
||||
│ ├── Program.cs
|
||||
│ └── generator-settings.json
|
||||
└── HostAvailabilityMonitor/
|
||||
├── App.config
|
||||
├── HostAvailabilityMonitor.csproj
|
||||
├── Program.cs
|
||||
└── appsettings.json
|
||||
```
|
||||
|
||||
Diese Struktur ist für ein normales Gitea-Repository ausgelegt. Build und Deployment können aus der Solution oder projektweise erfolgen.
|
||||
|
||||
---
|
||||
|
||||
## Unterstützte BizTalk-Quellen
|
||||
|
||||
### Send Ports
|
||||
|
||||
Es werden standardmäßig nur **gestartete Send Ports** übernommen.
|
||||
|
||||
Zusätzlich kann optional auch der **Secondary Transport** eines Send Ports berücksichtigt werden. Secondary Transports mit dem Adapter **SMTP** werden jedoch bewusst nicht als Monitor-Target übernommen, weil deren Address-Wert in BizTalk typischerweise nur eine Empfängerliste und keine prüfbare Netzwerkadresse darstellt.
|
||||
|
||||
### Receive Locations
|
||||
|
||||
Es werden standardmäßig nur **aktivierte Receive Locations** übernommen.
|
||||
|
||||
---
|
||||
|
||||
## Endpunkt-Normalisierung
|
||||
|
||||
Der Generator versucht, BizTalk-Adressen in Monitor-kompatible Endpunkte zu überführen.
|
||||
|
||||
### Direkt unterstützt
|
||||
|
||||
- `\\server\share`
|
||||
- `file://...`
|
||||
- `http://...`
|
||||
- `https://...`
|
||||
- `ftp://...`
|
||||
- `sftp://...`
|
||||
- `tcp://...`
|
||||
- `icmp://...`
|
||||
- Plain Host / Host:Port (best effort)
|
||||
|
||||
### Spezielle Behandlung
|
||||
|
||||
- `net.tcp://host:port/...` wird auf `tcp://host:port/...` umgeschrieben
|
||||
- lokale Dateipfade wie `C:\Drop\In` werden nur übernommen, wenn `IncludeLocalFilePaths=true`
|
||||
- `net.pipe://...` wird übersprungen, weil der Monitor diesen Typ nicht prüft
|
||||
|
||||
---
|
||||
|
||||
## HostAvailabilityMonitor: Mail- und Statusverhalten
|
||||
|
||||
Der Monitor kann drei Arten von Mail-Benachrichtigungen versenden:
|
||||
|
||||
1. **Failure-Mail**: wenn ein Endpoint von erreichbar auf nicht erreichbar wechselt
|
||||
2. **Recovery-Mail**: wenn ein Endpoint von nicht erreichbar auf wieder erreichbar wechselt
|
||||
3. **Tagesstatus-Mail**: einmal pro Tag ab einer konfigurierten lokalen Uhrzeit, standardmäßig **14:00 Uhr**
|
||||
|
||||
Die Tagesstatus-Mail wird absichtlich **nicht** über einen zweiten Task oder separaten Scheduler innerhalb der Anwendung realisiert.
|
||||
|
||||
Stattdessen gilt:
|
||||
|
||||
- der normale geplante Task startet die Anwendung wie bisher
|
||||
- die Anwendung prüft bei jedem Lauf, ob die konfigurierte Uhrzeit bereits erreicht ist
|
||||
- die **erste Ausführung ab dieser Uhrzeit** verschickt die Tagesstatus-Mail
|
||||
- pro Kalendertag wird **maximal eine** Tagesstatus-Mail gesendet
|
||||
- nur ein **erfolgreich versendeter** Tagesstatus wird im State gespeichert
|
||||
|
||||
Das ist robust für den Betrieb auf BizTalk-Servern, weil keine zusätzliche Orchestrierung erforderlich ist.
|
||||
|
||||
---
|
||||
|
||||
## Konfiguration des Monitors im Detail
|
||||
|
||||
Datei: `src\HostAvailabilityMonitor\appsettings.json`
|
||||
|
||||
### Root-Felder
|
||||
|
||||
- `ApplicationName`: Name des Monitors
|
||||
- `EnvironmentName`: Umgebungsname wie `HIP Produktion`
|
||||
- `Runtime`: Laufzeitverhalten
|
||||
- `Logging`: Dateilog-Konfiguration
|
||||
- `EventLog`: Windows Event Log Konfiguration
|
||||
- `Email`: SMTP- und Benachrichtigungskonfiguration
|
||||
- `Targets`: die zu prüfenden Endpunkte
|
||||
|
||||
### Email
|
||||
|
||||
Wichtige Felder im Abschnitt `Email`:
|
||||
|
||||
- `Enabled`: Mailversand insgesamt ein/aus
|
||||
- `SmtpHost`, `SmtpPort`, `UseSsl`, `UseDefaultCredentials`, `Username`, `Password`
|
||||
- `From`, `To`, `Cc`, `Bcc`, `SubjectPrefix`
|
||||
- `SendOnFailure`: Mail bei Ausfall senden
|
||||
- `SendOnRecovery`: Mail bei Recovery senden
|
||||
- `SendDailySummary`: tägliche Status-Mail senden
|
||||
- `DailySummaryHourLocal`: lokale Stunde des Servers, z. B. `14`
|
||||
- `DailySummaryMinuteLocal`: lokale Minute des Servers, z. B. `0`
|
||||
- `OnlyOnStateChange`: bei Failure-/Recovery-Mails nur auf Zustandswechsel reagieren
|
||||
- `CooldownMinutes`: Cooldown für wiederholte Failure-Mails, wenn `OnlyOnStateChange=false`
|
||||
- `TimeoutSeconds`: SMTP-Timeout
|
||||
|
||||
Hinweise zu Empfaengern:
|
||||
|
||||
- `To`, `Cc` und `Bcc` sind jeweils JSON-Arrays von Mailadressen.
|
||||
- Mehrere Empfaenger werden ueber mehrere Array-Eintraege konfiguriert.
|
||||
- Eine einzelne Zeichenkette mit Semikolon-Liste ist nicht vorgesehen.
|
||||
- Mindestens ein Empfaenger in `To`, `Cc` oder `Bcc` muss vorhanden sein, wenn `Email.Enabled=true`.
|
||||
|
||||
### Beispiel für den Email-Block
|
||||
|
||||
```json
|
||||
"Email": {
|
||||
"Enabled": true,
|
||||
"SmtpHost": "smtp.example.local",
|
||||
"SmtpPort": 25,
|
||||
"UseSsl": false,
|
||||
"UseDefaultCredentials": false,
|
||||
"Username": "",
|
||||
"Password": "",
|
||||
"From": "monitor@example.local",
|
||||
"To": [
|
||||
"operations@example.local",
|
||||
"integration-oncall@example.local"
|
||||
],
|
||||
"Cc": [
|
||||
"integration-leads@example.local"
|
||||
],
|
||||
"Bcc": [],
|
||||
"SubjectPrefix": "[HostAvailabilityMonitor]",
|
||||
"SendOnFailure": true,
|
||||
"SendOnRecovery": true,
|
||||
"SendDailySummary": true,
|
||||
"DailySummaryHourLocal": 14,
|
||||
"DailySummaryMinuteLocal": 0,
|
||||
"OnlyOnStateChange": true,
|
||||
"CooldownMinutes": 0,
|
||||
"TimeoutSeconds": 30
|
||||
}
|
||||
```
|
||||
|
||||
### Beispiel fuer mehrere Empfaenger
|
||||
|
||||
```json
|
||||
"Email": {
|
||||
"Enabled": true,
|
||||
"From": "monitor@example.local",
|
||||
"To": [
|
||||
"operations@example.local",
|
||||
"integration-oncall@example.local"
|
||||
],
|
||||
"Cc": [
|
||||
"integration-leads@example.local"
|
||||
],
|
||||
"Bcc": [
|
||||
"audit@example.local"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Inhalt der Tagesstatus-Mail
|
||||
|
||||
Die Tagesstatus-Mail enthält:
|
||||
|
||||
- Monitorname
|
||||
- Umgebung
|
||||
- Servername
|
||||
- Zeitfenster von Mitternacht bis Versandzeitpunkt
|
||||
- Anzahl heutiger erfolgreicher und fehlgeschlagener Checks laut Tageslog
|
||||
- aktueller Snapshot des letzten Monitor-Laufs
|
||||
- Liste aktuell DOWN befindlicher Endpunkte inklusive:
|
||||
- Anwendung
|
||||
- Name
|
||||
- Endpoint
|
||||
- Typ
|
||||
- Status
|
||||
- Detail
|
||||
- Host/Port/HTTP-Status, soweit vorhanden
|
||||
|
||||
Hinweis:
|
||||
|
||||
Die Tageszähler werden aus dem **heutigen Rolling-Log** ausgewertet. Sollte diese Auswertung ausnahmsweise fehlschlagen, bleibt die Mail-Funktion funktionsfähig; die Tageszähler werden dann defensiv mit `0` angegeben und der Vorfall wird geloggt.
|
||||
|
||||
---
|
||||
|
||||
## Generator-Konfiguration im Detail
|
||||
|
||||
Datei: `generator-settings.json`
|
||||
|
||||
### Root-Felder
|
||||
|
||||
- `GeneratorName`: Anzeigename für Logs/Eventlog des Generators
|
||||
- `EnvironmentName`: Umgebung wie `HIP Produktion`
|
||||
- `Logging`: Logging des Generators
|
||||
- `EventLog`: Eventlog des Generators
|
||||
- `BizTalk`: Discovery-Regeln
|
||||
- `Output`: Zielpfad und Erzeugungsregeln
|
||||
- `GeneratedMonitorConfig`: Vorlage für die endgültige Monitor-JSON
|
||||
|
||||
### BizTalk
|
||||
|
||||
- `ConnectionString`: Verbindung zur BizTalkMgmtDb
|
||||
- `IncludeSendPorts`: Send Ports auslesen
|
||||
- `IncludeReceiveLocations`: Receive Locations auslesen
|
||||
- `OnlyStartedSendPorts`: nur aktive Send Ports
|
||||
- `OnlyEnabledReceiveLocations`: nur aktive Receive Locations
|
||||
- `IncludeSecondaryTransportOnSendPorts`: sekundäre Send-Port-Transporte zusätzlich aufnehmen
|
||||
- SMTP-Sendports bzw. SMTP-Secondary-Transports werden vom Generator automatisch übersprungen
|
||||
- `IncludeDynamicSendPorts`: dynamische Send Ports aufnehmen
|
||||
- `IncludeLocalFilePaths`: lokale Pfade aufnehmen
|
||||
- `IgnoreSystemApplications`: Systemanwendungen ignorieren
|
||||
- `IgnoreApplications`: Anwendungen per Pattern ausblenden
|
||||
- `IgnoreArtifactNamePatterns`: Ports/Locations per Pattern ignorieren
|
||||
- `ApplicationMappings`: Mapping BizTalk-App -> fachliche App
|
||||
- `ArtifactMappings`: Mapping einzelner Artefakte -> fachliche App
|
||||
|
||||
### Output
|
||||
|
||||
- `Path`: Pfad der erzeugten Monitor-JSON
|
||||
- `OverwriteExisting`: bestehende Datei überschreiben
|
||||
- `FailIfNoTargetsFound`: ExitCode 2, wenn keine Targets gefunden wurden
|
||||
- `TargetTimeoutSeconds`: Standard-Timeout pro generiertem Target
|
||||
- `TargetEnabled`: `Enabled`-Default in jedem Target
|
||||
- `DefaultHttpMethod`: Standard für generierte HTTP/HTTPS-Ziele
|
||||
|
||||
### GeneratedMonitorConfig
|
||||
|
||||
Dies ist die Vorlage für den späteren Monitor.
|
||||
|
||||
Hier werden gepflegt:
|
||||
|
||||
- `ApplicationName` des Monitors
|
||||
- `EnvironmentName`
|
||||
- `Runtime`
|
||||
- `Logging`
|
||||
- `EventLog`
|
||||
- `Email`
|
||||
|
||||
`Targets` wird vom Generator zur Laufzeit neu erzeugt.
|
||||
|
||||
Wichtig:
|
||||
|
||||
Wenn der Generator die Monitor-JSON erzeugt, werden auch die Felder für die Tagesstatus-Mail mit erzeugt. Das heißt: `GeneratedMonitorConfig.Email.SendDailySummary`, `DailySummaryHourLocal` und `DailySummaryMinuteLocal` werden direkt in die Zielkonfiguration übernommen.
|
||||
|
||||
---
|
||||
|
||||
## Generator verwenden
|
||||
|
||||
### Variante A: direkt per EXE
|
||||
|
||||
```powershell
|
||||
C:\Tools\BizTalkMonitorConfigGenerator\BizTalkMonitorConfigGenerator.exe C:\Tools\BizTalkMonitorConfigGenerator\generator-settings.json
|
||||
```
|
||||
|
||||
### Variante B: per Wrapper-Skript
|
||||
|
||||
```powershell
|
||||
.\scripts\generate-monitor-config.ps1 -InstallPath C:\Tools\BizTalkMonitorConfigGenerator
|
||||
```
|
||||
|
||||
### Erwartetes Ergebnis
|
||||
|
||||
Nach dem Lauf sollte vorhanden sein:
|
||||
|
||||
- generierte Datei, z. B. `C:\Tools\BizTalkMonitorConfigGenerator\generated-monitor-appsettings.json`
|
||||
- Logdatei des Generators unter `logs\`
|
||||
- Eventlog-Einträge im `Application`-Log
|
||||
|
||||
### Monitor danach starten
|
||||
|
||||
```powershell
|
||||
C:\Tools\HostAvailabilityMonitor\HostAvailabilityMonitor.exe C:\Tools\BizTalkMonitorConfigGenerator\generated-monitor-appsettings.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Beispielablauf auf einem BizTalk-Server
|
||||
|
||||
### 1. Generator installieren
|
||||
|
||||
```powershell
|
||||
.\scripts\install-generator-on-server.ps1 `
|
||||
-SourcePath .\artifacts\publish\net472\BizTalkMonitorConfigGenerator `
|
||||
-InstallPath C:\Tools\BizTalkMonitorConfigGenerator `
|
||||
-RegisterEventSource
|
||||
```
|
||||
|
||||
### 2. Generator-Konfiguration anpassen
|
||||
|
||||
Datei bearbeiten:
|
||||
|
||||
```text
|
||||
C:\Tools\BizTalkMonitorConfigGenerator\generator-settings.json
|
||||
```
|
||||
|
||||
Typische Werte:
|
||||
|
||||
- `EnvironmentName = "HIP Produktion"`
|
||||
- `Output.Path = "C:\\Tools\\BizTalkMonitorConfigGenerator\\generated-monitor-appsettings.json"`
|
||||
- `BizTalk.ConnectionString = "SERVER=.;DATABASE=BizTalkMgmtDb;Integrated Security=SSPI"`
|
||||
- `GeneratedMonitorConfig.Email.SendDailySummary = true`
|
||||
- `GeneratedMonitorConfig.Email.DailySummaryHourLocal = 14`
|
||||
- `GeneratedMonitorConfig.Email.DailySummaryMinuteLocal = 0`
|
||||
|
||||
### 3. Generator ausführen
|
||||
|
||||
```powershell
|
||||
C:\Tools\BizTalkMonitorConfigGenerator\BizTalkMonitorConfigGenerator.exe C:\Tools\BizTalkMonitorConfigGenerator\generator-settings.json
|
||||
```
|
||||
|
||||
### 4. Generierte JSON prüfen
|
||||
|
||||
Prüfen, ob die Datei erzeugt wurde und `Targets` enthält.
|
||||
|
||||
Zusätzlich prüfen:
|
||||
|
||||
- ob `GeneratedMonitorConfig.Email.SendDailySummary` in der erzeugten JSON übernommen wurde
|
||||
- ob die Uhrzeitfelder korrekt gesetzt sind
|
||||
|
||||
### 5. Monitor installieren
|
||||
|
||||
```powershell
|
||||
.\scripts\install-on-server.ps1 `
|
||||
-SourcePath .\artifacts\publish\net472\HostAvailabilityMonitor `
|
||||
-InstallPath C:\Tools\HostAvailabilityMonitor `
|
||||
-RegisterEventSource
|
||||
```
|
||||
|
||||
### 6. Monitor mit der generierten JSON starten
|
||||
|
||||
```powershell
|
||||
C:\Tools\HostAvailabilityMonitor\HostAvailabilityMonitor.exe C:\Tools\BizTalkMonitorConfigGenerator\generated-monitor-appsettings.json
|
||||
```
|
||||
|
||||
### 7. Task Scheduler konfigurieren
|
||||
|
||||
Empfehlung:
|
||||
|
||||
- Generator z. B. alle 30 Minuten
|
||||
- Monitor z. B. 1 bis 2 Minuten später ebenfalls alle 30 Minuten
|
||||
- wichtig ist mindestens ein Monitor-Lauf **nach 14:00 Uhr lokal**, damit die Tagesstatus-Mail gesendet werden kann
|
||||
|
||||
---
|
||||
|
||||
## Erzeugte Target-Namen
|
||||
|
||||
Damit im Log und in der Mail eindeutig erkennbar ist, woher ein Ziel stammt, werden sprechende Namen erzeugt, z. B.:
|
||||
|
||||
- `SendPort: SAP_Outbound (Primary) [WCF-SQL]`
|
||||
- `SendPort: PartnerA_SFTP (Secondary) [SFTP]`
|
||||
- `ReceiveLocation: InboundOrders / RL_FileDrop [FILE]`
|
||||
|
||||
Das fachliche `ApplicationName` des Targets kommt aus:
|
||||
|
||||
1. `ArtifactMappings`
|
||||
2. `ApplicationMappings`
|
||||
3. BizTalk-Anwendungsname (Fallback)
|
||||
|
||||
---
|
||||
|
||||
## Logging und Resilienz des Generators
|
||||
|
||||
Der Generator ist defensiv gebaut:
|
||||
|
||||
- tägliche Logrotation
|
||||
- Retry beim Schreiben ins Logfile
|
||||
- Eventlog nur best effort
|
||||
- atomisches Schreiben der Ausgabedatei (`.tmp` + Rename)
|
||||
- bestehende Zieldatei wird vor Überschreiben als `.bak` gesichert
|
||||
- nicht unterstützte Endpunkte werden protokolliert und übersprungen
|
||||
- Discovery läuft möglichst weiter, auch wenn einzelne Artefakte unbrauchbar sind
|
||||
|
||||
---
|
||||
|
||||
## Logging und Resilienz des Monitors
|
||||
|
||||
Der Monitor ist ebenfalls defensiv gebaut:
|
||||
|
||||
- Rolling-Dateilog mit täglicher Rotation
|
||||
- Retention standardmäßig 5 Tage
|
||||
- Eventlog-Schreiben nur best effort
|
||||
- Statusdatei mit atomischem Schreiben
|
||||
- Failure-/Recovery-Mails nur bei definierten Bedingungen
|
||||
- Tagesstatus nur einmal pro Tag
|
||||
- Tagesstatus wird nur nach erfolgreichem SMTP-Versand als versendet markiert
|
||||
- Ziele, die wie SMTP-/E-Mail-Empfängerlisten aussehen, werden vom Monitor defensiv als `Skipped` protokolliert und nicht als DOWN alarmiert
|
||||
- Fehler bei der Tageslog-Auswertung oder beim SMTP-Versand stoppen den Monitorlauf nicht hart
|
||||
|
||||
---
|
||||
|
||||
## Server-Installation kompakt
|
||||
|
||||
### Deployment-Paket erzeugen
|
||||
|
||||
```powershell
|
||||
.\scripts\build-release.ps1 -CreateDeploymentPackage
|
||||
```
|
||||
|
||||
oder getrennt:
|
||||
|
||||
```powershell
|
||||
.\scripts\package-deployment.ps1
|
||||
```
|
||||
|
||||
Das Ergebnis liegt dann unter `artifacts\deploy\net472\` als ZIP.
|
||||
|
||||
### PowerShell-Installer (empfohlen)
|
||||
|
||||
Komplette Installation beider Programme aus dem Deployment-ZIP:
|
||||
|
||||
```powershell
|
||||
.\installers\powershell\Install-Both.ps1 `
|
||||
-PackageRoot . `
|
||||
-BaseInstallPath "C:\Program Files\JR IT Services\BizTalk Endpoint Monitor" `
|
||||
-BaseConfigPath "C:\ProgramData\JR IT Services\BizTalk Endpoint Monitor" `
|
||||
-RegisterEventSources
|
||||
```
|
||||
|
||||
Nur Monitor:
|
||||
|
||||
```powershell
|
||||
.\installers\powershell\Install-HostAvailabilityMonitor.ps1 `
|
||||
-PackageRoot .
|
||||
```
|
||||
|
||||
Nur Generator:
|
||||
|
||||
```powershell
|
||||
.\installers\powershell\Install-BizTalkMonitorConfigGenerator.ps1 `
|
||||
-PackageRoot .
|
||||
```
|
||||
|
||||
### WiX-MSI-Quellen (optional)
|
||||
|
||||
Fuer beide Programme liegen WiX-Quellen bereit. Auf einem Windows-Buildserver mit WiX Toolset v3 kannst du daraus MSI-Dateien erzeugen:
|
||||
|
||||
```powershell
|
||||
.\installers\wix\build-msi.ps1 `
|
||||
-PublishRoot .\artifacts\publish\net472 `
|
||||
-OutputRoot .\artifacts\msi
|
||||
```
|
||||
|
||||
### Einzelinstallation ueber die bisherigen Skripte
|
||||
|
||||
#### Monitor
|
||||
|
||||
```powershell
|
||||
.\scripts\install-on-server.ps1 `
|
||||
-SourcePath .\artifacts\publish\net472\HostAvailabilityMonitor `
|
||||
-InstallPath C:\Tools\HostAvailabilityMonitor `
|
||||
-RegisterEventSource
|
||||
```
|
||||
|
||||
#### Generator
|
||||
|
||||
```powershell
|
||||
.\scripts\install-generator-on-server.ps1 `
|
||||
-SourcePath .\artifacts\publish\net472\BizTalkMonitorConfigGenerator `
|
||||
-InstallPath C:\Tools\BizTalkMonitorConfigGenerator `
|
||||
-RegisterEventSource
|
||||
```
|
||||
|
||||
Danach typischerweise:
|
||||
|
||||
1. `generator-settings.json` anpassen
|
||||
2. Generator ausführen
|
||||
3. generierte Monitor-JSON prüfen
|
||||
4. Monitor mit dieser JSON starten
|
||||
5. Task Scheduler einrichten
|
||||
|
||||
---
|
||||
|
||||
## Hinweis zum Build
|
||||
|
||||
In dieser Arbeitsumgebung konnte kein echter Windows-Build gegen .NET Framework 4.7.2 und BizTalk ExplorerOM ausgefuehrt werden. Ebenso konnte hier kein echtes WiX-MSI gebaut werden, weil keine Windows-/WiX-Toolchain verfuegbar war. Der Code und die Repo-Struktur sind angepasst, der erste echte Build und Test muss auf einem Windows-/BizTalk-System erfolgen.
|
||||
|
||||
Reference in New Issue
Block a user