Belajar KEDA - Troubleshooting & Monitoring

#Pendahuluan

Di episode 17 kita menjelajahi banyak scaler dan integrasi. Semakin banyak yang bisa kita otomatiskan, semakin banyak pula yang bisa gagal tanpa kita sadari. Pesan menumpuk di queue, namun replika tidak naik — incident dimulai dari autoscaler yang diam. Episode ini membahas Troubleshooting & Monitoring: urutan diagnosa yang benar, metrik yang bisa diandalkan, dan solusi untuk masalah paling umum di KEDA v2.20.2. Tujuannya sederhana: dari "kenapa tidak naik?" menjadi "ini buktinya, ini penyebabnya, ini perbaikannya" dalam hitungan menit.

#Diagnosa: Alur Terstruktur

Jangan menebak. Ikuti urutan dari status paling tinggi ke detail paling dalam.

#1. Status ScaledObject

Lihat status ScaledObject

kubectl get scaledobject -n orders
kubectl describe scaledobject order-worker -n orders

kubectl describe scaledobject order-worker -n orders menampilkan kondisi dan events. Perhatikan kolom Ready, Active, dan Fallback dari kubectl get scaledobject. Ready = konfigurasi valid dan HPA terbentuk; Active = scaler sedang memicu; Fallback = scaler gagal dan fallback aktif.

#2. Deep dive ke YAML

Saat deskripsi tidak cukup:

Inspeksi YAML penuh

kubectl get scaledobject order-worker -n orders -o yaml
kubectl get scaledobject order-worker -n orders -o jsonpath="{.status.conditions[?(@.type=='Ready')].status}"

Bagian status berisi jawaban: kondisi, alasan, dan pesan error terakhir scaler. Banyak kasus langsung terlihat di sini — misalnya AuthSecret does not exist.

#3. HPA dan Replika Aktual

HPA yang dikelola KEDA

kubectl get hpa -n orders
kubectl get hpa order-worker -n orders -o yaml

KEDA memberi nama HPA sesuai ScaledObject. Jika HPA tidak ada, KEDA belum berhasil membuatnya — biasanya soal RBAC atau validasi. Jika HPA ada tapi replika tidak naik, lihat kubectl get pods -n orders untuk kondisi pod (Pending, CrashLoopBackOff).

#4. Log Operator dan Metrik

kubectl logs -n keda deploy/keda-operator --tail=100
kubectl logs -n keda deploy/keda-operator -f | grep -iE "error|failed"
kubectl port-forward -n keda deploy/keda-operator 8080:8080

Operator menuliskan semua aktivitas scaler ke stdout. Metrik Prometheus keda_scaler_* diekspos di port 8080 — pelajaran yang sudah kita mulai di episode 15. Grafana bisa memvisualisasikannya:

groups:
  - name: keda.rules
    rules:
      - alert: ScaledObjectNotReady
        expr: keda_scaledobject_ready == 0
        for: 5m
        labels:
          severity: warning

#Masalah Umum & Solusinya

#Scaler Tidak Aktif karena Activation Threshold

Gejala: antrean penuh, Active bernilai false, replika tetap nol. Penyebab paling sering: nilai metrik masih di bawah activationThreshold. Periksa dengan:

curl -s localhost:8080/metrics | grep keda_scaler_metrics_value
kubectl get scaledobject order-worker -n orders -o jsonpath="{.status.scaleMetricName}"

Jika keda_scaler_metrics_value di bawah threshold, bukan bug — memang desainnya. Naikkan threshold atau kurangi sensitivitas jika itu bukan yang diinginkan.

#HPA Tidak Diperbarui

Gejala: ScaledObject Ready, tapi replika tidak bergerak meski metrik tinggi. Periksa dua hal: apakah HPA membaca metrik eksternal, dan apakah Deployment scaleTargetRef benar.

kubectl describe hpa order-worker -n orders
kubectl get apiservice v1beta1.external.metrics.k8s.io

Jika external.metrics.k8s.io tidak terdaftar atau metrics server KEDA tidak merespons, HPA tidak punya sumber metrik. Restart metrics server: kubectl rollout restart deploy/keda-adapter -n keda.

#Authentication Gagal: Secret Tidak Ditemukan

Gejala: status ScaledObject menampilkan error AuthSecret does not exist atau 403 dari provider. Penyebab: nama secret di secretTargetRef tidak cocok, atau secret ada di namespace lain sedangkan TriggerAuthentication bersifat namespaced.

kubectl get secret -n orders
kubectl get triggerauthentication sqs-auth -n orders -o yaml
kubectl get secret sqs-creds -n orders -o jsonpath="{.data.AWS_ACCESS_KEY_ID}"

Periksa key yang dirujuk secretTargetRef.key benar-benar ada di secret. Untuk kredensial lintas namespace, ganti dengan ClusterTriggerAuthentication (episode 14).

#Webhook Error

Gejala: kubectl apply ScaledObject menolak dengan pesan Internal error occurred: failed calling webhook. Penyebab: pod keda-admission tidak sehat, atau konfigurasi memang invalid menurut validating webhook.

kubectl get pods -n keda -l app=keda-admission
kubectl logs -n keda deploy/keda-admission --tail=50
kubectl get validatingwebhookconfigurations | grep keda

Baca pesan lengkap error-nya — validating webhook memberi tahu field mana yang melanggar. Jika webhook sendiri mati, perbaiki pod-nya dulu; tanpa webhook, resource KEDA tetap bisa diterapkan (Kubernetes gagl-open behavior).

#Status Unknown

Gejala: kolom Ready/Active menampilkan Unknown. Ini biasanya berarti operator tidak bisa mengeksekusi scaler — credential timeout, DNS provider gagal, atau query tidak valid. Lihat pesan kondisi dan log operator:

kubectl get scaledobject order-worker -n orders -o jsonpath="{.status.conditions}"
kubectl logs -n keda deploy/keda-operator | grep -i "order-worker"

Salah satu penyebab klasik: query Prometheus yang mengandung karakter pipeline belum di-escape, sehingga metric parse gagal. Pastikan query di metadata menggunakan bentuk yang sudah disanitasi untuk YAML.

#Kesalahan Umum dalam Diagnosa

1. Hanya melihat status tanpa log. Status adalah gejala; log operator adalah akar masalah.
2. Lupa mengecek TriggerAuthentication. Error auth sering disalahartikan sebagai masalah scaler.
3. Mengabaikan keda_scaledobject_ready == 0. Autoscaler mati diam-diam jauh sebelum antrean menumpuk.
4. Mengetes HPA tanpa menunggu pollingInterval. Kesimpulan yang diambil terlalu cepat mengarahkan ke arah yang salah.
5. Menyalahkan KEDA saat Deployment-nya CrashLoopBackOff. Replika tidak naik bisa jadi karena pod-nya sendiri tidak sehat, bukan scaler.

#Penutup

Episode ini memberi kalian peta diagnosa: mulai dari status ScaledObject dan YAML penuh, lanjut ke HPA dan pod, lalu log operator dan metrik keda_scaler_*. Kita juga menutup enam masalah umum: activation threshold, HPA tak ter-update, auth gagal, webhook error, dan status Unknown — masing-masing dengan perintah periksa yang pasti.

Poin yang harus kalian bawa:

• Urutan diagnosa: status → YAML → HPA → log operator → metrik.
• keda_scaler_metrics_value dan keda_scaledobject_ready adalah dua metrik paling penting.
• Error auth biasanya soal secretTargetRef atau namespace trigger authentication.
• Status Unknown = operator tidak bisa mengeksekusi scaler, bukan konfigurasi.
• Selalu tunggu satu siklus polling sebelum menarik kesimpulan.

Setelah bisa memecahkan masalah, waktunya menyempurnakan perilaku. Di episode 19 selanjutnya kita membahas Performance & Tuning: pollingInterval vs cooldownPeriod yang optimal, kalkulasi saturation replica per pesan, menghadapi throttling API provider, serta cara mengukur latency scale-up dan trade-off biaya vs responsivitas. Sampai jumpa di episode 19!