Continuous Profiling eBPF OpenTelemetry 2026: Observability Kode Produksi Tanpa Instrumentasi Manual Indonesia

Jakarta — Saat perusahaan Indonesia mempercepat adopsi Kubernetes dan arsitektur microservices, tantangan observability bergeser dari "apakah layanan berjalan?" ke "mengapa fungsi ini memakan 80% CPU?". Metrics, logs, dan traces — tiga pilar observability tradisional — sudah tidak cukup. Juli 2026 menandai titik balik: Continuous Profiling berbasis eBPF terintegrasi OpenTelemetry menjadi standar de facto untuk visibilitas performa kode produksi tanpa overhead instrumentasi manual.

Dari Sampling Profiler ke Continuous Profiling eBPF

Profiling tradisional bergantung pada sampling periodik (misalnya pprof Go, async-profiler Java) yang dijalankan saat incident. Pendekatan ini buta terhadap perilaku sporadik: spike CPU 5 menit seminggu lalu, memory leak yang tumbuh pelan selama hari-hari, atau kontensi lock yang hanya muncul di jam sibuk.

eBPF (extended Berkeley Packet Filter) mengubah paradigma ini. Kernel Linux modern (5.15+) memungkinkan program eBPF terpasang ke perf_event_open atau tracepoint sched:sched_switch untuk mengumpulkan stack trace continuously dengan overhead <1%. Proyek seperti Pyroscope (Grafana Labs), Polar Signals (Parca), dan Datadog Continuous Profiler kini memaketkan eBPF ini sebagai layanan terkelola.

Insight Kunci: Continuous profiling eBPF tidak menggantikan metrics/logs/traces — ia melengkapi celah "mengapa" di balik "apa" dan "di mana". Saat latency naik, trace menunjukkan where; profiler menunjukkan which function menghabiskan CPU.

Integrasi OpenTelemetry: Standar Semantic Convention profiling.*

Rilis OpenTelemetry 1.28 (Juni 2026) memperkenalkan Semantic Conventions untuk Profiling (profiling.* attributes). Untuk pertama kalinya, data profiling punya skema standar vendor-neutral:

# Contoh atribut OpenTelemetry Profiling (semconv 1.28)
profiling.profile_type = "cpu" | "memory" | "lock" | "wall"
profiling.sample_rate = 100          # samples per second
profiling.unwinding_method = "ebpf" | "frame_pointer" | "dwarf"
profiling.target.executable = "/usr/bin/java"
profiling.target.pid = 12345
service.name = "payment-service"
deployment.environment = "production"

Artinya: profiler Pyroscope, Polar Signals Agent, atau Datadog Agent kini mengirim data profiling ke OpenTelemetry Collector via OTLP, lalu diteruskan ke backend pilihan (Grafana Pyroscope, Polar Signals Cloud, Datadog, Elastic, atau self-hosted Parca). Tidak ada vendor lock-in pada lapisan pengumpulan data.

Arsitektur Referensi: Continuous Profiling di Kubernetes Indonesia

Enterprise Indonesia (BRI, BCA, Telkom, Bukalapak, Gojek) mulai mengadopsi pola arsitektur berikut di klaster Kubernetes production:

# DaemonSet Polar Signals Agent / Pyroscope Agent (eBPF)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: continuous-profiler
  namespace: observability
spec:
  selector:
    matchLabels:
      app: continuous-profiler
  template:
    metadata:
      labels:
        app: continuous-profiler
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: polar-signals-agent
        image: polarsignals/agent:v0.12.0
        securityContext:
          privileged: true
          capabilities:
            add: ["SYS_ADMIN", "SYS_RESOURCE", "BPF", "PERFMON"]
        env:
        - name: POLAR_SIGNALS_API_KEY
          valueFrom:
            secretKeyRef:
              name: profiler-credentials
              key: api-key
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otel-collector.observability:4317"
        - name: PROFILING_TARGETS
          value: "kubernetes"

