Belajar Authentik - Monitoring & Performance
Episode 25 of 31

Belajar Authentik - Monitoring & Performance

Mengawasi Authentik dengan Prometheus dan Grafana: memanfaatkan endpoint metrik di port 9300, memahami metrik kunci seperti keberhasilan dan kegagalan login serta latensi, mengatur level log dan structured logging, menjaga kesehatan database dan Redis, serta menyusun alerting yang tepat.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 24 kalian menempatkan Authentik di Kubernetes — server dan worker yang berjalan sebagai Deployment, database dan Redis sebagai stateful service. Deployment yang sehat hari ini tidak menjamin sehat besok; database bisa penuh, worker bisa tertinggal, atau pola login aneh mulai muncul dari satu alamat IP. Itulah mengapa episode ini datang tepat waktu: monitoring.

Authentik adalah identity provider, dan ini membuatnya istimewa dalam satu hal: ia adalah titik kegagalan tunggal bagi seluruh ekosistem aplikasi. Ketika Authentik turun, semua aplikasi yang melayani autentikasi ikut terkunci — jauh lebih mahal daripada sekadar satu website yang error. Bayangkan lampu indikator di kokpit pesawat: pilot tidak peduli berapa banyak lampu, ia peduli lampu mana yang menyala saat ada masalah. Episode ini akan membangun "panel indikator" untuk Authentik kalian.

Health Check Endpoint: Detak Jantung yang Murah

Sebelum berbicara tentang metrik, ada dua endpoint yang harus di-watch setiap saat. Authentik menyediakan endpoint liveness dan readiness yang sederhana namun sangat informatif:

  • /-/health/live/ — mengembalikan 200 selama proses Authentik masih berjalan. Perhatikan trailing slash; tanpa slash, beberapa versi mengembalikan 404.
  • /-/health/ready/ — mengembalikan 200 hanya jika koneksi ke PostgreSQL bisa dijalin. Inilah sinyal "siap menerima trafik".
Cek liveness dan readiness
curl -fsS https://auth.example.com/-/health/live/
curl -fsS https://auth.example.com/-/health/ready/

Untuk worker, gunakan perintah ak healthcheck di dalam container — ia memverifikasi worker berjalan dan database dapat dihubungi. Kedua endpoint inilah yang dipakai Docker Compose dan Kubernetes sebagai probe bawaan; kalian hanya perlu mengeksposnya ke sistem monitoring eksternal agar tercatat sebagai uptime.

Metrik Prometheus di Port 9300

Authentik mengekspos metrik Prometheus di port 9300 — terpisah dari port HTTP utama 9000. Penting: metrik ini tidak memerlukan autentikasi, sehingga portnya sengaja tidak diekspos ke publik. Server, worker, dan setiap outpost semuanya menyediakan endpoint :9300/metrics.

Karena bersifat push ke arah scraper, cukup arahkan Prometheus ke target tersebut:

prometheus.yml — scrape Authentik
scrape_configs:
  - job_name: authentik
    metrics_path: /metrics
    static_configs:
      - targets:
          - authentik-server:9300
          - authentik-worker:9300

Pengguna Kubernetes bisa memanfaatkan ServiceMonitor yang sudah disediakan chart — cukup aktifkan lewat nilai server.metrics.serviceMonitor.enabled dan worker.metrics.serviceMonitor.enabled di values.yaml. Prometheus operator yang menemukan ServiceMonitor akan otomatis mulai scrape. Verifikasi bahwa objeknya benar-benar dibuat dengan kubectl get servicemonitors -n authentik, lalu tunggu beberapa menit dan pastikan target muncul di halaman status Prometheus.

Satu catatan penting soal port 9300: karena metrik tidak butuh autentikasi, pastikan port ini hanya bisa dijangkau dari jaringan internal monitoring. Di Kubernetes, itu berarti Service metrik tidak boleh diekspos keluar; di Compose, jangan memetakan port 9300 ke host.

Metrik Kunci yang Wajib Dipantau

Metrik saja tidak berguna tanpa pemahaman artinya. Kelompokkan menjadi empat kategori dan pertanyakan satu hal dari masing-masing:

KategoriPertanyaan yang dijawabSinyal bahaya
KetersediaanApakah server dan worker hidup?up bernilai 0 atau readiness tidak 200
Lalu lintasBerapa request yang masuk dan darimana?Volume tiba-tiba naik dari IP tertentu
LatensiSeberapa cepat flow autentikasi selesai?Persentil 99 mulai melewati target
Kesehatan bisnisBerapa login sukses dan gagal?Lonjakan kegagalan = indikasi brute force

Dua kategori terakhir layak digarisbawahi. Latensi biasanya diukur lewat histogram duration request; bagi user experience SSO, persentil 99 (bukan rata-rata) adalah angka yang menentukan — karena user yang login 3 detik lebih lama dari biasanya itulah yang mengeluh. Adapun login sukses dan gagal bisa diperoleh dari dua tempat: sistem event di admin (episode 22) yang memberi konteks lengkap siapa, dari mana, dan kapan, serta metrik di sisi server. Kombinasi keduanya menjadi dasar deteksi brute force yang melengkapi reputation system episode 19.

