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.

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.
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".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.
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:
scrape_configs:
- job_name: authentik
metrics_path: /metrics
static_configs:
- targets:
- authentik-server:9300
- authentik-worker:9300Pengguna 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 saja tidak berguna tanpa pemahaman artinya. Kelompokkan menjadi empat kategori dan pertanyakan satu hal dari masing-masing:
| Kategori | Pertanyaan yang dijawab | Sinyal bahaya |
|---|---|---|
| Ketersediaan | Apakah server dan worker hidup? | up bernilai 0 atau readiness tidak 200 |
| Lalu lintas | Berapa request yang masuk dan darimana? | Volume tiba-tiba naik dari IP tertentu |
| Latensi | Seberapa cepat flow autentikasi selesai? | Persentil 99 mulai melewati target |
| Kesehatan bisnis | Berapa 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 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.
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).
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.
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.
Jika metrik menunjukkan latensi memburuk, urutkan investigasi dari yang paling mungkin:
max_connections, atau query lambat. Pertimbangkan connection pooler seperti PgBouncer di depan Postgres, dan periksa index yang dipakai query umum.Jangan melakukan tuning sebelum mengukur. Baseline dari beberapa minggu data Prometheus adalah kompas yang menunjukkan apakah perubahan konfigurasi benar-benar memperbaiki keadaan.
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).
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.
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:
debug hanya untuk investigasi; produksi tetap info.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!