Belajar Podman - Observability & Operations

#Pendahuluan

Di episode 19 kalian menjalankan Podman di laptop lewat Podman Machine dan mengelola semuanya dari Podman Desktop. Episode 20 ini kembali ke sisi operasi yang sesungguhnya: begitu container kalian berjalan di server, kalian perlu tahu apakah container itu sehat, berapa sumber daya yang dipakainya, dan apa yang sedang terjadi di dalamnya. Materi ini adalah bekal utama untuk shift on-call: observability dan troubleshooting.

#Memantau Sumber Daya: podman stats

podman stats adalah dashboard real-time untuk pemakaian sumber daya container — CPU, memori, dan I/O jaringan. Tanpa argumen, perintah ini menampilkan semua container yang berjalan dan memperbarui datanya secara periodik:

podman stats
podman stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Dengan --no-stream, output hanya ditampilkan satu kali — cocok untuk skrip atau pengambilan snapshot. Opsi --format memungkinkan kalian memilih kolom tertentu. podman stats adalah tempat pertama yang harus kalian tuju saat sebuah layanan terasa lambat: apakah container kehabisan memori, atau CPU sedang jenuh.

#Mengikuti Aktivitas: podman events

Tidak seperti podman stats yang memberi gambaran sesaat, podman events memberikan jejak waktu: setiap kejadian penting — start, stop, die, health_status, dan lain-lain — direkam dengan timestamp:

podman events --since 1h
podman events --filter container=myapp --filter event=die

Filter membantu kalian menyaring kejadian yang relevan, misalnya container tertentu yang mati berulang kali. Kebiasaan yang baik di produksi: menyimpan aliran podman events ke file log atau pipeline monitoring, sehingga kalian bisa merekonstruksi urutan kejadian saat terjadi insiden. Ini adalah jembatan dari observability dasar menuju audit trail.

#Melihat Proses di Dalam Container: podman top

Untuk melihat proses yang sedang berjalan di dalam container, gunakan podman top. Sintaksnya meniru ps, karena outputnya memang dihasilkan dari namespace proses container:

podman top myapp
podman top myapp -eo pid,user,comm,args

Baris pertama menampilkan proses default; baris kedua memakai opsi gaya ps untuk memilih kolom. Saat sebuah container mengalami lonjakan CPU atau fork-bomb, podman top membantu kalian menemukan proses mana yang bersalah di dalam container — tanpa harus masuk dengan shell.

#Healthcheck: Menjaga Container Tetap Sehat

Menjalankan container itu mudah; mengetahui bahwa container masih berfungsi adalah tantangan tersendiri. Healthcheck adalah perintah yang dijalankan Podman secara berkala di dalam container untuk menentukan status kesehatannya: healthy, unhealthy, atau starting.

#Mendeklarasikan di Containerfile

FROM nginx:1.27
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
    CMD curl -f http://localhost/ || exit 1

Instruksi HEALTHCHECK menjalankan perintah curl setiap 30 detik; jika gagal tiga kali berturut-turut, container dianggap unhealthy.

#Memasang saat Run

Kalian juga bisa memasang healthcheck dari luar tanpa mengubah image, menggunakan --health-cmd dan flag pendampingnya:

podman run -d --name myapp \
    --health-cmd "curl -f http://localhost:8080/health" \
    --health-interval 15s --health-timeout 3s --health-retries 3 \
    myapp:latest
podman healthcheck run myapp

--health-cmd menentukan perintah, --health-interval frekuensi, --health-timeout batas waktu eksekusi, dan --health-retries jumlah kegagalan sebelum status berubah menjadi unhealthy. podman healthcheck run memicu pemeriksaan manual. Perhatikan bahwa --health-cmd membutuhkan tool di dalam container (seperti curl atau wget); untuk image sekecil mungkin, buat perintah healthcheck yang memakai tool yang sudah ada di image.

Status kesehatan juga muncul sebagai event health_status di podman events, sehingga healthcheck dan events bekerja sebagai satu kesatuan: perubahan status kesehatan terekam otomatis dalam jejak events kalian.

#Integrasi Metrics

Untuk pemantauan jangka panjang, kalian tentu ingin mengumpulkan metrics ke Prometheus atau Grafana. Perlu jujur disebutkan: tidak seperti Docker daemon yang mengekspos endpoint /metrics bawaan, Podman belum menyediakan endpoint metrics serupa di dalam engine-nya. Pendekatan yang umum dipakai:

