Logs: Builds und die Anfragen Ihrer Website
Logs zeigen, was wann geschehen ist: jeden Build und jede Veröffentlichung im Projekt sowie jede Anfrage, die den eigenen Code Ihrer Website im letzten Tag ausgeführt hat. Damit finden Sie heraus, warum ein Formular, eine geplante Aufgabe oder eine Seite sich nicht richtig verhält.
Zwei Arten von Protokollen
| Ansehen | Was angezeigt wird | Wie weit zurück |
|---|---|---|
| Builds | Jeder Build, jede Änderung und jede Veröffentlichung in diesem Projekt sowie die Schritte, die sie durchlaufen haben. | Die letzten 40 |
| Requests | Die Anfragen und Fehler der Website, die neuesten zuerst. | Die letzten 24 Stunden, jeweils bis zu 100 |
Geplante Aufgaben und Webhooks führen eigene Logs, dreißig Tage lang: Runs unter Geplante Aufgaben und Deliveries unter Webhooks. Nachrichten, die über Ihre Formulare gesendet wurden, bleiben unter Settings, Forms gespeichert.
Builds
Jeder Eintrag sagt, was angefragt wurde (in den Worten der Anfrage), wer es angefragt hat, wann und wie lange es dauerte. Wenn keine Person es gestartet hat, steht dort Briks. Rechts steht der Status:
| Status | Bedeutung |
|---|---|
| Waiting | Wartet hinter anderen Aufgaben. |
| Running | Ist gerade in Arbeit. |
| Done | Fertig. |
| Failed | Es wurde vor dem Ende angehalten. |
| Stopped | Sie wurde gestoppt, bevor sie fertig war. |
Klicken Sie auf einen Eintrag, um seine Schritte zu sehen, jeweils mit der Uhrzeit. Ein fehlgeschlagener Schritt wird rot angezeigt. Ein fehlgeschlagener Eintrag endet mit: It did not finish. Nothing on the live site changed, and no credits were charged for it.
Um dieselbe Arbeit live mitzuverfolgen, mit der Vorschau daneben, nutzen Sie das Studio: siehe Einen Build beobachten.
Anfragen
Requests zeigt Aufrufe, die den eigenen Code Ihrer Website ausgeführt haben: ihre /api-Routen und Seitenaufrufe, während ein A/B-Test die Besucher auf zwei Versionen aufteilt. Normale Seiten, Bilder und Dateien werden unverändert ausgeliefert, deshalb erscheinen sie nicht. Das gilt auch für Nachrichten über ein Kontaktformular, die direkt an Briks gehen und nicht durch den Code Ihrer Website.
Jede Zeile zeigt die Zeit, die Methode und den Pfad (GET fragt etwas an, POST sendet etwas), wie lange es in Millisekunden gedauert hat und den Status, mit dem die Website geantwortet hat, oder keine Antwort. Zeilen, die der Code Ihrer Website selbst geschrieben hat, zeigen ihre Nachricht und eine Stufe wie error oder warning. Klicken Sie auf eine Zeile für die vollständige Nachricht, das Datum und die ID der Anfrage.
| Status | Was es bedeutet |
|---|---|
| 2xx, etwa 200 | Es hat funktioniert. |
| 4xx, etwa 400 oder 404 | Die Anfrage wurde abgewiesen: Es fehlte etwas, oder etwas war falsch, oder unter diesem Pfad existiert nichts. |
| 5xx, zum Beispiel 500 | Der Code der Website ist bei der Antwort fehlgeschlagen. |
Filter
| Filter | Auswahl | Nutzen Sie es, um |
|---|---|---|
| Search | Beliebige Wörter: ein Pfad, eine Nachricht, eine Anfragekennung | Eine Route oder einen Fehler finden. |
| Level | All levels, Errors, Warnings | Nur Probleme anzeigen, die der Code gemeldet hat. |
| Status | Any status, Succeeded, 4xx, 5xx | Nur abgewiesene oder fehlgeschlagene Anfragen anzeigen. |
Legen Sie sie fest und drücken Sie Show. Die Adresse der Seite behält sie, sodass Sie eine gefilterte Ansicht als Lesezeichen speichern können. No requests in the last day bedeutet, dass in 24 Stunden kein Code der Website lief. Zeigt die Seite Logs cannot be read right now, versuchen Sie es in einer Minute erneut.
Ein fehlerhaftes Formular diagnostizieren
Suchen Sie nach dem Eintrag
Wo: Settings, Forms
Jede Nachricht eines Besuchers wird hier gespeichert, die letzten 100 auf dem Bildschirm. Jede zeigt, wann sie kam und von welcher Seite, dann emailed, not emailed oder preview.
Wenn dort Vorschau steht
Wo: Settings, Forms
Die Website wurde nicht in Produktion veröffentlicht, daher werden Einträge gespeichert, aber nicht per E-Mail verschickt. Siehe In Produktion veröffentlichen.
Wenn es heißt, die E-Mail wurde gesendet, aber nichts ankommt
Wo: Your inbox
Einträge gehen an die Person, die das Projekt erstellt hat, oder an den ersten Owner des Workspace, falls diese Person nicht mehr dabei ist. Prüfen Sie dieses Postfach, auch den Spam-Ordner.
Wenn es gar nicht da ist
Wo: The live site
Die Nachricht hat Briks nie erreicht. Senden Sie selbst eine. Antwortet das Formular, von hier seien zu viele Nachrichten gesendet worden, wurde ein Limit erreicht: bis zu 5 Nachrichten pro Besucher in 10 Minuten und bis zu 300 pro Tag für die Website.
Wenn ein anderes Tool es haben soll
Wo: Settings, Webhooks, Deliveries
Setzen Sie Status auf Failed und drücken Sie Show. Öffnen Sie die Zustellung, um zu lesen, was das andere Tool geantwortet hat, und wählen Sie nach der Korrektur Send again.
Eine fehlgeschlagene geplante Aufgabe untersuchen
Den Lauf lesen
Wo: Settings, Scheduled tasks, Runs
Öffnen Sie den fehlgeschlagenen Lauf. Er zeigt, was die Adresse geantwortet hat, etwa answered 500, und den Anfang der Antwort.
Den Fehler finden
Wo: Settings, Logs, Requests
Wenn die Aufgabe eine Route auf Ihrer Website aufruft, suchen Sie nach deren Pfad, zum Beispiel
/api/daily-summary, und setzen Sie Level auf Errors. Die Meldung sagt, was im Code schiefgelaufen ist.Bitten Sie um die Korrektur
Wo: Studio
Fügen Sie den Fehler in den Studio-Chat ein, zusammen mit einem Satz zur Aufgabe: Die Route für die tägliche Zusammenfassung schlägt jeden Morgen mit diesem Fehler fehl. Siehe Änderungen vornehmen.
Erneut versuchen
Wo: Settings, Scheduled tasks
Öffnen Sie nach der Veröffentlichung der Korrektur die drei Punkte der Aufgabe und wählen Sie Run now. Das Ergebnis erscheint sofort.
Ein als Skipped markierter Lauf ist nicht fehlgeschlagen: Die Aufrufe des Projekts für den Tag waren aufgebraucht. Die Läufe starten nach Mitternacht UTC wieder. Die Tariflimits stehen auf der Seite Geplante Aufgaben.
Eine langsame Seite diagnostizieren
Requests misst alles, was den Code Ihrer Website ausführt. Hier sollten Sie nachsehen, wenn sich eine Seite langsam anfühlt, die ihren Inhalt über die Routen der Website lädt. Apps und Dashboards funktionieren meist so.
Seite öffnen und die Uhrzeit notieren
Wo: The live site
Laden Sie die langsame Seite einmal selbst, damit ihre Anfragen zu den neuesten gehören.
Die Zeiten lesen
Wo: Settings, Logs, Requests
Sehen Sie sich die Millisekunden neben jeder Anfrage zu diesem Zeitpunkt an. Dauert eine Route mehrere Sekunden, während andere nur einige hundert Millisekunden brauchen, ist sie der Übeltäter.
Eingrenzen
Wo: Settings, Logs, Requests
Suchen Sie nach dem Pfad dieser Route, um zu sehen, ob sie immer langsam ist oder nur manchmal und ob daneben Warnings oder Errors erscheinen.
Um eine Korrektur bitten
Wo: Studio
Sagen Sie dem Studio, welche Route langsam ist und wie langsam, samt der Seite, die sie ausliefert.
Wenn nichts Langsames erscheint, liegt die Verzögerung nicht im Code Ihrer Website. Seiten, Bilder und Dateien werden unverändert ausgeliefert, achten Sie also darauf, was die Seite enthält, etwa große Bilder oder ein Video, und beschreiben Sie im Studio, was sich langsam anfühlt.
Praxisbeispiel: Eine Buchungs-App, die nicht mehr speicherte
Seit dem Morgen waren keine neuen Buchungen eingegangen, obwohl das Telefon weiter klingelte und Leute sagten, das Formular tue nichts.
Unter Requests mit Status auf 5xx wurde jedes POST /api/bookings seit 9:12 Uhr mit 500 beantwortet. Die Fehlerzeile daneben besagte, dass ein Pflichtfeld fehlte.
Seit heute Morgen schlägt jede Buchung mit einem 500 auf /api/bookings fehl. Im Protokoll steht, dass das Feld für die Tiergröße fehlt. Wir haben dieses Feld gestern aus dem Formular entfernt.
Die Änderung wurde veröffentlicht, und die nächste Buchung unter Requests wurde mit 200 beantwortet.