> ## Documentation Index
> Fetch the complete documentation index at: https://docs.skanesgalab.my.id/llms.txt
> Use this file to discover all available pages before exploring further.

# Fundamental Observability, Monitoring & Logging

> Pengenalan konsep Observability, perbedaan Monitoring vs Observability, 3 pilar utama (Metrics, Logs, Traces), dan mengapa sistem modern sangat membutuhkannya.

## Mengapa Observability & Monitoring Sangat Dibutuhkan?

Bayangkan kamu adalah seorang pilot yang menerbangkan pesawat komersial besar di malam hari di tengah badai awan tebal. Tanpa panel instrumen di kokpit (kecepatan angin, ketinggian, kompas, indikator bahan bakar), kamu menerbangkan pesawat dalam kondisi "buta". Kamu baru tahu ada kerusakan mesin ketika pesawat sudah menukik tajam ke bumi.

Dalam dunia rekayasa perangkat lunak modern:

* Aplikasi tidak lagi berjalan di satu server sederhana, melainkan terpecah menjadi puluhan hingga ratusan layanan kecil (**Microservices**), ratusan kontainer **Docker**, dan tersebar di berbagai kluster **Kubernetes** lintas kawasan dunia (*Multi-Region*).
* Jika pengguna melaporkan: *"Aplikasi lambat dan gagal checkout pembayaran"*, mencari penyebab masalah di antara ribuan server tanpa instrumen pemantau adalah hal yang mustahil.

**Monitoring dan Observability adalah "panel kokpit" bagi insinyur DevOps dan SRE (Site Reliability Engineer)** untuk melihat kesehatan sistem, memprediksi kegagalan sebelum terjadi, dan memperbaiki masalah dalam hitungan menit.

***

## Perbedaan Monitoring vs Observability

Meskipun sering digunakan bergantian, keduanya memiliki filosofi yang berbeda:

```mermaid theme={null}
flowchart TD
    subgraph MonitoringScope["Monitoring (Dasar)"]
        M1["Mendeteksi GEJALA: 'Apakah sistem bekerja?'"]
        M2["Menjawab pertanyaan: 'Sistem sedang down!'"]
        M3["Fokus pada hal yang sudah diketahui (Known-Unknowns)"]
    end

    subgraph ObservabilityScope["Observability (Mendalam)"]
        O1["Memahami PENYEBAB: 'Mengapa sistem rusak?'"]
        O2["Menjawab pertanyaan: 'Komponen mana yang rusak dan kenapa?'"]
        O3["Fokus pada hal yang tidak terduga (Unknown-Unknowns)"]
    end

    MonitoringScope -->|Bagian dari| ObservabilityScope
```

| Parameter | Monitoring | Observability |
| :- | :- | :- |
| **Pertanyaan Utama** | *"Apakah sistem sedang aktif atau mati?"* | *"Mengapa sistem lambat hanya untuk user dari pulau Jawa pada jam 12:00?"* |
| **Sifat Tindakan** | Reaktif (Menerima peringatan setelah terjadi error). | Proaktif (Menganalisis anomali sebelum error terjadi). |
| **Karakter Masalah** | *Known-Unknowns* (Kita tahu disk bisa penuh, lalu kita pasang alert jika disk > 90%). | *Unknown-Unknowns* (Kita tidak tahu kenapa request user tertentu menghasilkan deadlock memori). |
| **Derajat Pemahaman** | Melihat kondisi luar dari dasbor dashboard (*Black-box*). | Menyimpulkan kondisi internal sistem dari data telemetri yang dipancarkan (*White-box*). |

***

## 3 Pilar Utama Observability (The Three Pillars)

Untuk mendapatkan observabilitas penuh terhadap sistem, kita mengumpulkan 3 jenis data telemetri:

```mermaid theme={null}
flowchart TD
    Obs["3 Pilar Observability"]
    Obs --> M["1. METRICS (Angka Agregat)\n'Kapan & seberapa parah masalahnya?'\nContoh: CPU 95%, 450 req/sec"]
    Obs --> L["2. LOGS (Catatan Kejadian)\n'Apa pesan error spesifiknya?'\nContoh: NullPointerException line 42"]
    Obs --> T["3. TRACES (Jejak Permintaan)\n'Di microservice mana waktu habis?'\nContoh: Auth (5ms) -> DB Query (1200ms)"]
```