• Memasang exporter khusus seperti prometheus-podman-exporter yang menerjemahkan data podman stats menjadi format Prometheus.
• Membuat kolektor sendiri yang menjalankan podman stats --no-stream secara berkala dan mem-push hasilnya.
• Mengumpulkan log dan events (podman events) lewat agent log seperti Loki atau syslog.

Dengan pola ini, data podman stats dan podman events yang kalian kenal dari CLI bisa menjadi dasar dashboard Grafana dan alerting — walau tanpa endpoint bawaan, observability tetap bisa dibangun dari sisi klien.

#Troubleshooting: Ketika Sesuatu Salah

Ketika container bermasalah, jalankan pemeriksaan dengan urutan yang sistematis dari luar ke dalam.

#Diagnosis Awal: podman info --debug

podman info --debug menampilkan informasi menyeluruh tentang environment kalian — versi Podman, storage driver, network backend, konfigurasi, hingga rootless container storage. Saat melaporkan bug atau mengajukan pertanyaan di forum, output perintah ini adalah informasi pertama yang diminta karena hampir semua masalah akar ada di lingkungan:

podman info --debug

Perhatikan bagian networkBackend dan networkBackendInfo — di sinilah kalian melihat apakah Podman memakai netavark dengan aardvark-dns, dan apakah dukungannya aktif.

#Logs

Log aplikasi container diambil lewat podman logs. Mulailah dengan melihat bagian akhir, lalu putuskan apakah perlu memeriksa lebih jauh:

podman logs --tail 100 myapp
podman logs -f myapp

--tail membatasi baris terakhir, -f mengikuti log secara streaming. Jika log aplikasi kosong, cek kembali apakah aplikasi menulis ke stdout/stderr — Podman hanya menangkap output standar, bukan file log internal aplikasi.

#Events sebagai Kunci Diagnosa

podman events membantu menjawab pertanyaan "kenapa container mati?". Cari event die, stop, atau health_status di sekitar waktu kejadian, lalu cocokkan dengan log. Gabungan podman events --since dan podman logs adalah pasangan diagnosis pertama yang paling efektif.

#Diagnosa Networking Rootless

Masalah jaringan di mode rootless punya gejala khas sendiri. Beberapa titik cek:

• Pastikan backend networking yang aktif: cek networkBackend di podman info.
• Periksa status port yang dipublikasikan: podman ps memperlihatkan pemetaan port, lalu uji dengan curl dari host.
• Untuk pemetaan port rootless, Podman memakai pasta (atau slirp4netns di versi lama). Log proses networking ini bisa menjadi petunjuk saat port tidak bisa diakses dari luar.
• Pastikan layanan di dalam container benar-benar mendengarkan di interface yang dimaksud, bukan hanya di localhost container: jalankan podman exec myapp ss -tlnp untuk melihat socket yang terbuka.

Diagnosa networking rootless hampir selalu bermuara pada tiga kemungkinan: proses pasta/slirp bermasalah, port salah di-publish, atau aplikasi di dalam container hanya mendengarkan di alamat yang salah.

#Penutup

Pada episode 20 ini, kalian menguasai sisi observability dan operasi Podman: memantau resource dengan podman stats, mengikuti jejak kejadian dengan podman events, memeriksa proses dengan podman top, menjaga kesehatan container lewat HEALTHCHECK dan --health-cmd, membangun integrasi metrics ke Prometheus, serta men-debug masalah lewat podman info --debug, logs, events, dan diagnosis networking rootless.

Inti yang harus dibawa pulang:

• podman stats untuk masa sekarang, podman events untuk jejak masa lalu — keduanya saling melengkapi.
• Healthcheck adalah jendela kesehatan aplikasi — pasang dari Containerfile atau --health-cmd, dan pantau statusnya lewat events.
• podman info --debug adalah langkah pertama troubleshooting — selalu lampirkan outputnya saat bertanya.
• Networking rootless didiagnosa dari backend-nya — cek netavark/pasta, publikasi port, dan socket di dalam container.

Di episode 21 berikutnya, kita melihat ke depan: Fitur Modern & Roadmap — apa yang dibawa Podman 6.0 dan 6.1, termasuk config file rework, Quadlet overhaul, netavark/aardvark-dns v2, hingga roadmap menuju CNCF incubation.