Observability, biztonság, költségmodell

9.1A megfigyelhetőség rétegei — a CloudWatch-térkép

AWS-en a megfigyelhetőség egy központba folyt (CloudWatch Logs + Metrics + Alarms + X-Ray), amit te dróztoztál össze. A Workers-nél rétegek vannak, mindegyik a maga feladatára — így fordul a fejedben lévő térkép:

9.2Workers Logs a gyakorlatban

A bekapcsolás egy konfig-blokk — és mivel a 8. modul env-fegyelmét már ismered, rögtön környezetenként eltérő mintavétellel mutatom, ahogy élesben érdemes:

{
  "env": {
    "staging": {
      "observability": { "enabled": true, "head_sampling_rate": 1 }
    },
    "production": {
      "observability": {
        "enabled": true,
        "head_sampling_rate": 0.1,          // minden 10. kérés logja tárolódik
        "traces": { "enabled": true, "head_sampling_rate": 0.05 }
      }
    }
  }
}

A mintavétel head-based: kérés-szinten dől el, és ha egy kérés kiválasztódik, annak minden logsora megmarad — tehát összefüggő invocation-képet kapsz, nem véletlen sortöredékeket. A hibák tipikusan így is fennakadnak, mert a limit- és hiba-események (1102, kivételek) az invocation-státuszban mindig látszanak.

Strukturált logolás: a legjobb befektetésed

A Workers Logs a console.log-ba írt objektumokat mezőnként indexeli — vagyis ha JSON-t logolsz, a dashboard Query Builderében mezőkre szűrhetsz. A te multitenant SaaS-odban ez így néz ki:

// ne: console.log(`hiba a ${tenantId} tenantnál: ${err.message}`)
// hanem:
console.log({
  event: "invoice.create.failed",
  tenantId,
  orderId,
  error: err.message,
  durationMs: Date.now() - start,
});

Ezután a Query Builderben (vagy az API-n át) válaszolhatók a support-kérdések: „az acme tenant összes hibája tegnap óta", „melyik tenant generálja a legtöbb invoice.create.failed-et", „a p99 durationMs eseménytípusonként". Élő hibakereséshez pedig a tail:

npx wrangler tail --env production --status error          # csak a hibák, élőben
npx wrangler tail --env production --format json | jq '.logs'  # szkriptelhetően

Verzió-korreláció: a kanári műszerfala

A 8. modul kanári-folyamatának ez adja a szemét: a metrikák és logok versionönként bonthatók (a version metadata bindinggel a saját logjaidba is beírhatod a version ID-t). A kanári-emelés előtti kérdés tehát nem „nőtt-e a hibaarány?", hanem pontosan: „a v42 hibaaránya rosszabb-e, mint a v41-é?" — miközben mindkettő él. Az invocation-státuszok (pl. exceededCpu, exception) ugyanitt, versionre szűrve mutatják meg, ha az új kód CPU-limitet döntöget (2. modul).

9.3Traces: az X-Ray helyett, szabványosan

A Workers Traces OpenTelemetry-szabványú: bekapcsolod (fenti konfig), és a kérés útja — Worker → Hyperdrive-query → R2-hívás → subrequest — span-ekként áll össze a dashboardon. Ami a te szempontodból a lényeg: mivel OTel, zéró extra munkával exportálható a meglévő vagy leendő observability-stackedbe (Grafana Cloud, Honeycomb, Axiom), akár úgy is, hogy a Cloudflare-nél nem is tárolod (persist: false) — tehát nem záródsz be a platform sajáteszközeibe. Magas forgalomnál a trace-mintavételt lőd alacsonyra (1–5%), a logokét magasabbra.

9.4Analytics Engine: tenantonkénti metering — a rejtett gyöngyszem

Van egy kategória, amire se a log, se a platform-metrika nem való: a nagy kardinalitású termék-metrikák — nálad tipikusan a tenantonkénti fogyasztásmérés (usage-based billinghez, limitekhez, admin-dashboardhoz). CloudWatch custom metricsszel ez tenantonként×metrikánként fizetős és fájdalmas volt. Az Analytics Engine pontosan erre van: a Workerből egy sorral írsz egy adatpontot, és utána SQL-lel kérdezed le:

