Ketika Jaeger Production Tiba-Tiba Down
Dalam lingkungan Kubernetes production, layanan observability memiliki peran yang sangat penting untuk memantau performa aplikasi dan infrastruktur. Salah satu platform yang banyak digunakan adalah Jaeger untuk distributed tracing.
Namun, bagaimana jika suatu hari tim developer melaporkan bahwa Jaeger Production tiba-tiba tidak dapat digunakan?
Artikel ini membahas studi kasus nyata proses troubleshooting Jaeger Production Down pada lingkungan Kubernetes yang menggunakan Cassandra sebagai backend storage dan Longhorn sebagai storage provider. Mulai dari identifikasi gejala, analisis akar masalah, hingga recovery layanan secara bertahap tanpa kehilangan data.
Kronologi Awal Insiden
Tim developer melaporkan bahwa layanan Jaeger tidak dapat diakses dan proses tracing aplikasi berhenti berjalan.
Gejala awal yang ditemukan:
- Jaeger Collector mengalami CrashLoopBackOff
- Jaeger Query tidak dapat mengambil data tracing
- Cassandra menunjukkan status tidak sehat
- Restart pod tidak menyelesaikan masalah
Dari sini proses investigasi dimulai.
Tahap 1: Memeriksa Service Kubernetes
Perintah yang digunakan:
kubectl get svc -n jaeger
Tujuan:
- Memastikan service masih tersedia
- Memastikan service tidak terhapus
- Mengetahui dependency antar komponen
Hasil:
- Service Cassandra masih ada
- Service Collector masih ada
- Service Query masih ada
Kesimpulan:
Masalah bukan berasal dari service Kubernetes yang hilang.
Tahap 2: Memeriksa Endpoint Service
Perintah:
kubectl get endpoints -n jaeger
Tujuan:
Memastikan service memiliki backend pod yang siap menerima request.
Hasil:
jaeger-cassandra : kosong
jaeger-collector : kosong
jaeger-query : kosong
Kesimpulan:
Kubernetes tidak menemukan pod yang siap melayani request.
Tahap 3: Analisis Pod Cassandra
Perintah:
kubectl describe pod jaeger-cassandra-0 -n jaeger
Temuan:
Ready: False
Restart Count: 6386
Exit Code: 100
Indikasi kuat:
- Cassandra gagal startup
- Cassandra restart terus-menerus
- Cassandra menjadi kandidat utama penyebab outage
Tahap 4: Analisis Log Cassandra
Perintah:
kubectl logs -n jaeger jaeger-cassandra-0
Ditemukan error:
CommitLogReadException
Mutation checksum failure
CommitLog-6-xxxxxxxxxxxx.log
Apa Arti Error Ini?
Cassandra menyimpan transaksi ke dalam CommitLog sebelum ditulis ke SSTable.
Jika file CommitLog mengalami kerusakan (corrupt), Cassandra dapat gagal melakukan proses recovery saat startup.
Akibatnya:
Cassandra gagal startup
↓
Endpoint kosong
↓
Collector gagal koneksi
↓
Jaeger Down
Tahap 5: Validasi Storage Longhorn
Perintah:
kubectl get pvc -n jaeger
dan
kubectl get volumes.longhorn.io -n longhorn-system
Tujuan:
Memastikan kerusakan bukan berasal dari storage.
Hasil:
PVC : Bound
PV : Healthy
Longhorn Volume : Healthy
Kesimpulan:
Storage dalam kondisi normal.
Tahap 6: Verifikasi Snapshot Recovery
Perintah:
kubectl get snapshots.longhorn.io -n longhorn-system
Tujuan:
Memastikan tersedia titik pemulihan apabila recovery gagal.
Hasil:
Snapshot Longhorn masih tersedia sehingga proses recovery dapat dilakukan dengan aman.
Tahap 7: Scale Down Cassandra
Perintah:
kubectl scale sts jaeger-cassandra -n jaeger --replicas=0
Tujuan:
- Menghentikan restart berulang
- Melepaskan volume Longhorn
- Memungkinkan proses recovery
Tahap 8: Mount Volume Menggunakan Recovery Pod
Membuat pod sementara:
kubectl apply -f recovery-pod.yaml
Awalnya muncul error:
Multi-Attach Error
Penyebab:
Volume masih digunakan oleh pod Cassandra.
Setelah Cassandra dimatikan, volume berhasil dimount ke pod recovery.
Tahap 9: Menemukan File CommitLog Corrupt
Perintah:
kubectl exec recovery-pod -- ls -lah /data/commitlog
Ditemukan file:
CommitLog-6-xxxxxxxxxxxx.log
Nama file tersebut sama dengan yang disebutkan pada log error Cassandra.
Tahap 10: Recovery CommitLog
Alih-alih menghapus file, dilakukan rename:
mv CommitLog-6-xxxxxxxxxxxx.log \
CommitLog-6-xxxxxxxxxxxx.log.bak
Mengapa tidak dihapus?
Karena:
- Lebih aman
- Bisa dikembalikan jika diperlukan
- Memudahkan proses forensik
Tahap 11: Menyalakan Kembali Cassandra
Perintah:
kubectl scale sts jaeger-cassandra -n jaeger --replicas=1
Awalnya muncul:
Multi-Attach Error
karena volume masih digunakan pod recovery.
Solusi:
kubectl delete pod recovery-pod
Setelah volume dilepas, Cassandra berhasil startup.
Tahap 12: Verifikasi Kesehatan Cassandra
Perintah:
kubectl get pod -n jaeger
Hasil:
READY 1/1
STATUS Running
RESTARTS 0
Artinya:
- Cassandra berhasil startup
- Tidak ada crash
- Readiness probe berhasil
Tahap 13: Verifikasi Endpoint Service
Perintah:
kubectl get endpoints -n jaeger
Hasil:
jaeger-cassandra
jaeger-collector
jaeger-query
Semua endpoint kembali tersedia.
Ini menunjukkan service discovery Kubernetes kembali normal.
Tahap 14: Verifikasi Seluruh Stack Jaeger
Perintah:
kubectl get pods -n jaeger -o wide
Hasil:
jaeger-cassandra 1/1 Running
jaeger-collector 1/1 Running
jaeger-query 2/2 Running
jaeger-agent Running
Seluruh komponen berhasil pulih.
Perintah Kunci yang Digunakan
Pemeriksaan Service
kubectl get svc -n jaeger
Pemeriksaan Endpoint
kubectl get endpoints -n jaeger
Analisis Pod
kubectl describe pod <pod-name> -n jaeger
Pemeriksaan PVC
kubectl get pvc -n jaeger
Pemeriksaan Longhorn
kubectl get volumes.longhorn.io -n longhorn-system
Scale Down StatefulSet
kubectl scale sts jaeger-cassandra -n jaeger --replicas=0
Scale Up StatefulSet
kubectl scale sts jaeger-cassandra -n jaeger --replicas=1
Akses Recovery Pod
kubectl exec -n jaeger recovery-pod -- ls -lah /data
Rename CommitLog Corrupt
mv CommitLog-6-xxxxxxxxxxxx.log \
CommitLog-6-xxxxxxxxxxxx.log.bak
Pelajaran Penting dari Insiden Ini
Jangan Langsung Menyalahkan Storage
Storage sehat belum tentu aplikasi sehat.
Endpoint Kosong Adalah Gejala
Sering kali endpoint kosong bukan akar masalah, melainkan akibat dari pod yang gagal startup.
Analisis Log Sangat Penting
Error sebenarnya ditemukan dari log Cassandra, bukan dari service Kubernetes.
Snapshot Adalah Penyelamat
Snapshot Longhorn memberikan perlindungan tambahan saat melakukan recovery.
Monitoring Restart Count Sangat Penting
Restart yang meningkat drastis sering menjadi indikator awal adanya masalah serius.
Kesimpulan
Kasus Jaeger Production Down ini disebabkan oleh file Cassandra CommitLog yang mengalami korupsi sehingga Cassandra gagal melakukan startup. Akibatnya endpoint Cassandra hilang, Collector mengalami CrashLoopBackOff, dan seluruh layanan Jaeger tidak dapat beroperasi.
Melalui proses troubleshooting yang sistematis, validasi storage, recovery volume, dan isolasi file commitlog yang korup, layanan Cassandra berhasil dipulihkan tanpa kehilangan data dan seluruh stack Jaeger kembali berjalan normal.
“Troubleshooting yang baik bukan tentang menebak-nebak masalah, tetapi menghilangkan kemungkinan satu per satu hingga akar penyebab ditemukan.”
Pernah mengalami Cassandra gagal startup, CrashLoopBackOff di Kubernetes, atau masalah storage pada Longhorn?
Bagikan pengalaman Anda di kolom komentar. Jangan lupa share artikel ini kepada rekan DevOps, SysAdmin, dan Platform Engineer agar semakin banyak yang memahami teknik troubleshooting Kubernetes secara sistematis.
FAQ SEO
1. Apa penyebab Jaeger Production Down pada studi kasus ini?
Penyebab utamanya adalah file Cassandra CommitLog yang mengalami korupsi sehingga Cassandra gagal startup.
2. Mengapa endpoint Jaeger kosong?
Karena backend Cassandra tidak berhasil melewati readiness probe sehingga service tidak memiliki endpoint aktif.
3. Apa itu CommitLog pada Cassandra?
CommitLog adalah mekanisme pencatatan transaksi yang digunakan Cassandra untuk menjamin konsistensi dan recovery data.
4. Apakah file CommitLog corrupt harus dihapus?
Tidak selalu. Praktik yang lebih aman adalah melakukan rename terlebih dahulu untuk kebutuhan recovery dan forensik.
5. Bagaimana memastikan storage bukan penyebab masalah?
Dengan memeriksa status PVC, PV, dan volume Longhorn untuk memastikan semuanya dalam kondisi healthy.
