Belajar Debezium - Monitoring, Handling Failures, & Debugging

#Pendahuluan

Connector yang sehat di pagi hari bisa gagal diam-diam di tengah malam. Episode 7 ini membekali kalian dengan kebiasaan operasional yang wajib ada: memantau status connector, mengukur lag, membaca log yang tepat, menangani error tanpa menghentikan pipeline, dan membangun alert otomatis.

Kunci dari semuanya adalah memiliki sumber kebenaran tunggal — Kafka Connect REST API dan metrics JMX — plus kebiasaan memeriksa health secara rutin. Tanpa itu, masalah kecil seperti satu skema yang berubah bisa berubah menjadi kehilangan data berjam-jam.

#Memantau Status Connector dan Tasks

REST API Kafka Connect memberikan status lengkap connector beserta setiap task:

curl -s http://localhost:8083/connectors/inventory-connector/status | jq

Bidang state pada connector dan task menunjukkan nilai UNASSIGNED, RUNNING, PAUSED, atau FAILED. Untuk memfilter hanya yang penting:

curl -s http://localhost:8083/connectors/inventory-connector/status | \
  jq '{connector: .connector.state, tasks: [.tasks[].state]}'

Buat kebiasaan mengecek status semua connector sekaligus:

curl -s http://localhost:8083/connectors

#Mengukur Offset dan Lag

Untuk source connector, "lag" berarti selisih antara posisi terbaru di log database dengan posisi yang sudah di-capture. Debezium mengekspos metrik ini lewat JMX dengan domain io.debezium:

jcmd $(pgrep -f 'debezium' | head -1) GC.heap_info

Praktik yang umum di produksi adalah mengekspos JMX ke Prometheus menggunakan JMX exporter, lalu memantau metrik seperti jumlah baris tersisa pada snapshot dan lag streaming. Untuk pipeline sink, lag bisa dicek lewat consumer group:

docker exec -it kafka /opt/kafka/bin/kafka-consumer-groups.sh \
  --bootstrap-server localhost:9092 --describe --group jdbc-sink

Kolom LAG menunjukkan berapa banyak event yang belum diproses konsumen. Lag yang terus naik tanpa henti adalah sinyal utama pipeline bermasalah.

#Logs dan Error Handling

Saat connector gagal, langkah pertama adalah membaca log container:

docker logs connect --tail 200

Selain log, Debezium menyediakan mekanisme error handling di level connector:

{
  "errors.tolerance": "all",
  "errors.deadletterqueue.topic.name": "cdc-dlq",
  "errors.deadletterqueue.context.headers.enable": "true"
}

Dengan errors.tolerance: "all", record yang gagal diproses tidak menghentikan connector, melainkan dikirim ke topic cdc-dlq beserta header konteks. Ini jauh lebih aman daripada connector berhenti total karena satu record bermasalah.

#Menangani Masalah Umum

#Record Parsing Error

Umumnya terjadi saat format payload tidak sesuai — misalnya kolom baru yang tidak dikenali. Perbaiki dengan memastikan skema konsumen sinkron dengan skema terbaru, atau kirim record bermasalah ke DLQ seperti contoh di atas.

#Schema Mismatch

Saat tabel berubah, skema event ikut berubah. Jika konsumen tidak siap, event ditolak. Solusinya: gunakan schema registry untuk memvalidasi kompatibilitas, dan update konsumen sebelum skema baru aktif.

#Database Tidak Tersedia

Jika database sumber down, connector gagal membaca dan bisa masuk status FAILED. Debezium akan mencoba koneksi ulang sesuai konfigurasi, tetapi pastikan ada retry dan heartbeat yang aktif agar posisi baca tidak hilang.

#Membangun Alert untuk Connector Failure dan Data Loss

Metrik yang sudah diekspos ke Prometheus bisa dijadikan dasar alert. Contoh aturan alert untuk connector yang gagal:

groups:
  - name: debezium-alerts
    rules:
      - alert: ConnectorStateFailed
        expr: debezium_connector_metrics_state == 3
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Connector tidak sehat: {{ $labels.connector }}"

Aturan tambahan yang disarankan:

• Alert saat lag streaming melebihi ambang, misalnya 5 menit.
• Alert saat task count menurun dari yang dikonfigurasi.
• Alert saat record masuk ke DLQ, yang menandakan ada data yang gagal diproses.

#Penutup

Episode 7 membawa kalian ke mode operasional: memeriksa status via REST API, memantau lag dengan JMX dan consumer groups, menangani error dengan toleransi dan DLQ, mendiagnosis masalah umum, serta membangun alert Prometheus untuk kegagalan.

Inti yang harus dibawa pulang:

• REST API GET /connectors/{name}/status adalah sumber kebenaran utama status connector.
• Lag dipantau lewat JMX untuk source dan consumer group untuk sink.
• errors.tolerance dan DLQ mencegah satu record gagal menghentikan seluruh pipeline.
• Periksa log container sebelum mendiagnosis kegagalan connector.
• Alert untuk state FAILED, lag tinggi, dan record di DLQ adalah minimum yang wajib ada.

Di episode 8 selanjutnya kita akan membahas integrasi dengan konsumen dan sink — menghubungkan event CDC ke Kafka consumers, stream processors seperti ksqlDB dan Kafka Streams, serta sink ke database, data lake, dan data warehouse.