OmniDocZur Behebung von Dokumentfehlern sind Protokolle erforderlich, es ist jedoch nicht erforderlich, den vollständigen Text zu protokollieren.
Protokolle sind erforderlich, um Übersetzungsfehler zu lokalisieren, es ist jedoch nicht erforderlich, den gesamten Vertrag, die ID-Nummer oder den Download-Token auszudrucken. Das Protokoll sollte antworten, „welche Aufgabe, bei welchem Schritt und warum sie fehlgeschlagen ist“, anstatt zu einer zweiten Dokumentbibliothek ohne Berechtigungsverwaltung zu werden.
– Es wird empfohlen, Whitelist-Felder zu verwenden und nur bestimmte Felder wie interne Aufgaben-ID, Phase, Fehlerkategorie und Zeitverbrauch auszugeben.
- Die Blacklist übersieht leicht neue sensible Felder und die Whitelist-Projektion ist zuverlässiger.
- Feldwerte müssen noch auf Länge und Typ überprüft werden, sonst wird der vollständige Text in das falsche Kategoriefeld gestopft und von Whitelist-Namen nicht gespeichert.
- Protokolle müssen mit Zugriffskontrolle, Aufbewahrungsfrist und Löschvorgang ausgestattet sein und der Protokollstand sollte rechtzeitig nach der Fehlerbehebung wiederhergestellt werden.
Protokolle sind erforderlich, um Fehler bei der Dokumentübersetzung zu beheben. Die Protokolle müssen jedoch nicht den vollständigen Vertragstext, die ID-Nummer oder das Download-Token enthalten. In diesem Artikel wird erläutert, wie Sie im Protokoll die Antwort „Welche Aufgabe ist bei welchem Schritt fehlgeschlagen und warum"erstellen können, ohne Kundendokumente in das Protokoll zu kopieren.
Geeignete Leser sind Entwickler sowie Betriebs- und Wartungspersonal, die für Dokumentübersetzungsdienste, das Andocken von Übersetzungsschnittstellen oder die Pflege von Hintergrundprotokollen verantwortlich sind. Nach dem Lesen können Sie eine Reihe von Whitelist-Feldern entwerfen, überprüfen, ob das Protokoll nicht den Originaltext anzeigt, und den Aufbewahrungszeitraum und den Zugriffsbereich für die Fehlerbehebung festlegen.
Die Beispiele verwenden synthetische Beispiele, um Verarbeitungsmethoden zu demonstrieren, und der Code wurde in einer isolierten Umgebung überprüft. Dies stellt jedoch keine Garantie für alle echten Dateien oder die Produktleistung dar. Bevor Sie wichtige Dokumente bearbeiten, bewahren Sie bitte die Originale auf und überprüfen Sie sie anhand der unten aufgeführten Grenzen und Annahmepunkte.
Was sollte im Fehlerbehebungsprotokoll aufgezeichnet werden? Fazit in einem Satz
Das Protokoll zeichnet nur zulässige Felder wie Aufgaben-ID, Phase, Fehlerkategorie und Zeitverbrauch auf, nicht jedoch Dokumentinhalte und Anmeldeinformationen.
| Ihre Situation | Empfohlene Praktiken | Grund |
|---|---|---|
| Sie müssen wissen, welche Aufgabe fehlgeschlagen ist | Protokollierung einer zufälligen internen Aufgaben-ID | Möglichkeit, Probleme zu lokalisieren, ohne Benutzerdateinamen oder -pfade preiszugeben |
| Es muss ermittelt werden, in welchem Stadium sich die Karte befindet | Notieren Sie den Künstlernamen und die benötigte Zeit | Es sind nicht jeder Quelltext und jede Übersetzung erforderlich |
| Der Antrag wurde vom Upstream abgelehnt | Protokollieren Sie normalisierte Fehlerkategorien | Der Inhalt einer erstklassigen vollständigen Authentifizierungsanfrage sollte nicht in das Protokoll eingetragen werden |
| Zur Fehlerbehebung muss auf das Original zurückgegriffen werden | Verwendung von Referenzen innerhalb eines kontrollierten Systems | Bei Links, die dauerhaft öffentlich heruntergeladen werden können, besteht die Gefahr, dass sie durchsickern |
Beginnen Sie mit den Feldern, die aufgezeichnet werden dürfen
Die Blacklist kann leicht neue sensible Felder übersehen. Ein umsichtigerer Ansatz besteht darin, nur die entworfenen Felder auszugeben, zum Beispiel:
- Interne Aufgaben-ID
- Verarbeitungsphase
- Fehlerkategorie
- zeitaufwändig
Das folgende Synthesebeispiel verwendet eine Whitelist-Projektion, sodass der vollständige Text und die Token in der Eingabe nicht in das Protokoll eingegeben werden.
Das Verifizierungsprotokoll hat den Originaltext nicht angezeigt.
import io
import json
import logging
ALLOWED = ("job_id", "stage", "error_code", "elapsed_ms")
def log_record(data):
return {key: data[key] for key in ALLOWED if key in data}
stream = io.StringIO()
logger = logging.getLogger("synthetic-document-job")
logger.handlers.clear()
logger.propagate = False
logger.setLevel(logging.INFO)
handler = logging.StreamHandler(stream)
logger.addHandler(handler)
event = {"job_id": "demo-12", "stage": "parse", "error_code": "BAD_CONTAINER",
"elapsed_ms": 42, "document_text": "synthetic confidential clause",
"access_token": "synthetic-secret"}
logger.info(json.dumps(log_record(event), sort_keys=True))
logged = json.loads(stream.getvalue())
assert logged["error_code"] == "BAD_CONTAINER"
assert "document_text" not in logged
assert "synthetic-secret" not in stream.getvalue()
assert set(logged) <= set(ALLOWED)
logger.removeHandler(handler)Das Beispiel ändert nur den selbst benannten Demo-Logger. Es wird nicht empfohlen, den globalen Anwendungshandler in der Geschäftsbibliothek zu löschen. Feldwerte müssen noch auf Länge und Typ überprüft werden. Wenn Sie den vollständigen Text des Benutzers in error_code stopfen, wird Sie der Whitelist-Name allein nicht retten.
Assoziations-ID anstelle von sensiblen Inhalten
In der folgenden Tabelle sind allgemeine Anforderungen bei der Fehlerbehebung sowie empfohlene und nicht empfohlene Datensätze aufgeführt.
| Zu untersuchende Probleme | Empfohlene Datensätze | Aufnahme nicht empfohlen |
|---|---|---|
| Welche Aufgabe ist fehlgeschlagen | Zufällige interne Aufgaben-ID | Der vollständige Dateiname und der Pfad des Benutzers |
| Welche Stufe braucht Zeit | Phasen und zeitaufwändige Phasen | Jeder Absatz mit Quelltext und Übersetzung |
| Warum weigert sich Upstream? | Standardisierung von Fehlerkategorien | Eine vollständige Anfrage mit einem Authentifizierungsheader |
| Wie man das Original findet | Referenzen innerhalb des kontrollierten Systems | Ein dauerhaft verfügbarer Link zum öffentlichen Download |
Die Aufbewahrungsdauer ist genauso wichtig wie der Umfang des Zugangs
Selbst wenn das Protokoll keinen Text enthält, kann die Kombination aus Aufgabenzeit, Sprache und Dateigröße Geschäftsinformationen offenbaren. Protokolle sollten von Zugriffskontrollen, Aufbewahrungszeiten und Löschverfahren begleitet werden.
Während der Fehlersuche erhöhen Sie vorübergehend die Log-Ebene, klären Sie, wann die Arbeiten wieder aufgenommen werden sollen, und vermeiden Sie, dass der Debugging-Modus zu lange in der Produktionsumgebung bleibt.
Die Übersetzungsintegration liefert zudem klare und zurückhaltende Logs
Bei der Integration mit OmniDoc (Produkteinführung) wird nur die Verbindung zwischen lokalen und entfernten Aufgaben aufgezeichnet; von Benutzern hochgeladene Dateien sollten zur einfacheren Fehlersuche nicht in Logs kopiert werden.
Ein guter Problembericht kann die Ausfallphase und die Wiederholungsbedingungen erklären und gleichzeitig sicherstellen, dass Kundendokumente nur innerhalb autorisierter Verarbeitungspfade fließen.
Quellen: Python logging.
📊 Kernvergleich
| Methode | Vorteile | Risiko |
|---|---|---|
| Schwarze Liste | Die Schreibmethode ist unkompliziert und leicht zu erlernen | Empfindliche Felder, die leicht erscheinen, werden übersehen |
| Whitelist | Nur die gestalteten Felder werden ausgegeben, mit klaren Grenzen | Es ist notwendig, Felder im Voraus zu planen und die Länge sowie den Typ der Feldwerte zu überprüfen |
🎯 Welche Methode passt zu dir?
Wenn du eine Übersetzungsaufgabe finden musst
Erfasst zufällige interne Aufgaben-IDs und Ausfallphasen, ohne den vollständigen Dateinamen oder Pfad des Benutzers aufzuzeichnen.
Wenn du Upstream-Interface-Fehler behandeln möchtest
Erfassen Sie standardisierte Fehlerkategorien, aber vollständige Anfragen werden nicht mit Authentifizierungsheadern erfasst.
Wenn Sie Online-Probleme beheben
Erhöhen Sie vorübergehend die Log-Level und stellen Sie sie sofort nach der Inspektion wieder her.
Wenn du Logfelder entwerfen willst
Priorisieren Sie die Whitelist und überprüfen Sie die Länge und Art der Feldwerte.
❓ Häufig gestellte Fragen (FAQ)
1. Kann das Protokoll den vollständigen Dateinamen des Nutzers aufzeichnen?
Nicht zu empfehlen. Der vollständige Dateiname und der Pfad werden für die Aufnahme nicht empfohlen; Sie können stattdessen zufällige interne Task-IDs verwenden, um zuzuordnen.
2. Warum wird es nicht empfohlen, eine schwarze Liste zum Filtern sensibler Felder zu verwenden?
Blacklists übersehen meist neu entstandene sensible Felder, während Whitelists nur entworfene Felder ausgeben und so zuverlässiger sind.
3. Musst du nur Aufgabenzeit und Dateigröße verwalten?
Ja. Zusammen können diese Informationen auch Geschäftsdetails offenbaren, und die Protokolle sollten von Zugriffskontrollen, Aufbewahrungszeiten und Löschverfahren begleitet werden.
4. Können Debug-Logs während der Fehlersuche lange offen gehalten werden?
Nicht zu empfehlen. Nach einem vorübergehenden Upgrade des Log-Levels ist es wichtig anzugeben, wann der Debugging-Modus wieder aufgenommen werden soll, um zu vermeiden, dass der Debugging-Modus zu lange in der Produktionsumgebung bleibt.
5. Kannst du den globalen Handler aus der Geschäftsdatenbank löschen?
Nicht zu empfehlen. Das Beispiel ändert nur den Demo-Logger, den Sie selbst benannt haben; die Business-Bibliothek sollte nicht von der Global Handler-Anwendung geleert werden.
📝 Zusammenfassung
Bei der Fehlersuche bei Übersetzungsfehlern sollte das Protokoll die Aufgabe, Phase und Begründung beantworten, anstatt den Dokumentinhalt zu speichern. Die Verwendung von Whitelist-Feldern, kontrollierten Zitaten und klaren Aufbewahrungszeiten ist entscheidend, um Effizienz bei der Fehlersuche mit Dokumentensicherheit in Einklang zu bringen.