### 1. Metrics (Metrik Numerik)

* **Definisi:** Data numerik terukur yang dikumpulkan dalam interval waktu tertentu (*Time-Series Data*).
* **Karakteristik:** Sangat hemat penyimpanan (*lightweight*), mudah diagregasi menjadi grafik, dan sangat cepat dihitung.
* **Contoh:**
  * Utilisasi CPU & RAM server (%).
  * Jumlah permintaan HTTP per detik (*Requests Per Second - RPS*).
  * Rasio error (*Error Rate* HTTP 500).
* **Tools Populer:** Prometheus, InfluxDB, Datadog.

### 2. Logs (Catatan Peristiwa Terperinci)

* **Definisi:** Catatan baris teks berstempel waktu (*timestamped text*) yang dikeluarkan aplikasi ketika suatu peristiwa terjadi.
* **Karakteristik:** Memuat konteks mendalam (ID pengguna, payload transaksi, baris error file), namun memakan kapasitas penyimpanan harddisk yang sangat besar.
* **Contoh:**
  ```json theme={null}
  {"timestamp": "2026-10-26T22:45:00Z", "level": "ERROR", "user_id": 9821, "msg": "Database connection timeout after 3000ms"}
  ```
* **Tools Populer:** Grafana Loki, Elasticsearch/Logstash (ELK Stack), Fluentd.

### 3. Distributed Tracing (Penelusuran Jejak Terdistribusi)

* **Definisi:** Melacak perjalanan satu buah permintaan pengguna (*Request Flow*) dari awal masuk gateway, melintasi puluhan microservices independen, query database, hingga kembali ke pengguna.
* **Karakteristik:** Memberikan visualisasi latensi berupa diagram *Waterfall (Spans)* untuk menemukan bottleneck performa.
* **Contoh:** Mengetahui bahwa dari total loading 3 detik, 2.8 detik dihabiskan karena query `SELECT * FROM orders` yang tidak memiliki indeks database!
* **Tools Populer:** Jaeger, Zipkin, OpenTelemetry, Grafana Tempo.

***

## 4 Golden Signals (Standar SRE Google)

Google Site Reliability Engineering (SRE) menetapkan 4 metrik emas yang wajib dipantau pada setiap layanan pengguna:

1. **Latency (Latensi):** Berapa lama waktu yang dibutuhkan sistem untuk membalas permintaan (harus memisahkan latensi request sukses vs request error).
2. **Traffic (Lalu Lintas):** Beban permintaan yang masuk ke sistem (misal: HTTP requests per second, I/O network bandwidth).
3. **Errors (Tingkat Kegagalan):** Berapa banyak permintaan yang gagal (error rate HTTP 5xx, atau transaksi pembayaran gagal).
4. **Saturation (Saturasi / Kejenuhan):** Seberapa penuh sumber daya sistemmu (misal pemakaian memory 92%, connection pool database tersisa 2 slot).

***

## Kapan & Kenapa Observability Ini Bisa Ada?

1. **Evolusi Monolith ke Microservices:** Dahulu aplikasi monolith hanya menghasilkan 1 file log di satu server. Sekarang, satu klik tombol belanja melibatkan panggilan ke 15 container terpisah.
2. **Lingkungan Server Dinamis (Ephemeral):** Di Kubernetes, kontainer hidup dan mati dalam hitungan detik. Jika kontainer mati dan kamu tidak mengirim lognya ke sistem terpusat, catatan penyebab crash akan hilang selamanya.
3. **Kebutuhan SLA/SLO Bisnis:** Perusahaan modern menjanjikan ketersediaan 99.99% (*Four Nines*). Artinya dalam setahun, downtime maksimal hanya boleh 52 menit! Tanpa observabilitas, mencari akar masalah butuh berjam-jam.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.