Request yang lambat sering membawa beberapa tim ke dashboard berbeda: security mencari rule, network memeriksa koneksi, dan aplikasi melihat APM. Cloudflare memperkenalkan Traces dalam open beta pada 2 Oktober 2026 untuk menghubungkan bagian jalur tersebut. Nilainya bagi engineer ada pada kualitas bukti saat triage, bukan janji bahwa satu dashboard akan menemukan semua penyebab. Berikut analisis Cloud Network Lab tentang perubahan ini dan cara menilai kegunaannya tanpa menganggap telemetry sebagai jawaban otomatis.
Menurut pengumuman resmi, Cloudflare Traces merekam operasi yang didukung pada security rules, transformations, cache, routing, Workers, dan penanganan origin. Trace dapat diekspor melalui OTLP. Statusnya open beta; perluasan instrumentation masih menjadi roadmap, sehingga jangan mengasumsikan setiap produk sudah menghasilkan span. Ketersediaan fitur ini juga tidak membuktikan bahwa semua domain organisasi sudah mengaktifkannya.
Dokumentasi membedakan Cloudflare Traces yang merekam traffic nyata dengan Cloudflare Trace yang mensimulasikan pemrosesan konfigurasi. Dashboard Traces dapat mencari request berdasarkan Ray ID dan menampilkan hierarki span beserta atribut, outcome, dan durasi. Dalam investigasi, pilih alat berdasarkan pertanyaan: simulasi berguna untuk memahami konfigurasi; rekaman request berguna untuk menjelaskan kejadian yang benar-benar diamati.
Contoh hipotetis: pengguna melaporkan halaman checkout lambat, tetapi endpoint lain normal. Mulai dari satu request gagal dan pembanding sukses pada waktu berdekatan. Bandingkan jalur yang dilalui, perubahan URL, penggunaan cache, dan bagian yang menunggu respons. Jika keduanya melewati policy sama tetapi waktu menunggu origin berbeda, pemeriksaan berikutnya layak diarahkan ke origin. Itu hipotesis kerja, bukan bukti bahwa database menjadi penyebab. APM dan log aplikasi masih diperlukan untuk menjelaskan pekerjaan di dalam aplikasi.
Configuration docs menyediakan baseline sampling dan Trace Rules; rule pertama yang cocok menentukan override. Persistensi dan ekspor bisa dipilih terpisah. Rekomendasi editorial kami: mulai dari scope kecil yang mewakili workload, ukur volume, lalu buat pengecualian sementara untuk reproduksi masalah. Catat waktu berakhirnya investigasi dan pemilik rule. Jangan membaca ketiadaan trace sebagai ketiadaan error: request bisa tidak tersampel, filter bisa salah, atau waktu pencarian bisa berbeda.
Dokumentasi menjelaskan bahwa Forward to origin meneruskan trace context, tetapi tidak otomatis menginstrumentasi aplikasi. Agar span platform dan aplikasi terlihat tersambung pada backend eksternal, kirim keduanya ke destination OpenTelemetry yang sama. Secara operasional, verifikasi dengan request lab milik sendiri: cari identifier yang sama di kedua sisi, cocokkan timestamp, lalu pastikan ada span aplikasi yang diharapkan. Request yang hanya punya span koneksi origin belum menjelaskan query database atau panggilan layanan internal.
Incoming context secara default ditolak; Cloudflare memperingatkan bahwa context yang diterima dari pemanggil tidak diverifikasi sebagai tepercaya. Implikasi engineering-nya: trace ID cocok untuk korelasi, bukan izin akses atau bukti siapa yang melakukan transaksi. Hindari keputusan authorization berdasarkan header tracing. Saat menyimpan atribut, batasi informasi sensitif dan tentukan siapa yang boleh mencari serta mengekspornya. Pengumpulan yang lebih detail harus tetap punya tujuan investigasi dan kebijakan retention.
Rancang percobaan dengan kasus yang sudah diketahui: request normal, rewrite yang disengaja pada lab, cache miss, dan respons aplikasi yang lambat secara terkontrol. Ukur apakah engineer bisa menemukan bagian jalur yang relevan dan menghubungkannya dengan bukti aplikasi. Catat waktu triage, coverage request, volume data, serta kasus yang belum bisa dijelaskan. Ini rancangan evaluasi, bukan hasil benchmark Cloud Network Lab. Jangan mengklaim MTTR turun sebelum ada pembanding yang konsisten.
Pengumuman menyebut pricing observability baru mulai 1 Desember 2026. Review dokumentasi saat rollout sebelum membuat proyeksi biaya. Dari sisi desain, naikkan sampling bertahap dan pantau dampak volume serta akses data. Jika beta belum memenuhi kebutuhan audit, pertahankan jalur log dan monitoring yang sudah digunakan. Tracing melengkapi bukti operasional; ia tidak menggantikan alert, log akses, atau prosedur incident response.
Pilih satu hostname nonkritis dan satu pertanyaan investigasi yang selama ini sulit dijawab. Tetapkan owner, baseline, scope data, dan kriteria selesai sebelum mengaktifkan tracing. Dokumentasikan bagian platform yang terlihat dan bagian aplikasi yang belum terinstrumentasi. Takeaway-nya: gunakan update ini untuk mempersempit lokasi masalah dengan bukti request nyata, lalu lanjutkan diagnosis pada lapisan yang relevan. Jangan mengubah WAF atau origin hanya karena satu span tampak lama.
