---
title: "Monitor CPU, Memory, dan Logs Aplikasimu Langsung dari Dashboard Helipod"
url: "https://helipod.io/blog/monitoring-metrics-helipod"
date: "2026-05-11"
updated: "2026-05-11"
author: "Tim Helipod"
tags: ["monitoring", "metrics", "logs", "helipod", "observability", "performance"]
excerpt: "Monitor CPU, memory, dan logs di Helipod: chart real-time, multi-pod analytics, filter logs, dan cara baca metrics untuk optimasi resource."
---

# 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

| Kolom | Isi |
|-------|-----|
| **Time (WIB)** | Timestamp dalam WIB (Waktu Indonesia Barat) |
| **Pod** | Nama service yang generate log |
| **Deploy** | Commit hash deployment yang sedang berjalan |
| **Replica** | ID replica spesifik |
| **Data** | Isi log |

### 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
# Python dengan structlog
import structlog
log = structlog.get_logger()
log.info("user_login", user_id=123, email="user@example.com")
```

```typescript
// 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](/blog/terminal-live-di-helipod).

Punya pertanyaan? Hubungi kami di [support@helipod.io](mailto:support@helipod.io) atau bergabung ke komunitas di [hangar.helipod.io](https://hangar.helipod.io).