DevOps & Cloud

Monitoring & Observability untuk Developer

Tutorial lengkap memahami dan menerapkan monitoring serta observability — metrics, logs, distributed traces, Prometheus, Grafana, alerting, dan SLA/SLO untuk aplikasi production

📅 8 April 2026 📖 13 menit baca Menengah

🐝

Tim BeebaneLabs Penulis & Kontributor Teknologi

📋 Daftar Isi

Pengenalan Monitoring & Observability
Tiga Pilar Observability
Metrics: Angka yang Menceritakan Kondisi Sistem
Logs: Cerita Peristiwa Sistem
Distributed Traces: Jejak Request
Prometheus: Platform Monitoring Modern
Grafana: Visualisasi & Dashboard
Alerting: Sistem Peringatan Cerdas
SLA, SLO & SLI: Mengukur Kualitas Layanan
Quiz Pemahaman

1. Pengenalan Monitoring & Observability

Monitoring dan Observability adalah dua konsep krusial dalam pengembangan dan operasi sistem modern. Monitoring adalah praktik mengumpulkan dan menganalisis data dari sistem untuk memahami kondisinya. Observability adalah kemampuan untuk memahami kondisi internal sistem hanya dari output eksternalnya.

Bayangkan sebuah mobil tanpa dashboard — Anda tidak tahu kecepatan, sisa bahan bakar, atau suhu mesin. Tanpa monitoring, sistem aplikasi Anda seperti mobil tanpa dashboard. Dengan observability, Anda bisa menjawab pertanyaan seperti "mengapa aplikasi lambat?" bahkan tanpa merencanakan pertanyaan tersebut sebelumnya.

Mengapa Monitoring & Observability Penting?

Manfaat	Penjelasan
Detect Issues Early	Mendeteksi masalah sebelum pengguna terdampak secara signifikan
Root Cause Analysis	Menemukan penyebab akar masalah dengan cepat dan akurat
Performance Optimization	Mengidentifikasi bottleneck dan mengoptimalkan performa sistem
Capacity Planning	Merencanakan kebutuhan infrastruktur berdasarkan data historis
Compliance & Audit	Memenuhi kepatuhan regulasi dan kebutuhan audit keamanan
Business Intelligence	Insight bisnis dari data penggunaan dan pola aplikasi

Monitoring vs Observability

Aspek	Monitoring	Observability
Definisi	Mengumpulkan data & memberi peringatan	Memahami kondisi internal dari data eksternal
Fokus	What is happening?	Why is it happening?
Pertanyaan	Predefined (yang sudah diketahui)	Ad-hoc (spontan, tidak terduga)
Data	Metrics & Logs	Metrics, Logs, & Traces
Tool Contoh	Nagios, Zabbix	Prometheus, Grafana Tempo, Jaeger
Cocok untuk	Sistem sederhana, infrastructure	Microservices, distributed systems

Diagram: Monitoring vs Observability

2. Tiga Pilar Observability

Observability modern didasarkan pada tiga pilar utama: Metrics, Logs, dan Traces. Ketiga pilar ini saling melengkapi dan memberikan gambaran komprehensif tentang kondisi sistem.

Tiga Pilar dan Fungsinya

Pilar	Deskripsi	Format Data	Contoh Tools
Metrics	Numerik yang merepresentasikan kondisi sistem secara kuantitatif	Time series data	Prometheus, InfluxDB, Datadog
Logs	Catatan peristiwa detail dari aplikasi atau sistem	Structured/Unstructured text	ELK Stack, Loki, Fluentd
Traces	Jejak perjalanan request melalui berbagai service	Distributed trace data	Jaeger, Zipkin, Tempo

💡 Analogi Sederhana

Bayangkan Anda seorang dokter. Metrics seperti membaca detak jantung dan suhu tubuh (angka). Logs seperti rekam medis (catatan detail). Traces seperti mengikuti aliran darah dari jantung ke seluruh tubuh (perjalanan). Ketiganya dibutuhkan untuk diagnosis lengkap.

Kapan Menggunakan Pilar Mana?

Flowchart: Memilih Pilar Observability yang Tepat

LOGS
Error
Warnings
Events
Debug
METRICS
CPU
Memory
Latency
Traffic
Apa yang ingin Anda ketahui?
▼ ▼ ▼
Seberapa banyak? Apa yang terjadi? Bagaimana mengalir?
▼ ▼ ▼
TRACES
Request
Latency
Per
Service

⚠️ Kesalahan Umum

Jangan hanya mengandalkan satu pilar! Banyak tim hanya menggunakan metrics dan mengabaikan logs/traces. Saat terjadi masalah yang tidak terprediksi, mereka kesulitan menemukan root cause. Gunakan ketiga pilar secara harmonis untuk observability yang maksimal.

3. Metrics: Angka yang Menceritakan Kondisi Sistem

