Ketika aplikasi hanya terdiri dari satu service, mencari penyebab error mungkin cukup dengan membuka log.
Namun situasinya berubah ketika satu request melewati API gateway, lima microservice, database, cache, dan message broker sebelum menghasilkan response.
Di sinilah Strategi Observability menjadi penting. Tim tidak cukup hanya mengetahui bahwa CPU tinggi atau service sedang down.
Mereka perlu memahami apa yang terjadi, bagian mana yang bermasalah, dan bagaimana dampaknya terhadap pengguna. Dengan telemetry yang terstruktur, investigasi sistem terdistribusi bisa menjadi jauh lebih cepat dan terarah.
Observability Bukan Sekadar Monitoring
Monitoring biasanya menjawab pertanyaan yang sudah diketahui sebelumnya, seperti apakah CPU terlalu tinggi atau error rate melewati batas tertentu.
Observability bergerak lebih jauh.
OpenTelemetry menjelaskan observability sebagai kemampuan memahami kondisi internal sistem melalui output seperti traces, metrics, dan logs.
Instrumentasi yang baik memungkinkan engineer menyelidiki masalah baru tanpa harus menambahkan telemetry setiap kali muncul incident yang berbeda.
Contohnya, monitoring memberi tahu bahwa checkout sedang lambat.
Observability membantu menjawab kenapa.
Masalah mungkin berasal dari database, payment provider, queue backlog, atau satu service yang melakukan retry berkali-kali.
Perbedaan ini sangat penting pada microservices karena failure sering tidak berada di service pertama yang memperlihatkan gejala.
Mulai dari Empat Golden Signals
Mengumpulkan semua metric yang tersedia bukan strategi yang efektif.
Mulailah dari indikator yang benar-benar menggambarkan kesehatan layanan.
Google SRE memperkenalkan empat golden signals: latency, traffic, errors, dan saturation. Jika hanya mampu mengukur beberapa hal dari user-facing system, keempat sinyal ini memberikan fondasi monitoring yang kuat.
Latency menjelaskan waktu yang dibutuhkan untuk melayani request. Traffic memperlihatkan tingkat permintaan. Error menggambarkan permintaan yang gagal, sedangkan saturation menunjukkan seberapa dekat resource dengan batas kapasitasnya.
Misalnya Order Service mempunyai CPU 85%.
Angka itu sendiri belum cukup.
Jika traffic meningkat dua kali lipat sementara latency dan error tetap normal, sistem mungkin masih sehat.
Sebaliknya, CPU 55% tetapi p99 latency melonjak dari 400 ms menjadi lima detik bisa menjadi pertanda dependency tertentu mengalami masalah.
Konteks lebih penting daripada satu metric tunggal.
Hubungkan Metrics, Logs, dan Traces
Tiga jenis telemetry utama sebaiknya tidak berdiri sendiri.
Metrics menunjukkan bahwa sesuatu berubah. Logs memberikan detail event. Traces membantu mengikuti perjalanan satu request melalui berbagai service.
OpenTelemetry menyediakan framework vendor-neutral untuk menghasilkan, mengumpulkan, dan mengekspor traces, metrics, serta logs.
Bayangkan error rate checkout naik pukul 14.30.
Dashboard metrics menunjukkan lonjakan HTTP 500.
Distributed trace memperlihatkan sebagian besar request gagal setelah memanggil Inventory Service.
Log Inventory kemudian menunjukkan database connection timeout.
Tanpa korelasi, engineer harus membuka banyak dashboard dan mencoba mencocokkan timestamp secara manual.
Gunakan trace ID atau correlation ID agar logs dari berbagai service bisa dikaitkan dengan request yang sama. AWS juga menjelaskan distributed tracing sebagai cara melacak request yang bergerak melalui berbagai komponen microservices.
Observabilty menjadi jauh lebih berguna ketika data yang dikumpulkan dapat saling terhubung.
Gunakan Structured Logging secara Konsisten
Pada sistem kecil, log seperti:
Something went wrong
mungkin masih bisa ditoleransi.
Pada ratusan instance microservice, pesan seperti itu hampir tidak membantu.
Gunakan structured logging dengan field konsisten, misalnya service.name, environment, trace_id, request_id, customer_tier, error_type, dan duration_ms.
OpenTelemetry merekomendasikan structured logs karena metadata dapat diproses dan dikorelasikan dengan telemetry lainnya secara lebih efektif.
Hindari memasukkan semua informasi ke satu string panjang.
Dengan log terstruktur, tim bisa mencari pola seperti semua timeout pada payment-service di region tertentu selama 15 menit terakhir.
Tetapi jangan log semua hal.
Logging setiap function call pada aplikasi dengan jutaan request dapat menghasilkan biaya storage besar serta membuat signal penting tenggelam di antara noise.
Gunakan level log secara konsisten dan hindari menyimpan password, token, atau informasi sensitif.
Terapkan Distributed Tracing pada Critical Flow
Tracing sangat bernilai ketika satu transaksi menyentuh banyak service.
Misalnya proses checkout:
Gateway → Cart → Order → Inventory → Payment → Shipping
Tanpa distributed tracing, developer hanya melihat potongan informasi dari setiap service.
Dengan trace, request dapat dilihat sebagai rangkaian span.
Microsoft menekankan centralized logging, real-time monitoring, dan distributed tracing sebagai bagian penting observability pada arsitektur microservices.
Span dapat menunjukkan berapa lama setiap operasi berjalan serta relationship parent-child antarservice.
Jika checkout membutuhkan 2,4 detik dan 1,7 detiknya berasal dari Payment Service, investigasi langsung memiliki titik awal.
Pastikan context propagation bekerja secara konsisten.
Trace ID harus diteruskan melalui HTTP request, RPC, maupun message asynchronous. Jika context hilang ketika request masuk Kafka atau queue, perjalanan transaksi akan terlihat terputus.
Kesalahan kecil dalam konfigruasi tracing dapat membuat data terlihat lengkap padahal beberapa dependency sebenarnya tidak terlacak.
Gunakan SLO agar Telemetry Berhubungan dengan Pengguna
Observability dapat menghasilkan ribuan metric, tetapi tidak semuanya sama penting.
SLO membantu menentukan kualitas layanan yang benar-benar ingin dipertahankan.
Google SRE menjelaskan Service Level Objective sebagai target reliability layanan dan merekomendasikan penggunaan beberapa SLI yang mewakili fungsi paling kritis bagi pelanggan.
Misalnya API checkout memiliki target:
99,9% request berhasil dan 99% response selesai di bawah 800 ms.
Sekarang telemetry mempunyai konteks bisnis.
Latency 500 ms mungkin tidak membutuhkan incident jika masih jauh di dalam target. Namun peningkatan error yang menghabiskan error budget dengan cepat layak mendapat perhatian.
SLO juga membantu menghindari obsesi mencapai 100% reliability.
Jika target reliability sudah tercapai dengan margin sehat, engineering effort mungkin lebih bernilai digunakan untuk fitur atau scalability.
Dengan demikian, observability tidak hanya menjelaskan kondisi sistem, tetapi membantu menentukan prioritas teknis.
Bangun Alert Berdasarkan Dampak, Bukan Semua Anomali
Alert yang terlalu banyak akhirnya tidak efektif.
Jika engineer menerima 50 alert per hari, mereka mulai mengabaikan sebagian notifikasi.
Google SRE memperingatkan bahwa paging manusia mempunyai biaya tinggi dan monitoring sebaiknya menghasilkan signal dengan noise serendah mungkin.
Alert yang membutuhkan respons manusia idealnya berkaitan dengan kondisi yang urgent, actionable, dan berdampak pada pengguna.
Jangan membuat pager hanya karena CPU mencapai 75% selama satu menit.
CPU tinggi belum tentu menjadi insiden.
Lebih baik alert berdasarkan dampak, misalnya error budget burn rate meningkat atau p99 latency checkout melewati SLO selama periode tertentu.
Metric infrastructure tetap penting untuk diagnosis, tetapi tidak semuanya harus membangunkan engineer tengah malam.
Pisahkan alert menjadi notification, ticket, dan page berdasarkan tingkat urgensinya.
Pendekatan ini membuat sistem alerting jauh lebih dipercayai oleh tim.
Gunakan Collector agar Telemetry Lebih Mudah Dikelola
Pada microservices besar, setiap service mengirim telemetry langsung ke banyak backend dapat menciptakan dependesi baru.
OpenTelemetry Collector memberikan lapisan vendor-neutral untuk menerima, memproses, dan mengekspor telemetry. Collector juga dapat mengurangi kebutuhan menjalankan berbagai agent terpisah untuk setiap backend observability.
Misalnya seluruh service mengirim OTLP ke Collector.
Collector kemudian melakukan batching, filtering, sampling, serta meneruskan metrics, logs, dan traces ke backend yang dipilih.
Arsitektur semacam ini memberi fleksibilitas.
Jika perusahaan mengganti observability vendor, perubahan tidak harus dilakukan pada setiap microservice.
Namun Collector sendiri menjadi bagian infrastructure penting.
Pantau queue, dropped telemetry, CPU, memory, dan export failure agar sistem observability tidak diam-diam kehilangan data ketika traffic melonjak.
Strategi Observability yang kuat menghubungkan metrics, logs, traces, dan SLO menjadi satu alur diagnosis.
Mulailah dari golden signals, gunakan structured logging, terapkan tracing pada critical flow, dan buat alert berdasarkan dampak pengguna.
Jangan sekadar mengumpulkan data sebanyak mungkin. Audit satu perjalanan pengguna paling penting hari ini dan pastikan setiap service di dalamnya benar-benar dapat ditelusuri.