Monitoring

Host

CPU, RAM, storage — tiap 2 detik, 5 menit

Container

CPU, memori, jaringan — 1 jam live, 24h/7d/30d tersimpan

Limit

CPU millicore & memori MiB per app/database

Di mana melihatnya

1. 01DashboardCPU/RAM/Storage host live + kartu Host & Disk Docker (owner/admin)
2. 02Aplikasi → DeployKPI CPU / memori / jaringan + sparkline
3. 03DatabaseKPI yang sama di atas panel
4. 04Docker → strip diskrincian image/volume/container/cache + cleanup (Detail)

Dashboard: host live

Untuk owner/admin, Dashboard menampilkan tiga grafik 5 menit terakhir (sampel tiap 2 detik, di-poll hanya saat tab terlihat):

Di bawah grafik ada kartu Aktivitas terakhir (hanya owner/admin): 10 entri audit log terbaru dengan waktu, pelaku, aksi dalam bahasa yang mudah dibaca (mis. “Deploy aplikasi”, “Hapus database”), status, dan lewat apa (sesi, API token, webhook). Disegarkan tiap 30 detik selama tab terlihat; tautan Lihat semua membuka halaman Audit log. Isi request tidak ditampilkan di kartu ini.

Di container Docker, /proc/stat dan /proc/meminfo adalah milik host, jadi angkanya = host tanpa panggilan Docker per tick. Riwayat 150 titik di memori API (hilang saat restart).

Kartu Host & Disk Docker

• Host: versi Docker, container running/total, serta CPU dan memori yang dipakai container aoox (dari docker info + sampler).
• Disk Docker: meter bertumpuk image / volume / container / build cache (dari docker system df) — bukan seluruh filesystem host; untuk itu lihat grafik Storage.
• Ringkasan project: berapa project yang punya sesuatu yang running (aplikasi, database, atau stack).

Halaman Docker

Container sisa. Project dan aplikasi yang dihapus di versi aoox lama meninggalkan container yang masih berjalan lengkap dengan label Traefik-nya, sehingga sisa itu bisa tetap melayani domain lamanya. Dialog Detail pada strip disk menampilkannya (nama, jenis, status) bila ada: container di host aoox yang project, aplikasi, database, atau stack-nya sudah tidak ada. Owner bisa menghapus satu per satu lewat tombol tempat sampah, atau mencentang Sekalian hapus container sisa sebelum Bersihkan sekarang (mati secara default, juga di pembersihan malam). Panel aoox sendiri, proxy, registry, helper build dan job, serta apa pun yang tidak bisa dikaitkan ke resource yang sudah dihapus tidak pernah ditampilkan. Volume tidak ikut dihapus; pakai opsi volume yatim. Server remote tidak tercakup.

Infrastruktur → Docker (owner/admin) menampilkan container, image, volume, dan network di host atau di server remote (pilih server di atas tab; item Docker ada di grup Platform pada sidebar). Container, image, volume, dan network milik aoox diberi lencana (kolom Managed by aoox) dan hanya ditampilkan; container aoox (panel, proxy, registry, aplikasi, database, stack) tidak bisa dihentikan atau dihapus dari sini — gunakan halaman resource-nya.

• Container: semua, termasuk yang berhenti. Untuk yang bukan milik aoox: log (satu kali ambil, maks 500 baris), start, stop, restart, dan hapus (khusus owner, dengan konfirmasi).
• Image: hapus image yang tidak dipakai container mana pun, atau bersihkan yang dangling. Image yang dipakai ditolak.
• Volume dan Network: daftar saja, lengkap dengan ukuran, pemakai, dan penanda volume yatim milik aoox.

Metrik per container

Tab Deploy aplikasi dan halaman database punya baris KPI CPU / Memori / Jaringan dengan sparkline: sampel tiap 15 detik. Pemilih rentang di atas grafik menentukan dari mana datanya diambil:

• Sampel 15 detik diringkas menjadi satu baris per menit per aplikasi/database (task swarm dijumlahkan), lalu dirata-rata menjadi baris per jam.
• Baris menit dipangkas setelah 48 jam; baris jam setelah METRICS_RETENTION_DAYS hari (default 30).
• Karena tersimpan di database, riwayat bertahan saat API restart — hanya jendela 1 jam terakhir yang bersifat live.

• current: null bila container stop atau belum ada sampel (baru start < 15 detik).
• I/O disk per container tidak tersedia di Docker Desktop, jadi tidak ditampilkan.
• Container berlabel komponen aoox (app, database) disampel lewat satu stream; container stack compose lewat stream kedua yang dikenali dari nama project compose (aoox-<slug>) — job dan helper build tetap tidak disampel.
• Aplikasi di server remote tidak disampel — sampler hanya membaca daemon host aoox.
• Untuk aplikasi mode service, metrik adalah jumlah task yang berjalan di host — lihat Docker Swarm.

Batas sumber daya

Aplikasi (Pengaturan) dan database (kartu Batas sumber daya) punya CPU (millicore) dan Memori (MiB). 1000 millicore = 1 core; kosong = tanpa batas.

CPU 500    → maksimal setengah core (NanoCpus 0.5e9)
Memori 512 → limit keras 512 MiB, tanpa swap (MemorySwap = Memory)

• Container yang melewati limit memori di-OOM-kill oleh kernel → restart oleh Docker → notifikasi container mati bila berulang. Cek sparkline memori sebelum menurunkan limit.
• Preview PR dan job Container terpisah mewarisi limit aplikasinya.
• Stack compose: atur deploy.resources di file compose.

