Observability vs monitoring
Kapcsolódó szolgáltatás Weboldal és webshop
MEGHATÁROZÁS
A monitoring előre definiált kérdésekre ad választ: él-e a szerver, megy-e a CPU 80 fölé, a checkout endpoint p95 latency-je 500 ms alatt van-e. Riasztásokat ad, amikor egy ismert metrika kilépett a sávból. Az observability ennek a fordítottja: olyan adat-rétegeket gyűjt (három pillér · metrics, logs, traces, plus events és profiles), amik alapján utólag, a forráskód módosítása nélkül is meg tudjuk válaszolni az eddig fel sem tett kérdéseket. Tehát: monitoring azt mondja, hogy valami baj van, observability azt, hogy konkrétan ennek a checkout-failure-nek miért volt 7 hop a trace-ében és melyik downstream szolgáltatásnál állt meg. Gyakorlati lefordítás: Prometheus plus Grafana monitoring, OpenTelemetry plus Tempo plus Loki plus Jaeger observability. 2026-ban az OTel a vendor-semleges default, a kereskedelmi backend (Datadog, Honeycomb, New Relic) ezen ül.
- SSR (Server-Side Rendering)→
A HTML-t a szerver rendereli kérésre, minden felhasználónak frissen. Dinamikus tartalomra (dashboard) ideális, de lassabb, mint az SSG.
- SSG (Static Site Generation)→
Az oldalak build-időben készülnek el HTML-ként, és egy CDN szolgálja ki őket. Szinte nulla TTFB. A DField saját oldala 111+ oldallal fut így.
- ISR (Incremental Static Regeneration)→
SSG + időzített regeneráció: a HTML statikus, de megadott intervallumban újragenerálódik. Blog-cikkekhez ideális · frissesség CDN-sebességgel.
- Edge rendering→
A kód a felhasználóhoz legközelebbi CDN-pontban fut (Cloudflare Workers, Vercel Edge). Dinamikus válasz ~10–50 ms TTFB-vel.
- RSC (React Server Components)→
React-komponensek, amik kizárólag szerveren futnak, és nem kerülnek át a böngészőbe. Eredménye kevesebb kliens-oldali JS és gyorsabb hydration.
- LCP (Largest Contentful Paint)→
A legnagyobb látható elem megjelenésének ideje. Google Core Web Vitals zöld küszöbe 2.5s alatt · mi jellemzően <1s alá lőjük a landing oldalakat.