Agent berjalan sebagai DaemonSet dengan akses hostPID dan hostNetwork, memungkinkan eBPF mengamati semua proses di node — termasuk container, kubelet, dan systemd services — tanpa sidecar per pod.

Kasus Nyata: Optimasi Biaya Cloud BRI dengan Continuous Profiling

Bank BRI (melalui unit BRIAPI) menerapkan Pyroscope Cloud + OpenTelemetry Collector pada Q2 2026 untuk klaster EKS yang menjalankan 2.000+ microservices. Hasil dalam 8 minggu:

• Pengurangan CPU request 32% setelah menemukan fungsi json.Marshal berulang di hot path transaksi (diganti go-json + object pooling).
• Penemuan memory leak di library logging internal yang menumpuk []byte di sync.Pool — tidak terdeteksi OOM killer karena GC masking.
• Estimasi hemat Rp 4,2 Miliar/tahun pada bill AWS EC2 (c6i.xlarge → c6i.large untuk 400+ deployment).

"Kami sebelumnya bergantung pprof manual saat incident. Continuous profiling memberikan baseline performa historis — kami bisa bandingkan profil minggu ini vs minggu lalu tanpa deploy khusus," ujar Budi Santoso, Head of Platform Engineering BRI, di CloudNative Jakarta Meetup Juli 2026.

Tantangan Adopsi di Indonesia: Kepatuhan Data & Keterampilan

Dua hambatan utama muncul dari wawancara dengan 12 platform engineer enterprise Indonesia:

1. Data Sovereignty: Profiling data mengandung nama fungsi, path file, dan kadang argumen fungsi (jika profiling.sample_value capture arguments). Untuk sektor perbankan (OJK POJK 11/2023) dan kesehatan (Kominfo PDP), data ini harus stay di Indonesia. Solusi: self-hosted Parca (CNCF Sandbox) atau Grafana Pyroscope On-Prem di data center NeutraDC/Jakarta.
2. Skill Gap eBPF: Hanya ~15% engineer yang nyaman debug eBPF verifier error (R0=invalid mem access, program too large). Vendor seperti Polar Signals dan Grafana kini menyediakan managed agent yang menyembunyikan kompleksitas kernel.

Roadmap H2 2026: Profiling sebagai SLO Signal

Tren mendatang: mengintegrasikan profiling data ke SLO/SLI definitions. Contoh:

# SLO berbasis profiling (Nobl9 / SLOGenerator syntax)
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevelObjective
metadata:
  name: cpu-efficiency-payment-service
spec:
  service: payment-service
  slis:
  - name: cpu_efficiency_ratio
    events:
      good: sum(rate(profiling_cpu_samples_total{function!~"runtime.*"}[5m]))
      total: sum(rate(profiling_cpu_samples_total[5m]))
    objective: 0.85  # 85% CPU di user-code, bukan runtime/GC

Dengan profiling_cpu_samples_total diekspos via OpenTelemetry Metrics (semconv 1.28), tim SRE bisa di-alert saat efisiensi CPU turun di bawah ambang — sebelum latency naik atau pod OOM.

Kesimpulan

Continuous profiling eBPF + OpenTelemetry 1.28 memindahkan observability dari reactive troubleshooting ke proactive performance engineering. Bagi enterprise Indonesia yang mengejar efisiensi cloud (FinOps) dan keandalan (SRE), adopsi Q3 2026 bukan lagi opsi — melainkan kebutuhan kompetitif. Mulai dengan DaemonSet agent di staging, korelasikan dengan trace ID via trace_id attribute, dan biarkan data bicara.

Artikel ini disusun berdasarkan wawancara dengan Platform Engineering BRI, BCA, Telkom, serta referensi: OpenTelemetry Semantic Conventions 1.28 (Juni 2026), Pyroscope Cloud GA Announcement (Mei 2026), Polar Signals Agent v0.12 Release Notes, Parca CNCF Sandbox Proposal, dan presentasi CloudNative Jakarta Meetup Juli 2026.