// írás a Workerből — nem blokkol, nem kell await
env.USAGE.writeDataPoint({
  blobs:   [tenantId, "api_call", endpoint],   // dimenziók (szöveg)
  doubles: [1, responseBytes],                 // mértékek (szám)
  indexes: [tenantId],                          // ezen lehet gyorsan szűrni
});

-- lekérdezés a SQL API-n át (pl. a havi számlázási cron-ból):
SELECT blob1 AS tenant, SUM(double1) AS calls, SUM(double2) AS bytes
FROM usage_dataset
WHERE timestamp > NOW() - INTERVAL '30' DAY
GROUP BY tenant

Az adatpontok mintavételezéssel skálázódnak (tehát óriási forgalomnál is olcsó marad), cserébe ez becslés-pontosságú aggregátum — számlázási alapnak bevált gyakorlat, fillérre pontos főkönyvnek nem való (azt D1-ben könyveled). A hármas felosztás tehát: Workers Logs = hibakeresés (7 nap), Analytics Engine = termék/üzleti metrikák (hónapok), D1 = tranzakcionális igazság.

9.5Biztonság: ami a platformból jön

Itt fordul a legnagyobbat a világ az AWS-hez képest: ami ott külön termék, külön számla és külön konfiguráció volt (Shield, WAF, API Gateway throttling, Cognito egy része), az itt a platform rétegei — a kérés már átesett rajtuk, mire a Workered meghívódik:

• DDoS-védelem — mindig aktív, konfiguráció és külön díj nélkül (az AWS Shield Advanced árcéduláját ismerve ez önmagában érv).
• WAF — a managed rulesets (OWASP-jellegű szabálykészletek) bekapcsolása pár kattintás a zónán; a custom rules-szal saját feltételeket írsz (ország, path, header, ASN…).
• Rate limiting rules — zóna-szinten, a Worker előtt: pl. „a /api/auth/login-ra IP-nként max 10 kérés/perc, fölötte block". Mikor ez, és mikor a 7. modul DO-rate-limitere? A zóna-szabály durva szemcséjű, infra-szintű védelem (brute force, scraping) — ingyen szűri a zajt a Worker előtt. A DO-limiter üzleti logika: tenant-plan-függő, pontos kvóták. Éles SaaS-ban mindkettő kell, más ellen védenek.
• Turnstile — a CAPTCHA-pótló widget (ingyenes): regisztráció, login, form-védelem, a reCAPTCHA adatvédelmi vitái nélkül.
• Cloudflare Access — „SSO-kapu bármi elé": ezzel véded a preview URL-eket (8. modul), a staging domaint és a saját admin/support felületedet (5b. modul!) — a Google/GitHub/OIDC loginon át nem jutó kérés el sem éri a Workert. Az AWS-en ehhez ALB + Cognito vagy VPN kellett.
• Secrets Store + a bindings-modell — a támadási felület oldaláról nézve: nincsenek hosszú életű AWS-kulcsok a CI-ban és a szerveren szétszórva; egy Worker csak ahhoz fér hozzá, ami be van kötve.

9.6A költségmodell — és egy végigszámolt példa

A Workers Paid $5/hó alapdíjból plusz fogyasztásból áll. A mentális modell minden komponensnél ugyanaz: bőséges included keret + lineáris túlfogyasztási ár, üresjárati díj nélkül. A fő tételek (nagyságrendek — az aktuális árlista a developers.cloudflare.com/workers/platform/pricing oldalon):

Példaszámítás: egy közepes SaaS hónapja

Tegyük fel: 20 M dinamikus kérés/hó (API + SSR), átlag 5 CPU-ms/kérés (emlékezz a 2. modul idővonalára: a DB-várakozás nem számít!), plusz a statikus forgalom (ingyen):

