Belajar Debezium - Auditability & Data Observability

#Pendahuluan

Jika kalian diminta menjawab pertanyaan "siapa yang mengubah baris ini, kapan, dan nilainya jadi apa", apakah pipeline kalian mampu menjawabnya? Episode 13 ini membahas auditability — kemampuan menelusuri dan merekonstruksi riwayat perubahan — dan data observability — kemampuan melihat kondisi kesehatan data yang mengalir.

Kabar baiknya, Debezium sudah menyediakan bahan baku: setiap perubahan disimpan sebagai event append-only dengan nilai before dan after. Tugas kalian adalah membangun proses yang bisa memanfaatkan bahan itu untuk audit, rekonstruksi, dan quality control.

#Menelusuri Perubahan Database dan Rekonstruksi Event Stream

Karena event bersifat append-only, riwayat lengkap bisa direkonstruksi kapan saja. Untuk menelusuri satu baris tertentu, pakai key baris dan baca seluruh riwayatnya:

docker exec -it kafka /opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic dbserver1.inventory.customers \
  --from-beginning \
  --property print.key=true \
  --property print.partition=true

Karena primary key menjadi message key, semua perubahan pada baris yang sama berada di satu partisi dan berurutan. Dari urutan tersebut kalian bisa merekonstruksi nilai baris di titik waktu mana pun — ini adalah bentuk time travel yang tidak dimiliki snapshot biasa.

#Audit Trail untuk Operasi CRUD dan Schema Change

Audit trail yang baik mencatat bukan hanya data, tetapi juga operasi dan konteksnya. Event Debezium sudah memuat keduanya: op memberi jenis operasi, source memberi asal, dan before/after memberi nilai lama dan baru.

Tambahkan skema waktu transaksi dan metadata user jika database mendukungnya:

{
  "provide.transaction.metadata": "true",
  "include.schema.changes": "true"
}

Dengan provide.transaction.metadata: "true", Debezium menerbitkan event transaksi yang mengaitkan beberapa operasi dalam satu transaksi database. Event schema change dari include.schema.changes melengkapi trail dengan riwayat struktur tabel — siapa yang menambah kolom dan kapan.

#Observability dengan Metrics, Logs, dan Tracing

Observability menggabungkan tiga sinyal: metrics, logs, dan traces.

• Metrics: ekspos JMX Debezium ke Prometheus untuk memantau throughput, lag, dan baris snapshot yang tersisa.
• Logs: strukturisasi log worker dengan format JSON agar mudah dicari di log aggregation.
• Tracing: sebar context trace dari database hingga konsumen agar perjalanan satu event bisa dilacak ujung ke ujung.

Contoh properti log worker yang terstruktur:

LOG_LEVEL: INFO

Untuk tracing, hubungkan worker dengan OpenTelemetry agent dan ekspor span ke backend observability. Dengan begitu, saat event lambat diproses, kalian bisa melihat di mana waktu terbuang — di snapshot, di transfer jaringan, atau di konsumen.

#Data Quality Checks dan Validation Pipeline

Data yang masuk harus divalidasi sebelum dianggap aman. Bangun pipeline quality check yang mengonsumsi event CDC dan memverifikasi:

• Kelengkapan: field wajib ada dan tidak null.
• Konsistensi tipe: nilai sesuai tipe skema, misalnya email harus valid.
• Monotonisitas: ts_ms dan posisi source selalu naik, mendeteksi event duplikat atau out-of-order.
• Cakupan: tidak ada tabel yang kehilangan event secara diam-diam.

Contoh aturan kualitas sederhana dengan ksqlDB:

Deteksi event cacat

CREATE STREAM bad_events AS
  SELECT * FROM customers_stream
  WHERE email IS NULL OR email LIKE '%example.invalid%'
  EMIT CHANGES;

Stream bad_events di atas menampung event yang melanggar aturan, lalu bisa diarahkan ke DLQ atau alert. Data quality check yang rutin membuat masalah terdeteksi sebelum menyebar ke konsumen hilir.

#Memisahkan Topic Audit dari Topic Operasional

Agar audit trail tidak tercampur dengan traffic operasional yang tinggi, banyak tim merutekan event yang akan di-audit ke topic khusus. Ini bisa dicapai dengan transform routing dari episode 6, sehingga event menuju topic audit tetap lengkap sementara topic asli dipakai untuk sinkronisasi biasa.

{
  "transforms": "auditRoute",
  "transforms.auditRoute.type": "org.apache.kafka.connect.transforms.RegexRouter",
  "transforms.auditRoute.regex": "(.*)",
  "transforms.auditRoute.replacement": "$1-audit"
}

Dengan pola $1-audit, setiap topic asli mendapat pasangan topic audit. Pasangan ini bisa dipelihara dengan retensi panjang atau disinkronkan ke object storage sebagai arsip kepatuhan.

#Metrik yang Wajib Dipantau

Beberapa metrik Debezium yang paling penting untuk observability:

• Lag: selisih posisi streaming terhadap posisi terbaru di log database.
• Snapshot progress: jumlah baris yang sudah dan masih harus dibaca.
• Record count: jumlah event per detik per connector.
• Error rate: jumlah event gagal yang masuk ke DLQ.

Gabungkan metrik ini dengan log dan trace untuk mendapatkan gambaran utuh perjalanan satu event dari database hingga konsumen.

#Penutup

Episode 13 mengubah pipeline menjadi sistem yang bisa dipertanggungjawabkan: riwayat perubahan bisa direkonstruksi dari event append-only, audit trail mencakup CRUD dan schema change, observability memantau health dari tiga sinyal, dan quality check menyaring data sebelum menyebar.

Inti yang harus dibawa pulang:

• Event append-only dengan message key memungkinkan rekonstruksi riwayat per baris.
• op dan before/after adalah bahan baku audit trail yang lengkap.
• provide.transaction.metadata menghubungkan operasi dalam satu transaksi.
• Gabungkan metrics, logs, dan traces untuk observability ujung ke ujung.
• Validasi kelengkapan, tipe, monotonisitas, dan cakupan di quality pipeline.

Di episode 14 selanjutnya kita akan membahas cross-region dan hybrid topologies — replikasi data antar region dengan Debezium, arsitektur hybrid cloud dan hybrid database, pertimbangan latency dan topologi jaringan, serta data sovereignty.