Sign in Subscribe
Observabilitas

Observabilitas 2026: SLO-First, OpenTelemetry, eBPF, dan LGTM Stack untuk Enterprise Indonesia

Observabilitas bukan lagi "nice to have" bagi tim ops. Di 2026, ini jadi business capability yang menentukan kecepatan release, biaya insiden, dan kepercayaan customer. Artikel ini bahas migrasi dari monitoring tradisional ke SLO-first, adoptasi OpenTelemetry + eBPF, serta deployment LGTM Stack (Lok

Aziz

— 4 min read
Share
Observabilitas 2026: SLO-First, OpenTelemetry, eBPF, dan LGTM Stack untuk Enterprise Indonesia

Tahun 2026 menandai titik balik bagi praktik observabilitas di Indonesia. Perusahaan tidak lagi puas dengan dashboard berantakan dan alert berbunyi di malam hari tanpa konteks bisnis. Pergeseran paradigma menuju Service Level Objectives (SLO) sebagai pusat gravitasi observabilitas telah menjadi standar de facto bagi organisasi yang serius soal reliability. Kombinasi OpenTelemetry sebagai standar instrumentasi, eBPF untuk visibility kernel-level tanpa instrumentasi kode, dan LGTM Stack (Loki, Grafana, Tempo, Mimir) sebagai backend terpadu menciptakan fondasi yang scalable dan vendor-neutral.

Dari Monitoring ke SLO-First: Mengapa Metrik Tradisional Gagal

Monitoring tradisional fokus pada health checks dan threshold statis — CPU > 80%, memory > 85%, disk > 90%. Pendekatan ini menghasilkan alert fatigue: tim ops dibanjiri notifikasi saat sistem sebenarnya masih berfungsi normal bagi user. Di sisi lain, insiden kritis yang mempengaruhi user experience (latency spike pada checkout, error rate naik di payment gateway) sering lolos karena tidak memicu threshold infrastruktur.

SLO-first memindahkan fokus ke Service Level Indicators (SLI) yang langsung merepresentasikan pengalaman user: latency p99 < 200ms, error rate < 0.1%, throughput > 1000 req/s. Dari SLI turun SLO (target misal 99.9% request memenuhi SLI dalam 30 hari), dan Error Budget (sisa ketidaksempurnaan yang bisa ditoleransi). Alert hanya aktif saat error budget burn rate melebihi ambang — misalnya 2% error budget habis dalam 1 jam (burn rate 14.4x).

Praktik terbaik 2026: Definisikan SLI per user journey (login, search, checkout), bukan per service. SLO harus disepakati product dan engineering bersama — ini kontrak bisnis, bukan preferensi teknis.

OpenTelemetry: Standar Instrumentasi Universal

OpenTelemetry (OTel) v1.30+ (rilis Juli 2026) telah mencapai stabilitas API untuk traces, metrics, dan logs. Keunggulan utamanya: auto-instrumentation untuk Java, Python, Go, Node.js, .NET — cukup attach agent tanpa ubah kode aplikasi. Untuk bahasa compiled (Go, Rust), opentelemetry-go-contrib/instrumentnet/http/otelhttp dan opentelemetry-rust menyediakan middleware siap pakai.

# Contoh Dockerfile dengan OTel Java Agent
FROM eclipse-temurin:21-jre

# Install OTel Java Agent
ADD https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/v1.32.0/opentelemetry-javaagent.jar /opt/otel/javaagent.jar

ENV JAVA_TOOL_OPTIONS="-javaagent:/opt/otel/javaagent.jar"
ENV OTEL_EXPORTER_OTLP_ENDPOINT="http://otel-collector:4317"
ENV OTEL_RESOURCE_ATTRIBUTES="service.name=payment-service,deployment.environment=production"
ENV OTEL_TRACES_SAMPLER="traceidratio"
ENV OTEL_TRACES_SAMPLER_ARG="0.1"

COPY target/app.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

Di sisi kolektor, OpenTelemetry Collector (distribusi otelcol-contrib) berfungsi sebagai telemetry pipeline terpusat: receive (OTLP, Prometheus, Jaeger, Zipkin), process (batch, memory_limiter, transform, filter), export (ke Tempo, Loki, Mimir, Prometheus, atau vendor SaaS). Konfigurasi config.yaml standar enterprise 2026 sudah mencakup memory_limiter (hindari OOM), batch (efisiensi jaringan), dan resource/detection (auto-detect cloud provider, k8s, host).

eBPF: Visibility Kernel-Level Tanpa Instrumentasi Kode

Extended Berkeley Packet Filter (eBPF) memungkinkan program sandboxed berjalan di kernel space untuk mengumpulkan network flow, system call, disk I/O, dan CPU profiling — tanpa restart aplikasi dan tanpa sidecar per pod. Tools seperti Cilium Tetragon, Pixie, dan Grafana Beyla (auto-instrumentation berbasis eBPF untuk Go, Python, Java, Node.js) telah matang di 2026.

Beyla secara otomatis menginstrumentasi library HTTP/gRPC (OpenSSL, BoringSSL, libgo, libpython) dan mengekspor traces + metrics ke OTel Collector via OTLP. Keuntungan: zero-code change, coverage 100% service (termasuk legacy dan third-party), overhead < 3% CPU.

# Beyla config snippet untuk OTel export
beyla:
  otel:
    endpoint: "otel-collector:4317"
    insecure: true
    attributes:
      - "k8s.namespace"
      - "k8s.pod.name"
      - "service.name"
  discovery:
    kubernetes: true
  profiling:
    enabled: true
    cpu: true
    heap: true

Kombinasi OTel (application-level context: business logic, user ID, request ID) + eBPF (kernel-level context: TCP retransmit, syscall latency, CPU flamegraph) memberikan full-stack observability tanpa blind spot.

LGTM Stack: Backend Terpadu yang Scalable

LGTM = Loki (logs), Grafana (visualisasi), Tempo (traces), Mimir (metrics). Semua komponen berbagi model data berbasis labels (bukan full-text indexing), memungkinkan korelasi instan antar pilar: klik trace ID di Grafana → buka log terkait di Loki → lihat metric latency di Mimir — semua dengan label yang sama (service.name, k8s.pod, traceID).

  • Mimir: Prometheus-compatible, horizontal scalable, multi-tenant, compression block storage (TSDB + object storage S3/GCS). Cocok untuk retention 13 bulan (compliance) dengan cost rendah.
  • Loki: Log aggregation dengan index label-only. Query {service="payment"} |= "error" | json | level="ERROR" return dalam detik untuk TB-scale logs.
  • Tempo: Trace backend object-storage-native, tidak butuh index terpisah. Support TraceQL (query language mirip LogQL) untuk filter trace by attribute, duration, error.
  • Grafana: Unified dashboard, alerting (Unified Alerting berbasis PromQL/LogQL/TraceQL), SLO dashboard built-in (grafana/slo plugin), OnCall untuk escalation.

Deployment standar 2026: Grafana Alloy (successor Promtail + OTel Collector) sebagai agent tunggal di setiap node — collect logs, metrics, traces, profiles; forward ke LGTM. Alloy config declaratif (.alloy file) mendukung discovery.kubernetes, prometheus.remote_write, loki.write, tempo.spanprocessor dalam satu pipeline.

Implementasi di Enterprise Indonesia: Lesson Learned

Beberapa enterprise Indonesia (fintech, e-commerce, telco) telah migrasi ke stack ini sepanjang H1 2026. Temuan kunci:

  1. Start small: Pilih 2-3 critical user journey, definisikan SLI/SLO, instrument dengan OTel auto-instrumentation + Beyla. Jangan coba instrument seluruh estate sekaligus.
  2. Error budget policy: Tetapkan error budget burn rate alert (2%/1h, 5%/6h, 10%/24h) sebagai alert utama. Matikan alert threshold infrastruktur lama bertahap.
  3. Cost control: Mimir + Loki + Tempo di object storage (MinIO on-prem / S3) ~ 60% lebih murah vs vendor SaaS untuk volume > 50 TB/bulan. Alloy mengurangi jumlah agent dari 3 jadi 1 per node.
  4. Team ownership: Setiap squad own SLO-nya. Platform team provide "paved road": Alloy DaemonSet, OTel Collector deployment, Grafana datasource provisioning, SLO dashboard template.

Roadmap 2026 H2: Profiling, AI-Ops, dan OpenTelemetry Profiles

Continuous Profiling (Pyroscope/Grafana Profiler) menjadi pilar ke-4 observabilitas. eBPF profiling (Beyla, Pyroscope eBPF) memberikan flamegraph CPU/memory tanpa agent per language. OTel Profiles (stabil Q3 2026) akan standarisasi format profiling cross-language.

AIOps mulai berguna: anomaly detection pada metric baseline (seasonal ARIMA di Mimir), log clustering (Loki + ML), trace root-cause suggestion (Tempo + dependency graph). Namun human-in-the-loop tetap wajib — AI propose, engineer dispose.

OpenTelemetry Metrics v2 (stable Q4 2026) membawa delta temporality default, exponential histogram native (kompresi tinggi untuk high-cardinality latency), dan exemplars linking metric ke trace ID — menghilangkan kebutuhan custom correlation.

Observabilitas 2026 bukan soal tools, tapi soal kultur reliability. SLO sebagai bahasa bersama product & engineering, OpenTelemetry + eBPF sebagai sensor universal, LGTM Stack sebagai backend terpadu. Enterprise Indonesia yang adopsi hari ini akan punya keunggulan komptitif: release lebih cepat, MTTR lebih rendah, dan customer trust yang terukur.

Read more