Quand quelque chose ne va pas : logs et métriques

Deux onglets répondent à presque toutes les questions « qu'est-ce qui se passe ? » sur un environnement : Métriques pour la façon dont il tourne, Logs pour ce qu'il dit. Ni terminal, ni cluster, ni personne de la plateforme n'est nécessaire.

Les deux sont en lecture seule, et les deux sont accessibles à un Lecteur : observer un environnement n'est pas la même permission que le modifier, et la personne qui remarque un problème en premier n'est souvent pas celle qui a le droit de déployer.

Trois chiffres avant tout le reste

L'onglet Métriques s'ouvre sur trois tuiles, et il vaut la peine de les lire dans l'ordre.

• État — la façon dont l'environnement tourne, plus le nombre de répliques prêtes sur le nombre voulu. Running avec 1/1 est sain ; 1 voulue et 0 prête signifie qu'il démarre, ou qu'il n'y arrive pas.
• Disponibilité — le temps écoulé depuis le dernier démarrage. Un chiffre bien plus petit que prévu, c'est la découverte que quelque chose a redémarré pendant que vous regardiez ailleurs.
• Redémarrages — combien de fois l'environnement a redémarré depuis sa création. C'est le chiffre le plus instructif de la page. Zéro est normal. Un compteur qui monte tout seul est une boucle de plantage, et la raison se trouve dans les journaux de l'exécution précédente.

Si un message apparaît sous les tuiles, c'est l'explication de la plateforme elle-même sur un environnement en mauvaise santé, transmise telle quelle.

CPU et mémoire, face à leurs limites

Sous les tuiles, deux graphiques — lorsqu'un historique d'usage est disponible pour cet environnement.

Chaque graphique montre la valeur actuelle, la moyenne et le pic sur la fenêtre choisie, et trace la limite en pointillés. Cette ligne est tout l'intérêt du graphique : un environnement n'est pas lent parce que le CPU est haut, il est lent parce que le CPU est haut par rapport à ce qui lui est permis ; et la mémoire qui atteint sa limite ne ralentit rien du tout — elle tue l'environnement, ce que le compteur de redémarrages ci-dessus enregistre ensuite.

Quatre plages sont proposées — 15 minutes, 1 heure, 6 heures, 24 heures — plus une fenêtre absolue quand vous savez à quel moment l'incident a eu lieu.

D'où viennent les chiffres compte, et le panneau le dit :

Le flux de journaux

L'onglet Logs affiche la sortie d'exécution de l'environnement, en quasi temps réel, avec les niveaux colorés : erreurs en rouge, avertissements en ambre, le reste plus discret.

Les commandes sont celles dont on a réellement besoin en lisant :

• Filtrer — les correspondances sont surlignées sur place, et le compteur de lignes se met à jour pour vous dire combien il y en a.
• Nombre de lignes — de 200 à 2000.
• Pause — arrête le rafraîchissement automatique pour qu'une ligne en cours de lecture ne défile pas. Elle arrête aussi complètement l'interrogation.
• Retour à la ligne, copier, télécharger — le dernier vous donne un fichier texte à joindre à un rapport de bug.

La vue suit automatiquement les nouvelles lignes tant que vous ne remontez pas ; quand elle cesse de suivre, un bouton apparaît pour revenir en bas.

Direct ou historique : la distinction qui compte

Le badge en haut à droite du panneau indique laquelle des deux sources vous lisez, et elles n'offrent pas la même garantie.

Direct, c'est la sortie de l'environnement en cours d'exécution. Elle est éphémère : elle appartient à cette exécution, et un redémarrage l'emporte avec elle. Si un environnement a planté puis est revenu, le flux direct vous montre les journaux du processus sain qui a remplacé celui que vous vouliez lire.

Historique, c'est un stockage conservé à part de l'environnement lui-même. Il survit aux redémarrages, ce qui est précisément ce dont on a besoin après un plantage — et il permet de demander une fenêtre dans le passé plutôt que le seul présent.

Le sélecteur Direct / Historique force l'un ou l'autre. En mode historique vous obtenez en plus une plage de temps, et une fenêtre absolue ne se rafraîchit pas automatiquement : une tranche figée du passé ne change pas, elle n'est donc pas rechargée.

Quand l'historique n'est pas disponible, le panneau retombe sur le flux direct plutôt que de ne rien afficher, et le badge change en conséquence. Vérifiez le badge avant de conclure qu'une ligne de journal n'existe pas : absente du flux direct signifie seulement absente depuis le dernier redémarrage.

Lire un plantage

L'ordre qui trouve la cause le plus vite :

1. Redémarrages, sur l'onglet Métriques. En hausse ? Quelque chose tue l'environnement.
2. Graphique mémoire face à sa limite. S'il touche la ligne, la mise à mort vient de la limite mémoire, et aucune ligne de journal ne le dira : le processus a été terminé, il n'a pas échoué.
3. Journaux en mode historique, sur une fenêtre qui couvre le redémarrage. C'est la seule source qui détient encore ce qu'a dit l'exécution arrêtée.
4. Filtrer sur Traceback ou ERROR pour sauter jusqu'à l'échec, puis lire vers le haut : la ligne intéressante est en général la requête qui l'a précédé.

Si la mémoire est plate et que les journaux se terminent sur une traceback, la faute est dans le code, et le guide sur les modules décrit la boucle déployer-puis-migrer qui la corrige.