Alapdíj:                                          $5.00
Kérések:  20M − 10M included = 10M × $0.30/M  =   $3.00
CPU:      20M × 5ms = 100M ms − 30M included
          = 70M ms × $0.02/M ms               =   $1.40
                                              ─────────
Workers compute összesen:                        ~$9.40/hó

Ehhez jön a tárolás (R2/D1/KV — jellemzően dollárok, nem tízdollárok ebben a méretben), és ennyi. Amit érdemes a mostani számláddal szembeállítani: a Beanstalk EC2-instance-ok (éjjel is), az ALB, a NAT gateway, a CloudFront-forgalom és az S3-egress — ezek a tételek itt vagy nem léteznek, vagy nullák. A tipikus tapasztalat ebben a méretosztályban: nagyságrendi csökkenés a compute+CDN+egress vonalon; ami marad érdemi tételnek, az az Aurora (amíg meg nem válaszolod az 5. modul kérdését).

9.7Error tracking: kell-e külön eszköz a Nuxt server-kód mellé?

Jogos kérdés, hogy az eddigiek mellett kell-e még Sentry/Honeybadger-féle eszköz. A válasz két részre bomlik, mert két különböző munkáról van szó:

• Log-gyűjtő / shipper (pino transport, CloudWatch agent): NEM kell. A Workers Logs pont ezt a réteget adja: minden console.log automatikusan begyűjtődik és indexelődik — nincs mit „kiszállítani", és nincs is hosszú életű processz, amiben egy log-buffer élhetne. A pinót megtarthatod formázónak, de transport nem kell alá.
• Error tracker: IGEN, ezt érdemes tartani. A Workers Logs log-rendszer, nem hibakövető. Ami hiányzik belőle: a hibák csoportosítása issue-kká (ezer előfordulás = egy hibajegy), a dedup, a „resolved → regression" életciklus, az azonnali értesítés új hibatípusnál, a release-hez kötés és a source-map-elt stack trace user-kontextussal.

Mi illik a Workers-runtime-hoz?

A Sentry-protokoll de facto szabvány lett: a legtöbb alternatíva Sentry-SDK-kompatibilis, tehát a kódba a @sentry/cloudflare SDK megy (ez kifejezetten a Workers-runtime-ra készült, és a Nitro server-oldalon is működik), és csak a DSN-t irányítod máshova. A kódod így nem köteleződik el egyetlen szolgáltató mellett sem. A source map feltöltést kapcsold be, különben minifikált kódot látsz a trace-ekben:

{ "upload_source_maps": true }

A Node-alapú SDK-k (pl. a Honeybadger klasszikus kliense) Node API-kra támaszkodhatnak — ezek vagy nem, vagy csak vékony saját wrapperrel mennek Workersből (fetch-hívás a reporting API-ra, ctx.waitUntil()-lel, hogy ne késleltesse a választ).

A végállapot tehát: Workers Logs (debug) + Analytics Engine (termék-metrikák) a platformról, plusz egy error tracker a hibák életciklusára. Ez lefedi, amit ma CloudWatch + Honeybadger párossal kapsz — a verzió-korrelált metrikákkal (9.2) még többet is.

9.8Riasztások — az őszinte kép

A beépített notifications rendszer értesít a fontos eseményekről (Workers-hibaküszöbök, usage/billing küszöbök, SSL-lejárat stb. — email/webhook/PagerDuty). Ez a mindennapi „szólj, ha baj van" szintet lefedi. Amit őszintén ki kell mondani: a CloudWatch Alarms-féle, tetszőleges metrikára írt, összetett riasztási logika beépítve nincs ilyen mélységben. A bevált minta emiatt: az OTel-exporton (9.3) a logok/trace-ek a meglévő stackedbe (Grafana, Honeycomb…) folynak, és a riasztási agy ott él — a Cloudflare a jel, a te eszközöd a sziréna. Kis csapatnak addig is sokat ad egy 5 perces cron-Worker, ami a Query Builder API-n lekérdezi az elmúlt 5 perc hibaszámát, és küszöb fölött Slackre ír (7. modul mintáival ez fél óra munka).

9.9Ellenőrizd magad