Cloudflare Traces Masuk Open Beta: Satu Request, Satu Timeline Lintas Platform

Cloudflare mengumumkan Cloudflare Traces dalam status open beta pada 2 Oktober 2026. Fitur ini memperluas tracing otomatis yang sebelumnya hanya menjangkau Worker menjadi seluruh jalur permintaan yang melewati platform mereka. Artinya, dalam satu trace, kamu bisa melihat aturan keamanan yang dievaluasi, transformasi URL, keputusan cache, routing, eksekusi Worker, sampai penanganan di origin. Semua langkah itu terekam dalam satu timeline request-level tanpa perlu memasang instrumentation tambahan.

Bagi tim yang selama ini menambal debugging dari beberapa sumber log terpisah, perubahan ini cukup berarti. Sebelumnya, menjawab pertanyaan sederhana seperti kenapa sebuah request diblokir atau kenapa responsnya lambat sering berujung pada mengorek log Cloudflare, log origin, dan konfigurasi satu per satu. Cloudflare Traces menyatukan potongan-potongan itu ke dalam satu tempat, lengkap dengan waktu dan hasil tiap tahap.

Apa yang Sebenarnya Direkam

Setiap langkah yang didukung dicatat sebagai span. Span memuat timing, hasil, dan atribut yang relevan dengan operasi tersebut. Beberapa span yang paling berguna dalam praktik harian antara lain:

• Span aturan keamanan, yang menunjukkan kapan custom rule atau managed rule dievaluasi, berapa lama evaluasinya, dan aksi apa yang dihasilkan. Kalau sebuah request diblokir atau ditantang, kamu bisa menemukan aturan mana yang bertanggung jawab lewat event pada span tersebut.
• Span transformasi URL, yang memperlihatkan setiap perubahan yang dilakukan Transform Rule sebelum request mencapai aplikasi. Kamu bisa melihat komponen request mana yang diubah dan aturan mana yang melakukannya, termasuk posisinya relatif terhadap routing dan origin.
• Span routing Worker, yang menunjukkan apakah sebuah route cocok, jenis routing apa yang dipakai, dan pola route yang cocok.
• Span cache, upstream, dan origin, yang bisa dibuka berlapis untuk melihat di mana request menghabiskan waktu.

Cloudflare memberi contoh konkret dalam pengumumannya: sebuah cache miss yang diteruskan ke origin menghabiskan 527 milidetik dari total 539 milidetik untuk mendapatkan respons. Angka semacam ini biasanya baru terlihat setelah menggabungkan data dari beberapa alat. Dengan satu trace, hubungan antara konfigurasi dan waktu proses jadi lebih mudah ditelusuri.

Kontrol Sampling dan Trace Rules

Tracing penuh pada setiap request tidak selalu masuk akal secara biaya, terutama pada trafik besar. Karena itu Cloudflare menyediakan dua lapis kontrol. Pertama, kamu menetapkan baseline sampling rate, yaitu persentase dasar request yang akan direkam. Kedua, kamu bisa memakai Trace Rules untuk menimpa baseline itu pada trafik yang cocok dengan kondisi tertentu.

Pola yang lazim adalah menetapkan sampling rendah sebagai default, lalu menaikkannya khusus untuk endpoint yang sedang bermasalah, misalnya halaman checkout atau API yang sering timeout. Dengan begitu kamu bisa mengumpulkan detail lebih banyak justru di tempat yang butuh, tanpa membakar kuota ingestion untuk trafik yang tidak menarik.

Propagasi Konteks dan Ekspor OpenTelemetry

Salah satu keputusan desain yang penting: Cloudflare Traces menerima dan meneruskan header W3C traceparent. Ini berarti trace bisa dimulai di Cloudflare, dilanjutkan ke layanan yang berjalan di origin, dan tetap tersambung sebagai satu jejak. Tim yang sudah memakai OpenTelemetry tidak perlu membangun format baru, karena span bisa diekspor ke endpoint OTLP mana pun yang kompatibel.

Investasi jangka panjangnya jelas: Cloudflare ingin menjadikan lapisan mereka sebagai bagian yang paling teramati dari stack kamu. Selama ini, tim internal Cloudflare memakai trace mereka sendiri untuk menelusuri request yang bisa melibatkan ribuan span dari puluhan layanan. Fitur ini pada dasarnya membuka tingkat visibilitas yang sama untuk pelanggan.

Praktiknya di Dashboard dan untuk Agen

Traces bisa dilihat langsung dari dashboard Cloudflare, dengan tampilan timeline request dan detail span. Untuk yang lebih suka otomatisasi, Cloudflare menyediakan SQL API sehingga agen bisa meng-query data observability, membandingkan trace yang gagal dengan yang berhasil, lalu mencari titik di mana span-nya mulai berbeda. Karena agen juga bisa memeriksa repositori, temuan itu bisa dihubungkan ke kode yang relevan dan dijadikan usulan perbaikan.