Log Level dan Structured Logs

Log Authentik memakai format terstruktur (key-value) yang nyaman di-parse oleh agregator seperti Loki atau ELK. Level dikontrol lewat variabel AUTHENTIK_LOG_LEVEL, dengan default info. Urutan levelnya: debug, info, warning, error, critical.

Snippet compose — naikkan level log
environment:
  AUTHENTIK_LOG_LEVEL: "debug"

Aturannya: di produksi tetap info — level debug menghasilkan volume log yang sangat besar dan memperlambat. Naikkan sementara ke debug hanya saat investigasi aktif, lalu kembalikan. Log terstruktur ini juga harus dibatasi masa simpannya; agregator dan retention policy mencegah disk penuh dan membantu kepatuhan (episode 22).

Kesehatan Database dan Redis

Readiness endpoint sudah memastikan PostgreSQL bisa dihubungi, tapi itu bukan segalanya. Untuk Postgres, perhatikan jumlah koneksi aktif terhadap max_connections dan keberadaan query lambat. Untuk Redis, perhatikan penggunaan memory terhadap maxmemory dan jumlah evictions — jika Redis terus menge-victim key karena memory penuh, antrian tugas dan cache makin tidak efektif.

Uji koneksi dan cek koneksi aktif
docker compose exec postgresql psql -U authentik -d authentik \
  -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

Redis pada Authentik adalah cache dan message queue — data di dalamnya boleh hilang (itu bukan sumber kebenaran), sehingga Redis yang dipersistensikan biasanya malah membuang resource. Yang penting justru health dan kapasitasnya.

Performance Tuning Dasar

Jika metrik menunjukkan latensi memburuk, urutkan investigasi dari yang paling mungkin:

  1. Database — koneksi melampaui max_connections, atau query lambat. Pertimbangkan connection pooler seperti PgBouncer di depan Postgres, dan periksa index yang dipakai query umum.
  2. Worker tertinggal — antrian tugas menumpuk berarti worker butuh replica lebih atau resource lebih besar.
  3. Redis — pastikan Redis berjalan di storage cepat dan memory cukup; eviction yang agresif menambah beban database.
  4. Server — jika CPU server jenuh sementara DB dan Redis sehat, tambah replica server di belakang load balancer.

Jangan melakukan tuning sebelum mengukur. Baseline dari beberapa minggu data Prometheus adalah kompas yang menunjukkan apakah perubahan konfigurasi benar-benar memperbaiki keadaan.

Alerting: Supaya Kalian Tahu Lebih Dulu

Metrik tanpa alert seperti smoke detector yang hanya berbunyi saat api sudah membakar dapur. Buat aturan alert yang berangkat dari SLO: server down selama 5 menit, persentil 99 latensi melewati ambang, peningkatan tajam login gagal, atau volume metrik tiba-tiba nol (yang bisa berarti scrape gagal).

Contoh alert rule (Prometheus)
groups:
  - name: authentik
    rules:
      - alert: AuthentikDown
        expr: up{job="authentik"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Authentik tidak bisa di-scrape selama 5 menit"

Kirim alert ke Alertmanager, lalu ke kanal komunikasi yang benar-benar dilihat — email, Telegram, Slack, atau PagerDuty. Alert yang berisik justru berbahaya: terlalu banyak alarm menyebabkan "alert fatigue", dan pada akhirnya tidak ada yang diperhatikan saat terjadi insiden nyata.

Penutup

Pada episode 25 ini kalian telah belajar memonitor Authentik secara menyeluruh: endpoint health /-/health/live/ dan /-/health/ready/ untuk ketersediaan, metrik Prometheus di port 9300 untuk server, worker, dan outpost, empat kategori metrik kunci dari ketersediaan hingga kesehatan bisnis, pengaturan level log dan structured logging, pemantauan kesehatan PostgreSQL serta Redis, langkah dasar performance tuning, dan alerting yang mengubah metrik menjadi tindakan.

Inti yang harus kalian bawa:

  • Port 9300 adalah endpoint metrik tanpa autentikasi — jangan diekspos ke publik.
  • Pantau latensi di persentil 99, bukan rata-rata; pantau login gagal untuk mendeteksi brute force.
  • Database dan Redis punya tanda vital masing-masing di luar readiness endpoint.
  • Level debug hanya untuk investigasi; produksi tetap info.
  • Alert yang baik sedikit tapi tepat sasaran, bukan banyak dan berisik.

Sistem yang bisa diawasi adalah sistem yang bisa diselamatkan. Di episode 26 berikutnya kita akan membahas Backup & Disaster Recovery: apa saja yang wajib di-backup (database, blueprint, kunci), cara dump dan restore PostgreSQL dengan benar, prosedur pemulihan bencana, dan alasan mengapa backup yang tidak pernah diuji hanyalah ilusi keamanan. Sampai jumpa di episode 26!

Belajar Authentik - Monitoring & Performance | Belajar Authentik