Exchange Queue Monitoring
Ein früher Indikator für Probleme bei einem Mail-System sind die Warteschlangen, bzw. wie diese sich füllen, leeren und wie lange Mails darin verweilen. Exchange Selbst liefert dazu entsprechende Wert schon mit, die man nur auswerten muss. Diese Seite zeigt, was möglich und sinnvoll ist.
Get-Queue
Der erste und einfachste Weg sich über die Warteschlangen eines Exchange Systems zu informieren ist die Ausgabe von Get-Queue.
[PS] C:\>Get-Queue | ft Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain -------- ------------ ------ ------------ -------- --------- -------------- ------------- EX2016\3 SmtpDeliv... Ready 0 0 Normal 0 mailboxes EX2016\4 SmartHost... Ready 1 0 Normal 0 nospamproxy.msxfaq.net EX2016\Poison Undefined Ready 0 0 Normal 0 Poison Message EX2016\Submission Undefined Ready 0 0 Normal 0 Submission
Hier sehen Sie die vier Warteschlangen, die quasi auf jedem Exchange Server in der ein oder anderen Weise vorhanden sind. Es gibt Warteschlangen für die Zustellung in Mailboxen, die PoisonQueue, die idealerweise leer ist, die Submission-Queue für neue eingehende Mails hier eine Warteschlange für die Zustellung nach extern über einen Smarthost. Wenn Exchange direkt versendet, dann gibt es sicher noch viel mehr Queues und wer mehrere Exchange Server betreibt, wird auch Queues für die Kommunikation zwischen den Servern finden. In der Liste erscheint aber ein Wert namens "Velocity", den ich erst mal nachschlagen musste.
Auf der Seite Warteschlangen und Nachrichten in Warteschlangen https://technet.microsoft.com/de-de/library/bb125022(v=exchg.160).aspx#Warteschlangeneigenschaften findet sich dazu folgende Information:
So richtig bin ich davon nun nicht überzeugt, denn dazu muss ich nun wissen, wie die "IncomingRate" und "OutgoingRate" gebildet wird. Microsoft schreibt dazu auf der gleichen Seite
Die Rate, mit der Nachrichten bei der Warteschlange eingehen/ausgehen. Bei der Rate handelt es sich um die Anzahl von Nachrichten pro Sekunde als Durchschnitt der letzten Minute.
Das ist ja zumindest mal ein Hinweis und wenn ich mir das mit der Kasse am Supermarkt vergleiche, dann macht diese Kennzahl durchaus Sinn. Die Werte für "IncomginRate und "OutgoingRage" lassen sich auch entsprechend anzeigen:
[PS] C:\>Get-Queue | ft identity,deliverytype,status,velocity,*rate Identity DeliveryType Status Velocity IncomingRate OutgoingRate -------- ------------ ------ -------- ------------ ------------ EX2016\3 ...eliveryToMailbox Ready 0 0 0 EX2016\4 ...onnectorDelivery Active 0 0 0 EX2016\5 ...onnectorDelivery Active 0 0 0 EX2016\Poison Undefined Ready 0 0 0 EX2016\Submission Undefined Ready 0 0 0
Auf meiner Demo-VM ist natürlich nicht viel los. Dennoch ist ein Blick in die Details einer Queue interessant:
[PS] C:\>(Get-Queue)[0] | fl DeliveryType : SmtpDeliveryToMailbox NextHopDomain : mailboxes TlsDomain : NextHopConnector : GUID Status : Ready MessageCount : 0 LastError : RetryCount : 0 LastRetryTime : 22.12.2017 12:00:11 NextRetryTime : FirstRetryTime : DeferredMessageCount : 0 LockedMessageCount : 0 MessageCountsPerPriority : {0, 0, 0, 0} DeferredMessageCountsPerPriority : {0, 0, 0, 0} RiskLevel : Normal OutboundIPPool : 0 NextHopCategory : Internal IncomingRate : 0,03 OutgoingRate : 0,03 Velocity : 0 OverrideSource : QueueIdentity : EX2016\3 PriorityDescriptions : {High, Normal, Low, None} Identity : EX2016\3 IsValid : True ObjectState : New
Hier tauchen noch weitere Felder aus, die durchaus für eine Auswertung interessant sind. So liefert "MessageCountsPerPriority" sogar eine fertig Aufschlüsselung der Mail in der Queue nach Priorität.
Für eine Überwachung sind diese Werte aber durchaus interessant, z.B.: um folgendes zu ermitteln.
- Plötzliche Zunahme von Mails
Das könnte ja ein NDR-Sturm oder ein Spammer sein. - Plötzliche Zunahme von Mails in
Verbindung mit einer hohen Anzahl
Hier kommt der Server dann wohl nicht mit der Abarbeitung hinterher - Hohe Anzahl und niedrige Abflussrate
Das kann daran liegen, dass die Gegenseite nicht schnell genug die Mails annehmen kann.
Leider sind Queues "dynamisch", d.h. werden neu angelegt und wieder abgebaut, so dass man hier bei der Auswertung etwas mehr Grips aufwenden muss um speziell bei einem Versand per DNS statt Smarthost die vielen Queues nebeneinander zu überwachen. Sie wollen ja nicht pro Zieldomäne einen eigenen Counter aufmachen.
Perfmon für Alter der Mails
Leider sieht man aus den Queues keinen Counter, wie alt die älteste Mail in der Warteschlange ist. So ein Wert fände ich sehr interessant um frühzeitig auch zu erkennen, wenn eine Mail "länger liegen bleibt": Das ist fast immer unangenehm für einen Betreiber selbst wenn es nur eine einzige Mail betrifft. Interessanterweise gibt es aber solche Werte als Performance Counter:
Diese Counter sind natürlich auch interessant für eine Überwachung der Transport-Rollen von Exchange Servern und Exchange Edge-Servern. Denn wenn sehr viel mehr Mails pro Zeiteinheit beim Server abgeliefert werden als dieser dann letztlich weiter verarbeiten kann, dann werden auch hier die Counter sich eher vom "<=90sec" Wert auf längere Werte verlagern. Allerdings muss man auch diesen Wert wieder relativieren, denn es gibt immer Mails, die auf dem Server länger verbleiben ohne dass der eigene Server Schuld ist. Es kann ja durchaus sein, dass die Gegenseite tatsächlich offline oder nur schlecht erreichbar ist und sich daher Mails zu einem System verzögern. Insofern ist hier wieder die Überwachung der Queueinhalte nach dem Ziel interessant um genau solche Ziele dann ein Erfahrung zu bringen.
Nachträgliche Analyse
Die Auswertung mit Get-Queue funktioniert natürlich nur zur aktuellen Zeit aber erlaubt keinen Rückschluss auf Vorgänge in der Vergangenheit. Hier können Sie sich dann aber mit dem Messagetracking von Exchange behelfen. Dort wird ja der Mail durch jede Instanz gewissenhaft protokolliert und es gibt sogar Werte für die Latenzzeit, mit der Sie dann direkt erfassen können, wie lange eine Mail in ihrem Exchange System unterwegs war. Wer etwas tiefer in die Daten einsteigt kann auch den Weg einer Mail durch ihres Instanzen nachverfolgen und sich die entsprechenden Werte.
Entsprechende Informationen finden sie z.B. auf Message Tracking Latenz
Wie nun überwachen?
Es gibt keine Empfehlung von meiner Seite, welche Werte Sie mit welchen Grenzwerten versehen sollen, um frühzeitig über Probleme informiert zu werden. Dies hängt auch etwas von ihrem Monitoring-Programm ab, welche Werte es schnell mal so erfassen kann. Es dürfte sicherlich leicht sein, die Werte der Performance Counter auszulesen und einige Tage zu beobachten um auf den Werten dann Schwellwerte nach oben und ggfls. unten zu definieren.
Die Werte, die per "Get-Queue" ermittelt werden, sind nach meiner Kenntnis nicht per Perfmon direkt zu erfassen. Hier wird Get-Queue vermutlich über die Exchange Verwaltungsschnittstellen mit dem Transport-Dienst kommunizieren, um die aktuellen Werte zu erhalten. HIer können Sie dann am einfachsten per PowerShell diese Daten ermitteln und dem Monitoring zuführen. Wobei Sie hier eine Nachverarbeitung einbauen sollten, um die passenden Kennzahlen zu ermitteln.
Weitere Links
- Nachrichtentracking
- Nachrichtentracking Exchange 2007/2010
- Message Tracking Latenz
- Queue properties
https://technet.microsoft.com/en-us/library/bb125237(v=exchg.160).aspx - Warteschlangen und Nachrichten in
Warteschlangen
https://technet.microsoft.com/de-de/library/bb125022(v=exchg.160).aspx - Exchange 2013 Queue Velocity
http://techgenix.com/exchange-2013-queue-velocity/