← Cloudflare Workers / workers / observability

Metriky a analytika

V daném okamžiku máte k dispozici dva grafické zdroje informací o provozu vašich Workers: Workers metrics a Workers analytics na úrovni zóny.

Workers metrics vám pomáhají diagnostikovat problémy a pochopit zátěž vašich Workers tím, že zobrazují jejich výkon a využití. Pokud váš Worker běží na trase v rámci zóny nebo na několika zónách, Workers metrics ukážou, kolik provozu Worker zpracovává v jednotlivých zónách a kolik požadavků váš web dostává.

Analytika zóny ukazuje, kolik provozu zpracovávají všechny Workery přiřazené k dané zóně.

Workers metrics agregují data o požadavcích pro jednotlivý Worker (pokud váš Worker běží na více doménách a na *.workers.dev, metriky agregují požadavky napříč nimi). Metriky svého Workeru zobrazíte takto:

Existují dvě metriky, které vám pomohou pochopit stav vašeho Workeru v daném okamžiku: metriky úspěšnosti a chybovosti požadavků a stavy vyvolání.

První graf zobrazuje historický počet požadavků z runtime Workers rozdělený na úspěšné požadavky, požadavky s chybou a subrequesty.

• Celkem: Všechny příchozí požadavky zaznamenané Workerem. Požadavky blokované WAF ↗ nebo jiné bezpečnostní funkce se nezapočítají.
• Úspěch: Požadavky, které vrátily stav volání Success nebo Client Disconnected.
• Chyby: Požadavky, které vrátily stav volání Script Threw Exception, Exceeded Resources nebo Internal Error, naleznete v Invocation Statuses pro přehled zdrojů vašich chyb.

U časových rozsahů kratších než šest hodin může graf u posledních zobrazených minut ukazovat pokles v datech provozu požadavků. Neznamená to skutečný pokles provozu, ale mírné zpoždění při agregaci a doručování metrik.

Podpožadavky jsou požadavky vyvolané voláním fetch z Workeru. Dílčí požadavek (subrequest), který vyvolá neošetřenou chybu, se nezapočítá.

• Celkem: Všechny dílčí požadavky vyvolané voláním fetch z Workeru.
• V mezipaměti: Počet vrácených odpovědí z mezipaměti.
• Bez mezipaměti: Počet vrácených odpovědí mimo mezipaměť.

Reálný čas představuje dobu v milisekundách, která uplyne od zahájení volání Workeru do okamžiku, kdy runtime Workers určí, že už nemusí běžet žádný další JavaScript. Konkrétně graf wall time per execution měří dobu (wall time), po kterou zůstal kontext JavaScriptu otevřený, včetně času stráveného čekáním na I/O a času stráveného prováděním kódu ve vašem Workeru waitUntil() handler. Reálný čas není stejný jako čas, za který váš Worker odešle poslední bajt odpovědi zpět klientovi. Reálný čas může být vyšší, pokud úlohy uvnitř waitUntil() se stále vykonávají i po odeslání odpovědi, nebo může být nižší. Pokud se například vrací odpověď s velkým tělem, runtime Workers může v některých případech rozpoznat, že už není potřeba spouštět další JavaScript, a ukončí kontext JavaScriptu dříve, než všechny bajty projdou a budou odeslány.

Graf Wall Time per execution zobrazuje historická data o wall time rozdělená do příslušných kvantilů pomocí reservoir sampling ↗. Zjistěte více o interpretace kvantilů ↗.

Graf CPU Time per execution zobrazuje historická data o době využití CPU rozdělená do relevantních kvantilů pomocí reservoir sampling ↗. Zjistěte více o interpretace kvantilů ↗. V některých případech se může zdát, že vyšší kvantily překračují Limity času CPU bez vyvolání chyb volání díky mechanismu v runtime Workers, který umožňuje přenos CPU času u požadavků pod limitem CPU.

Graf Duration per request zobrazuje historická doba trvání na jedno vyvolání Workeru. Data jsou rozdělena do příslušných kvantilů, podobně jako u grafu CPU time. Další informace najdete v interpretace kvantilů ↗. Pochopení doby trvání ve vašem Workeru je užitečné zejména tehdy, když v samotném Workeru plánujete provádět náročnější výpočty.

Graf Memory usage ukazuje, kolik paměti V8 izolátu váš Worker využívá při každém vyvolání, rozdělené do percentilů P50, P90, P99 a P999 pomocí reservoir sampling ↗. Další informace najdete v Interpretace kvantilů ↗.

Workers běží ve V8 izoláty, každý s limit paměti 128 MB. Jeden izolát dokáže zpracovat mnoho souběžných požadavků a sdílí mezi nimi paměť. Metrika využití paměti ukazuje, kolik z této sdílené paměti je využito v okamžiku každého volání.

Značky nasazení v grafu vám umožňují propojit změny paměti s konkrétními nasazeními kódu, což usnadňuje zjištění, zda nová verze nezpůsobila regresi v paměti.

Pokud si všimnete, že využití paměti v čase postupně roste, může to znamenat únik paměti. Použijte profilování paměti pomocí DevTools lokálně a pořídit heap snapshots, abyste identifikovali konkrétní objekty způsobující vysokou spotřebu paměti.

