Logs

Logs im Backend

Die Seite Logs zeigt technische GLS-Protokolle aus Labelerstellung und Stornierung. Der Bereich hilft beim Einordnen von API-Antworten, Fehlermeldungen, Rueckgabecodes und maskierten Requestdaten.

Inhaltsverzeichnis

Zweck und Datenbasis

Die GLS-Logseite nutzt den allgemeinen Daily-Logviewer fuer Versand- und Schnittstellenprotokolle. Angezeigt werden Tagesdateien mit dem GLS-Logprefix und der Textdatei-Endung. Neue Logdateien entstehen, wenn GLS-Label erzeugt oder GLS-Tickets storniert werden.

  • Logbereich: Der Viewer ist fest auf GLS eingestellt.
  • Dateityp: Gelesen werden Textdateien des GLS-Logbereichs.
  • Aufbewahrung: Daily-Logs werden standardmaessig 14 Tage aufbewahrt und danach bereinigt.
  • Loginhalt: Ein Eintrag enthaelt Zeitpunkt, Methode, Ziel, Header, Request, Response-Header, HTTP-Code und Response-Inhalt.
  • Schreibstellen: GLS-Labelerstellung und GLS-Stornierung schreiben jeweils einen Eintrag.
Wenn noch keine GLS-Logdatei vorhanden ist, zeigt der Viewer eine Meldung statt einer Dateivorschau.

Datei herunterladen: In der Metazeile der ausgewaehlten Logdatei steht zusaetzlich ein Downloadlink. Damit kann die aktuell angezeigte Tagesdatei auf dem eigenen Rechner gespeichert werden, ohne die Loganzeige zu verlassen.

Auswahl und Abrufen

Die Bedienung besteht aus einer Dateiauswahl und einer Abrufen-Aktion. Es gibt keine Datentabelle, keine Spaltensteuerung und kein separates Suchformular.

  • Logdatei: Auswahlfeld fuer vorhandene GLS-Logdateien. Jede Option zeigt Dateiname und ungefaehre Groesse in KB.
  • Standardauswahl: Ohne explizite Auswahl wird die neueste gefundene Datei geladen.
  • Abrufen: Laedt die ausgewaehlte Datei neu und bleibt innerhalb der GLS-Log-Unterseite.
  • Dateischutz: Die Auswahl wird auf den Dateinamen reduziert. Dadurch kann der Viewer nur Dateien aus der gefundenen Logliste oeffnen.
  • Fallback: Wenn ein angeforderter Dateiname nicht zur Liste passt, wird wieder die erste verfuegbare Logdatei genutzt.

Anzeige und Vorschau

Nach dem Abrufen zeigt der Viewer Metadaten zur Datei und darunter eine scrollbare Textvorschau.

  • Ausgewaehlt: Dateiname der aktuell angezeigten Logdatei.
  • Geaendert: Zeitpunkt der letzten Dateiaenderung.
  • Groesse: Dateigroesse gerundet in KB.
  • Vorschau: Angezeigt wird der Loginhalt als vorformatierter Text mit Scrollbereich.
  • Kuerzung: Bei grossen Dateien liest der Viewer die letzten rund 200 KB und setzt einen Kuerzungshinweis vor den Ausschnitt.
Die Vorschau ist fuer schnelle Fehleranalyse gedacht. Fuer zeitlich weit zurueckliegende Vorgaenge zuerst die passende Tagesdatei waehlen.

Maskierung sensibler Daten

Vor der Anzeige wird der Loginhalt maskiert. Dadurch bleiben typische Zugangsdaten und Tokens in der Backendansicht geschuetzt.

  • Authorization-Header: Bearer- und Basic-Werte werden ersetzt.
  • API-Schluessel: Header und Parameter mit API-Key-Bezug werden maskiert.
  • Tokens und Secrets: Access-Token, Refresh-Token, Client-Secrets, Webhook-Secrets, Private-Keys, Signaturen, Passwoerter und Codes werden ersetzt.
  • Cookies: Cookie- und Set-Cookie-Header werden maskiert.
  • JSON und Array-Ausgaben: Sensible Schluessel werden auch in strukturierten Ausgaben ersetzt.
Auch maskierte Logs koennen Bestell-, Versand- oder Empfaengerkontext enthalten. Logauszuege nur zweckgebunden weitergeben und vorher auf Personen- oder Auftragsbezug pruefen.

GLS-Vorgaenge im Log

GLS schreibt Protokolle fuer die wichtigsten Schnittstellenaktionen im Versandprozess.

  • Label erstellen: Beim Erstellen eines Labels wird der Versandauftrag an GLS gesendet. Der Logeintrag zeigt Requestdaten, Response-Header, HTTP-Code und die Rueckgabe von GLS.
  • Labelantwort: Bei erfolgreicher Antwort enthaelt die Rueckgabe unter anderem die Track-ID und die Druckdaten fuer das Label.
  • Stornierung: Beim Stornieren wird die Ticketnummer an GLS uebergeben. Der Logeintrag zeigt, ob GLS eine verwertbare Antwort geliefert hat.
  • Fehlerfall: Wenn GLS keine verwertbare Rueckgabe liefert, werden Headerinformationen fuer Fehler und Meldung zur weiteren Analyse genutzt.

Pruefung bei Fehlern

  1. Nach fehlgeschlagener Labelerstellung oder Stornierung die neueste GLS-Logdatei abrufen.
  2. Den Zeitpunkt des Vorgangs mit dem Logzeitstempel abgleichen.
  3. Request, HTTP-Code, Response-Header und Response-Inhalt zusammen betrachten.
  4. Bei Authentifizierungsfehlern GLS-Benutzername, Passwort, Contact-ID und API-Endpunkt auf der Einstellungsseite pruefen.
  5. Bei Storno-Problemen Ticketnummer und Status aus der Labeltabelle mit der GLS-Antwort vergleichen.
  6. Wenn kein Eintrag vorhanden ist, zuerst Modulstatus, Recht, Versandart und aktivierten GLS-Labeldruck pruefen.

War diese Seite hilfreich?

Hilf uns, das Handbuch weiter zu verbessern. Wenn etwas fehlt oder unverständlich ist, kannst Du direkt einen kurzen Kommentar senden.