Belajar Pentaho - Monitoring & Observability

#Pendahuluan

Platform data yang tidak dipantau adalah bom waktu. Job bisa gagal diam-diam, performa menurun pelan-pelan, dan tidak ada yang tahu sampai user mengeluh. Episode ini membahas monitoring dan observability — bagaimana kalian tahu platform dalam keadaan sehat, menemukan masalah lebih awal, dan memahami penyebabnya.

Kalian akan belajar memantau eksekusi job, membaca dan menangkap log, mengukur resource dan throughput, serta mengintegrasikan Pentaho ke alat monitoring eksternal bila dibutuhkan.

#Memantau Eksekusi Job dan Transformasi

Ada beberapa level tempat eksekusi job dipantau:

• Di Spoon: saat development, tab Execution results menampilkan riwayat dan status tiap run.
• Di Pentaho Server: Schedules di PUC menunjukkan jadwal, status, dan log eksekusi terakhir setiap job.
• Di command line: logfile yang dihasilkan Pan dan Kitchen menjadi jejak untuk dipantau script atau alat eksternal.

Untuk job yang berjalan di cron atau CI/CD, hasil eksekusi sebaiknya selalu ditulis ke logfile dan, bila gagal, mengirim notifikasi. Pola yang sudah kalian buat di episode 5 — hop failure ke email — adalah dasar dari monitoring reaktif.

Biasakan menulis log ke file dengan lokasi yang konsisten:

kitchen.sh -file=etl_daily.kjb -level=Basic -logfile=/var/log/pentaho/etl_daily.log

Dengan logfile yang tersimpan, script monitoring atau alat eksternal bisa membaca hasil eksekusi secara programatik. Saat job sedang berjalan, pantau langsung dengan tail -f /var/log/pentaho/etl_daily.log untuk melihat progres tanpa menunggu selesai.

#Logging Terstruktur dengan Database Log

Selain logfile teks, PDI bisa menulis log ke database melalui Logging configuration — setiap job/transformasi mencatat eksekusi, step, dan error ke tabel khusus. Untuk job yang berjalan di Pentaho Server, tabel log ini otomatis dikelola dan bisa diquery langsung untuk laporan operasional, misalnya:

SELECT COUNT(*) AS gagal
FROM r_job
WHERE status = 'STOPPED'
  AND log_date > CURRENT_DATE - INTERVAL '7 days';

Dengan tabel log yang bisa diquery, tim tidak perlu menebak-nebak kesehatan pipeline dari ingatan — jawabannya ada di database dan bisa dimasukkan ke dashboard monitoring.

#Analisis Log dan Penangkapan Error

Log adalah sumber kebenaran saat investigasi. Hal yang harus kalian perhatikan:

• Level log: Error, Minimal, Basic, Detailed, Debug, Rowlevel — pilih sesuai kebutuhan. Produksi biasanya Basic; Debug hanya saat investigasi.
• Pola error yang umum: ORA-... atau SQL error untuk masalah database, File not found untuk masalah file, dan Unknown type untuk metadata yang melenceng.
• Korelasi waktu: bandingkan waktu error dengan kejadian lain — misalnya crash database atau perubahan konfigurasi.

Untuk menangkap error secara otomatis, skenarionya biasanya: grep logfile untuk baris error, lalu picu notifikasi atau open ticket. Contoh pencarian pola error di logfile:

grep -i "error\|exception\|failed" /var/log/pentaho/etl_daily.log

Kalian bisa melihat bagian log yang mencurigakan dengan perintah di atas. Untuk investigasi yang lebih terstruktur, buka logfile lengkapnya di editor dan ikuti jejak mulai dari pesan pertama yang aneh.

#Metrics Resource dan Throughput

Selain log, kalian perlu memantau metrik kuantitatif:

• Resource server: CPU, RAM, dan disk dari mesin yang menjalankan PDI atau Pentaho Server. Server Java yang kehabisan memori adalah penyebab utama kegagalan misterius.
• Throughput ETL: baris per detik dan durasi tiap job. Degradasi bertahap menandakan data membesar atau perlu optimasi (topik episode 14 dan 15).
• Jumlah error: tren error antar hari — jika naik, ada sesuatu yang berubah di sumber data.

Untuk PDI, tab Step Metrics di Spoon sudah memberi gambaran throughput tiap step. Untuk jangka panjang, kalian perlu mencatat durasi dan status setiap run — baik di log, spreadsheet, atau database metrik.

#Metrik Kunci untuk Dipantau

Agar pemantauan tidak menenggelamkan kalian dalam angka, fokus pada lima metrik yang paling banyak bercerita:

• Durasi eksekusi: tren harian — naik berarti data membesar atau ada bottleneck baru.
• Baris dibaca vs ditulis: selisih besar berarti banyak baris dibuang — validasi atau filter terlalu agresif.
• Error count: nol adalah normal; angka yang naik tiba-tiba adalah alarm.
• CPU dan memori server: kenaikan persisten menandakan perlu tuning heap (episode 14).
• Slot scheduler: job yang menunggu antrean menunjukkan server kelebihan beban.

Catat metrik ini di satu tempat — spreadsheet, database, atau alat monitoring — setiap kali job berjalan, agar perbandingan antar hari menjadi mudah.

#Integrasi dengan Alat Monitoring Eksternal

Untuk organisasi yang sudah punya infrastruktur monitoring, Pentaho harus masuk ke dalamnya. Pola integrasi yang umum:

• Log collection: arahkan log PDI dan Pentaho Server ke log aggregator seperti Elastic Stack atau Loki, sehingga pencarian log terpusat.
• Metrics export: ekspor durasi dan status job sebagai metrik ke Prometheus (melalui exporter atau skrip) untuk visualisasi di Grafana.
• Alerting: bangun alert berdasarkan kondisi — misalnya job gagal dua kali beruntun atau durasi melebihi ambang normal.
• Health check API: gunakan REST API Pentaho untuk memeriksa status server dari sistem pemantauan.

Berikut gambaran skenario: skrip membaca logfile, mengekstrak durasi job, lalu mem-publish metrik yang bisa diquery alat monitoring:

grep "Finished job entry" /var/log/pentaho/etl_daily.log | tail -1

Hasilnya bisa dijadikan metrik throughput atau input alerting. Ini hanya jembatan sederhana; untuk skala penuh, bangun pipeline metrik yang rapi di episode 17-18.

#Penutup

Di episode 13 ini kalian membekali diri untuk memantau platform: memantau eksekusi job di berbagai level, menganalisis log dan menangkap error, memantau resource dan throughput, serta mengintegrasikan Pentaho dengan alat monitoring eksternal.

Inti yang harus dibawa pulang:

• Log ke file dengan level yang tepat di produksi, lalu pantau hasilnya secara programatik.
• Monitoring memberi tahu "ada apa", observability membantu memahami "kenapa".
• Resource server dan throughput job adalah metrik inti yang harus diukur terus-menerus.
• Integrasi dengan log aggregator dan alerting membuat platform masuk ekosistem operasional perusahaan.

Di episode 14, kita mendorong performa: deployment & scalability — membandingkan arsitektur standalone dan clustered, men-scaling transformasi dengan eksekusi paralel, men-tuning resource Spoon, Carte, dan Pentaho Server, serta mempertimbangkan load balancing dan failover.