Chcete-li zkontrolovat stavy volání:

Stavy vyvolání Workeru udávají, zda Worker běžel úspěšně, nebo zda se mu v runtime Workers nepodařilo vygenerovat odpověď. Stavy vyvolání se liší od Stavové kódy HTTP. V některých případech se volání Workeru zdaří, ale nevygeneruje úspěšný stav HTTP kvůli jiné chybě mimo runtime Workers. Některé stavy volání vedou k Kód chyby Workers je vrácena klientovi.

¹ Stav Překročené prostředky se může zobrazit, pokud Worker překročí limit runtime. Nejčastější příčinou je nadměrná spotřeba CPU času, ale může jít i o překročení doby spuštění nebo limitů free tier.

² Stav Interní chyba se může zobrazit, pokud runtime Workers nedokáže zpracovat požadavek kvůli internímu selhání v našem systému. Tyto chyby nezpůsobuje žádný problém v kódu Workeru ani překročení limitu zdrojů. Požadavky se stavem Interní chyba jsou vzácné, přesto se některé mohou objevit i při běžném provozu. Do využití pro fakturační účely se tyto požadavky nezapočítávají. Pokud zaznamenáte zvýšený výskyt požadavků se stavem Interní chyba, projděte si www.cloudflarestatus.com ↗.

Chcete-li výjimky dále prozkoumat, použijte wrangler tail.

Graf doby trvání požadavku ukazuje, jak dlouho trvalo Workeru odpovědět na požadavky, včetně provádění kódu a času stráveného čekáním na I/O operace. Graf doby trvání požadavku je aktuálně dostupný pouze v případě, že váš Worker má Smart Placement zapnuté.

Na rozdíl od doba provádění, které měří pouze dobu, po kterou je Worker aktivní, doba trvání požadavku se měří od okamžiku, kdy požadavek dorazí do datacentra, až do doručení odpovědi.

Data zobrazují dobu trvání požadavků se zapnutým Smart Placement v porovnání s požadavky, u nichž je Smart Placement vypnutý (ve výchozím nastavení je 1 % požadavků směrováno s vypnutým Smart Placement). Graf zobrazuje histogram, kde je na ose x doba trvání a na ose y procento požadavků spadajících do dané doby trvání.

Metriky Workeru lze zobrazit zpětně až tři měsíce, v maximálních přírůstcích po jednom týdnu.

Analytika zóny agreguje data o požadavcích za všechny Workery přiřazené k libovolné trasy definováno pro zónu.

Chcete-li zkontrolovat metriky zóny:

V dashboardu Cloudflare přejděte na Workers Analytics stránku vaší zóny.

Data zóny lze omezit na časový rozsah v rámci posledních 30 dnů. Dashboard obsahuje grafy a informace popsané níže.

Tento graf zobrazuje subpožadavky: požadavky vyvolané voláním fetch z Workeru, rozdělené podle stavu mezipaměti.

• Bez mezipaměti: Požadavky zodpovězené přímo vaším origin serverem nebo jinými servery odpovídajícími na subrequesty.
• V mezipaměti: Požadavky zodpovězené z Cloudflare cache ↗. Čím více obsahu Cloudflare ukládá do cache, tím rychleji se obsah doručuje a tím nižší je zátěž vašeho origin serveru.

Tento graf zobrazuje historické využití šířky pásma pro všechny Workers v zóně, rozdělené podle stavu mezipaměti.

Tento graf zobrazuje historické požadavky všech Workerů v zóně rozdělené podle stavového kódu HTTP.

Tento graf zobrazuje historická data pro všechny Workers v zóně, rozdělená na úspěšné požadavky, neúspěšné požadavky a dílčí požadavky. Tyto typy požadavků jsou kategorizovány podle stavového kódu HTTP, kde 200-úrovně požadavky jsou úspěšné a 400 na 500-úrovně požadavky selžou.

Metriky Workeru běží na GraphQL. Více o dotazování na naše datové sady se dozvíte v Návod: Dotazování metrik Workers pomocí GraphQL.

Výše popsané metriky poskytují přehled o výkonu Workeru a chování za běhu. Pro vlastní analytiku specifickou pro danou aplikaci použijte Workers Analytics Engine.

Analytics Engine je užitečný pro:

• Vlastní obchodní metriky - Sledujte události specifické pro vaši aplikaci, jako jsou registrace, nákupy nebo používání funkcí.
• Analytika pro jednotlivé zákazníky - Zaznamenávejte data s dimenzemi o vysoké kardinalitě, jako jsou ID zákazníků nebo klíče API.
• Fakturace podle využití - Počítejte volání API, výpočetní jednotky nebo jiné zpoplatněné události pro jednotlivé zákazníky.
• Sledování výkonu - Měřte doby odezvy, míry zásahů do cache nebo chybovost pomocí vlastních dimenzí.

Zápisy do Analytics Engine jsou neblokující a nepřidávají žádnou latenci vašemu Workeru. Data dotazujte pomocí SQL prostřednictvím Analytics Engine SQL API nebo ji vizualizovat v Grafana.

Viz Příklad Analytics Engine pro začátek.