Belajar DevOps Engineer - Observability: Logging, Metrics, Tracing

#Pendahuluan

Di episode 10 kalian mengotomasi konfigurasi server. Tetapi setelah sistem jalan di produksi, muncul pertanyaan yang jauh lebih sulit: apakah sistem ini sehat? Deployment berhasil secara teknis belum berarti berfungsi bagi pengguna. Untuk menjawabnya, kalian butuh observability.

Observability adalah kemampuan menyimpulkan kondisi internal sistem dari output eksternalnya. Bedanya dengan monitoring: monitoring adalah alat (dashboards dan alert), observability adalah sifat sistem yang memungkinkan pertanyaan apa pun dijawab — bahkan pertanyaan yang belum pernah diajukan. Tim DevOps yang baik membangun keduanya. Di episode ini kalian memahami tiga pilar observability dan merakit stack-nya.

#Tiga Pilar Observability

#1. Logging — Apa yang Terjadi?

Log adalah catatan peristiwa: error, request, audit. Prinsip utamanya adalah structured logging — log sebagai JSON, bukan string bebas, agar bisa di-query dengan mudah:

# Buruk — sulit di-query
"User 42 login gagal dari 10.0.1.5"
 
# Baik — mudah difilter dan diaggregasi
{"level":"error","event":"login_failed","user_id":42,"ip":"10.0.1.5","ts":"2026-08-16T08:12:33Z"}

Stack populer: ELK (Elasticsearch, Logstash, Kibana) dan Loki (Grafana Labs) yang hemat resource karena mengindeks label, bukan seluruh isi log.

#2. Metrics — Seberapa Sehat?

Metrics adalah angka numerik yang diukur terus-menerus: http_requests_total, cpu_usage, latency. Bentuknya ringan dan bisa di-aggregasi, cocok untuk alerting dan dashboard.

Prometheus adalah standar de facto: ia melakukan pull metrics dari aplikasi (endpoint /metrics), menyimpannya secara time-series, dan mengevaluasi aturan alert. Grafana menampilkannya menjadi dashboard.

# Rate HTTP 5xx dalam 5 menit
rate(http_requests_total{status=~"5.."}[5m])

#3. Tracing — Ke Mana Request Pergi?

Microservice memecah satu request menjadi banyak hop. Distributed tracing melacak perjalanan satu request melewati semua service: setiap hop menjadi span dengan durasi, dan rangkaian span membentuk trace.

Alatnya: Jaeger dan Tempo, plus bahasa standar dari OpenTelemetry. Tanpa tracing, menemukan penyebab latensi tinggi di sistem 20 service adalah tebak-tebakan.

#OpenTelemetry: Bahasa Bersama

Masalah klasik observability: setiap library punya format sendiri. OpenTelemetry (OTel) menyelesaikannya dengan satu SDK dan satu format untuk semua sinyal — traces, metrics, dan logs.

import { NodeSDK } from "@opentelemetry/sdk-node"
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http"
import { OTLPMetricExporter } from "@opentelemetry/exporter-metrics-otlp-http"
 
const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: "http://otel-collector:4318" }),
  metricExporter: new OTLPMetricExporter({ url: "http://otel-collector:4318" }),
  serviceName: "myapp",
})
 
sdk.start()

Aplikasi yang di-instrumentasi OTel mengirim data ke OTel Collector — proxy yang menerima semua format, memproses (filter, redaksi), lalu meneruskannya ke backend pilihan (Prometheus, Jaeger, Loki, dll). Ini membuat stack observability bisa diganti-ganti tanpa mengubah aplikasi.

#Praktik: Stack Observability Lengkap

Mari rakit stack ringkas dengan Docker Compose. Prometheus mengambil metrics, Grafana menampilkan, dan OTel Collector menerima telemetry dari aplikasi:

services:
  prometheus:
    image: prom/prometheus:v2.53.0
    ports: ["9090:9090"]
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
 
  grafana:
    image: grafana/grafana:11.0.0
    ports: ["3000:3000"]
 
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.104.0
    ports:
      - "4317:4317"
      - "4318:4318"

global:
  scrape_interval: 15s
 
scrape_configs:
  - job_name: "myapp"
    static_configs:
      - targets: ["myapp:3000"]

#Pitfall Umum

• Log tanpa struktur — string bebas tidak bisa di-query secara efektif; buat semua log JSON.
• Metrics tanpa label yang disengaja — label status, endpoint, instance berguna; tetapi kardinalitas tak terbatas (misal user_id per metric) akan meledakkan storage.
• Alert tanpa baseline — alert yang membunyikan alarm untuk hal normal membuat tim mati rasa (alert fatigue).
• Observability tanpa action — dashboard yang tidak pernah dibuka tidak bernilai; hubungkan dengan alert dan runbook.
• Mengabaikan OpenTelemetry — vendor lock-in observability mahal; OTel menjaga portabilitas.

#Penutup

Inti yang harus dibawa pulang:

• Monitoring = alat; observability = kemampuan bertanya apa pun tentang sistem.
• Tiga pilar: logging (apa yang terjadi), metrics (seberapa sehat), tracing (ke mana request pergi).
• Prometheus + Grafana untuk metrics; Loki/ELK untuk log; Jaeger/Tempo untuk tracing.
• OpenTelemetry adalah standar satu SDK yang menjadikan stack observability portabel.

Di episode 12 selanjutnya kita naik satu tingkat ke Cloud Platforms (AWS/GCP/Azure) — tempat sebagian besar infrastruktur modern dijalankan. Kalian akan belajar layanan inti setiap penyedia, cara men-deploy aplikasi di cloud, dan best practices biaya serta keamanan yang wajib dipegang sejak awal.