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: aseptic 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:

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

Die Logs bleiben erhalten: aseptic 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 aseptic restart <micro>).

Siehe auch

• Logs-Dock · Panel Umgebungsprüfung