Avamar : Activation et interprétation de la journalisation avtar COMSTATS pour diagnostiquer les problèmes de communication

La sortie des statistiques de communication (COMSTATS) est utile pour diagnostiquer les problèmes de communication entre avtar et Avamar Server. Ces informations peuvent vous aider à déterminer si un goulot d’étranglement de communication s’est produit sur le serveur Avamar.

Comstats fournit des statistiques sur les données transférées entre le client Avamar et le serveur. Il ne peut pas être utilisé pour diagnostiquer les problèmes d’envoi d’une sauvegarde à Data Domain.

En effet, lorsque des sauvegardes sont envoyées à Data Domain, seules les métadonnées sont envoyées à l’instance d’Avamar Server. La taille des métadonnées est infime par rapport aux données de sauvegarde qu’avtar envoie à Data Domain.


Comment appliquer la sortie « COMSTATS » à la journalisation avtar :

COMSTATS ajoute de nombreuses lignes aux journaux, il doit donc être utilisé avec parcimonie.
Utilisez-le uniquement pour les scénarios de problèmes de performances où le temps de réponse du serveur Avamar ou le temps de file d’attente du client est soupçonné d’en être la cause.
 

1. Modifiez ou créez un fichier texte sur le système client nommé avtar.Cmd. Le fichier doit être placé dans le répertoire d’installation d’Avamar (mentionné plus haut dans cet article).
2. Utilisez un éditeur de texte pour créer le fichier et ajoutez ces lignes avant d’enregistrer le fichier.

--comstats

Il est également possible d’activer la journalisation comstats via l’interface utilisateur pour une seule sauvegarde ou de l’activer pour un jeu de données entier. 
 

• Sélectionnez le bouton « Plus d’options ».
• Choisissez Options avancées. 
• Cochez la case « Enable Debugging Messages » lors de l’exécution d’une sauvegarde unique ou de l’ajout de l’option --comstats=true à un jeu de données. 
• Cette procédure est documentée dans le guide d’administration système d’Avamar.

Informations générales :
 

• La mémoire tampon du socket TCP côté client est remplie avec les demandes « maxpending » adressées à Avamar Server.
• Avtar surveille le temps de réponse du serveur Avamar et, par défaut, ajuste la valeur « maxpending » pour qu’il corresponde au taux de réponse du serveur Avamar.
• Si avtar ne reçoit pas de réponse de l’instance d’Avamar Server dans les 60 s, il renvoie la demande. Il s’agit d’une nouvelle tentative au niveau de l’application, et non de TCP. Dans ce cas, si Avamar Server a déjà répondu (ACK), avtar reçoit un second ACK et signale UNEEDED.
• WorkQ0 conserve les réponses d’Avamar Server. Ce nombre doit toujours être un chiffre bas, à un chiffre. Si ce n’est pas le cas, cela indique un problème côté client.

Anatomie d’une ligne

COMSTATSSi l’option --comstats est définie, avtar affiche des messages COMSTATS toutes les secondes dans le journal.

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

La ligne suivante présente les statistiques des temps de réponse et de délai du serveur Avamar dans l’intervalle écoulé depuis le message précédent :

• Le délai moyen était de 0,008 s.
• [Plage de 0 à 0,21 s].
• Écart-type = 0,03.
• n =< Nombre de messages depuis le dernier « TUNE »>.

La première série de chiffres concerne le retard des messages de type « Non-données ». Le deuxième jeu de données concerne le délai des messages de type « Data ».

• MSG_CMD_LOGIN : connectez-vous au serveur à l’aide des informations d’identification fournies.
• TICKETLOGIN - connectez-vous au serveur avec le ticket de session fourni.
• HASH_IS_PRESENT (hachage) : le hachage est-il déjà stocké sur le serveur ?
• MSG_CMD_MOD_BACKUP_LIST (heure, étiquette, taille, expiration, hachage racine, LSTR_ADD) -- Enregistre un nouveau hachage racine de sauvegarde.

• ADD_HASH_DATA (hachage, type, données) : ajoute de nouvelles données de type avec hachage d’adresse.
• GET_HASH_DATA (hachage)- Récupérez les données pour le hachage retournant le type et les données.

Plus d’informations sur MAXPENDING