Belajar Data Engineer - Monitoring & Alerting Pipeline

#Pendahuluan

Di episode 8-14 kalian membangun pipeline yang berjalan — dan di episode 14, quality gates yang memastikan datanya benar. Tapi ada satu pertanyaan yang belum terjawab: bagaimana kalian tahu pipeline sehat sebelum konsumen mengeluh? Monitoring adalah mata dan telinga data engineer: tanpa metrik dan alerting, kalian hidup menunggu laporan "data error".

Episode 20 membangun fondasi observability untuk data pipeline: metrik inti yang wajib diukur, cara mendefinisikan SLA/SLO secara jujur, desain alerting yang tidak membuat mati rasa, dan penggunaan OpenTelemetry sebagai standar observability — plus praktik dashboard monitoring.

#Metrik Inti Pipeline

Jangan memantau segalanya — pantau hal yang menentukan kesehatan. Empat metrik inti data pipeline:

Empat metrik ini menjawab dua pertanyaan paling mendasar: apakah pipeline berjalan tepat waktu? dan apakah data yang dihasilkan masih segar?

from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.metrics import Stats
from datetime import datetime
 
 
def extract_with_metrics():
    start = time.time()
    try:
        rows = extract_orders()
        Stats.gauge("etl.extract.rows", len(rows))
        Stats.incr("etl.extract.success")
    except Exception as e:
        Stats.incr("etl.extract.failure")
        raise
    finally:
        Stats.timing("etl.extract.duration", time.time() - start)

Pola yang sama berlaku untuk semua tool: setiap langkah pipeline memancarkan durasi, jumlah baris, dan status ke sistem monitoring.

#SLA, SLO, dan SLI

Istilah-istilah ini sering tertukar. Definisi singkatnya:

• SLA (Service Level Agreement) — perjanjian eksternal: "data tersedia pukul 06.00 WIB, 99.9% dari hari".
• SLO (Service Level Objective) — target internal yang lebih ketat dari SLA, agar SLA selalu terpenuhi.
• SLI (Service Level Indicator) — metrik yang diukur, misal "persentase hari data tersedia tepat waktu".

Contoh nyata untuk pipeline batch harian:

• SLI: persentase hari dbt build selesai sebelum 05.30 WIB.
• SLO: 95% dari 30 hari terakhir.
• SLA: data dashboard tersedia pukul 06.00, kecuali force majeure.

Aturan emasnya: SLO harus lebih ketat dari SLA. Jika SLA bilang 06.00, SLO bilang 05.30 — ada bantalan untuk kegagalan tanpa melanggar janji ke konsumen.

#Alerting yang Tidak Mematikan

Kesalahan paling umum monitoring: alarm terlalu banyak → tim mati rasa → alarm serius terlewat. Desain alerting yang sehat mengikuti tiga prinsip:

1. Alert pada konsumen, bukan pada indikator. Jangan alert setiap task lambat; alert ketika SLO terancam — misal "estimasi selesai melewati 05.30".
2. Severity jelas. P1 = data tidak tersedia & berdampak bisnis; P2 = terdegradasi tapi tidak memblokir; P3 = perlu perhatian tapi tidak mendesak.
3. Alert harus actionable. Setiap alert memuat: apa yang terjadi, dampaknya, dan langkah pertama. Alert tanpa instruksi = kebisingan.

groups:
  - name: data-pipeline
    rules:
      - alert: FreshnessBreached
        expr: time() - max(ingested_at) > 7200
        labels:
          severity: P1
        annotations:
          summary: "Data orders tidak diperbarui > 2 jam"
          description: "Cek pipeline CDC (slot, connector), lalu konsumen Kafka"

#Observability dengan OpenTelemetry

OpenTelemetry (OTel) adalah standar observability terbuka yang menyatukan traces, metrics, dan logs di bawah satu vendor-netral format. Alih-alih tiga tool terpisah yang tidak saling bicara, pipeline data bisa memancarkan ketiganya sekali:

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
 
trace.set_tracer_provider(TracerProvider(
    span_processors=[BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))]
))
tracer = trace.get_tracer("data-pipeline")
 
 
def run_elt():
    with tracer.start_as_current_span("elt.orders"):
        with tracer.start_as_current_span("extract") as span:
            rows = extract_orders()
            span.set_attribute("rows", len(rows))
        with tracer.start_as_current_span("transform"):
            dbt_build()
        with tracer.start_as_current_span("load"):
            load_warehouse()

Trace memungkinkan pertanyaan yang tidak bisa dijawab metrik biasa: pipeline 3 menit lebih lambat — di task mana? Dengan span, jawabannya terlihat dalam satu gambaran. Series learn-opentelemetry di repositori ini membahas topik ini jauh lebih dalam.

#Praktik: Monitoring Dashboard Pipeline

Rangkai metrik, SLO, dan alerting menjadi dashboard yang benar-benar dipakai. Komponen minimum:

1. Grafik durasi tiap DAG/task (7 hari) — lihat tren melambat.
2. Kesehatan SLO — persentase 30 hari terakhir vs target.
3. Freshness tiap tabel inti — siapa yang paling lama tidak ter-update.
4. Consumer lag untuk pipeline streaming.
5. Quality gate status — hasil dbt test dan Soda scan terakhir (episode 14).

Alat yang bisa dipakai: Grafana + Prometheus (metrik), OpenTelemetry Collector + Jaeger/Tempo (trace), dan backend logging (Loki/ELK). Semua open-source, semua saling terhubung via OTLP.

#Kesalahan Umum (Common Pitfalls)

1. Alarm untuk segalanya. Alert yang tidak actionable adalah noise. Alert hanya ketika konsumen akan merasakan dampak.

2. SLO tanpa basis. Menetapkan SLO 99.9% tanpa mengukur baseline hanya menciptakan alarm yang selalu melanggar. Ukur dulu, lalu tetapkan target realistis.

3. Monitoring proses, bukan hasil. Memantau "task berhasil" tanpa "data benar & segar" melewatkan kegagalan kualitas (episode 14). Gabungkan keduanya.

4. Tool banyak tapi tidak terhubung. OTel menyatukan traces/metrics/logs. Tiga tool terisolasi tidak membentuk observability.

#Penutup

Di episode 20 ini kalian telah membangun observability pipeline:

• Empat metrik inti: duration, failure rate, consumer lag, freshness.
• SLI/SLO/SLA diukur jujur — SLO lebih ketat dari SLA agar ada bantalan.
• Alerting yang actionable dengan severity jelas — alert pada konsumen, bukan indikator.
• OpenTelemetry menyatukan traces, metrics, logs dalam satu standar.
• Praktik: dashboard dengan 4 metrik inti + panel SLO, dibaca setiap pagi.

Di episode 21 selanjutnya kita mengoptimasi mesin pemrosesan: Spark distributed processing — RDD/DataFrame, partitioning, shuffles, caching, broadcast join, dan praktik mengoptimasi job Spark. Sampai jumpa di episode 21!