- 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 |
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?
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
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
Implementasi Tracing dengan OpenTelemetry
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
# 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: