Episode ini membuat aplikasi bisa diamati: metrik dengan Prometheus, tracing dengan OpenTelemetry, strukturisasi log, dan error monitoring dengan Sentry. Kalian juga belajar performance budget dan alerting untuk menjaga layanan tetap sehat.

Setelah aplikasi berjalan di production, pertanyaannya berubah: bagaimana kita tahu ia sehat? Episode 21 menjawab dengan observability — tiga pilar: metrik, log, dan trace. Kalian akan belajar memakai Prometheus, OpenTelemetry, dan Sentry.
Kita juga membahas performance budget dan alerting, agar masalah terdeteksi sebelum pengguna mengeluh. Observability bukan opsional — ia mata dan telinga aplikasi production.
Prometheus mengumpulkan metrik dari aplikasi lewat endpoint HTTP. Library prometheus-client menyediakannya:
pip install prometheus-clientfrom prometheus_client import Counter, start_http_server
import random
import time
REQUEST_TOTAL = Counter("http_request_total", "Total request HTTP", ["method"])
start_http_server(8001)
for _ in range(5):
REQUEST_TOTAL.labels(method="GET").inc()
time.sleep(1)
print("metrik dikirim")Counter("http_request_total", "Total request HTTP", ["method"]) mendefinisikan metrik counter dengan label. start_http_server(8001) membuka endpoint metrik. Prometheus men-scrape endpoint ini secara berkala dan menyimpan datanya.
Tracing melacak perjalanan satu request melalui banyak layanan. OpenTelemetry adalah standar untuk ini:
pip install opentelemetry-api opentelemetry-sdkfrom opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor, ConsoleSpanExporter
trace.set_tracer_provider(TracerProvider())
provider = trace.get_tracer_provider()
provider.add_span_processor(SimpleSpanProcessor(ConsoleSpanExporter()))
tracer = trace.get_tracer("belajar")
with tracer.start_as_current_span("proses-pembayaran"):
print("membuat span pembayaran")trace.get_tracer("belajar") mengambil tracer bernama. tracer.start_as_current_span("proses-pembayaran") membuat span yang mengukur durasi operasi. Span diekspor ke backend seperti Jaeger atau Tempo untuk visualisasi.
Log terstruktur memakai format JSON agar mudah dianalisis:
import json
import logging
logger = logging.getLogger("aplikasi")
def proses(order_id):
logger.info(json.dumps({
"event": "order_processed",
"order_id": order_id,
"status": "success",
}))
proses("order-123")json.dumps({...}) mengubah dict log menjadi JSON. Format ini bisa di-parse oleh sistem seperti Loki, Elasticsearch, dan Cloud Logging. Log terstruktur jauh lebih mudah difilter daripada teks bebas.
Sentry mengumpulkan error dan crash secara otomatis:
pip install sentry-sdkimport sentry_sdk
sentry_sdk.init(
dsn="https://contoh@o0.ingest.sentry.io/0",
traces_sample_rate=1.0,
)
def panggil():
raise ValueError("contoh error")
try:
panggil()
except Exception:
sentry_sdk.capture_exception()
print("error dikirim ke Sentry")sentry_sdk.init(dsn=...) menghubungkan aplikasi ke project Sentry. sentry_sdk.capture_exception() mengirim error beserta stack trace dan konteks. Sentry juga mengumpulkan uncaught exception secara otomatis di kebanyakan framework.
Performance budget adalah batas performa yang disepakati — misalnya response time p95 di bawah 300 ms. Metrik dari Prometheus dipakai untuk mengukurnya:
from prometheus_client import Histogram
REQUEST_DURATION = Histogram(
"http_request_duration_seconds",
"Durasi request HTTP",
buckets=(0.05, 0.1, 0.25, 0.5, 1, 2.5, 5),
)Histogram("http_request_duration_seconds", ...) mengukur distribusi durasi request. Bucket menentukan granularitas persentil seperti p95. Histogram adalah dasar penghitungan performance budget secara kuantitatif.
Alert memberi tahu saat metrik melanggar batas. Contoh aturan Prometheus:
groups:
- name: aplikasi
rules:
- alert: RequestLambat
expr: histogram_quantile(0.95, http_request_duration_seconds_bucket) > 0.3
for: 5m
annotations:
summary: "Response time p95 di atas 300ms"histogram_quantile(0.95, ...) > 0.3 memicu alert saat p95 melewati 300 ms selama 5 menit. Alert dikirim ke Slack, email, atau PagerDuty. Alerting yang baik membatasi noise — hanya memberitahu masalah yang benar-benar penting.
Inti yang harus dibawa pulang:
Di episode 22 selanjutnya kita akan membahas migration, scaling teams, dan governance — mengupgrade versi Python dengan aman, kebijakan deprecation dan compatibility testing, strategi monorepo versus polyrepo, pengelolaan package internal, serta coding standards dan contribution guidelines untuk tim besar. Inilah penutup perjalanan Belajar Python kalian!