Die Angebotsanfrage bis zum Ziel verfolgen

Einführung

PARCEL ist ein fiktiver Geschenkeladen. Besucher sehen sich Arc lamp oder Clay vase an und vergleichen Lieferung und Abholung. Die Abholung liefert bereits eine Schätzung, die Lieferung schlägt fehl. Du verfolgst eine neue fehlgeschlagene Anfrage vom Eingang zum antwortenden Dienst und stellst korrekte Lieferpreise wieder her, ohne die Abholung zu beschädigen.

Grundlegende Terminalkenntnisse genügen. Du bearbeitest zwei kurze Nginx-Konfigurationsdateien, liest echte Logs und testest tatsächliche Antworten. Anwendungsprogrammierung, SDK, externe Konten, Käufe und persönliche Daten sind unnötig. Alle Dienste laufen auf einer vorbereiteten Trainingsinstanz: Es geht um Anfragekorrelation, nicht um eine vollständige Plattform für verteiltes Tracing.

Nutze Website zum Stöbern und Anfordern von Schätzungen. Alle Befehle gehören in Workstation, anfangs in /home/labex/project/parcel. Jede Einheit hat eine eigene Umgebung. Der Eingang auf Port 8081 leitet jede Schätzungsanfrage an ein Backend weiter. Lieferung lauscht auf 8091, Abholung auf 8092. Ein Port bezeichnet einen Netzwerkdienst; in Workstation bedeutet 127.0.0.1 diese Lab-Instanz.

Einer neuen Anfrage eine gemeinsame Referenz geben

In diesem Schritt lernst du den normalen Kundenweg kennen, beobachtest den Fehler und verknüpfst eine neue Anfrage in zwei echten Logs. Beginne in Website.

Den Laden kennenlernen

Öffne Arc lamp unter Two good things. Die Detailseite zeigt $48 und eine lokale Illustration. Wähle Estimate collection, lasse Arc lamp und Near ausgewählt und klicke Get estimate. Erwartet werden $2.00 und HTTP 200. Diese normale Funktion musst du erhalten. Gehe mit PARCEL↗ zur Startseite, öffne Delivery und klicke Get estimate. Es erscheinen Estimate unavailable und HTTP 404.

HTTP ist das Anfrage-Antwort-Protokoll des Browsers. 200 bedeutet eine erfolgreiche Antwort; 404 bedeutet, dass der empfangende Dienst den angefragten Pfad nicht gefunden hat. Ein Verbindungsfehler ist etwas anderes: Es kam keine nutzbare Serverantwort an. Die Referenz lautet noch not available, sodass sich die Kundenantwort nicht leicht mit den Logs verbinden lässt.

Die Belege verstehen

Das vorbereitete Eingangs-Log zeichnet bereits die von Nginx für jede Anfrage erzeugte Kennung auf. Das Backend kann eine weitergeleitete Kennung aufzeichnen. Verbunden erzeugt eine fehlgeschlagene Anfrage Einträge wie diese; die Punkte stehen für deine eigene Kennung:

entry:    {"id":"...","path":"/api/delivery","status":404,"upstream":"127.0.0.1:8091","upstream_status":"404"}
delivery: {"service":"delivery","id":"...","path":"/v1/shipping","status":404}

Der Eingangspfad ist der vom Browser angeforderte Pfad. Der Backend-Pfad ist der tatsächlich weitergeleitete Pfad. upstream bezeichnet die kontaktierte Adresse, upstream_status deren wirklichen Antwortstatus. Eine gleiche Kennung verbindet die Beobachtungen; nur Zeitstempel zu vergleichen wäre bei vielen Anfragen weniger zuverlässig. Anfragekörper und Geheimnisse werden nicht protokolliert.

Die Kennung verbinden

Wechsle zu Workstation. pwd zeigt das aktuelle Verzeichnis, cat einen Dateiinhalt:

pwd

Erwarte /home/labex/project/parcel. Falls du das Verzeichnis verlassen hast, führe cd /home/labex/project/parcel aus; cd wechselt das aktuelle Verzeichnis. Pfade ohne führenden /, etwa correlation.conf, sind relativ zu diesem Verzeichnis.

cat correlation.conf

