Déboguer un micro qui ne démarre pas

Un micro ne échoue pas toujours de la même façon. La clé : un micro qui n’arrive pas à démarrer (commande fausse, dépôt absent, port occupé) n’écrit pas une seule ligne à lui —la raison est dans les logs du moteur—, et c’est justement l’échec qui égare le plus si vous ne regardez que les logs du micro.

1. Diagnostic en un coup

Le plus rapide : le diagnostic du micro réunit en une seule réponse son état à l’exécution, ce que le moteur a dit de lui, ses erreurs et son dernier échantillon de métriques. Il n’exige pas que le scénario soit encore actif : diagnostiquer après un plantage est le cas normal.

Depuis le CLI : microlab diagnose <micro>.

2. Les logs

Dans le dock Logs, filtrez par ce micro et par niveau Error. Si vous ne voyez rien de lui, regardez les sources système (engine) — c’est là qu’apparaît pourquoi il n’a pas démarré.

Depuis le CLI :

microlab logs orders-core -n 500      # ses dernières lignes
microlab logs --errors                 # seulement les erreurs, dans tout le scénario
microlab logs -g "connection refused"  # un indice concret

Les logs persistent : microlab logs fonctionne même si le moteur n’est plus actif.

3. Vérifiez l’environnement

Beaucoup d’échecs de démarrage sont d’environnement (un outil, un identifiant, Docker manquant). La Vérification de l’environnement les détecte avant de lancer.

4. Redémarrez juste ce micro

Si vous avez corrigé quelque chose, pas besoin de relancer tout le scénario : redémarrez juste ce micro (dans sa carte/ligne, ou microlab restart <micro>).

Voir aussi

• Dock de Logs · Panneau Vérification de l’environnement