Monitor CPU, Memory, dan Logs Aplikasimu Langsung dari Dashboard Helipod

Deploy aplikasi ke production bukan berarti pekerjaan selesai. Kamu perlu tahu: apakah aplikasi berjalan normal? Apakah ada memory leak? Apakah error rate meningkat setelah deploy terbaru?

Helipod menyediakan monitoring built-in langsung dari dashboard — tanpa perlu setup Prometheus, Grafana, atau tool monitoring terpisah. Semua tersedia di tab Metrics dan halaman Logs.

Tab Metrics — Per Service

Buka service apapun di dashboard Helipod, klik tab Metrics. Kamu akan melihat 4 angka utama di bagian atas:

CPU

Tampil dalam millicores (m). 1000m = 1 vCPU.

• 0.0m — pod idle, tidak ada request masuk
• 50m — 5% dari 1 vCPU
• 500m — 50% dari 1 vCPU (mulai perlu perhatian)
• 1000m+ — penuh, pertimbangkan scale up atau optimize

Memory

Tampil dalam MB dengan keterangan limit plan.

Contoh: 325 MB · 31.0% of 1024MB limit

Memory yang stabil di angka tertentu adalah normal. Yang perlu diwaspadai adalah memory yang terus naik secara linear dari waktu ke waktu — ini indikasi memory leak.

Restarts

Jumlah restart otomatis yang terjadi sejak pod terakhir deploy.

• 0 — pod stabil, tidak ada crash
• 1-3 — ada masalah, perlu investigasi tapi tidak kritis
• 5+ — ada masalah serius, cek App logs segera

Restart terjadi saat:

• Container crash (aplikasi error fatal)
• Out of memory (OOM) — Kubernetes kill container karena melebihi memory limit
• Health check gagal berkali-kali

Uptime

Durasi sejak pod terakhir start. Uptime yang panjang (hari/minggu) artinya pod stabil.

Jika uptime reset padahal kamu tidak melakukan redeploy, berarti ada crash atau OOM yang memicu restart otomatis.

Time Range Selector

Di bagian atas chart, ada pilihan time range: 5 min, 15 min, 30 min, 1 hour, 3 hours, 6 hours, 1 day.

Gunakan strategi ini:

• 5–15 min — debugging real-time, lihat apa yang terjadi sekarang
• 1 hour — investigasi insiden yang baru terjadi
• 6 hours / 1 day — analisis pola traffic harian, identifikasi jam sibuk

Chart CPU Usage

Chart CPU menampilkan penggunaan CPU dalam cores per waktu. Perhatikan pola:

Pola normal:

• Traffic patterns yang mengikuti jam kerja (pagi–siang tinggi, malam rendah)
• Spike singkat saat ada burst traffic, lalu kembali normal
• Idle rendah (<10m) di luar jam sibuk

Pola yang perlu perhatian:

• CPU yang terus tinggi tanpa spike — mungkin ada infinite loop atau blocking operation
• Spike sangat tinggi lalu drop ke 0 — kemungkinan OOM kill
• CPU flatline di limit — pod throttled, perlu scale up CPU

Chart Memory Usage

Memory lebih predictable dibanding CPU. Pola normal:

Healthy: Memory naik saat startup, stabil di angka tertentu, tidak terus naik.

Memory leak: Memory naik terus secara linear dari waktu ke waktu. Restart memperbaiki sementara, lalu naik lagi.

OOM (Out of Memory): Memory naik sampai mendekati limit → tiba-tiba drop ke 0 → Restarts counter naik. Ini artinya Kubernetes kill container karena melebihi memory limit.

Solusi OOM:

1. Scale up memory di Settings → Scaling & Resources
2. Atau investigasi memory leak di kode

Analytics Multi-Pod

Di sidebar kiri dashboard, ada halaman Analytics (ikon chart) yang menampilkan metrics semua pod dalam satu project sekaligus.

Tampilan mencakup 4 chart:

• CPU Usage — semua service dalam satu grafik, tiap service punya warna berbeda
• Memory Usage — bandingkan memory usage antar service
• Network In — traffic masuk ke setiap pod
• Network Out — traffic keluar dari setiap pod

Ini sangat berguna untuk:

• Identifikasi service mana yang paling banyak konsumsi resource
• Korelasi antara traffic masuk dan CPU usage
• Deteksi service yang anomali dibanding yang lain

Cara Baca Chart Multi-Pod

Dari screenshot dashboard yang menampilkan 6 service (craftify, db-ui, samudrait, analytic, monitoring, postgres), kamu bisa langsung lihat:

• Service monitoring (pink) konsumsi CPU paling tinggi
• Service postgres (kuning) Memory-nya kecil tapi Network Out-nya besar — normal untuk database
• Service lain idle hampir 0 CPU — artinya traffic sedikit

Halaman Logs Real-time

Klik ikon Logs di sidebar kiri (ikon terminal/list) untuk membuka halaman Logs.

