Belajar GitOps dengan ArgoCD - Monitoring & Observability

#Pendahuluan

Di episode 21 sebelumnya kita membangun rencana disaster recovery yang solid. Namun ada asumsi yang mendasarinya: kita bisa mengetahui ketika sistem mulai menyimpang. ArgoCD adalah controller yang terus merekonsiliasi — tetapi siapa yang merekonsiliasi ArgoCD itu sendiri? Jawabannya: kalian, lewat monitoring & observability. Pada episode ini kita membuka metrik yang diekspos ArgoCD, membangun dasbor Grafana, menyusun alerting yang benar-benar berguna, dan menata log komponen.

Mengapa ini penting? GitOps memindahkan kompleksitas dari "cara deploy" ke "cara menjalankan deployment sebagai sistem". Sebuah ArgoCD yang diam-diam berhenti menyinkronkan (repo server kehabisan memory, Redis down, kredensial kedaluwarsa) adalah bahaya yang sama dengan aplikasi yang error — hanya saja lebih berbahaya karena kegagalannya senyap. Observability membuat kegagalan senyap itu menjadi berisik.

#Metrik ArgoCD

ArgoCD mengekspos metrik Prometheus dari tiga komponen utama:

Metrik paling berharga bagi operasional adalah yang mencerminkan status delivery:

argocd_app_info{namespace="api"} 1
argocd_app_sync_status{name="api",sync_status="Synced"} 1
argocd_app_health_status{name="api",health_status="Healthy"} 1
argocd_app_reconcile_count{name="api"} 4820
argocd_repo_pending_request_total{repo="repo"} 3

argocd_app_sync_status dan argocd_app_health_status adalah inti observability ArgoCD: keduanya menceritakan apakah Git dan cluster setuju serta apakah yang berjalan sehat. argocd_app_reconcile_count memberi petunjuk aktivitas reconciliasi — angka yang tidak naik bisa berarti controller macet.

#Menyiapkan Scraping

Jika memakai kube-prometheus-stack, gunakan ServiceMonitor (sesuaikan nama port dengan Service ArgoCD):

ServiceMonitor untuk ArgoCD

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-controller
  namespace: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-application-controller
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

#Grafana Dashboards

Ekosistem Argo menyediakan dasbor resmi (ID 14592 untuk controller, ID 14593 untuk repo server) yang bisa diimpor langsung ke Grafana. Setelah impor, dasbor menampilkan: jumlah aplikasi per status sync, per status health, laju reconcile, dan error controller.

Untuk kebutuhan khusus, buat dasbor kustom. Tiga panel yang hampir selalu berguna:

• Apps OutOfSync — count(argocd_app_sync_status{sync_status="OutOfSync"}) — satu angka yang menceritakan "berapa aplikasi menyimpang".
• Sync duration — histogram_quantile(0.95, sum(rate(argocd_app_sync_duration_seconds_bucket[5m])) by (le)) — berapa lama sinkronisasi berlangsung; memburuk berarti repo server melambat.
• Reconcile rate — sum(rate(argocd_app_reconcile_count[5m])) by (name) — aktivitas per aplikasi.

count(argocd_app_sync_status{sync_status="OutOfSync",name!=""})

#Observability Aplikasi

Observability ArgoCD tidak berhenti di status sync. Untuk memahami pengalaman pengguna, perluas ke metrik aplikasi:

• Deployment metrics — argocd_app_info dengan label health dan sync sebagai garis waktu pelepasan.
• Sync duration — waktu dari perubahan Git sampai status Synced; tren naik menandakan masalah repo atau banyaknya resource.
• Error rates — metrik HTTP aplikasi (http_requests_total dari episode 20), bukan hanya status deployment.

Pola yang kuat: hubungkan metrik aplikasi ke analisis Rollout (episode 19) sehingga dasbor delivery dan dasbor aplikasi berbicara dari data yang sama. Ketika canary digelar, error rate aplikasi adalah umpan balik yang sama yang dipakai AnalysisTemplate untuk memutuskan promosi.

#Alerting

Metrik tanpa alert adalah arsip. Gunakan Prometheus rules dengan AlertManager untuk menangkap tiga kelas masalah yang paling umum:

groups:
  - name: argocd
    rules:
      - alert: ArgoCDAppSyncFailed
        expr: argocd_app_sync_status{sync_status="Unknown"} == 1
          or argocd_app_health_status{health_status="Missing"} == 1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Sync gagal atau resource hilang"
      - alert: ArgoCDAppOutOfSync
        expr: argocd_app_sync_status{sync_status="OutOfSync"} == 1
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Aplikasi tidak sinkron lebih dari 15 menit"
      - alert: ArgoCDRepoServerDown
        expr: up{job="argocd-repo-server"} == 0
        for: 5m
        labels:
          severity: critical

Catatan penting: alert OutOfSync harus punya for yang cukup lama. Menurut desain, aplikasi selalu OutOfSync sesaat setelah manifest diubah dan sebelum sync selesai — alert tanpa for akan berbunyi di setiap deployment normal. Aturan praktisnya:

• Sync failure / health degraded → segera (severity critical).
• OutOfSync persisten → beri waktu (misal 15 menit).
• Komponen ArgoCD down → segera (semua sync berhenti).

#Logging

Metrik menceritakan apa yang terjadi; log menceritakan mengapa. ArgoCD menulis log ke stdout — kubectl logs -n argocd deployment/argocd-application-controller — tetapi untuk investigasi lintas waktu, agregasikan dengan Loki atau Elasticsearch.

Dua kelas log yang wajib dikumpulkan:

• Log komponen ArgoCD — controller (reconcile, sync operation), repo server (clone, cache), API server (request, audit).
• Log aplikasi — log pods yang dikelola ArgoCD; sumber utama saat debugging.

Untuk Loki dengan Promtail/Alloy, tambahkan scrape_configs sederhana untuk namespace argocd:

scrape_configs:
  - job_name: kubernetes-pods-argocd
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        regex: argocd
        action: keep

Dengan log terkumpul, investigasi masalah menjadi jauh lebih cepat: ambil rentang waktu dari alert, query log controller pada rentang itu, dan temukan akar masalah tanpa membuka terminal di tengah malam.

#Penutup

Episode ini melengkapi ArgoCD dengan mata dan telinga: metrik Prometheus dari controller, API server, dan repo server; ServiceMonitor untuk scraping; dasbor Grafana resmi dan kustom; alerting untuk sync failure, out-of-sync, dan komponen down; observability aplikasi lewat sync duration dan error rate; serta agregasi log dengan Loki.

Poin yang harus kalian bawa:

• argocd_app_sync_status dan argocd_app_health_status adalah metrik inti delivery.
• Alert OutOfSync butuh for agar tidak berbunyi pada deployment normal.
• Dasbor resmi ArgoCD adalah titik awal; panel kustom menjawab pertanyaan tim.
• Metrik aplikasi dan metrik delivery harus berbicara dari data yang sama.
• Log komponen ArgoCD wajib diagregasi untuk investigasi lintas waktu.

Sistem yang terlihat dan bersuara sekarang dimiliki. Namun observability yang baik justru menarik perhatian ke isu yang selama ini tersembunyi — termasuk keamanan. Di episode 23 selanjutnya kita membahas security best practices — autentikasi dan SSO, RBAC, keamanan API, jaringan, hingga keamanan supply chain. Sampai jumpa di episode 23!