- 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 |
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β OBSERVABILITY STACK β β β β ββββββββββββββ ββββββββββββββ ββββββββββββββ β β β METRICS β β LOGS β β TRACES β β β β (Angka) β β (Teks) β β (Jejak) β β β β β β β β β β β β CPU: 72% β β [ERROR] DB β β ββreqβββΊ β β β β RAM: 4GB β β timeout at β β svc-A β β β β Req/s: 1k β β line 42 β β βββΊsvc-B β β β βββββββ¬βββββββ βββββββ¬βββββββ βββββββ¬βββββββ β β β β β β β ββββββββββββββ¬βββββββββββββββββββββββ β β βΌ β β ββββββββββββββββββ β β β CORRELATION β β Menghubungkan data β β βββββββββ¬βββββββββ β β βΌ β β ββββββββββββββββββ β β β DASHBOARDS & β β Visualisasi & Alerting β β β ALERTS β β β ββββββββββββββββββ β ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
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 |
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?
Apa yang ingin Anda ketahui?
β
ββββββββββββΌβββββββββββββββββββββββββββββββββββ
βΌ βΌ βΌ
Seberapa banyak? Apa yang terjadi? Bagaimana mengalir?
β β β
βΌ βΌ βΌ
βββββββββββ ββββββββββββ βββββββββββββ
β METRICS β β LOGS β β TRACES β
β β β β β β
β CPU β β Error β β Request β
β Memory β β Warnings β β Latency β
β Latency β β Events β β Per β
β Traffic β β Debug β β Service β
βββββββββββ ββββββββββββ βββββββββββββ
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:
# R = Rate β Jumlah request per detik
rate(http_requests_total[5m])
# E = Errors β Jumlah error per detik
rate(http_requests_total{status=~"5.."}[5m])
# D = Duration β Latency request
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# Error ratio = errors / total requests
rate(http_requests_total{status=~"5.."}[5m])
/
rate(http_requests_total[5m])
USE Method untuk Infrastruktur
USE Method difokuskan pada infrastruktur (CPU, disk, network, memory):
# U = Utilization β Persentase penggunaan resource node_cpu_seconds_total node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes # S = Saturation β Overload / queue yang menunggu node_load1 # Load average 1 menit node_disk_io_time_weighted_seconds_total # E = Errors β Error yang terjadi node_disk_read_errors_total node_network_receive_errs_total
- Gunakan RED Method untuk layanan/application level
- Gunakan USE Method untuk infrastruktur level
- Ingat formula: Latency Γ Traffic = Errors (semua saling terkait)
- Setiap microservice minimal harus mengekspos metrik RED
4. Logs: Cerita Peristiwa Sistem
Logs adalah catatan kronologis peristiwa yang terjadi dalam sistem. Logs memberikan detail kontekstual yang kaya tentang apa yang terjadi pada waktu tertentu, membuatnya sangat berharga untuk debugging dan audit trail.
Structured vs Unstructured Logs
| Aspek | Unstructured Logs | Structured Logs (JSON) |
|---|---|---|
| Format | Plain text bebas | JSON dengan key-value pair |
| Parsing | Sulit, perlu regex | Mudah, otomatis |
| Searchability | Lambat | Cepat dengan indexing |
| Contoh | 2026-06-25 ERROR: Connection timeout | {"time":"2026-06-25","level":"error","msg":"timeout","db":"primary"} |
| Rekomendasi | Hindari | Gunakan selalu |
Menerapkan Structured Logging
{
"timestamp": "2026-06-25T14:30:22.123Z",
"level": "error",
"service": "payment-api",
"trace_id": "abc123def456",
"span_id": "789ghi012",
"method": "POST",
"path": "/api/v1/payments",
"status_code": 500,
"duration_ms": 3420,
"error": "Connection refused to payment-gateway:5432",
"user_id": "u_12345",
"request_id": "req_abc789",
"host": "payment-api-3a7f9c",
"message": "Payment processing failed"
}
Log Levels dan Kapan Menggunakannya
| Level | Contoh | Kapan Digunakan |
|---|---|---|
| DEBUG | Variable value, function entry | Development/debugging, nonaktifkan di production |
| INFO | Server started, request handled | Operasi normal, event penting |
| WARN | Disk usage 80%, slow query | Perlu perhatian tapi belum error |
| ERROR | Connection failed, payment error | Operasi gagal, perlu investigasi |
| FATAL | Out of memory, corrupted DB | Sistem tidak bisa melanjutkan operasi |
ELK Stack: Solusi Logging Populer
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β ELK STACK β β β β ββββββββββββ ββββββββββββ ββββββββββββββββ β β β App Logs βββββΆβLogstash βββββΆβ Elasticsearchβ β β β β β(Parse & β β (Search & β β β β Web App β β Enrich) β β Index) β β β β API β ββββββββββββ ββββββββ¬ββββββββ β β β DB β β β β ββββββββββββ βΌ β β ββββββββββββββββ β β β Kibana β β β β (Dashboard & β β β β Visualization)β β β ββββββββββββββββ β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
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
Client βββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β β Trace ID: abc-123-def-456 βΌ βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β Gateway (Span 1) β 120ms β β βββ Auth Service (Span 2) β 15ms β β βββ Product Service (Span 3) β 45ms β β β βββ Redis Cache (Span 4) β 2ms β β βββ Cart Service (Span 5) β 30ms β β β βββ PostgreSQL (Span 6) β 12ms β β βββ Payment Service (Span 7) β 25ms β β βββ Payment Gateway (Span 8) β 18ms β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ Total latency: 120ms Bottleneck: Product Service (45ms) β 37.5% dari total waktu
Implementasi Tracing dengan OpenTelemetry
// Instalasi: npm install @opentelemetry/sdk-node @opentelemetry/api
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { JaegerExporter } = require('@opentelemetry/exporter-jaeger');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const { trace } = require('@opentelemetry/api');
// Setup tracer provider
const provider = new NodeTracerProvider({
resource: new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: 'payment-service',
[SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
}),
});
// Export ke Jaeger
const exporter = new JaegerExporter({
endpoint: 'http://jaeger:14268/api/traces',
});
provider.addSpanProcessor(new BatchSpanProcessor(exporter));
provider.register();
// Menggunakan tracing di kode aplikasi
const tracer = trace.getTracer('payment-service');
async function processPayment(orderId, amount) {
return tracer.startActiveSpan('processPayment', async (span) => {
try {
span.setAttribute('order.id', orderId);
span.setAttribute('payment.amount', amount);
// Span untuk validasi
await tracer.startActiveSpan('validateOrder', async (childSpan) => {
await validateOrder(orderId);
childSpan.end();
});
// Span untuk koneksi payment gateway
await tracer.startActiveSpan('callPaymentGateway', async (childSpan) => {
await callGateway(amount);
childSpan.end();
});
span.setStatus({ code: 0 }); // OK
} catch (error) {
span.setStatus({ code: 2, message: error.message }); // ERROR
span.recordException(error);
throw error;
} finally {
span.end();
}
});
}
- Gunakan OpenTelemetry sebagai standar vendor-neutral
- Pastikan semua service meneruskan trace context dalam HTTP headers (
traceparent) - Tambahkan attributes bermakna pada span (user ID, order ID, dll)
- Gunakan sampling strategis untuk sistem dengan traffic tinggi
6. Prometheus: Platform Monitoring Modern
Prometheus adalah sistem monitoring open-source yang dirancang untuk mengumpulkan dan mengekspos metrics sebagai time series data. Prometheus menggunakan model pull-based β ia aktif mengambil (scrape) metrics dari target aplikasi secara berkala.
Fitur Utama Prometheus
| Fitur | Penjelasan |
|---|---|
| Pull-based Model | Prometheus scrape metrics dari target, bukan push dari aplikasi |
| PromQL | Bahasa query yang powerful untuk analisis time series data |
| Multi-dimensional Labels | Data bisa di-filter dan di-group dengan label |
| Built-in Alerting | Integrasi dengan Alertmanager untuk notifikasi |
| Service Discovery | Otomatis menemukan target baru (Kubernetes, Consul, dll) |
| TSDB Storage | Time series database lokal yang efisien |
Instalasi Prometheus
# Download Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar xzf prometheus-2.53.0.linux-amd64.tar.gz
cd prometheus-2.53.0.linux-amd64
# Konfigurasi prometheus.yml
cat > prometheus.yml << 'EOF'
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager:9093
rule_files:
- "alert_rules.yml"
scrape_configs:
# Monitor Prometheus itu sendiri
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# Monitor aplikasi Node.js
- job_name: 'node-app'
static_configs:
- targets: ['app-server:9100']
# Monitor dengan service discovery Kubernetes
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
EOF
# Jalankan Prometheus
./prometheus --config.file=prometheus.yml --storage.tsdb.retention.time=30d
PromQL: Bahasa Query Prometheus
# Rate of HTTP requests per second (5m window)
rate(http_requests_total[5m])
# Error rate (request dengan status 5xx)
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
# P99 latency
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# CPU usage per instance
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# Memory usage percentage
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
# Top 10 busiest endpoints
topk(10, sum by (handler) (rate(http_requests_total[5m])))
# Alert: Error rate lebih dari 5% dalam 5 menit
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
Arsitektur Prometheus
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β PROMETHEUS ARCHITECTURE β β β β ββββββββββββ ββββββββββββ ββββββββββββ ββββββββββββ β β β Node β β App β β MySQL β β Redis β β β β Exporter β β Metrics β β Exporter β β Exporter β β β β :9100 β β :8080 β β :9104 β β :9121 β β β ββββββ¬ββββββ ββββββ¬ββββββ ββββββ¬ββββββ ββββββ¬ββββββ β β β β β β β β ββββββββββββββββ΄βββββββ¬ββββββββ΄βββββββββββββββ β β β Scrape (pull) β β ββββββββββ΄βββββββββ β β β PROMETHEUS β β β β :9090 β β β β β β β β βββββββββββββββ β β β β β TSDB β β β β β β (Storage) β β β β β βββββββββββββββ β β β ββββββββββ¬βββββββββ β β β β β ββββββββββββββββΌβββββββββββββββ β β βΌ βΌ β β ββββββββββββββββββββ ββββββββββββββββ β β β GRAFANA β β ALERTMANAGER β β β β (Visualisasi) β β (Notifikasi)β β β ββββββββββββββββββββ ββββββββββββββββ β ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
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
# 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
# /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
- 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
# 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
# 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 }}'
Alert fatigue terjadi ketika tim menerima terlalu banyak alert, sehingga alert yang benar-benar penting diabaikan. Beberapa strategi untuk menghindarinya:
- Gunakan
forclause 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.
# 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 |
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
10. Quiz: Uji Pemahamanmu!
Setelah membaca tutorial di atas, jawablah 5 pertanyaan berikut untuk menguji pemahamanmu tentang Monitoring & Observability: