Avamar: Aktivieren und Interpretieren der Avtar COMSTATS-Protokollierung zur Diagnose von Kommunikationsproblemen

Die Ausgabe von Kommunikationsstatistiken (COMSTATS) ist nützlich für die Diagnose von Kommunikationsproblemen zwischen avtar und Avamar Server. Anhand dieser Informationen kann nachgewiesen werden, ob auf dem Avamar-Server ein Kommunikationsengpass vorliegt.

Comstats stellt Statistiken zu Daten bereit, die zwischen dem Avamar Client und Server übertragen werden. Es kann nicht verwendet werden, um Probleme zu diagnostizieren, bei denen ein Backup an Data Domain gesendet wird.

Dies liegt daran, dass bei Backups an Data Domain nur Metadaten an den Avamar Server gesendet werden. Diese Größe der Metadaten ist winzig im Verhältnis zu den Backupdaten, die avtar an Data Domain sendet.


So wenden Sie die Ausgabe "COMSTATS" auf die avtar-Protokollierung an:

COMSTATS fügt den Protokollen viele Zeilen hinzu, daher sollte es sparsam verwendet werden.
Verwenden Sie sie nur für Performanceproblemszenarien, bei denen die Antwortzeit des Avamar-Servers oder die Clientwarteschlangenzeit als Ursache vermutet wird.
 

1. Bearbeiten oder erstellen Sie auf dem Clientsystem eine Textdatei mit dem Namen avtar.Cmd. Die Datei muss im Avamar-Installationsverzeichnis (weiter oben in diesem Artikel erwähnt) abgelegt werden.
2. Erstellen Sie die Datei mit einem Texteditor und fügen Sie diese Zeilen hinzu, bevor Sie die Datei speichern.

--comstats

Es ist auch möglich, die comstats-Protokollierung über die Benutzeroberfläche für ein einzelnes Backup oder für ein gesamtes Datenvolumen zu aktivieren. 
 

• Wählen Sie die Schaltfläche "More Options" aus.
• Wählen Sie "Erweiterte Optionen". 
• Aktivieren Sie das Kontrollkästchen "Enable Debugging Messages", während Sie ein einzelnes Backup durchführen oder die Option "--comstats=true " zu einem Datenvolumen hinzufügen. 
• Dies ist im Avamar-Systemadministratorhandbuch dokumentiert.

Allgemeine Informationen:
 

• Der clientseitige TCP-Socket-Puffer wird mit "maxpending"-Anforderungen an den Avamar Server gefüllt.
• Avtar überwacht die Antwortzeit des Avamar-Servers und passt standardmäßig "maxpending" an die Antwortrate des Avamar-Servers an.
• Wenn avtar innerhalb von 60 Sekunden keine Antwort des Avamar-Servers empfängt, wird die Anfrage erneut gesendet. Dies ist eine Wiederholung auf Anwendungsebene, kein TCP. Wenn der Avamar-Server in diesem Fall bereits geantwortet hat (ACK), empfängt avtar eine zweite ACK und meldet UNECESSARY.
• WorkQ0 speichert die Antworten vom Avamar-Server. Diese Zahl sollte immer eine niedrige, einstellige Zahl sein. Wenn dies nicht der Fall ist, weist dies auf ein clientseitiges Problem hin.

Anatomie einer COMSTATS-Linie

Falls --comstats gesetzt ist, gibt avtar jede Sekunde COMSTATS-Meldungen in das Protokoll aus.

avtar Stats <0000>: 2010-10-11 06:18:20 COMSTATS:0 sent= 84 recv[0]= 84 pending= 1/ 5 int= 0/50 send= 0 bytes= 9408+ 17711 sleepms= 0 delay=(0.008 [0.000..0.210] sd=0.030 n= 53) (0.022 [0.000..0.324] sd=0.066 n= 31)

COLOR CODED EXPLANATION OF THE LOG LINE:

COMSTATS:0 --> The "0" is the DPN index and refers to the GSAN. It is only useful for replication jobs. 0=Source, 1=Target.

sent= 84 recv[0]= 84 --> 84 requests were sent and 84 responses received from the server since the previous comstat message.

pending= 1/ 5 --> avtar has 1 message awaiting server response out of a queue max depth of 5=<current value of maxpending>. 
Large PENDING values indicate slow server response. Avtar will try to increase maxpending to match.

int= 0/50 --> Internal Pending messages / <Avtar FLAG value of MAXPENDING>

send= 0 --> Send queue length

bytes= 9408+ 17711 --> "Message" bytes is 9409; (Xmit-bytes + Rcv-bytes) is 17711
"Message" bytes are defined as GETHASH + ADDHASH + ADDCOMP.

sleepms= 0 --> Throttle delay = 0

Die folgende Zeile enthält Statistiken für die Antwort- und Verzögerungszeiten des Avamar-Servers im Intervall seit der letzten Meldung:

• Die durchschnittliche Verzögerung betrug 0,008 s.
• [Bereich 0 bis 0,21 Sek.]
• Standardabweichung = 0,03.
• n=<Anzahl der Nachrichten seit dem letzten "TUNE">.

Die erste Zahlengruppe ist für die Verzögerung von Meldungen vom Typ "Nicht-Daten". Der zweite Datensatz ist für die Verzögerung von Meldungen vom Typ "Daten".

• MSG_CMD_LOGIN – Melden Sie sich mit den angegebenen Zugangsdaten beim Server an.
• TICKETLOGIN - melden Sie sich mit dem bereitgestellten Session-Ticket auf dem Server an.
• HASH_IS_PRESENT (Hash): Ist der Hash bereits auf dem Server gespeichert?
• MSG_CMD_MOD_BACKUP_LIST (time, label, size, expiration, root hash, LSTR_ADD): Zeichnet einen neuen Backup-Root-Hash auf.

• ADD_HASH_DATA (hash, type, data): Fügen Sie neue unart Daten mit Adress-Hash hinzu.
• GET_HASH_DATA (Hash) – Abrufen von Daten für Hash-Rückgabe von Typ und Daten.

Weitere Informationen zu MAXPENDING