Dílčí požadavky Workeru

Proč jsou pole origin u počátečního požadavku prázdná, když Worker provede dílčí požadavek?

Když požadavek dorazí do zóny s Workerem, počáteční záznam protokolu HTTP požadavku představuje požadavek koncového uživatele na Worker. Pokud tento Worker následně provede fetch() požadavek na váš origin server zapíše Cloudflare druhý záznam protokolu HTTP požadavku pro tento dílčí požadavek Workeru.

Protože počáteční záznam protokolu pokrývá pouze požadavek od klienta k Workeru, OriginResponseStatus je 0 a OriginIP je u tohoto záznamu prázdné. Tato pole jsou vyplněna až u druhého záznamu protokolu, který představuje fetch z Workeru na origin server. Více o tom, co OriginResponseStatus=0 znamená v různých kontextech, viz Odpovědi 504 s origin status 0 v Logpush.

Co představují oba záznamy protokolu

Položka protokolu	Typicky `ClientRequestSource` hodnota	Co představuje	Pole originu
Počáteční požadavek	`eyeball`	Požadavek koncového uživatele na Worker	`OriginResponseStatus` je `0`, `OriginIP` je prázdné
Dílčí požadavek Workeru	`edgeWorkerFetch`	Worker `fetch()` požadavek na origin server	Určuje, kdy dojde ke kontaktování origin serveru

Viz Pole ClientRequestSource pro úplný seznam možných ClientRequestSource hodnoty.

Jak jsou tyto dva záznamy propojeny

Každý záznam v logu má vlastní RayID. Podřízený požadavek Workeru (subrequest) také obsahuje ParentRayID, což je RayID požadavku, který jej vyvolal: jeho bezprostředního předchůdce.

Pole	Počáteční požadavek	Dílčí požadavek Workeru
`RayID`	Jedinečné ID požadavku pro požadavek koncového uživatele	Jedinečné ID požadavku pro podpožadavek
`ParentRayID`	Vyprázdnit	`RayID` požadavku, který jej vyvolal

Chcete-li propojit oba záznamy:

Najděte původní požadavek a poznamenejte si jeho RayID.
Vyhledejte záznamy protokolu, kde ParentRayID se rovná tomu, že RayID.
Zkontrolujte odpovídající záznam protokolu dílčího požadavku pro OriginIP, OriginResponseStatus, a další pole týkající se origin serveru.

Jeden požadavek koncového uživatele může vygenerovat více záznamů protokolu podřízených požadavků Workeru. Každý podřízený požadavek má vlastní RayID, přičemž každý z těchto záznamů protokolu přebírá od vyvolávajícího požadavku RayID jako svou ParentRayID.

ParentRayID je jednoúrovňové: odkazuje na nejbližšího rodiče, nikoli na původní požadavek koncového uživatele. Při nastavení s jedním Workerem na tom nezáleží, protože rodičem je právě požadavek koncového uživatele. Pokud jsou Workery řetězené (například Worker A volá Workera B, který volá origin server), záznam podpožadavku Workeru B obsahuje RayID jako svou ParentRayID, nikoli koncového uživatele. Chcete-li vysledovat celý řetězec zpět až k požadavku koncového uživatele, sledujte jednotlivé ParentRayID vždy jednu úroveň.

Pomocí počátečního požadavku spolu s odpovídajícími záznamy podpožadavků můžete zrekonstruovat celou cestu požadavku od klienta přes Worker až po origin server.

Příklad

# Initial request
ClientRequestSource: eyeball
RayID: 7b52f2c4f9f64c1a
ParentRayID:
OriginResponseStatus: 0

# Worker subrequest
ClientRequestSource: edgeWorkerFetch
RayID: 7b52f2c4f9f64c1b
ParentRayID: 7b52f2c4f9f64c1a
OriginResponseStatus: 200
OriginIP: 192.0.2.10

Kdy druhý záznam protokolu chybí

Pokud Worker neprovede fetch() požadavek na origin server, neexistuje žádný záznam protokolu Worker-origin, se kterým by se dal spárovat. Worker může například vrátit odpověď přímo, aniž by kontaktoval origin server.

Doporučená pole pro zahrnutí do Logpush

Chcete-li snadněji prozkoumat dílčí požadavky Worker, zahrňte do protokolů HTTP požadavků tato pole:

RayID
ParentRayID
ClientRequestSource
OriginIP
OriginResponseStatus