Belajar Cloud Computing - Cloud Observability, Monitoring & Logging

#Pendahuluan

Setelah di episode 14 kita membangun pertahanan berlapis — firewall, WAF, dan enkripsi — satu pertanyaan tersisa: bagaimana kalian tahu sistem kalian benar-benar sehat? Keamanan melindungi sistem dari serangan dari luar; observability melindungi sistem dari dalam: dari kesalahan kode, resource yang menipis, dan perubahan yang tidak disengaja.

Seorang engineer yang andal bukan yang mengklaim "sistem kami tidak pernah down", melainkan yang bisa menunjukkan angkanya: berapa persen ketersediaannya, berapa latensi rata-ratanya, dan ke mana error mengalir saat ada masalah. Episode ini membekali kalian dengan tiga pilar observability, pengumpulan log terpusat, alerting, serta perbandingan alat di AWS, GCP, dan Azure.

#Pembahasan Utama

#Tiga Pilar Observability

Observability berdiri di atas tiga pilar yang saling melengkapi. Menguasai ketiganya sekaligus — bukan salah satu saja — yang membedakan operasional modern dari sekadar "memantau":

1. Metrik — angka kuantitatif dalam deret waktu: CPU, memory, request rate, error rate, dan latency. Ringkas, murah untuk disimpan, dan ideal untuk alerting. Analoginya speedometer: ia memberi tahu kalian kecepatan naik, tanpa menjelaskan mengapa.
2. Log — catatan peristiwa berstruktur dengan timestamp: siapa memanggil apa, dengan parameter apa, dan hasilnya apa. Kaya detail dan ideal untuk troubleshooting. Analoginya black box pesawat: lengkap, tetapi baru benar-benar dibuka saat ada masalah.
3. Trace — perjalanan satu request melintasi banyak service, dari API gateway sampai database. Analoginya petugas yang mengikuti satu pelanggan di seluruh mal untuk mengetahui di toko mana ia berlama-lama.

Hubungan ketiganya sederhana: metrik menjawab ada masalah?, log menjawab apa yang terjadi?, dan trace menjawab kenapa bisa terjadi?. Monitoring memberi tahu bahwa sesuatu salah; observability memberi tahu apa dan mengapa, tanpa perlu menebak.

#Metrik: Ukur yang Penting, Bukan yang Mudah

Untuk layanan yang melayani request, pola RED method adalah titik awal yang baik: Rate (jumlah request per detik), Error (jumlah request gagal per detik), dan Duration (distribusi latensi). Untuk infrastruktur pendukung, perhatikan CPU, memory, disk, dan jaringan.

Perhatikan kolom alarm: nilai puncak sesaat biasanya bukan indikator masalah — yang berbahaya adalah tren yang berkelanjutan. Baseline selama 30 hari adalah kompas kalian untuk menilai apakah kenaikan kali ini normal atau sinyal masalah.

#Centralized Log Collection dan Alerting

Mengapa log harus dikumpulkan terpusat? Instance di cloud bersifat fana — ia bisa diganti kapan saja — dan container berpindah antar node. Log yang tersimpan di disk instance akan ikut hilang saat instance dihentikan. Grep manual ke 50 server juga mustahil saat insiden. Solusinya adalah agregasi terpusat: agent di setiap instance mengirim log ke satu tempat, lalu tempat itu bisa dicari, di-query, dan dijadikan alarm.

Alur standarnya: agent di instance mengirim log ke layanan log terpusat (CloudWatch Logs, Cloud Logging, Log Analytics), lalu alarm berbasis metrik atau log mengirim notifikasi ke email, Slack, atau PagerDuty saat ambang batas terlewati. Contoh mengambil statistik CPU instance lewat CLI:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --statistics Average \
  --period 300 \
  --start-time 2026-08-03T00:00:00Z \
  --end-time 2026-08-03T01:00:00Z

Perintah aws cloudwatch get-metric-statistics mengembalikan deret titik data dalam rentang waktu yang diminta. Hasilnya berupa JSON seperti berikut:

{
  "Datapoints": [
    {
      "Timestamp": "2026-08-03T00:30:00Z",
      "Average": 42.7,
      "Unit": "Percent"
    },
    {
      "Timestamp": "2026-08-03T00:45:00Z",
      "Average": 61.3,
      "Unit": "Percent"
    }
  ],
  "Label": "CPUUtilization"
}