Fitur ini tersedia lewat dashboard, API, maupun Terraform. Tidak ada plugin atau konfigurasi khusus yang diperlukan. Begitu tracing diaktifkan untuk sebuah domain, Cloudflare menghasilkan span-span tersebut secara otomatis.

Harga dan Kapan Berlaku

Cloudflare Traces akan menjadi bagian dari model harga Observability terpadu. Yang menarik, penagihannya bukan berdasarkan jumlah span atau event, melainkan berdasarkan berapa banyak data observability yang di-ingest dan berapa lama data itu disimpan. Harga baru ini berlaku untuk Cloudflare Tracing sekaligus Workers Tracing mulai 1 Desember 2026.

Paket	Ingestion	Retensi	Biaya tambahan
Free	0,5 GB per hari	7 hari	Tidak tersedia
Paid dan Enterprise	50 GB per siklus penagihan	10 GB-bulan penyimpanan	0,25 dolar per GB di-ingest; 0,10 dolar per GB-bulan disimpan

Retensi hingga satu tahun masih berstatus "coming soon" untuk paket berbayar dan Enterprise. Perlu dicatat bahwa angka-angka ini bisa berubah selama periode beta dan menjelang tanggal penerapan harga.

Yang Masih Menyusul

Setelah open beta, Cloudflare merencanakan beberapa pengembangan. Mereka akan menambah span di jalur HTTP request, misalnya untuk aturan DDoS dan Access, serta di jalur eksekusi Worker, misalnya untuk Workflows, Queues, dan Pipelines. Ada juga rencana authenticated context propagation, yaitu membiarkan pemanggil yang tepercaya melanjutkan trace yang sudah ada tanpa harus menerima konteks dari setiap request yang masuk. Selain itu, ada ad hoc tracing untuk menangkap satu request tertentu tanpa mengubah baseline sampling, dukungan OpenTelemetry API di Worker, dan retensi lebih panjang hingga 365 hari.

Kenapa Ini Penting untuk Tim Kecil

Bagi tim kecil yang tidak punya anggaran untuk membangun tumpukan observability sendiri, menyatukan tracing di satu penyedia bisa memotong cukup banyak kerja manual. Pertanyaan yang dulu butuh tiga alat dan dua orang kini bisa dijawab dari satu timeline. Untuk arsitektur yang menempatkan Cloudflare di depan origin, ini mengurangi salah satu titik gelap terbesar dalam proses debugging: bagian antara "request masuk" dan "request sampai ke aplikasi".

Yang perlu diantisipasi justru soal biaya dan volume. Karena penagihan berbasis data yang di-ingest dan disimpan, tim perlu menyusun strategi sampling sejak awal. Menyalakan tracing dengan sampling tinggi untuk semua trafik bisa membuat tagihan membengkak tanpa manfaat sepadan. Pendekatan yang lebih aman adalah memulai dari baseline rendah, mengidentifikasi endpoint kritis, lalu menaikkan sampling secara selektif lewat Trace Rules.

Untuk pengguna Indonesia, tracing semacam ini relevan karena banyak layanan lokal memakai Cloudflare di depan origin yang tersebar di beberapa penyedia. Ketika latensi naik, pertanyaan pertama biasanya "masalahnya di edge, di jaringan, atau di aplikasi". Trace yang mencakup jalur lengkap mempersempit ruang pencarian itu jauh lebih cepat daripada menebak dari log yang terpisah-pisah.

Hubungannya dengan Log dan Analytics yang Sudah Ada

Perlu dipahami bahwa tracing bukan pengganti log. Keduanya menjawab pertanyaan yang berbeda. Log memberi tahu kamu apa yang terjadi pada satu peristiwa, misalnya pesan error dari aplikasi atau status respons dari origin. Trace memberi tahu kamu bagaimana sebuah permintaan bergerak dari satu komponen ke komponen lain, berapa lama di masing-masing tahap, dan di mana ia keluar dari jalur yang diharapkan.

Dalam praktiknya, keduanya saling melengkapi. Trace memberi petunjuk kasar tentang di mana masalah berada, lalu log memberi detail pada titik itu. Kalau kamu sudah memakai Logpush atau analitik trafik, trace menambahkan dimensi waktu dan urutan yang sering hilang di kedua alat tersebut. Sementara itu, atribut pada span membuat kamu bisa memfilter berdasarkan kolom, POP, status, atau pola route tertentu tanpa harus menebak dari sekumpulan baris log.