Metrics adalah data numerik yang dikumpulkan dari waktu ke waktu (time series data). Metrics membantu Anda memahami kondisi sistem secara kuantitatif dan mendeteksi anomali atau tren tertentu.

Jenis-Jenis Metrics

Jenis	Deskripsi	Contoh
Counter	Nilai yang selalu naik, tidak pernah turun	Jumlah request HTTP, jumlah error
Gauge	Nilai yang bisa naik atau turun	CPU usage, memory usage, jumlah koneksi aktif
Histogram	Distribusi nilai dalam range tertentu	Response time distribution
Summary	Statistik agregat dari data	P95/P99 latency, total request count

RED Method untuk Microservices

RED Method adalah framework metrik yang dirancang khusus untuk microservices. Setiap service harus mengekspos metrik berikut:

5. Distributed Traces: Jejak Request

Distributed Tracing memungkinkan Anda melacak perjalanan sebuah request dari awal hingga akhir melewati berbagai service dalam arsitektur microservices. Setiap operasi dalam request direpresentasikan sebagai span yang memiliki hubungan parent-child.

Konsep Dasar Distributed Tracing

Konsep	Penjelasan
Trace	Seluruh perjalanan request dari client hingga response lengkap
Span	Satu unit kerja dalam trace — misalnya query database atau HTTP call
Trace ID	Identifier unik yang menghubungkan semua span dalam satu request
Span ID	Identifier unik untuk setiap span individual
Parent Span ID	ID span induk — menunjukkan hubungan hierarchical
Context Propagation	Mekanisme meneruskan trace context antar service

Contoh Distributed Trace

Diagram: Distributed Trace dalam E-Commerce

Implementasi Tracing dengan OpenTelemetry

Diagram: Arsitektur Monitoring dengan Prometheus

flowchart TD
    N0["ALERTMANAGER (Notifikasi)"]
    N1["Node Exporter :9100"]
    N2["App Metrics :8080"]
    N3["MySQL Exporter :9104"]
    N4["Redis Exporter :9121"]
    N5["TSDB (Storage)"]
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N0

7. Grafana: Visualisasi & Dashboard

Grafana adalah platform visualisasi data open-source yang mendukung berbagai sumber data seperti Prometheus, Elasticsearch, InfluxDB, PostgreSQL, dan banyak lagi. Grafana memungkinkan Anda membuat dashboard interaktif yang indah untuk memvisualisasikan metrics.

Fitur Utama Grafana

Fitur	Penjelasan
Multi-DataSource	Hubungkan Prometheus, Elasticsearch, SQL, dll dalam satu dashboard
Panel Beragam	Graph, gauge, table, heat map, stat, bar chart, dll
Alerting Built-in	Alert langsung dari dashboard panel
Annotation	Tandai event penting seperti deploy atau incident pada grafik
Sharing & Export	Share dashboard sebagai link atau JSON provisioned
Template Variables	Dashboard interaktif dengan dropdown filter

Instalasi Grafana

Bash — Instalasi Grafana

# Instalasi Grafana OSS di Ubuntu/Debian
sudo apt-get install -y apt-transport-https software-properties-common wget
wget -q -O - https://apt.grafana.com/gpg.key | sudo gpg --dearmor > /etc/apt/keyrings/grafana.gpg
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install grafana

# Jalankan Grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

# Akses dashboard di http://localhost:3000
# Default login: admin / admin

Provisioning Data Source & Dashboard

YAML — Grafana Data Source Provisioning

# /etc/grafana/provisioning/datasources/prometheus.yml
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false

  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100
    editable: false

  - name: Jaeger
    type: jaeger
    access: proxy
    url: http://jaeger:16686
    editable: false

Dashboard Best Practices

💡 Tips Membuat Dashboard Efektif

Overview → Detail: Mulai dari dashboard ringkasan, lalu drill-down ke detail
Golden Signals: Tampilkan Latency, Traffic, Errors, Saturation (dari SRE book)
Consistent Layout: Panel paling penting di kiri atas, kurang penting di kanan bawah
Template Variables: Buat dropdown untuk filter namespace, service, instance
Annotation: Tandai waktu deploy untuk korelasi perubahan performa
Jangan Overload: Dashboard harus bisa dibaca dalam 5 detik sekilas

8. Alerting: Sistem Peringatan Cerdas

Alerting adalah komponen kritis dalam monitoring yang memastikan tim operasional mendapat notifikasi tepat waktu saat ada masalah. Alert yang baik harus informatif, actionable, dan tidak membuat tim kelelahan (alert fatigue).

Prinsip Alerting yang Baik

