Ketika aplikasi mengalami insiden, satu jenis telemetry hampir tidak pernah memberikan jawaban lengkap.
Metrics mungkin menunjukkan error rate meningkat, tetapi tidak menjelaskan request mana yang gagal. Logs memberi detail error, tetapi sering kehilangan gambaran perjalanan request antarservice.
Karena itu, Menggabungkan Metrics, Logs, dan Traces menjadi pendekatan yang jauh lebih efektif. Ketiga sinyal ini mempunyai fungsi berbeda tetapi saling melengkapi.
Metrics membantu menemukan gejala, traces mempersempit lokasi masalah, sedangkan logs memberikan detail teknis yang membantu tim menemukan root cause dan mengambil tindakan.
Pahami Fungsi Berbeda dari Setiap Telemetry
Metrics adalah pengukuran numerik yang dikumpulkan selama aplikasi berjalan. Contohnya request per second, error rate, CPU utilization, memory usage, atau response time.
Logs merekam event secara lebih detail, seperti database timeout, authentication failure, atau exception tertentu.
Sementara itu, traces menggambarkan perjalanan sebuah request melalui aplikasi terdistribusi.
OpenTelemetry mendefinisikan ketiganya sebagai sinyal observability berbeda: metrics merepresentasikan pengukuran runtime, logs merekam event, sedangkan traces memperlihatkan jalur request melalui sistem.
Tidak ada satu sinyal yang selalu lebih baik.
Nilainya justru muncul ketika ketiganya digunakan untuk menjawab pertanyaan berbeda dalam incident investigation.
Mulai Investigasi dari Metrics
Metrics biasanya menjadi pintu masuk paling praktis ketika masalah mulai terjadi.
Google SRE menjelaskan bahwa metrics cocok digunakan untuk dashboard dan alert karena sifatnya yang relatif cepat serta mampu memberikan gambaran kondisi sistem secara agregat. Logs kemudian sering digunakan untuk mencari akar masalah karena memiliki detail lebih granular.
Misalnya dashboard menunjukkan p95 checkout latency naik dari 450 ms menjadi 2,3 detik pada pukul 14.15.
Jangan langsung membuka jutaan baris log.
Persempit dulu masalah menggunakan metric tambahan. Apakah error ikut meningkat? Apakah hanya terjadi pada satu region? Apakah database connection pool mulai penuh?
Pendekatan seperti ini mengubah investigasi dari pencarian acak menjadi proses eliminasi.
Google SRE juga merekomendasikan empat golden signals: latency, traffic, errors, dan saturation untuk memahami kesehatan distributed system.
Berpindah dari Metrics ke Trace yang Bermasalah
Metrics dapat menunjukkan bahwa 2% transaksi menjadi lambat, tetapi tidak memberi tahu request mana yang termasuk 2% tersebut.
Distributed tracing mengisi celah itu.
Bayangkan checkout memiliki alur:
Gateway → Cart → Order → Inventory → Payment
Trace dari request lambat menunjukkan total durasi 2,3 detik. Order hanya membutuhkan 90 ms, Inventory 80 ms, tetapi Payment menghabiskan 1,8 detik.
Sekarang ruang investigasi sudah jauh lebih kecil. OpenTelemetry juga mendukung korelasi metrics dengan traces.
Salah satu mekanismenya adalah exemplar, yaitu pengukuran metric tertentu yang membawa referensi ke trace sehingga engineer dapat berpindah dari titik anomali pada grafik menuju request nyata yang merepresentasikannya.
Cara ini jauh lebih berguna dibanding memasukkan Trace ID sebagai label metric, yang justru dapat menghasilkan cardinality explosion.
Gunakan Logs untuk Menjawab Kenapa Span Gagal
Trace memberitahu bahwa Payment Service membutuhkan 1,8 detik.
Namun kenapa?
Di sinilah logs mengambil peran.
OpenTelemetry memungkinkan log membawa Trace ID dan Span ID. Dengan context tersebut, engineer dapat mengambil hanya log yang berasal dari request atau span tertentu, bahkan ketika transaksi melewati beberapa service berbeda.
Misalnya log pada span Payment menunjukkan:
payment provider timeout after 1500ms
Kemudian log lain memperlihatkan dua retry tambahan.
Sekarang hipotesisnya menjadi lebih spesifik: bukan Payment Service secara umum yang lambat, tetapi external payment provider mengalami timeout dan retry memperpanjang latency.
Korelasi ini mengurangi kebutuhan mencocokkan timestamp secara manual.
Structured logging akan membuat prosesnya semakin mudah. Gunakan field konsisten seperti service.name, trace_id, span_id, error_type, environment, dan service.version.
Pastikan Context Propagation Berjalan Antarservice
Korelasi hanya bekerja jika context tetap dibawa ketika request bergerak.
OpenTelemetry menjelaskan context propagation sebagai mekanisme yang memungkinkan traces, logs, dan metrics dikaitkan walaupun dihasilkan oleh service atau execution unit yang berbeda.
Misalnya Gateway memulai trace dan meneruskan context ke Order Service.
Order kemudian memanggil Inventory dan Payment.
Jika Payment tidak meneruskan trace context, aktivitas downstream-nya bisa muncul sebagai trace terpisah. Tim akhirnya kehilangan bagian penting dari cerita transaksi.
Masalah ini makin mudah terjadi pada asynchronous workflow seperti Kafka atau message queue.
Audit propagation pada HTTP client, RPC library, producer, dan consumer.
Trace yang terlihat “putus” belum tentu berarti downstream service tidak berjalan. Bisa saja instrumentasi atau konfigruasi observability yang tidak lengkap.
Korelasikan Berdasarkan Resource dan Deployment
Trace ID bukan satu-satunya cara menghubungkan telemetry.
OpenTelemetry juga menggunakan resource context agar logs, traces, dan metrics dapat membawa informasi asal yang konsisten, misalnya service, pod, process, atau infrastructure tempat telemetry dibuat.
Tambahkan metadata seperti service.name, service.version, region, dan deployment identifier.
Contohnya error mulai meningkat pukul 10.05.
Setelah difilter berdasarkan versi, ternyata 92% error berasal dari checkout-service v3.8, sementara versi v3.7 masih normal.
Sekarang deployment baru menjadi kandidat kuat.
Korelasi seperti ini sangat berguna pada canary release karena metrics dapat menunjukkan perbedaan performa antarversi, traces membantu menunjukkan jalur yang berubah, dan logs menjelaskan exception yang terjadi.
Tanpa metadata yang konsisten, diagonsis bisa memakan waktu jauh lebih lama.
Bangun Workflow Incident yang Konsisten
Telemetry paling canggih tetap kurang berguna jika setiap engineer mempunyai cara investigasi berbeda.
Buat alur sederhana:
alert → metric → segmentasi → trace → span → log → validasi root cause.
Google SRE menjelaskan monitoring tidak hanya digunakan untuk alerting, tetapi juga untuk diagnosis, visualisasi kondisi sistem, dan memahami tren jangka panjang.
Misalnya alert menunjukkan error budget checkout terbakar cepat.
Engineer membuka metric error berdasarkan region dan menemukan masalah hanya di Asia.
Ia membuka exemplar atau trace lambat dari region tersebut.
Trace menunjukkan Payment API sebagai dependency bermasalah.
Logs kemudian memperlihatkan DNS timeout ke provider tertentu.
Alur seperti ini mudah dilatih, didokumentasikan, dan digunakan kembali.
Setelah incident selesai, evaluasi apakah telemetry yang tersedia cukup untuk menjawab pertanyaan atau masih ada gap observabilty.
Hindari Mengumpulkan Data Tanpa Tujuan
Lebih banyak telemetry tidak selalu menghasilkan observability yang lebih baik.
Menyimpan setiap debug log, setiap span, dan ratusan label metric bisa meningkatkan biaya tanpa mempercepat troubleshooting.
Google SRE menekankan bahwa monitoring sebaiknya tetap sederhana dan berorientasi pada informasi yang berguna untuk alert maupun investigasi.
Gunakan metrics untuk data agregat dan near-real-time.
Gunakan logs untuk detail event.
Gunakan traces untuk memahami causal path request.
Jangan memasukkan user_id atau trace_id sebagai label metric hanya agar semuanya bisa dikorelasikan.
Cardinality yang terlalu tinggi dapat membuat metrics mahal dan sulit digunakan. Untuk hubungan metric ke trace, exemplar biasanya merupakan pilihan yang lebih sesuai.
Observability yang matang bukan tentang menyimpan semua data, tetapi mempertahankan data yang membantu membuat keputusan.
Menggabungkan Metrics, Logs, dan Traces membuat analisis insiden jauh lebih terarah. Gunakan metrics untuk mendeteksi pola, traces untuk menemukan jalur dan dependency bermasalah, lalu logs untuk memahami detail penyebabnya.
Pastikan context dan metadata konsisten agar perpindahan antartelemetry tetap mulus. Audit satu incident terbaru dan lihat apakah tim Anda dapat bergerak dari alert sampai root cause tanpa tebakan.