Cloud-native monitorings un novērojamība

Bez monitoringa jūs uzzināt par problēmu no lietotāja — un parasti tajā brīdī sekas jau ir kritiskas. Ar labu novērojamību — jūs to redzat pirms lietotājs to pamana, saprotat cēloni un novēršat sekunžu laikā.

Trīs novērojamības pīlāri — detalizēti

Metrikas (Metrics)

Cipariski mērījumi laika gaitā — kvantitatīvi dati par sistēmas veselību:

• Infrastruktūras metrikas — CPU utilizācija, RAM lietojums, disk I/O, network throughput. Pamatā — vai pietiek resursu
• Aplikācijas metrikas — pieprasījumu skaits/s (RPS), atbildes laiki (p50, p95, p99), kļūdu likme (4xx, 5xx), aktīvo savienojumu skaits
• Biznesa metrikas — reģistrācijas/min, pasūtījumi/h, maksājumu veiksmīgums %, API key lietojums. Bieži svarīgākas nekā tehniskās
• Node.js specifiskas — event loop lag, heap used/total, GC pauzēs ilgums, active handles/requests

Prometheus ir de facto standartu metrisku vākšanai: pull-based modelis (scrape regulāri), PromQL vaicājumu valoda, alert rules. Node.js: `prom-client` bibliotēka eksponē /metrics endpointu.

Žurnāli (Logs)

Strukturēti notikumu ieraksti ar kontekstu:

• Strukturēts formāts — JSON (ne plain text). Katram ierakstam: timestamp, level, message, service, traceId, userId, requestId
• Līmeņi — ERROR (jāreaģē), WARN (jāpārbauda), INFO (normālas operācijas), DEBUG (tikai izstrādē)
• Korelācijas ID — katram pieprasījumam unikāls `requestId`, kas saista VISUS šī pieprasījuma žurnālus kopā. Middleware: `req.id = uuid()` un propagēt visos loggera izsaukumos
• Bibliotēkas — Winston (populārākā Node.js), Pino (ātrākā — 5–10x ātrāka nekā Winston), Bunyan

Centralizēšana — žurnāli no visām instancem vienā vietā:

• ELK stack — Elasticsearch (glabāšana + meklēšana) + Logstash (apstrāde) + Kibana (vizualizācija). Spēcīgs, bet resursu ietilpīgs
• Grafana Loki — viegls, efektīvs, integrējas ar Grafana. Neindeksē žurnālu saturu — tikai labels, query laikā meklē. Ievērojami lētāks nekā ELK
• Betterstack (Logtail) — SaaS, vienkārša integrācija, reāllaika meklēšana
• DataDog Logs — pilnvērtīga platforma ar automātisku korelāciju starp metrikām, žurnāliem un trasēm

Trasēšana (Distributed Tracing)

Parāda pieprasījuma ceļu cauri visiem servisiem — kur laiks tiek patērēts:

• Span — viena operācija (datubāzes vaicājums, HTTP izsaukums, cache lasīšana). Katram span: sākuma laiks, ilgums, statuss
• Trace — sakopots span koks. Piemērs: lietotāja pieprasījums → API gateway → auth service → datubāze → cache → response
• Bottleneck identifikācija — vizuāli redzams, ka 80% laika patērēts vienā datubāzes vaicājumā. Bez tracing to nevar zināt

OpenTelemetry — industrijas standarts: viena SDK metrikām, žurnāliem un trasēm. Eksportē uz jebkuru backend (Jaeger, Zipkin, DataDog, Grafana Tempo).

Node.js: `@opentelemetry/sdk-node` ar auto-instrumentation — automātiski instrumentē HTTP, Express, pg, Redis bez koda izmaiņām.

Brīdinājumu stratēģija — gudri, ne daudz

Uz simptomiem balstīti brīdinājumi (SLI/SLO)

Brīdiniet par to, ko lietotājs izjūt:

• Kļūdu likme — 5xx > 1% 5 minūšu logā → kritisks brīdinājums
• Latency — p95 > 2s 10 minūšu logā → augsta prioritāte
• Pieejamība — uptime < 99.9% pēdējā stundā → brīdinājums

NE brīdiniet par: CPU > 80% (var būt normāli), vienu neveiksmīgu health check (var būt pārejoša), disk > 70% (informatīvs, ne urgents).

Brīdinājumu noguruma novēršana (Alert Fatigue)

Pārāk daudz brīdinājumu = visi ignorēti. Taktika:

• Prioritātes — P1 (nekavējoties), P2 (darba laikā), P3 (nākamais sprints), P4 (backlog)
• Grupēšana — viens incidents, ne 50 brīdinājumi par katru symptōmu atsevišķi
• Escalation — ja P1 nav atrisināts 15 min → eskalē uz nākamo līmeni
• Regulārs audits — ik nedēļu pārskatiet brīdinājumus: kurš bija noderīgs, kurš bija troksnis

On-call prakse

PagerDuty, Opsgenie vai grafika formā: dežūras rotācija, runbook (soli-pa-solim ko darīt pie konkrēta brīdinājuma), post-incident review.

Rīki un platformas — izvēles matrica

Open-source stack (self-hosted)

• Grafana — vizualizācija (dashboards). Atbalsta visus datu avotus
• Prometheus — metrikas (pull model, PromQL, alerting rules)
• Loki — žurnāli (labels-based, efektīvs)
• Tempo — trasēšana (integrējas ar Grafana)
• Alertmanager — brīdinājumu maršrutēšana un grupēšana
• Priekšrocība: pilna kontrole, bez cenas. Trūkums: jāuztur infrastruktūra

SaaS platformas

• DataDog — viss vienā: metrikas, žurnāli, trases, APM, RUM, synthetics. Dārgs, bet pilnvērtīgs
• New Relic — spēcīgs APM ar automātisku bottleneck identifikāciju. Bezmaksas plāns 100GB/mēn
• Grafana Cloud — managed Grafana + Prometheus + Loki + Tempo. Bezmaksas plāns 10K metrikas, 50GB žurnāli
• Sentry — kļūdu izsekošana ar stack trace, breadcrumbs un reproducēšanas informāciju. Specifisks — ne vispārējs monitorings

Vienkāršākie risinājumi

• Vercel Analytics — iebūvēts Web Vitals. Pietiek vienkāršām Next.js lietojumiem
• Uptime Robot — pieejamības monitorings no ārpuses. Bezmaksas 50 monitoriem
• Betterstack — uptime + incidents + logs vienā platformā

SLA, SLO un Error Budgets

Definīcijas

• SLA (Service Level Agreement) — līgumisks solījums klientiem. Piemērs: 99.9% uptime, < 500ms atbilde
• SLO (Service Level Objective) — iekšējais mērķis, stingrāks par SLA. Ja SLA = 99.9%, SLO var būt 99.95%
• SLI (Service Level Indicator) — faktiskā metrika, kas mēra SLO. Error rate, latency p95, availability

Error Budget — inovācijas balansēšana

Ja SLO = 99.9%, tad error budget = 0.1% (≈43 min/mēn). Kamēr error budget nav iztērēts — drīkst veikt riskantākas izvietošanas un eksperimentus. Ja error budget iztērēts — stop deploys, focus uz stabilitāti.

Praktiskie cipari

• 99% = 7.3h dīkstāves/mēn. Piemērots interāniem un mazāk kritiskiem servisiem
• 99.9% = 43 min/mēn. Standarts lielākajai daļai SaaS un e-komercijas
• 99.95% = 22 min/mēn. Augsta pieejamība, prasa redundanci
• 99.99% = 4.3 min/mēn. Kritiska infrastruktūra, prasa multi-reģionu arhitektūru