Belajar Cloud Engineer - Monitoring & Logging Cloud

#Pendahuluan

Di episode 8 kalian mengotomasi manajemen resource — tetapi ada pertanyaan yang belum terjawab: bagaimana kalian tahu semuanya berjalan baik? Server bisa down di tengah malam, disk bisa penuh pelan-pelan, dan response API bisa melambat tanpa ada yang menyadarinya. Inilah mengapa observability bukan opsional.

Episode 9 membahas monitoring & logging cloud: metrik (angka yang terus berjalan), log (rekaman peristiwa), alarm (pemicu aksi), dan dashboard (pandangan ringkas). Kalian akan belajar memakai layanan monitoring resmi — CloudWatch (AWS), Cloud Monitoring (GCP), Azure Monitor — dan membangun setup observability untuk infrastruktur yang sudah kalian bangun sejak episode 3.

#Tiga Pilar Observability

• Metrik — angka berkelanjutan: CPU, memory, request rate, error count, latency. Menjawab "berapa banyak?"
• Log — peristiwa diskrit: pesan aplikasi, request, stack trace. Menjawab "apa yang terjadi?"
• Trace — perjalanan satu request lintas service. Menjawab "di mana lambat?" (dibahas lebih dalam di episode 12 microservices).

Monitoring cloud mencakup dua-duanya: metrik dari resource (VM, DB, load balancer) dan log dari aplikasi.

#Metrik Cloud dan CloudWatch / Cloud Monitoring / Azure Monitor

Setiap provider punya sistem metrik terpusat:

Contoh: melihat metrik CPU instance dan membuat alarm — semua provider bisa, bedanya sintaks:

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

gcloud monitoring metrics-list \
  --filter="metric.type=compute.googleapis.com/instance/cpu/utilization"

Custom metrics penting saat metrik bawaan tidak cukup — misalnya jumlah antrian di aplikasi kalian sendiri. Dengan custom metric, alarm bisa mencakup apa pun yang bisa diukur kode kalian.

#Log Aggregation

Aplikasi kalian menghasilkan log di banyak tempat: VM, function, database, load balancer. Log aggregation menyatukan semuanya ke satu tempat yang bisa dicari:

• AWS: CloudWatch Logs, dengan agent CloudWatch Agent di VM.
• GCP: Cloud Logging, otomatis terintegrasi.
• Azure: Log Analytics workspace.

Alur khas di VM Linux: agent membaca file log aplikasi, mengirim ke layanan log cloud, dan bisa di-query.

fields @timestamp, @message
| filter @message like /ERROR|Exception/
| stats count() by bin(5m)
| sort @timestamp desc
| limit 50

Pola query di atas adalah contoh nyata: ambil semua log error, hitung per 5 menit, tampilkan terbaru. Kemampuan filter dan aggregate ini yang mengubah "tumpukan log" menjadi jawaban investigasi.

#Tips log yang baik

• Structured logging — output JSON, bukan teks bebas, agar mudah di-query.
• Selalu sertakan request id — menghubungkan log dengan satu permintaan user.
• Jangan log data sensitif — password, token, dan data pribadi tidak boleh masuk log (ini juga aspek compliance episode 15).

#Alarm dan Notifikasi

Alarm adalah jembatan antara metrik dan manusia: ketika ambang terlampaui, kirim notifikasi. Contoh alarm CPU tinggi:

aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --alarm-description "CPU di atas 80% selama 10 menit" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-southeast-1:123456789012:ops-alerts

Yang perlu dipikirkan matang:

1. Ambang yang masuk akal — terlalu sensitif = alarm spam (diabaikan); terlalu longgar = kecelakaan tidak terdeteksi. Mulai dari metrik yang bermakna: error rate, bukan sekadar CPU.
2. Saluran — SNS/Slack/PagerDuty email untuk level berbeda. Urgent → telepon/pager; info → email.
3. Siapa yang menerima — rout ke tim yang tepat, bukan semua orang.
4. Auto-remediation — alarm tidak harus selalu "menghubungi manusia"; bisa memicu function untuk merespons (contoh: restart service). Ini langkah menuju SRE.

#Dashboard

Dashboard adalah jendela kondisi sistem dalam satu pandangan. Setiap provider punya builder-nya (CloudWatch Dashboards, Cloud Monitoring Dashboards, Azure Dashboards), dan tool open-source seperti Grafana juga umum dipakai. Komponen yang harus ada untuk aplikasi web:

Prinsip dashboard: satu layar, bisa langsung dimengerti dalam 10 detik. Kalau butuh membaca dokumentasi untuk memahami dashboard, itu dashboard yang gagal.

#Praktik: Monitoring Infrastruktur Cloud

Mari rangkai setup observability untuk VM lab-web yang kalian buat di episode 3:

1. Ambil metrik dasar: CPU, network, disk (get-metric-statistics di atas).
2. Install CloudWatch Agent di VM (atau pakai metrik bawaan untuk mulai).
3. Buat dua alarm: CPU > 80% 10 menit (info) dan instance status check failed (urgent).
4. Buat dashboard ringkas: CPU semua instance + status code dari load balancer.
5. Uji: jalankan stress-ng --cpu 4 di VM, lihat alarm menyala, lalu hentikan.

Setelah alarm berdering dan dashboard berfungsi, kalian baru bisa menyebut infrastruktur kalian "diamati". Selanjutnya kita akan melihat bagaimana alarm memicu scaling otomatis (episode 21) dan auto-remediation.

#Kesalahan Umum (Common Pitfalls)

1. Hanya memonitor CPU — abaikan error rate, latency, disk, dan log.
2. Alarm spam — ambang terlalu rendah; tim mati rasa dan mengabaikan semua alarm.
3. Log tanpa struktur — teks bebas yang tidak bisa di-query; jadikan structured logging default.
4. Dashboard tanpa aksi — dashboard indah tapi tidak ada yang melihatnya; hubungkan ke alarm.
5. Tidak ada retention policy — log menumpuk dan tagihan storage membengkak; atur retensi (misal 30 hari hot, 365 hari archive).

#Penutup

Inti yang harus dibawa pulang:

• Observability = metrik + log + trace; gabungannya menghasilkan insight yang tidak bisa didapat salah satunya saja.
• CloudWatch / Cloud Monitoring / Azure Monitor adalah tiga pilar resmi — konsepnya sama, sintaks beda.
• Alarm harus didesain dari sudut pandang user (error rate, latency), dengan ambang yang tidak spam.
• Log harus terstruktur, mudah di-query, dan tidak berisi data sensitif.
• Dashboard = satu layar, paham dalam 10 detik.

Di episode 10 selanjutnya kita akan membawa aplikasi ke level berikutnya: containers on cloud — managed Kubernetes (EKS/GKE/AKS), node pools, deployment, dan menjalankan aplikasi container di cluster yang dikelola provider. Sampai jumpa di episode 10!