Einen Micro debuggen, der nicht startet

Ein Micro scheitert nicht immer gleich. Der Schlüssel: Ein Micro, der es nicht schafft zu starten (falscher Befehl, fehlendes Repo, belegter Port), schreibt keine einzige eigene Zeile —der Grund liegt in den Engine-Logs—, und das ist genau der Fehler, der am meisten in die Irre führt, wenn Sie nur die Logs des Micros ansehen.

1. Diagnose auf einen Schlag

Das Schnellste: Die Diagnose des Micros versammelt in einer einzigen Antwort seinen Laufzeitstatus, was die Engine über ihn sagte, seine Fehler und seinen letzten Metrik-Messwert. Sie verlangt nicht, dass das Szenario noch aktiv ist: nach einem Absturz zu diagnostizieren ist der Normalfall.

Vom CLI: microlab diagnose <micro>.

2. Die Logs

Filtern Sie im Dock Logs nach diesem Micro und nach der Stufe Error. Wenn Sie nichts Eigenes von ihm sehen, schauen Sie in die Systemquellen (engine) — dort erscheint, warum er nicht gestartet ist.

Vom CLI:

microlab logs orders-core -n 500      # seine letzten Zeilen
microlab logs --errors                 # nur Fehler, im ganzen Szenario
microlab logs -g "connection refused"  # ein konkreter Hinweis

Die Logs bleiben erhalten: microlab logs funktioniert, auch wenn die Engine nicht mehr aktiv ist.

3. Prüfen Sie die Umgebung

Viele Startfehler sind Umgebungsfehler (ein Werkzeug, ein Zugangsdatum, Docker fehlt). Die Umgebungsprüfung erkennt sie vor dem Start.

4. Starten Sie nur diesen Micro neu

Wenn Sie etwas behoben haben, müssen Sie nicht das ganze Szenario neu starten: Starten Sie nur diesen Micro neu (in seiner Karte/Zeile oder microlab restart <micro>).

Siehe auch

• Logs-Dock · Panel Umgebungsprüfung