Protokoly jsou potřebné k odstraňování problémů s dokumentem, ale není třeba protokolovat celý text.

Protokoly jsou nutné k odstraňování problémů s překlady dokumentů, ale protokoly nemusí obsahovat úplný text smlouvy, identifikační číslo nebo token stahování. Tento článek vysvětluje, jak zajistit, aby protokol odpověděl „která úloha v kterém kroku selhala a proč"bez kopírování dokumentů zákazníka do protokolu.

Vhodnými čtenáři jsou vývojáři a pracovníci provozu a údržby, kteří jsou zodpovědní za služby překladu dokumentů, dokování překladových rozhraní nebo údržbu protokolů na pozadí. Po přečtení můžete navrhnout sadu polí whitelistu, ověřit, že protokol nezobrazuje původní text, a nastavit dobu uchování a rozsah přístupu pro odstraňování problémů.

Příklady používají syntetické vzorky k demonstraci metod zpracování a kód byl zkontrolován v izolovaném prostředí, ale to nepředstavuje záruku všech skutečných souborů nebo výkonu produktu. Před zpracováním důležitých dokumentů si prosím uschovejte originály a zkontrolujte je podle níže uvedených hranic a položek přijetí.

Co by mělo být zaznamenáno v protokolu řešení problémů? Závěr jednou větou

Protokol zaznamenává pouze povolená pole, jako je ID úlohy, fáze, kategorie chyb a spotřeba času, ale nezaznamenává obsah dokumentu a pověření.

Začněte s poli, která mohou zaznamenávat

Černá listina může snadno minout nová citlivá pole. Obezřetnějším přístupem je vydávat pouze navržená pole, například:

• ID interní úlohy
• Fáze zpracování
• kategorie chyb
• časově náročné

Níže uvedený příklad syntézy používá projekci whitelistu, takže do protokolu není zapsán celý text a tokeny ve vstupu.

Ověřovací protokol nezobrazil původní text.

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)

Příklad pouze upravuje samojmenovaný demo logger. Nedoporučuje se vymazat globální obslužnou rutinu aplikace v obchodní knihovně. U hodnot polí je stále třeba ověřit délku a typ. Pokud do error_code nacpete celý text uživatele, samotný název whitelistu vás nezachrání.

ID přidružení namísto citlivého obsahu

V následující tabulce jsou uvedeny běžné požadavky při odstraňování problémů a také doporučené a nedoporučené záznamy.

Doba udržení je stejně důležitá jako rozsah přístupu

I když záznam neobsahuje žádný hlavní text, kombinace času úkolu, jazyka a velikosti souboru může odhalit obchodní informace. Záznamy by měly být doprovázeny kontrolou přístupu, obdobími uchovávání a procesy mazání.

Během řešení problémů dočasně zvyšte úroveň logu, upřesněte, kdy obnovit provoz, a vyhněte se příliš dlouhému zůstávání ladění v produkčním prostředí.

Překladová integrace také poskytuje jasné a střídmé záznamy

Při integraci s OmniDoc (produktový záznam) se zaznamenává pouze asociace mezi lokálními a vzdálenými úkoly; soubory nahrané uživateli by neměly být kopírovány do logů pro snadnější řešení problémů.

Dobrá zpráva o problému dokáže vysvětlit fázi selhání a podmínky opakování, přičemž zajistí, že klientské dokumenty budou probíhat pouze v rámci autorizovaných procesních cest.

Zdroje: Python logging.

📊 Srovnání jádra

🎯 Která metoda ti vyhovuje?

Pokud potřebujete najít překladatelský úkol

Zaznamenává náhodné interní ID úloh a fáze selhání, aniž by zaznamenával celé uživatelské jméno souboru nebo cestu.

Pokud chcete řešit chyby rozhraní v upstream

Zaznamenávejte standardizované kategorie chyb, ale nezaznamenávejte kompletní požadavky s autentizačními hlavičkami.

Pokud řešíte online problémy

Dočasně zvyšte hladinu klád a ihned po inspekci obnovte.

Pokud chceš navrhovat logaritmová pole

Upřednostněte whitelisting a ověřte délku a typ hodnot polí.

❓ Často kladené otázky (FAQ)

1. Může log zaznamenat celé uživatelské jméno souboru?

Nedoporučuji. Plné jméno souboru a cesta se nedoporučují pro nahrávání; můžete použít náhodné interní ID úloh k přiřazení.

2. Proč se nedoporučuje používat černou listinu pro filtrování citlivých polí?

Černé listy často přehlížejí nově vzniklá citlivá pole, zatímco bílé listy vynechávají pouze navržená pole, což je činí spolehlivějšími.

3. Potřebujete jen spravovat čas úkolu a velikost souboru?

Ano. Tyto informace mohou také odhalit obchodní detaily a záznamy by měly být doplněny o kontrolu přístupu, doby uchovávání a procesy mazání.

4. Lze debug logy během řešení problémů držet otevřené dlouhou dobu?

Nedoporučuji. Po dočasném vylepšení úrovně logu je důležité specifikovat, kdy ladění obnovit, aby ladění nebylo v produkčním prostředí příliš dlouho ponecháno.

5. Můžete vymazávat globální handler z obchodní databáze?

Nedoporučuji. Příklad upravuje pouze demo logger, který jste si sami pojmenovali; business knihovna by neměla být vyprázdněna z aplikace globálního handleru.

📝 Shrnutí

Při řešení problémů s překladem by měl log odpovídat na úkol, fázi a důvod, místo aby ukládal obsah dokumentu. Používání bílých seznamů, kontrolovaných citací a jasných období uchovávání je nezbytné pro vyvážení efektivity řešení problémů s bezpečností dokumentů.

Zkušenost nyní: Nahrajte svůj dokument a začněte s překladem, přičemž zachováte původní formátování