Prinsip	Penjelasan
Actionable	Setiap alert harus memerlukan tindakan manusia atau di-acknowledge
Urgent & Important	Hanya alert untuk kondisi yang mempengaruhi pengguna atau SLA
Diagnosable	Alert harus menyertakan konteks yang cukup untuk diagnosis awal
Proportional	Tingkat urgensi sesuai dengan dampak aktual
No Alert Fatigue	Hindari alert terlalu sensitif yang sering false positive

Konfigurasi Alert Rules di Prometheus

YAML — Prometheus Alert Rules

# alert_rules.yml
groups:
  - name: application_alerts
    rules:
      # Alert: Error rate tinggi
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))
          > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate tinggi terdeteksi"
          description: "Error rate {{ $value | humanizePercentage }} melebihi 5% selama 5 menit"
          runbook_url: "https://wiki.internal/runbook/high-error-rate"

      # Alert: Latency P99 tinggi
      - alert: HighP99Latency
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          ) > 2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "P99 latency tinggi: {{ $value }}s"

      # Alert: Disk usage hampir penuh
      - alert: DiskSpaceRunningLow
        expr: |
          (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes)
          * 100 > 85
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Disk usage {{ $value }}% pada {{ $labels.instance }}"

      # Alert: Pod restart berulang
      - alert: PodCrashLooping
        expr: |
          increase(kube_pod_container_status_restarts_total[1h]) > 3
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.pod }} crash looping"

Konfigurasi Alertmanager

YAML — Alertmanager Configuration

# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  receiver: 'default'
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack-warning'

receivers:
  - name: 'default'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/xxx'
        channel: '#alerts'
        title: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}'

  - name: 'pagerduty-critical'
    pagerduty_configs:
      - service_key: 'your-pagerduty-key'

  - name: 'slack-warning'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/yyy'
        channel: '#alerts-warning'
        title: '[WARNING] {{ .GroupLabels.alertname }}'

⚠️ Hindari Alert Fatigue

Alert fatigue terjadi ketika tim menerima terlalu banyak alert, sehingga alert yang benar-benar penting diabaikan. Beberapa strategi untuk menghindarinya:

Gunakan for clause untuk memastikan kondisi berlangsung cukup lama sebelum alert
Group alert yang serupa untuk mengurangi noise
Rutin review dan matikan alert yang sering false positive
Gunakan escalation policy berbeda untuk severity berbeda

9. SLA, SLO & SLI: Mengukur Kualitas Layanan

Dalam operasi sistem production, penting untuk memiliki standar kualitas layanan yang jelas dan terukur. Tiga konsep utama dalam framework ini adalah SLI (Service Level Indicator), SLO (Service Level Objective), dan SLA (Service Level Agreement).

Perbedaan SLI, SLO, dan SLA

Istilah	Definisi	Contoh
SLI	Metrik kuantitatif yang mengukur tingkat kualitas layanan	Persentase request yang berhasil, latency P99
SLO	Target internal untuk SLI yang ingin dicapai	Availability 99.9%, P99 latency < 200ms
SLA	Perjanjian formal dengan konsekuensi jika tidak terpenuhi	Uptime 99.9% dengan credit jika gagal

Error Budget

Error Budget adalah sisa toleransi error yang tersedia berdasarkan SLO. Jika SLO Anda adalah 99.9% availability, maka Anda memiliki error budget sebesar 0.1% atau sekitar 43.8 menit downtime per bulan.

PromQL — Menghitung Error Budget

# SLO: 99.9% availability (error budget = 0.1%)

# Total request dalam 30 hari
total_requests = sum(increase(http_requests_total[30d]))

# Total error request dalam 30 hari
error_requests = sum(increase(http_requests_total{status=~"5.."}[30d]))

# Actual availability
actual_availability = (1 - error_requests / total_requests) * 100

# Error budget remaining (dalam persentase)
error_budget_total = 0.1  # 0.1% for 99.9% SLO
error_budget_consumed = (error_requests / total_requests) * 100
error_budget_remaining = error_budget_total - error_budget_consumed

# Error budget remaining (dalam menit per bulan)
error_budget_minutes = error_budget_remaining / 100 * 30 * 24 * 60

Contoh SLO untuk Berbagai Layanan

Layanan	SLI	SLO	Error Budget / Bulan
API Gateway	Availability	99.95%	~21.6 menit
Payment Service	Availability	99.99%	~4.38 menit
Notification Service	Availability	99.9%	~43.8 menit
Analytics Pipeline	Data Freshness	< 5 menit lag	N/A
CDN / Static Assets	P95 Latency	< 100ms	N/A

💡 Error Budget Policy

Buat kebijakan error budget yang jelas. Contoh:

Error budget > 50% tersisa: Tim boleh melakukan deployment berisiko tinggi
Error budget 20-50%: Deployment dengan approval, tambah testing
Error budget < 20%: Freeze deployment, fokus stabilitas
Error budget habis: Code freeze total, semua engineer fokus reliability