Filter Logs

Di bagian atas, kamu bisa:

Filter by Pod — dropdown "All pods (6)" untuk melihat semua log, atau pilih pod spesifik.

Search — ketik keyword untuk filter log. Tekan / untuk focus ke search bar (keyboard shortcut).

Time range — pilih rentang waktu yang ingin dilihat.

Kolom Logs

Warna Log

• Putih/abu — log normal (INFO, access log)
• Merah — error log — langsung terlihat tanpa perlu scroll

Dari contoh logs di dashboard, terlihat:

• Error berwarna merah: [error] 34#34: *5570 open() "/usr/share/nginx/html/robots.txt" failed
• Log normal berwarna putih: "GET / HTTP/1.1" 200 60638

Cara Baca Access Log

Format access log nginx (standar):

10.42.4.44 - [27/Apr/2026:08:11:44 +0000] "GET / HTTP/1.1" 200 60638 "-" "Uptime-Kuma/1.23.17" "10.42.5.0"

• 10.42.4.44 — IP client (internal jika dari load balancer)
• GET / HTTP/1.1 — method, path, protokol
• 200 — HTTP status code
• 60638 — response size (bytes)
• Uptime-Kuma/1.23.17 — User-Agent (ini health check dari Uptime Kuma)

Pattern Error yang Perlu Diperhatikan

404 Not Found yang banyak:

"GET /robots.txt HTTP/1.1" 404
"GET /wp-admin HTTP/1.1" 404
"GET /.env HTTP/1.1" 404

Ini normal untuk scanner internet yang mencoba file sensitif. Tidak perlu khawatir.

500 Internal Server Error:

"POST /api/users HTTP/1.1" 500

Ini error di aplikasi — perlu investigasi di App logs (bukan Build logs).

OOM Kill: Di App logs, lihat apakah ada log terpotong tiba-tiba diikuti restart. Ini indikasi OOM.

Build Logs vs App Logs

Di tab Deployments, setiap deployment punya dua tombol log:

Build logs — output dari proses build Docker image. Berguna untuk debug jika deployment gagal saat build.

App logs — output dari aplikasi yang sedang berjalan (stdout/stderr). Berguna untuk debug error runtime.

Kebanyakan masalah production ada di App logs — bukan Build logs.

Tips Monitoring Efektif

1. Baseline dulu Pantau metrics 2–3 hari pertama setelah deploy untuk tahu baseline normal CPU dan Memory aplikasimu. Ini referensi untuk deteksi anomali di masa depan.

2. Set alert eksternal Helipod menampilkan metrics real-time, tapi belum punya fitur alert bawaan. Untuk notifikasi proaktif, integrasikan dengan Uptime Kuma, Better Uptime, atau service monitoring eksternal yang ping health endpoint-mu.

3. Health endpoint yang informatif Buat endpoint /health yang return status database, Redis, dan dependencies kritis — bukan hanya {"status": "ok"}. Ini membantu identifikasi masalah sebelum user merasakannya.

4. Structured logging Gunakan JSON logging di aplikasimu agar log lebih mudah dibaca dan dicari di Helipod:

# Python dengan structlog
import structlog
log = structlog.get_logger()
log.info("user_login", user_id=123, email="user@example.com")

// NestJS dengan JSON logger
import { Logger } from '@nestjs/common';
const logger = new Logger('UserService');
logger.log(`User ${userId} logged in`);

5. Monitor setelah setiap deploy Buka tab Metrics dengan time range 15 menit setelah setiap deployment. Pastikan tidak ada spike CPU/Memory yang abnormal atau peningkatan Restarts.

Menentukan Resource yang Tepat

Gunakan data dari tab Metrics untuk menentukan resource yang optimal:

CPU terlalu rendah (throttled):

• CPU chart flatline di angka tinggi
• Response time meningkat
• Solusi: naikkan CPU di Settings → Scaling & Resources

Memory terlalu rendah (OOM):

• Memory chart naik ke limit lalu reset
• Restarts counter naik
• Solusi: naikkan Memory di Settings

Resource overkill (terlalu besar):

• CPU selalu < 10% dari yang dialokasikan
• Memory selalu < 30% dari limit
• Solusi: turunkan spec untuk hemat biaya

Kesimpulan

Monitoring di Helipod dirancang agar developer bisa langsung tahu kondisi aplikasi tanpa perlu setup tool terpisah. CPU, Memory, Uptime, Restarts — semua tersedia real-time di dashboard.

Yang terpenting: pantau metrics secara rutin, terutama setelah deploy baru. Jangan tunggu user lapor error untuk mulai investigasi.

Ingin belajar cara menggunakan Terminal untuk debug langsung ke container? Baca Terminal Live di Helipod.

Punya pertanyaan? Hubungi kami di support@helipod.id atau bergabung ke komunitas di hangar.helipod.io.