Angka inilah yang menjadi bahan keputusan: rata-rata 42 sampai 61 persen menandakan instance ter-utilisasi wajar. Jika hasilnya menunjukkan 95 persen secara konsisten, itu sinyal untuk menaikkan kapasitas — atau mengevaluasi konfigurasi aplikasi.

#Contoh Log: Pencarian Terpusat

Ketika metrik memberi tahu bahwa ada masalah, log memberi tahu detailnya. Setelah log terpusat, kalian tidak lagi membuka terminal per server — cukup satu tempat untuk mencari. Contoh query di CloudWatch Logs Insights untuk menemukan error terbaru:

fields @timestamp, @message, @requestId
| filter @message like /ERROR|Exception/
| sort @timestamp desc
| limit 20

Query ini mengambil timestamp, isi pesan, dan request ID dari semua instance sekaligus, menyaring yang mengandung ERROR atau Exception, lalu mengurutkannya dari yang terbaru. Pola yang sama berlaku di Cloud Logging (dengan query SQL-like) dan Log Analytics (dengan KQL). Yang penting bukan sintaksnya — melainkan konsepnya: log dari seluruh fleet dipersempit menjadi beberapa baris yang relevan dalam hitungan detik.

#Trace: Melacak Satu Request

Ketika satu request melewati banyak service — API gateway, autentikasi, service A, service B, sampai database — siapa yang paling lambat? Log per service tidak menjawab ini, karena tiap service hanya melihat potongan kecil. Di sinilah trace berperan: satu trace ID menandai seluruh perjalanan satu request, dan setiap hop direkam sebagai span.

Dari tabel di atas terlihat jelas: 120 ms di service User bukanlah kegagalan aplikasi — ia penyumbang latensi terbesar. Tanpa trace, kalian akan menebak-nebak service mana yang harus dioptimasi. Dengan trace, keputusannya berbasis data. Di balik layar, alat seperti X-Ray, Cloud Trace, dan Application Insights membangun tabel semacam ini secara otomatis dari request yang melewati sistem kalian.

#Alerting yang Sehat

Alarm tidak berguna jika semua alarm dianggap sebagai alarm palsu. Praktik yang sehat:

• Berbasis metrik, bukan log mentah — metrik bisa dihitung dan di-threshold secara stabil, sedangkan log lebih cocok untuk pencarian saat diagnosis.
• Beri jeda — alarm sebaiknya menyala setelah kondisi berlangsung beberapa menit, bukan langsung pada fluktuasi sesaat, agar tidak histeris.
• Tunjuk pemilik — setiap alarm harus jelas siapa yang bertanggung jawab menindaklanjuti, dan jalur eskalasinya sampai ke mana.

#Perbandingan Layanan Observability Big 3

Ketiga cloud besar membangun fondasi observability yang identik, dengan penamaan berbeda:

Semuanya berpikir dengan pola yang sama: metrik disimpan sebagai deret waktu, log disimpan dan bisa di-query (CloudWatch Logs Insights, Cloud Logging, Log Analytics), dan trace mengikuti satu request melintasi service. Jika kalian sudah memahami konsep episode ini, berpindah cloud hanya soal belajar penamaan dan sintaks query — fondasi konseptualnya sudah sama.

#Penutup

Pada episode 15 ini kalian telah membangun kemampuan untuk membuktikan kesehatan sistem: tiga pilar observability — metrik untuk alert, log untuk diagnosis, dan trace untuk memahami alur lintas service; pengumpulan log terpusat — mengumpulkan log dari instance fana ke satu tempat yang bisa dicari; alerting yang sehat — alarm berbasis ambang yang jelas, berjeda, dan punya pemilik; serta perbandingan alat di AWS, GCP, dan Azure.

Namun ada paradoks yang harus kalian pahami: observability hanya berguna jika sistem yang diamati bisa direproduksi dengan pasti. Membangun environment staging kedua secara manual lewat klik-klik konsol hampir dijamin menghasilkan sistem yang berbeda — dan monitoring di atas fondasi yang berbeda itu menjadi menyesatkan. Episode berikutnya, Infrastructure as Code & Cloud Automation, memberikan kalian kunci untuk membangun, menduplikasi, dan mengubah infrastruktur dengan presisi yang sama seperti menulis kode.