Debug di un micro che non si avvia

Un micro non fallisce sempre allo stesso modo. La chiave: un micro che non riesce ad avviarsi (comando sbagliato, repo assente, porta occupata) non scrive nemmeno una riga propria —il motivo è nei log del motore—, ed è proprio l’errore che più depista se guardi solo i log del micro.

1. Diagnosi in un colpo

Il più veloce: la diagnosi del micro riunisce in un’unica risposta il suo stato a runtime, ciò che il motore ha detto di lui, i suoi errori e il suo ultimo campione di metriche. Non richiede che lo scenario sia ancora attivo: diagnosticare dopo una caduta è il caso normale.

Dalla CLI: microlab diagnose <micro>.

2. I log

Nel dock Log, filtra per quel micro e per livello Error. Se non vedi nulla di suo, guarda le fonti di sistema (engine) — lì appare perché non si è avviato.

Dalla CLI:

microlab logs orders-core -n 500      # le sue ultime righe
microlab logs --errors                 # solo errori, in tutto lo scenario
microlab logs -g "connection refused"  # un indizio concreto

I log persistono: microlab logs funziona anche se il motore non è più attivo.

3. Verifica l’ambiente

Molti errori di avvio sono di ambiente (manca uno strumento, una credenziale, Docker). La Verifica dell’ambiente li rileva prima di avviare.

4. Riavvia solo quel micro

Se hai sistemato qualcosa, non serve riavviare tutto lo scenario: riavvia solo quel micro (nella sua scheda/riga, o microlab restart <micro>).

Vedi anche

• Dock dei Log · Pannello Verifica dell’ambiente