Die Datei enthält nur einen Kommentar. Nginx ist der vorbereitete Eingangsserver. Seine Konfiguration besteht aus Direktiven, die mit Semikolon enden. Der Hauptserver bindet diese kleine Datei ein; sein Grundgerüst bearbeitest du nicht.

Ein Header ist ein benannter Wert in einer HTTP-Anfrage oder -Antwort. proxy_set_header setzt einen zum Backend gesendeten Header; add_header ergänzt einen in der Kundenantwort. $request_id ist der von Nginx für diese Anfrage erzeugte Wert. always schließt Fehlerantworten ein. X-Request-ID ist hier die gemeinsame Namenskonvention. Der Eingang erzeugt seine Kennung selbst, statt einem Besucherwert zu vertrauen.

cat > correlation.conf ersetzt die Datei durch ein Here-Dokument. Füge den ganzen Block ein, einschließlich des letzten CONF in einer eigenen Zeile. Die Anführungszeichen um 'CONF' erhalten $request_id wörtlich, damit Nginx und nicht die Shell es auswertet:

cat > correlation.conf <<'CONF'
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
CONF

Lies die gespeicherte Datei und wende sie mit dem bereitgestellten Helfer an. bash führt dieses Shell-Skript aus. Es prüft zuerst die Syntax und lädt Nginx nur bei gültiger Konfiguration neu; es repariert keine Routen und bewertet keine Preise.

cat correlation.conf

bash reload.sh

Erwarte einen erfolgreichen Konfigurationstest und Configuration accepted. Send a new request to test it. Bei einem Zeilenfehler vergleiche Schreibweise, Semikolons und wörtliche Dollarzeichen, schreibe die Datei erneut und wiederhole den Aufruf. Scheitert die Syntaxprüfung, bleibt die vorherige Konfiguration aktiv. Neuladen verändert keine alte Antwort: Sende eine neue Anfrage.

Deinen eigenen neuen Fehler verfolgen

Klicke in Delivery unter Website erneut Get estimate. Der Fehler bleibt, aber Request reference enthält nun 32 hexadezimale Zeichen. Kopiere genau diesen neuen Wert, nicht die Punkte oben oder eine Kennung aus einem Screenshot.

Zurück in Workstation speichert eine Shell-Variable einen Wert für spätere Befehle. Ersetze PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE durch die genaue neue Referenz aus Website. Behalte die einfachen Anführungszeichen und verwende keine Leerzeichen um =. Die Anführungszeichen erhalten den wörtlichen Wert; führe den Platzhalter nicht unverändert aus:

REQUEST_ID='PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE'

grep zeigt passende Zeilen. -F behandelt den Wert als einfachen Text; doppelte Anführungszeichen halten den Variablenwert zusammen. Diese absoluten Pfade funktionieren aus jedem Verzeichnis:

grep -F "$REQUEST_ID" /var/log/parcel/entry.jsonl

grep -F "$REQUEST_ID" /var/log/parcel/delivery.jsonl

Beide Einträge sollten exakt dieselbe Kennung, den Backend-Pfad /v1/shipping und Status 404 zeigen. Damit ist belegt, dass die Lieferung ein antwortendes Backend erreicht: Der Dienst ist nicht gestoppt und die Verbindung fehlt nicht. Leere Ausgabe deutet oft auf eine alte oder falsch kopierte Referenz hin. Fordere in Website erneut an, kopiere den neuen Wert und setze REQUEST_ID erneut. Nur mit dem Antwort-Header bliebe die Backend-Kennung -; beide Direktiven sind nötig.

Die Schrittprüfung sendet neue schreibfreie Anfragen zur Korrelation. Sie verlangt weder eine bestimmte Shell-Variable noch Befehlsverlauf oder kopierte Log-Dateien.

Die Route reparieren und beide Schätzungen erhalten

In diesem Schritt reparierst du die Lieferung anhand der beiden Einträge und des Dienstvertrags. Beginne in Workstation.

Adresse und Pfad trennen

Zeige die Routing-Konfiguration mit cat:

cat routes.conf

Ein location =-Block trifft einen exakten öffentlichen Pfad; geschweifte Klammern gruppieren seine Direktiven. proxy_pass nennt Nginx das Ziel. In http://127.0.0.1:8091/v1/shipping wählen Adresse und Port den Dienst, während /v1/shipping die Operation auswählt. Beide Teile können falsch sein. Bei diesen exakten Locations ersetzt der konfigurierte Backend-Pfad den passenden öffentlichen Pfad; die Abfrageoptionen werden weiterhin übertragen.

