Observabilnost web aplikacija: praktični vodič za logove, metrike i tracing za React i Next.js

# Što ćete izgraditi u ovom vodiču#

Ovaj vodič je praktičan nacrt za observabilnost web aplikacija u modernom React i Next.js stacku. Cilj nije „prikupiti više podataka”, nego skratiti vrijeme do detekcije i vrijeme do rješenja stvarnih produkcijskih problema.

Postavit ćete end-to-end pristup koji pokriva:

• Praćenje grešaka za frontend i server-side kvarove
• Nadzor performansi za Web Vitals i backend latenciju
• Strukturirane logove koje možete stvarno pretraživati tijekom incidenta
• Tracing koji povezuje sporo učitavanje stranice sa sporim upitom prema bazi
• Nadzorne ploče i alerte koji hvataju incidente do kojih je korisnicima stalo

Dobit ćete i preporučeni stack, fazni plan instrumentacije te primjere koje možete copy-pasteati.

# Zašto je observabilnost web aplikacija važna za React i Next.js#

React i Next.js aplikacije otkazuju na načine na koje tradicionalne server aplikacije nisu. Jedno „učitavanje stranice” obuhvaća renderiranje u pregledniku, API pozive, server-side rendering, edge caching, third-party skripte i podatkovne spremnike.

Bez observabilnosti timovi upadaju u skupe obrasce:

• Prijave bugova postaju pogađanje jer ne možete reproducirati stanje korisnika, rutu ili mrežne uvjete.
• Regresije performansi prolaze neprimijećeno, zatim padnu konverzije i vidite to tek u revenue analitici danima kasnije.
• Incidenti traju dulje jer ne možete povezati „korisnici vide prazan ekran” s „SSR greške su skočile” i „p95 latencija baze se udvostručila”.

Industrijski podaci dosljedno pokazuju cijenu loše detekcije: IBM-ova često citirana procjena stavlja prosječni trošak data breach-a na 4,45 milijuna USD, a detekcija i eskalacija čine najveći dio troškova životnog ciklusa. Observabilnost nije samo ops tema; to je i sigurnosna te kontrola rizika. Uparite ovo sa svojom sigurnosnom bazom iz Web Application Security Checklist.

Performanse su jednako kritične za poslovanje. Googleovo istraživanje Web Vitalsa i ekosustavni benchmarkovi više puta pokazuju da poboljšanja u LCP-u i INP-u koreliraju s boljim angažmanom i konverzijom. Ako vam je brzina važna, kombinirajte ovaj vodič s Website Performance Optimization.

# Observability 101: logovi, metrike, traceovi i što svaki rješava#

Trebate tri stupa jer svaki odgovara na drugo pitanje:

Praktično pravilo: metrike detektiraju, traceovi objašnjavaju, logovi potvrđuju.

🎯 Ključna poruka: Promatrajte observabilnost kao alat za workflow incidenta, a ne kao projekt prikupljanja podataka. Instrumentirajte ono što pomaže detektirati i objasniti utjecaj na korisnika.

# Preporučeni observability stack za Next.js i React#

Ne postoji jedan savršen stack, ali želite alate koji mogu korelirati signale i podržati i browser i server runtime.

Pragmatičan, široko prihvaćen stack#

Ako želite najniži operativni overhead za mali tim, suite jednog vendora može smanjiti integracijske probleme. Ako želite maksimalnu prenosivost i kontrolu, standardizirajte na OpenTelemetry i odaberite best-of-breed backende.

Što mi tipično preporučujemo u Samioda#

• Sentry za praćenje grešaka i vidljivost performansi na frontendu
• OpenTelemetry za traceove i server metrike
• Grafana za nadzorne ploče i alert pravila
• Strukturirani JSON logovi usmjereni u Loki ili managed log platformu

Ovo daje brz time-to-value uz zadržavanje prenosive core instrumentacije.

ℹ️ Napomena: Za Next.js na Vercelu možda ćete morati uskladiti logiranje i tracing pristup sa serverless ograničenjima. I dalje možete pouzdano raditi strukturirane logove i Sentry te dodati OpenTelemetry gdje je podrška runtimea dostupna.

# Redoslijed instrumentacije: što prvo dodati za brzi ROI#

Većina timova pogriješi pokušavajući instrumentirati sve u prvom tjednu. Umjesto toga instrumentirajte ovim redom:

1. 1
   Praćenje grešaka s release i commit metapodacima
2. 2
   Frontend performanse (Web Vitals i route transitions)
3. 3
   Server performanse za vaše kritične API i SSR rute
4. 4
   Strukturirani logovi s korelacijom po requestu
5. 5
   Distribuirani tracing kroz servise i podatkovne spremnike
6. 6
   SLO temeljene nadzorne ploče i akcijski alerti

Ovaj redoslijed prati učestalost incidenata. U tipičnim produkcijskim aplikacijama najčešći „stop the line” događaji su neuhvaćene iznimke, pokvareni deployi i jedna spora ovisnost koja uzrokuje globalnu sporost.

💡 Savjet: Definirajte svoja top 3 korisnička putovanja prije instrumentacije. Primjeri: registracija, checkout, pretraga. Ako to ne možete mjeriti, slijepi ste čak i uz savršene infrastrukturne metrike.

# Korak 1: Praćenje grešaka za React i Next.js#

Praćenje grešaka treba odgovoriti: što je puklo, kod koliko korisnika, nakon kojeg releasea i kako to reproducirati.

Postavite Sentry s releaseovima i source mapovima#

Ključne best practice točke:

• Uploadajte source mapove u CI-u kako bi stack traceovi mapirali na pravi kod
• Tagirajte događaje s release i environment
• Pažljivo prikupljajte korisničke identifikatore kako biste poštovali privatnost i compliance
• Pratite deploye kako biste mogli korelirati spikeove s releaseovima

Minimalni primjer inicijalizacije Sentryja na klijentu:

// sentry.client.config.js
import * as Sentry from "@sentry/nextjs";
 
Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NEXT_PUBLIC_APP_ENV,
  release: process.env.NEXT_PUBLIC_APP_RELEASE,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.01,
  replaysOnErrorSampleRate: 0.1,
});

U početku držite sampleanje konzervativno. Kasnije povećajte za specifične rute.

Što hvatati kako bi greške bile akcijske#

Hvatajte kontekst koji omogućuje reprodukciju problema:

⚠️ Upozorenje: Nemojte dodavati sirova request tijela ili tokene u error eventove. To je česta privatnosna i sigurnosna bomba koja samo čeka da eksplodira. Izbacite osjetljiva polja i koristite allowliste.

Postavite alertanje za spikeove grešaka i nove issueove#

Konfigurirajte alerte za:

• Novi issue uveden u zadnjem releaseu
• Stopu grešaka iznad praga, npr. errors per minute veće od vaše baseline vrijednosti za 3 puta
• Crash-free sessions ispod cilja, npr. manje od 99,5 posto za consumer aplikacije ili više za B2B SaaS

Pazite da alerti pageaju čovjeka samo kada je potrebna akcija. Sve ostalo neka ide u kanal za triage.

# Korak 2: Nadzor performansi koji se mapira na UX i prihod#

Praćenje performansi nije „CPU i memorija”. Za web aplikacije to je korisničko iskustvo.

Pratite Web Vitals i performanse po ruti#

Minimalno pratite:

• LCP za iskustvo učitavanja
• INP za latenciju interakcije
• CLS za vizualnu stabilnost
• TTFB za odziv servera i cachea

Next.js podržava izvještavanje Web Vitalsa. Možete ih proslijediti u svoj observability backend.

Primjer: hvatanje Web Vitalsa i slanje u API rutu:

// pages/_app.js
export function reportWebVitals(metric) {
  const body = JSON.stringify(metric);
  navigator.sendBeacon("/api/vitals", body);
}

Zatim agregirane metrike spremite server-side.

Postavite pragove koji odražavaju realnost#

Koristite pragove usklađene s Google smjernicama i poslovnim zahtjevima:

Ako je aplikacija content-heavy, LCP je obično prva pobjeda. Ako je više dashboard tipa, INP često najviše utječe na doživljenu kvalitetu.

Za dublje taktike optimizacije povežite ovo s Website Performance Optimization.

Nadzirite stvarne korisničke tokove, ne samo prosjeke#

Prosjeci skrivaju bol. Instrumentirajte p75 i p95 za:

• /login
• /checkout
• /search
• bilo koju SSR rutu s dohvatom podataka

Većina performansnih incidenata pojavi se u repu distribucije. Mala p95 regresija može nerazmjerno utjecati na konverzije.

# Korak 3: Strukturirano logiranje koje možete pretraživati tijekom incidenta#

Logovi trebaju biti strukturirani, konzistentni i povezani s requestom ili traceom. Console stringovi nisu dovoljni.

Definirajte JSON log shemu#

Krenite sa shemom poput ove:

Implementirajte lagani logger u Next.js#

Neka bude jednostavno i konzistentno:

// lib/logger.js
export function log(level, message, context = {}) {
  const entry = {
    timestamp: new Date().toISOString(),
    level,
    message,
    service: "web",
    env: process.env.APP_ENV,
    ...context,
  };
  console[level === "error" ? "error" : "log"](JSON.stringify(entry));
}

U API rutama:

// pages/api/checkout.js
import { log } from "../../lib/logger";
 
export default async function handler(req, res) {
  const start = Date.now();
  const requestId = req.headers["x-request-id"] || `req_${Math.random().toString(16).slice(2)}`;
 
  try {
    // ... your logic
    log("info", "Checkout request", { request_id: requestId, route: "/api/checkout" });
    res.status(200).json({ ok: true });
  } catch (e) {
    log("error", "Checkout failed", {
      request_id: requestId,
      route: "/api/checkout",
      duration_ms: Date.now() - start,
      error_message: e?.message,
    });
    res.status(500).json({ ok: false });
  }
}

Ovo proizvodi logove koje možete filtrirati po request_id, ruti i trajanju.

💡 Savjet: Preferirajte stabilne error_code vrijednosti umjesto sirovih poruka iznimki. Error kodovi omogućuju pouzdane nadzorne ploče i alerte te smanjuju šum od varijacija u porukama.

# Korak 4: Metrike koje stvarno detektiraju produkcijske probleme#

Metrike trebaju imati nisku kardinalnost i biti usklađene s utjecajem na korisnika.

Ključne metrike za početak#

Izbjegavajte dimenzije poput punog URL-a s id-jevima, user id-eva ili session id-eva. To pripada u logove ili traceove.

Kreirajte SLI i SLO po kritičnom korisničkom putovanju#

Čak i ako ne uvodite puni SRE, definirajte jedan SLO:

• Dostupnost checkouta: najmanje 99.9 posto requestova vraća 200 ili 201 u 30 dana
• Latencija checkouta: p95 manji od 1.5 sekundi za /api/checkout

SLO-ovi drže nadzorne ploče fokusiranima. Također olakšavaju tuning alerta.

# Korak 5: Distribuirani tracing za Next.js i downstream servise#

Tracing odgovara na pitanje: gdje je otišlo vrijeme.

Kada tracing postaje obavezan#

Dodajte tracing kada vidite ove obrasce:

• Možete detektirati usporenja u metrikama, ali root cause traje satima
• Problemi prelaze preko više servisa, npr. SSR zove API, API zove DB i payment providera
• Morate dokazati je li usko grlo u app kodu ili u latenciji ovisnosti

Koristite OpenTelemetry i propagirajte kontekst#

Ključno je dosljedno propagiranje konteksta s trace_id. Čak i ako krenete samo sa server-side tracingom, mogućnost korelacije sporih requestova s logovima je veliki dobitak.

Pojednostavljen primjer kreiranja spanova oko downstream poziva:

// lib/instrumentation.js
import { trace } from "@opentelemetry/api";
 
export async function tracedFetch(url, options = {}) {
  const tracer = trace.getTracer("web");
  return tracer.startActiveSpan("http.client", async (span) => {
    try {
      span.setAttribute("http.url", url);
      const res = await fetch(url, options);
      span.setAttribute("http.status_code", res.status);
      return res;
    } catch (e) {
      span.recordException(e);
      throw e;
    } finally {
      span.end();
    }
  });
}

Koristite ovo oko kritičnih ovisnosti: payments, search, auth i CMS.

⚠️ Upozorenje: Trace podaci mogu brzo postati skupi. Agresivno sampleajte i fokusirajte se na kritične rute. Čest pristup je 1 posto sampleanja globalno i 10 posto za checkout.

# Korak 6: Nadzorne ploče koje hvataju stvarne incidente#

Nadzorne ploče trebaju odgovoriti: jesu li korisnici pogođeni, gdje i od kada.

Tri nadzorne ploče koje svaki Next.js tim treba imati#

1) Executive nadzorna ploča utjecaja na korisnike

Fokus: ishodi, ne interne metrike.

Paneli koje uključiti:

• Stopa grešaka kroz vrijeme, po environmentu
• p75 i p95 LCP i INP kroz vrijeme
• p95 SSR latencija za ključne rute
• Stopa uspješnosti checkouta i latencija

2) Release health nadzorna ploča

Fokus: „je li deploy nešto pokvario”.

Paneli koje uključiti:

• Errors per minute po releaseu
• Broj novih issueova po releaseu
• Promjena p95 latencije u odnosu na prethodni release
• Web Vitals delta

Povežite ovo s vašim delivery workflowom iz Web Development Process Step-by-Step.

3) Dependency health nadzorna ploča

Fokus: pouzdanost upstream i downstream sustava.

Paneli koje uključiti:

• Latencija i greške payment providera
• Latencija i greške email providera
• p95 latencija baze i zasićenost konekcija
• Cache hit ratio i evictions

Jednostavna, učinkovita alert matrica#

Alertanje treba mapirati na štetu za korisnika:

Pazite da svaki alert ima vlasnika i link na runbook.

ℹ️ Napomena: Mnogi timovi postavljaju statične latency pragove i dobiju alert fatigue. Preferirajte alerte temeljene na promjeni u odnosu na baseline, uz apsolutne guardrailove.

# Korak 7: Što prvo instrumentirati u stvarnom projektu#

Ako imate jedan tjedan, napravite ovo:

1. 1
   Sentry za frontend i Next.js server greške, s releaseovima i source mapovima
2. 2
   Web Vitals reporting prema vašem metrics backendu
3. 3
   Strukturirani JSON logovi iz API ruta i SSR-a, s request id-evima
4. 4
   Jedna nadzorna ploča: release health plus checkout putovanje
5. 5
   Dva paging alerta: checkout greške i SSR 500 spikeovi

Ako imate jedan mjesec, dodajte:

• OpenTelemetry traceove za kritične rute
• Dependency metrike za payments, auth i bazu
• SLO-ove i alertanje na error budget
• Synthetic monitoring za sign-in i checkout

Ovo stvara efekt akumulacije: svaki novi signal postaje vrijedniji jer ga možete korelirati.

# Česte zamke i kako ih izbjeći#

1. 1

   Prikupljanje previše podataka bez pitanja
   Krenite od failure modeova. Primjer: „korisnici ne mogu platiti”, „homepage je spor na mobitelu”, „SSR vraća 500”.

2. 2

   Stavljanje high-cardinality podataka u metrike
   Izbjegavajte user id-eve i pune URL-ove u metrics labelima. Neka budu u logovima i traceovima.

3. 3

   Nema correlation id-eva kroz logove, greške i traceove
   request_id i trace_id trebali bi se pojavljivati svugdje. Bez toga debugging postaje ručan.

4. 4

   Alerti bez runbookova
   Ako alert zazvoni u 3 ujutro, responder treba sljedeći korak u 30 sekundi.

5. 5

   Ignoriranje sigurnosti u telemetriji
   Telemetrija često sadrži osjetljive podatke. Primijenite isti rigor kao u sigurnosnim praksama iz Web Application Security Checklist.

# Ključne poruke#

• Observabilnost web aplikacije započnite s praćenjem grešaka i zdravljem releasea, a zatim u fazama dodajte performanse, logove i tracing.
• Instrumentirajte Web Vitals i kritična korisnička putovanja koristeći p75 i p95, ne samo prosjeke.
• Koristite strukturirane JSON logove sa stabilnim error_code, request_id i trace_id kako bi incidenti bili pretraživi i brzo debugabilni.
• Držite metrike nisko-kardinalnima i usklađenima sa SLO-ovima kako bi nadzorne ploče i alerti odražavali utjecaj na korisnika.
• Izgradite tri nadzorne ploče koje odgovaraju stvarnosti: utjecaj na korisnika, release health i dependency health, a zatim povežite alerte s jasnim runbookovima.

# Zaključak#

Čvrst temelj observabilnosti web aplikacije za React i Next.js nije kompliciran, ali mora biti namjeran. Krenite s instrumentacijom visokog signala, korelirajte sve putem request i trace identifikatora te gradite nadzorne ploče i alerte oko korisničkih putovanja koja pokreću prihod.

Ako želite da Samioda implementira end-to-end observability stack za vašu Next.js aplikaciju, uključujući Sentry, OpenTelemetry, nadzorne ploče i akcijske alerte, kontaktirajte nas i isporučit ćemo produkcijski spremnu postavu usklađenu s vašim release procesom i ciljevima performansi.