Belajar OpenTelemetry - Processors: Batching, Filtering, Redaction

#Pendahuluan

Di episode 9 kita melihat processor sebagai tahap tengah pipeline; episode 12 membedahnya satu per satu. Inilah lapisan yang membuat observability kalian hemat, aman, dan cepat — dan juga lapisan yang paling sering diabaikan sampai biaya cloud membengkak atau PII bocor ke backend.

Mengapa processor penting? Bayangkan 10.000 request/detik di produksi. Tanpa batching, setiap span dikirim satu-satu — backend kewalahan. Tanpa filtering, data debug masuk ke produksi — biaya naik. Tanpa redaksi, alamat email pelanggan bocor ke vendor observability — pelanggaran privasi. Tiga masalah ini diselesaikan di satu file YAML, bukan di kode aplikasi.

#batch: Efisiensi Ekspor

Processor paling penting dan termudah. Ia menampung data lalu mengekspor dalam kelompok, sehingga mengurangi jumlah HTTP/gRPC call secara drastis.

processors:
  batch:
    timeout: 2s               # ekspor maksimal setiap 2 detik
    send_batch_size: 1024     # atau saat 1024 item terkumpul
    send_batch_max_size: 2048 # batas keras ukuran batch

Parameter kuncinya: timeout (seberapa lama menunggu) dan send_batch_size (berapa item per ekspor). Tanpa processor ini, throughput collector bisa turun puluhan kali lipat.

#memory_limiter: Pengaman dari OOM

Collector yang kehabisan memory akan di-kill oleh kernel — dan data yang belum diekspor ikut hilang. memory_limiter mencegah ini dengan menolak data masuk saat ambang tercapai.

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
    spike_limit_mib: 128

• limit_mib — batas total memory collector; set sekitar 80% dari limit container.
• spike_limit_mib — ruang untuk lonjakan sesaat sebelum collector menolak data.
• Saat limit tercapai, collector menolak telemetry dengan error ResourceExhausted — dan SDK yang menerima sinyal ini akan melakukan retry (episode 14).

Aturan pemasangan: processor ini harus paling awal di setiap pipeline, sebelum processor lain yang boros memory.

#attributes & resource: Mutasi Metadata

#attributes processor

Menambah, menghapus, atau mengubah attribute pada span/log/metric point:

processors:
  attributes/normalize:
    actions:
      - key: http.response.status_code
        action: delete
      - key: region
        action: insert
        value: ap-southeast-1
      - key: service.environment
        action: upsert
        value: production
      - key: user.email
        action: extract
        pattern: ([^@]+)@.+
        from: user.email

Kasus umum: menghapus attribute besar/tak terpakai, menyuntikkan nilai default, atau meng-ekstrak nilai dari attribute lain.

#resource processor

Sama untuk level Resource — paling sering dipakai untuk deteksi otomatis environment:

processors:
  resource/detect:
    detectors: [env, system]
  resource/add:
    attributes:
      - key: collector.stage
        action: upsert
        value: prod

detectors: [env, system] membaca environment variable dan sistem host untuk mengisi Resource secara otomatis — mengurangi kerja manual tiap aplikasi.

#filter: Buang yang Tidak Perlu

filter memutuskan data mana yang di-drop sebelum diekspor — penghemat biaya terbesar:

processors:
  filter/debug:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.response.status_code"] == 200'
    metrics:
      metric:
        - 'name == "healthcheck.duration"'
    logs:
      log_record:
        - 'body == "heartbeat"'

Contoh di atas membuang span request sukses (status 200), metric healthcheck, dan log heartbeat. Hasilnya: volume data produksi turun drastis, biaya backend ikut turun — tanpa mengorbankan informasi yang berguna.

#redaction: Lindungi PII

redaction memblokir atau memodifikasi attribute yang mengandung data sensitif — nomor kartu, email, token:

processors:
  redaction:
    block_values:
      - "BEARER .+"
      - "[0-9]{16}"
    allow_all_keys: true
    blocked_keys:
      - user.email
      - authorization

• block_values — pola nilai yang akan di-hash (misal kartu kredit 16 digit).
• blocked_keys — key yang dihapus dari telemetry.
• Saat nilai cocok pola, value diubah menjadi hash sehingga referensi tetap ada tanpa membocorkan data asli.

#tailsampling & lainnya

tailsampling adalah processor khusus untuk keputusan sampling setelah trace lengkap berkumpul di collector — kita bahas tuntas di episode 13. Processor lain yang berguna: transform (transformasi OTTL), k8sattributes (enrichment Kubernetes, episode 18), dan spanmetrics (mengubah span menjadi metrics).

#Pipeline Lengkap: receiv → detect → filter → redact → batch → export

Gabungan semua processor dalam satu pipeline yang siap produksi:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
 
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  resource/detect:
    detectors: [env, system]
  filter/noise:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.response.status_code"] == 200'
  redaction:
    block_values:
      - "BEARER .+"
      - "[0-9]{16}"
    blocked_keys:
      - user.email
      - authorization
  batch:
    timeout: 2s
    send_batch_size: 1024
 
exporters:
  otlp/backend:
    endpoint: jaeger:4317
    tls:
      insecure: true
  debug:
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, resource/detect, filter/noise, redaction, batch]
      exporters: [otlp/backend, debug]

Urutannya bermakna: lindungi memory dulu (memory_limiter), lengkapi identitas (resource/detect), buang kebisingan (filter), bersihkan sensitif (redaction), baru ekspor efisien (batch).

#Common Pitfalls

• Urutan processor salah — batch sebelum memory_limiter membuat lonjakan memory tak terkendali; lindungi memory paling awal.
• Redaksi memakai regex mahal — pola seperti [0-9]{16} di semua nilai bisa memperlambat; batasi scope-nya.
• Filter menghapus data debugging yang masih dibutuhkan — selalu pertimbangkan biaya vs nilai sebelum membuang.
• Resource detection tidak dijalankan — telemetry tanpa identitas lingkungan mengacaukan grouping.

#Penutup

Pada episode 12 ini, kalian telah menguasai processor inti collector.

Inti yang harus dibawa pulang:

• batch membuat ekspor efisien; memory_limiter melindungi collector dari OOM dan harus paling awal.
• attributes/resource memodifikasi metadata; filter membuang data yang tidak perlu untuk menghemat biaya.
• redaction melindungi PII di lapisan terakhir; hygiene di kode tetap yang utama.
• Pipeline produksi: receiv → detect → filter → redact → batch → export.

Di episode 13 selanjutnya, kita akan membahas sampling: head vs tail — sampling di SDK (parent-based, ratio) vs di collector (policy-based: latency, error, trace_id), serta strategi hemat-biaya 100% head ditambah tail cerdas untuk error dan lambat. Sampai jumpa di episode 13!