Iki minangka telung tiang observabilitas. Padha wangsul pitakon beda-beda: metrik ngomong-omong apa sing salah, log ngomong-omong apa sing kelakon, lan trace ngomong-omong ing aliran distribusi waktu utawa kesalahan misil.
Iki minangka telung tiang observabilitas. Padha wangsul pitakon beda-beda: metrik ngomong-omong apa sing salah, log ngomong-omong apa sing kelakon, lan trace ngomong-omong ing aliran distribusi waktu utawa kesalahan misil.
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
Metrik ngarang sampeyan menyang gejala lan jenela waktu; trace nglokalisasi menyang serbis utawa panggilan; log menehi sebab sing tepat. Menyang langsung menyang log tanpa metrik tegese nggoleki buta.
Metrik dikumpulaken, mula padha tetep murah sanajan ing skala — ideal kanggo dashboard lan alert sing tansah nyambung. Log lan trace saben-saben lan larang, dadi biasane dijamak lan ditakon ing permintaan sajrone investigasi.
Nggunakake tiang sing salah mbuwang waktu: sampeyan ora bisa nggawat alert kanthi efektif ing log mentah (bising banget, larang banget), lan sampeyan ora bisa debug permintaan sing gagal saka metrik agregat. Ngerti yen metrik nyedhiyakake, trace nglokalisasi, lan log njelasake menehi sampeyan dalan sing cepet lan bisa baleni saka "ana sing salah" menyang penyebab akar.