10
Exchange 2016: Journal Account erzeugt massig Logs
Hallo zusammen,
wir setzen hier einen Exchange 2016 mit 3 Datenbanken (insg. ca. 1,5TB) und 450 Postfächern ein.
Auf den Datenbanken ist das Journaling aktiv.
Das Journalpostfach wird alle 30min von einer E-Mail-Archivierungssoftware geleert.
Hier werden im Schnitt 150-200 Mails pro 30min neu archiviert -> Gehen wir mal großzügig von 100MB in 30min an reinen E-Mails aus.
Jetzt ist es leider so, dass die Transaktionslogs auf der Datenbank mit dem Journalpostfach seit ca. einer Woche "Amok" laufen.
Bedeutet: Zwischen den täglichen Backups werden ca. 30.000 .log Dateien erzeugt was halt 30GB entspricht.
Die anderen Datenbanken erzeugen ca. 1/10 an Logdateien.
Sucht man im Netz, findet man bzgl. der Transaktionslogs meist Informationen bzgl. ActiveSync.
Wir haben dieses Skript verwendet: https://www.alitajran.com/exchange-transaction-logs-growing-rapidly/
Die Auswertung ist unserer Meinung nach unauffällig, über alle Datenbanken verteilt gibt es keine Ausreißer bei der ActiveSync Nutzung.
Irgendwann ist uns dann das Journalpostfach aufgefallen.
Die Hohe Generierung an Transaktionslogs wanderte mit als wir das Postfach zu Testzwecken auf eine andere DB verschoben haben.
Die Archivierungslösung ist auch nicht verantwortlich - eine vorübergehendes Pausieren des Jobs hat nichts geändert.
Kann mir jemand erklären, was alles im Journalpostfach geloggt wird und wie wir den Verursacher finden können?
Vielen Dank im Voraus!
wir setzen hier einen Exchange 2016 mit 3 Datenbanken (insg. ca. 1,5TB) und 450 Postfächern ein.
Auf den Datenbanken ist das Journaling aktiv.
Das Journalpostfach wird alle 30min von einer E-Mail-Archivierungssoftware geleert.
Hier werden im Schnitt 150-200 Mails pro 30min neu archiviert -> Gehen wir mal großzügig von 100MB in 30min an reinen E-Mails aus.
Jetzt ist es leider so, dass die Transaktionslogs auf der Datenbank mit dem Journalpostfach seit ca. einer Woche "Amok" laufen.
Bedeutet: Zwischen den täglichen Backups werden ca. 30.000 .log Dateien erzeugt was halt 30GB entspricht.
Die anderen Datenbanken erzeugen ca. 1/10 an Logdateien.
Sucht man im Netz, findet man bzgl. der Transaktionslogs meist Informationen bzgl. ActiveSync.
Wir haben dieses Skript verwendet: https://www.alitajran.com/exchange-transaction-logs-growing-rapidly/
Die Auswertung ist unserer Meinung nach unauffällig, über alle Datenbanken verteilt gibt es keine Ausreißer bei der ActiveSync Nutzung.
Irgendwann ist uns dann das Journalpostfach aufgefallen.
Die Hohe Generierung an Transaktionslogs wanderte mit als wir das Postfach zu Testzwecken auf eine andere DB verschoben haben.
Die Archivierungslösung ist auch nicht verantwortlich - eine vorübergehendes Pausieren des Jobs hat nichts geändert.
Kann mir jemand erklären, was alles im Journalpostfach geloggt wird und wie wir den Verursacher finden können?
Vielen Dank im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6452661345
Url: https://administrator.de/contentid/6452661345
Ausgedruckt am: 21.11.2024 um 13:11 Uhr
10 Kommentare
Neuester Kommentar
Moin...
was hast du den für eine Datensicherung?!? die logs sinder aber nach dem Backup gelöscht?
Umlaufprotokollierung an?
erstelle mal eine neue DB und schiebe dort alles rein!
Frank
was hast du den für eine Datensicherung?!? die logs sinder aber nach dem Backup gelöscht?
Umlaufprotokollierung an?
erstelle mal eine neue DB und schiebe dort alles rein!
Frank
Hallo Frank,
Danke für Deine Antwort.
Wir sichern mit Veeam und ja, die Logs sind danach gelöscht.
Es ist halt so, dass permanent (mehrere pro Minute) neue Dateien erzeugt werden.
Also neue DB und dann nur das Journalpostfach hinein?
Danke für Deine Antwort.
Wir sichern mit Veeam und ja, die Logs sind danach gelöscht.
Es ist halt so, dass permanent (mehrere pro Minute) neue Dateien erzeugt werden.
Also neue DB und dann nur das Journalpostfach hinein?
Moin,
was ist mit der Umlaufprotokollierung?
hast du mal in die SMTP logs geschaut was da so geschrieben wird...
was sagt das Ereignisprotokoll?
Frank
Zitat von @Knorkator:
Hallo Frank,
Danke für Deine Antwort.
Wir sichern mit Veeam und ja, die Logs sind danach gelöscht.
Es ist halt so, dass permanent (mehrere pro Minute) neue Dateien erzeugt werden.
Also neue DB und dann nur das Journalpostfach hinein?
nein, alle postfächer und mnatürlich das Jurnalpstfach!Hallo Frank,
Danke für Deine Antwort.
Wir sichern mit Veeam und ja, die Logs sind danach gelöscht.
Es ist halt so, dass permanent (mehrere pro Minute) neue Dateien erzeugt werden.
Also neue DB und dann nur das Journalpostfach hinein?
was ist mit der Umlaufprotokollierung?
hast du mal in die SMTP logs geschaut was da so geschrieben wird...
was sagt das Ereignisprotokoll?
Frank
Hallo Frank,
Eine neue DB mit 1.5TB Platz zu erstellen und alle Postfächer dahin zu verschieben, Ok.
Kannst Du mir sagen, was Du Dir davon versprichst?
Nicht falsch verstehen.. aber das ist ja nicht mal eben gemacht.
Die Umlaufprotokollierung ist nicht aktiv.
Nach erfolgreichem Backup werden die Logdateien gelöscht.
Die massive Erzeugung der Logdateien fängt dann allerdings sofort wieder an (wie erwähnt.. es sind so ca. 30k an Dateien pro Tag die mit dem Journalpostfach mitwandern).
Bzgl. SMTP-Log.
Im SMTP-Log Hier sehen wir keine Auffälligkeiten.
Wir haben vor dem Exchange einen Postfix und einen sehr restriktiven Spamfilter.
https://www.reddoxx.com/die-reddoxx-ciss-technologie/
Spam-Mails kommen bei uns erst am Exchange an, wenn der User diese am Spamfilter freigibt.
Bzgl. Eventlog:
Wir können hier keine Auffälligkeiten erkennen.
Hast Du ein bestimmtes Log was ich auf Auffälligkeiten untersuchen soll?
Monitoring:
Wir nutzen folgendes Zabbix Template zur Überwachung des Servers.
https://www.zabbix.com/de/integrations/ms_exchange
Die genutzen Performancecounter sind im Link gut beschrieben.
Hier kann ich noch Performancewerte zur Analyse liefern, wenn diese hilfreich sein sollten.
Vielen Dank!
Eine neue DB mit 1.5TB Platz zu erstellen und alle Postfächer dahin zu verschieben, Ok.
Kannst Du mir sagen, was Du Dir davon versprichst?
Nicht falsch verstehen.. aber das ist ja nicht mal eben gemacht.
Die Umlaufprotokollierung ist nicht aktiv.
Nach erfolgreichem Backup werden die Logdateien gelöscht.
Die massive Erzeugung der Logdateien fängt dann allerdings sofort wieder an (wie erwähnt.. es sind so ca. 30k an Dateien pro Tag die mit dem Journalpostfach mitwandern).
Bzgl. SMTP-Log.
Im SMTP-Log Hier sehen wir keine Auffälligkeiten.
Wir haben vor dem Exchange einen Postfix und einen sehr restriktiven Spamfilter.
https://www.reddoxx.com/die-reddoxx-ciss-technologie/
Spam-Mails kommen bei uns erst am Exchange an, wenn der User diese am Spamfilter freigibt.
Bzgl. Eventlog:
Wir können hier keine Auffälligkeiten erkennen.
Hast Du ein bestimmtes Log was ich auf Auffälligkeiten untersuchen soll?
Monitoring:
Wir nutzen folgendes Zabbix Template zur Überwachung des Servers.
https://www.zabbix.com/de/integrations/ms_exchange
Die genutzen Performancecounter sind im Link gut beschrieben.
Hier kann ich noch Performancewerte zur Analyse liefern, wenn diese hilfreich sein sollten.
Vielen Dank!
Moin...
ok, bei 1,5TB wäre die frage des platzes noch nötig
du hast ja "Auf den Datenbanken" geschrieben, ich gehe davon aus, das die 1,5 TB in 3 DBs liegen!
die DB mit dem Journal würde ich mal in eine neue DB verschieben!
oder gleich zum Test, das Journal in die neue DB.
das verschieben kannst du so machen:
Prüfen:
und Abschluss:
Die Umlaufprotokollierung ist nicht aktiv.
ich bin zu 95% ein Freund der Umlaufprotokollierung, allerdings ist dann einiges zu beachten (inkrementelles Backup)
Frank
Zitat von @Knorkator:
Hallo Frank,
Eine neue DB mit 1.5TB Platz zu erstellen und alle Postfächer dahin zu verschieben, Ok.
Kannst Du mir sagen, was Du Dir davon versprichst?
Nicht falsch verstehen.. aber das ist ja nicht mal eben gemacht.
öh... doch, je nach Leistung deines Blech / VM bekommt das kaum einer mit, alternativ lass das am Wochenende laufen!Hallo Frank,
Eine neue DB mit 1.5TB Platz zu erstellen und alle Postfächer dahin zu verschieben, Ok.
Kannst Du mir sagen, was Du Dir davon versprichst?
Nicht falsch verstehen.. aber das ist ja nicht mal eben gemacht.
ok, bei 1,5TB wäre die frage des platzes noch nötig
du hast ja "Auf den Datenbanken" geschrieben, ich gehe davon aus, das die 1,5 TB in 3 DBs liegen!
die DB mit dem Journal würde ich mal in eine neue DB verschieben!
oder gleich zum Test, das Journal in die neue DB.
das verschieben kannst du so machen:
Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | New-MoveRequest -TargetDatabase DB2016Neu -Priority emergency Get-MoveRequest | Get-MoveRequestStatistics | ft displayname,status,BytesTransferred -autosizeGet-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest Kannst Du mir sagen, was Du Dir davon versprichst?
ja... viele kleine Probleme konnen so plötzlich verschwunden sein!Die Umlaufprotokollierung ist nicht aktiv.
Nach erfolgreichem Backup werden die Logdateien gelöscht.
Die massive Erzeugung der Logdateien fängt dann allerdings sofort wieder an (wie erwähnt.. es sind so ca. 30k an Dateien pro Tag die mit dem Journalpostfach mitwandern).
Bzgl. SMTP-Log.
Im SMTP-Log Hier sehen wir keine Auffälligkeiten.
Wir haben vor dem Exchange einen Postfix und einen sehr restriktiven Spamfilter.
https://www.reddoxx.com/die-reddoxx-ciss-technologie/
Spam-Mails kommen bei uns erst am Exchange an, wenn der User diese am Spamfilter freigibt.
Bzgl. Eventlog:
Wir können hier keine Auffälligkeiten erkennen.
Hast Du ein bestimmtes Log was ich auf Auffälligkeiten untersuchen soll?
Monitoring:
Wir nutzen folgendes Zabbix Template zur Überwachung des Servers.
https://www.zabbix.com/de/integrations/ms_exchange
Die genutzen Performancecounter sind im Link gut beschrieben.
Hier kann ich noch Performancewerte zur Analyse liefern, wenn diese hilfreich sein sollten.
Vielen Dank!
Die massive Erzeugung der Logdateien fängt dann allerdings sofort wieder an (wie erwähnt.. es sind so ca. 30k an Dateien pro Tag die mit dem Journalpostfach mitwandern).
Bzgl. SMTP-Log.
Im SMTP-Log Hier sehen wir keine Auffälligkeiten.
Wir haben vor dem Exchange einen Postfix und einen sehr restriktiven Spamfilter.
https://www.reddoxx.com/die-reddoxx-ciss-technologie/
Spam-Mails kommen bei uns erst am Exchange an, wenn der User diese am Spamfilter freigibt.
Bzgl. Eventlog:
Wir können hier keine Auffälligkeiten erkennen.
Hast Du ein bestimmtes Log was ich auf Auffälligkeiten untersuchen soll?
Monitoring:
Wir nutzen folgendes Zabbix Template zur Überwachung des Servers.
https://www.zabbix.com/de/integrations/ms_exchange
Die genutzen Performancecounter sind im Link gut beschrieben.
Hier kann ich noch Performancewerte zur Analyse liefern, wenn diese hilfreich sein sollten.
Vielen Dank!
Frank
1
Hallo Frank,
sorry für die späte Rückmeldung.
Wir haben eine neue DB für das Journalpostfach erstellt, das Journaling auf der DB deaktiviert.
Die DB ist von der automatische Zuweisung neuer Postfächer ausgeschlossen.
Die DB bleibt dann vorerst exklusiv für das Journalpostfach reserviert.
Der Server hat sich direkt danach beruhigt und erstellt nun nicht mehr Logs ohne Ende..
Vielen Dank!
sorry für die späte Rückmeldung.
Wir haben eine neue DB für das Journalpostfach erstellt, das Journaling auf der DB deaktiviert.
Die DB ist von der automatische Zuweisung neuer Postfächer ausgeschlossen.
Die DB bleibt dann vorerst exklusiv für das Journalpostfach reserviert.
Der Server hat sich direkt danach beruhigt und erstellt nun nicht mehr Logs ohne Ende..
Vielen Dank!
Wir haben hier eine neue Auffälligkeit die mir Sorgen bereitet.
Seitdem das Journalpostfach in einer eigenen DB liegt, steigen die RPC-Requests per Second für diese Datenbank kontinuierlich an.
Auf dieser DB habe ich die Umlaufprotokollierung aktiviert.
Gleichzeitig steigt die CPU-Auslastung auf dem Server kontinuierlich an.
Die beiden verantwortlichen Prozesse bzgl. der CPU-Auslastung sind:
edgetransport.exe
msexchangedelivery.exe
Ein automatischer Reboot nach den üblichen Updates am Mittwoch hat hier auch nichts geändert - nur der Vollständigkeit halber.
Ich such mal weiter.. vielleicht hat ja noch jemand eine Idee dazu.
Seitdem das Journalpostfach in einer eigenen DB liegt, steigen die RPC-Requests per Second für diese Datenbank kontinuierlich an.
Auf dieser DB habe ich die Umlaufprotokollierung aktiviert.
Gleichzeitig steigt die CPU-Auslastung auf dem Server kontinuierlich an.
Die beiden verantwortlichen Prozesse bzgl. der CPU-Auslastung sind:
edgetransport.exe
msexchangedelivery.exe
Ein automatischer Reboot nach den üblichen Updates am Mittwoch hat hier auch nichts geändert - nur der Vollständigkeit halber.
Ich such mal weiter.. vielleicht hat ja noch jemand eine Idee dazu.
Moin...
was ist mit der auslastung von HDD und Nic?
sind die auch gestiegen?
Frank
was ist mit der auslastung von HDD und Nic?
sind die auch gestiegen?
Frank
Die HDD bzw. die von der maildb_3 ist bei knapp 260MB -> Hier ist meiner Meinung nach alles friedlich.
Das hier ist mir eben aufgefallen.. da wird wohl das Problem liegen.
Das hier ist mir eben aufgefallen.. da wird wohl das Problem liegen.
Argh.. ich sehe grad.. das Mailstore Journal hat hier auch keine Nachrichten protokolliert.
Wie es scheint, haben wir eine Journalmailbox auf Maildb_3 liegen welche keine Nachrichten zugestellt bekommt.
Maildb1,2,4 haben das MailstoreJournalpostfach als Ziel angegeben.. aber scheinbar kommt nix auf Maildb_3 an.
edit: Die Grenzwerte auf Maildb_3 waren, warum auch immer, alle bei 0 und nicht bei unlimited.
Aktuell läuft ein Retry-Queue.
Wie es scheint, haben wir eine Journalmailbox auf Maildb_3 liegen welche keine Nachrichten zugestellt bekommt.
Maildb1,2,4 haben das MailstoreJournalpostfach als Ziel angegeben.. aber scheinbar kommt nix auf Maildb_3 an.
edit: Die Grenzwerte auf Maildb_3 waren, warum auch immer, alle bei 0 und nicht bei unlimited.
Aktuell läuft ein Retry-Queue.