Deteksi container mati

API menjaga stream docker events (die) untuk container berlabel aoox, plus stream kedua untuk container stack compose (dikenali dari nama project). Setelah jeda 5 detik ia memutuskan:

Aktifkan di Notifikasi → toggle Container mati. Berlaku untuk host lokal dan untuk aplikasi di server remote (pesannya menyebut nama server).

Monitor HTTP (opsional)

Container yang hidup belum tentu sehat: aplikasi bisa mengembalikan 5xx atau macet tanpa pernah mati. Nyalakan pemeriksaan HTTP per aplikasi di tab Pemantauan (developer ke atas mengubah, viewer hanya melihat).

Yang diperiksa, dan dari mana

• Host tidak pernah kamu ketik. Targetnya diturunkan dari aplikasi itu sendiri: domain pertamanya (URL publik lewat proxy, jadi jalur proxy ikut teruji); bila tidak ada, port host (host:port, untuk server remote alamat server itu); bila tidak ada juga, nama container di jaringan aoox (hanya bila API berjalan di jaringan itu, yaitu stack distribusi). Target yang dipakai ditampilkan di tab. Dengan begitu panel tidak bisa diarahkan untuk memindai jaringan internal atau metadata cloud.
• Pengalihan diikuti maksimal 3 kali dan hanya ke host dan port yang sama; pengalihan ke tempat lain tidak diikuti (status 3xx-nya yang dinilai). Isi respons dibaca sampai batas kecil lalu dibuang — tidak pernah disimpan.
• Pemeriksaan berjalan dari mesin panel: itu tidak membuktikan aplikasi bisa dijangkau dari internet luar, dan dengan domain publik hasilnya bisa terpengaruh hairpin NAT.

Kapan dicek, kapan diam

• Hanya aplikasi yang running. Aplikasi yang di-stop bukan "down": monitornya hanya kembali ke "belum dicek".
• Tidak dicek selama deploy berjalan dan 60 detik sesudahnya, dan deret gagal yang melewati deploy dimulai dari nol — jadi deploy tidak memicu alert.
• Status terakhir disimpan di database, jadi API yang restart di tengah gangguan tidak mengumumkannya lagi dan tidak mengirim "down" palsu untuk aplikasi yang sehat.

Notifikasi, uptime, dan riwayat

Setelah jumlah kegagalan beruntun tercapai, satu notifikasi Monitor HTTP gagal dikirim (pengingat maksimal tiap 6 jam selama masih down) dan satu pesan pulih dengan lama down saat sehat lagi — lihat Notifikasi. Tab Monitor menampilkan status, uptime 24 jam dan 7 hari, latensi rata-rata dan p95, grafik latensi 24 jam, dan daftar kejadian down terakhir. Hasil disimpan 7 hari; isi respons tidak pernah disimpan. Konfigurasi monitor ikut ekspor/impor project (tanpa riwayat).

Peringatan sumber daya (opsional)

Dapatkan notifikasi saat aplikasi atau database terus-menerus memakai CPU atau memori terlalu banyak. Masing-masing punya kartu Peringatan sumber daya: pada aplikasi ada di bawah monitor HTTP di tab Pemantauan, pada database di tab Ringkasan. CPU dan memori adalah aturan terpisah.

• CPU adalah persen dari satu core, angka yang sama dengan grafik, jadi bisa lebih dari 100 pada beberapa core (tidak dibagi limit CPU).
• Memori adalah persen dari batas memori container, atau dari RAM host bila batas belum diatur (lihat Batas sumber daya).
• Pengecekan berjalan tiap menit dari metrik per menit yang tersimpan, jadi aplikasi di server remote ikut tercakup. Peringatan datang sekitar semenit setelah nilai berada di atas ambang selama seluruh durasi; satu menit data yang hilang ditoleransi, dan data yang kosong tidak pernah dianggap tinggi.
• Sebuah aturan memperingatkan sekali, mengingatkan tiap 6 jam selama nilai tetap tinggi, dan mengirim satu pesan kembali normal saat turun. Tiap aturan menampilkan lencana (normal / memeriksa / memperingatkan) dan pembacaan terakhir.
• Tidak ada yang dikirim saat aplikasi atau database berhenti atau saat aplikasi sedang deploy, dan pembacaan sebelum deployment terakhir selesai tidak dihitung. Mengubah aturan mengatur ulang statusnya tanpa pesan.
• Status disimpan, jadi restart API tidak mengulang peringatan dan tidak melupakan pelanggaran yang sedang berlangsung.
• Pesan dikirim ke setiap kanal yang sakelar peringatan CPU atau memori-nya aktif (aktif secara default) dan ke lonceng notifikasi — lihat Notifikasi. Developer ke atas mengubah aturan; viewer hanya melihat. Aturan ikut ekspor/impor project.

Peringatan disk menipis

Sekali sehari (pukul 07:00 waktu API) aoox mengukur pemakaian filesystem tempat data Docker berada. Bila melewati ambang — default 90 %, ubah dengan DISK_ALERT_PERCENT — event diskLow dikirim ke channel notifikasi yang mengaktifkannya, maksimal sekali sehari selama masih di atas ambang.

Tindak lanjutnya biasanya Bersihkan sekarang di strip disk di atas halaman Docker, menurunkan retensi deployment, atau memangkas backup lama — lihat Registry.

Jebakan umum

Langkah berikutnya