Kombinasi yang paling efisien biasanya begini: aktifkan tracing dengan sampling rendah sebagai jaring pengaman, lalu ketika ada insiden, naikkan sampling khusus untuk endpoint yang bermasalah lewat Trace Rules. Setelah insiden selesai, turunkan lagi. Dengan begitu kamu tidak menyimpan data berlebihan, tetapi tetap punya cukup jejak saat dibutuhkan.

Langkah Mengaktifkan

Karena tracing tidak memerlukan instrumentation tambahan, langkah awalnya relatif singkat. Urutan yang aman untuk dicoba di staging lebih dulu:

1. Pilih satu domain, idealnya domain non-produksi atau domain dengan trafik rendah, agar kamu bisa menilai volume data tanpa risiko tagihan.
2. Aktifkan tracing dari dashboard Cloudflare. Kamu juga bisa melakukannya lewat API atau Terraform bila ingin dimasukkan ke alur infrastruktur sebagai kode.
3. Tetapkan baseline sampling rate. Mulailah dari angka kecil, lalu amati berapa banyak span yang dihasilkan per hari.
4. Tambahkan satu atau dua Trace Rules untuk endpoint yang paling sering bermasalah, dan naikkan sampling di sana.
5. Kalau memakai OpenTelemetry, siapkan endpoint OTLP tujuan dan verifikasi bahwa span dari Cloudflare benar-benar sampai, lengkap dengan konteks trace yang tersambung ke layanan origin.
6. Bandingkan volume ingestion dengan kuota paket kamu, dan sesuaikan sampling sebelum trafik naik.

Setelah tracing menyala, luangkan waktu untuk membaca beberapa trace nyata dari endpoint yang kamu kenal baik. Cara tercepat memahami alat baru adalah melihatnya bekerja pada sesuatu yang sudah kamu pahami, bukan pada insiden yang sedang panas.

Jebakan Umum

Ada beberapa kesalahan yang mudah terjadi saat baru memakai tracing berbasis sampling. Pertama, menyalakan sampling tinggi di semua trafik sejak hari pertama. Ini cepat menguras kuota ingestion dan membuat tagihan tidak terduga, sementara sebagian besar trace yang tersimpan tidak pernah dibuka. Kedua, lupa menetapkan retensi sesuai kebutuhan investigasi. Retensi tujuh hari di paket gratis cukup untuk insiden jangka pendek, tetapi tidak untuk analisis tren bulanan.

Ketiga, menganggap trace sudah otomatis menutup semua pertanyaan. Span yang didukung memang banyak, tetapi cakupannya bertahap. Beberapa bagian jalur, misalnya aturan DDoS dan Access atau fitur Worker tertentu seperti Workflows dan Queues, baru akan ditambahkan setelah open beta. Jadi, kalau ada bagian yang belum muncul, kemungkinan besar itu belum diinstrumentasi, bukan berarti tidak ada masalah di sana.

Keempat, mencampur data trace dengan data pribadi secara sembarangan. Karena span bisa memuat atribut request, tim perlu memastikan tidak ada informasi sensitif yang ikut terekspor ke tujuan pihak ketiga. Ini terutama penting kalau endpoint menerima data pengguna yang harus dilindungi.

Membaca Timeline dengan Efektif

Kunci membaca timeline adalah mencari selisih waktu yang tidak proporsional, bukan melihat total durasi saja. Sebuah request yang selesai dalam 539 milidetik terdengar wajar sampai kamu melihat bahwa 527 milidetiknya dihabiskan di satu tahap. Dari situ pertanyaan menjadi lebih tajam: apakah tahap itu cache, koneksi ke origin, atau aplikasi itu sendiri.

Pola lain yang sering muncul adalah span yang saling bertumpuk atau bersarang. Span cache yang di dalamnya ada span upstream, yang di dalamnya lagi ada span origin, menceritakan bahwa request benar-benar melakukan perjalanan penuh. Sebaliknya, span yang berakhir cepat tanpa menurunkan latensi total biasanya menandakan waktu habis di tempat lain, misalnya antrean di runtime atau jaringan antara POP dan origin.

Dengan membiasakan diri membaca selisih antar-span, kamu bisa memindahkan perdebatan dari "sepertinya lambat" menjadi "tahap ini yang paling mahal". Itu pergeseran yang membuat diskusi teknis jauh lebih produktif.

Ringkasnya, Cloudflare Traces menutup jarak antara visibilitas internal yang mereka pakai sendiri dan visibilitas yang tersedia untuk pelanggan. Kalau kamu sudah memakai Worker Tracing, langkah berikutnya adalah mengaktifkan tracing pada domain, menyetel sampling, dan menyambungkan ekspor ke OTLP tujuan. Selama masih open beta, ini saat yang tepat untuk mencoba dan memberi umpan balik sebelum harga baru berlaku.