Die vorbereiteten Dienste haben diesen Vertrag:

Beide antworten auch auf /health, aber ein gesunder Dienst beweist kein korrektes Routing. Die Logs zeigen Lieferung auf 8091 am Pfad /v1/shipping. Der Dienst ist zuständig, bietet aber diesen Pfad nicht an. Der Vertrag verlangt /v1/delivery. Bei der Abholung stimmen Adresse und Pfad bereits.

Die kleine Reparatur anwenden

Ersetze nur die bearbeitbare Routendatei und erhalte die Abholung:

cat > routes.conf <<'CONF'
location = /api/delivery {
    proxy_pass http://127.0.0.1:8091/v1/delivery;
}
location = /api/collection {
    proxy_pass http://127.0.0.1:8092/v1/collection;
}
CONF

bash reload.sh

Bei Syntaxfehlern vergleiche Klammern und Semikolons, schreibe die Datei neu und wiederhole. Bearbeite weder Backend, Website, Logs noch Hauptkonfiguration. 200 ohne echte korrekte Schätzung würde den Fehler nur verdecken.

Echte Preise und Korrelation testen

Öffne Delivery in Website und fordere Arc lamp / Near erneut an. Erwartet werden $6.00, HTTP 200 und eine neue Referenz. Clay vase / Far muss $13.00 ergeben. Teste Collection: Arc lamp / Near muss weiterhin $2.00, Clay vase / Far $4.00 zeigen. Jeder Klick sendet eine neue Anfrage, daher müssen sich die Referenzen unterscheiden. Auch die Produktseiten über PARCEL↗ müssen Bilder und Preise behalten.

Zurück in Workstation sendet curl eine HTTP-Anfrage. -sS blendet Fortschritt aus, zeigt aber Verbindungsfehler; -i enthält Antwort-Header. Einfache Anführungszeichen halten & in der URL, statt es von der Shell auswerten zu lassen. Die Optionen nach ? wählen Objekt und Entfernung:

curl -sS -i 'http://127.0.0.1:8081/api/delivery?item=vase&zone=far'

Erwarte HTTP/1.1 200 OK, einen X-Request-ID-Header und JSON mit "service": "delivery", "amount": 13, "currency": "USD". JSON ist ein Textformat aus benannten Werten. request_id im Antwortkörper muss dem Header entsprechen. Die Großschreibung von Headernamen kann variieren, ohne ihre Bedeutung zu ändern.

Nimm die Referenz dieser Antwort und setze REQUEST_ID erneut und wiederhole beide grep -F aus Schritt 1. Beide Logs zeigen jetzt 200, das delivery-Log /v1/delivery. Alte 404-Einträge sind weiterhin nützlich; lösche oder überschreibe sie nicht.

Prüfe die erhaltene Funktion unabhängig:

curl -sS -i 'http://127.0.0.1:8081/api/collection?item=lamp&zone=near'

Erwarte 200, "service": "collection" und "amount": 2. Ein 404 ist eine normale HTTP-Antwort, daher kann curl ohne Option zum Fehlschlagen bei HTTP-Fehlerstatus normal enden. Ein Verbindungsfehler deutet auf einen nicht verfügbaren Prozess oder eine falsche Adresse hin. Prüfe die letzte funktionierende Konfiguration, statt dies mit dem obigen Pfadbeleg zu verwechseln.

Die Abschlussprüfung fordert alle Objekt-/Entfernungskombinationen beider Operationen an, ordnet neue Kennungen echten Dienst-Logs zu und prüft die vollständige Website. Nur gewöhnliche Zugriffslogs wachsen; die Bewertung lädt keine Konfiguration neu, schreibt keine Dateien um und erstellt keine Bestellungen.

Zusammenfassung

Du hast Eingangs- und Backend-Logs einer neuen Anfrage über eine erzeugte Referenz verknüpft, einen fehlenden Pfad eines antwortenden Dienstes von einem Verbindungsfehler unterschieden und die tatsächliche Route repariert. Du hast unterschiedliche Geschäftsergebnisse getestet und die Abholung erhalten. Die unabhängige Challenge ändert den empfangenden Dienst mit denselben Methoden für Adresse, Pfad und Korrelation.