Jejak terdistribusi menghasilkan volume data rentang yang besar. Tanpa pengambilan sampel, biaya penyimpanan dan komputasi meningkat seiring lalu lintas, sementara sebagian besar jejak merepresentasikan permintaan normal dan sehat. Application Real-Time Monitoring Service (ARMS) menyediakan lima kebijakan pengambilan sampel yang memungkinkan Anda menyimpan jejak penting—seperti error, permintaan lambat, atau antarmuka berlalu lintas rendah—dan membuang sisanya. Hal ini mengurangi biaya sekaligus mempertahankan cakupan observabilitas yang diperlukan untuk troubleshooting dan analisis kinerja.
Semua perubahan konfigurasi pengambilan sampel berlaku secara langsung tanpa perlu restart aplikasi.
Istilah
| Istilah | Definisi |
|---|---|
| Span | Operasi tunggal dalam suatu permintaan, seperti panggilan RPC atau pemanggilan metode internal. |
| Root span | Rentang pertama dalam suatu jejak. Root span tidak memiliki induk. |
| Local root span | Rentang pertama dari suatu jejak dalam satu layanan. Setiap layanan dalam jejak terdistribusi memiliki local root span-nya sendiri. |
| Span context | Metadata yang terkait dengan suatu rentang, yang dipropagasi melintasi batas proses. |
| Head-based sampling | Keputusan pengambilan sampel yang dibuat pada root span sebelum jejak mulai dipropagasi. Head-based sampling menjamin kelengkapan jejak: semua rentang diambil sampelnya, atau tidak sama sekali. |
| Non-head based sampling | Pengambilan sampel yang berlaku ketika head-based sampling tidak dipicu. Non-head based sampling dapat dipicu pada setiap local root span, sehingga kelengkapan jejak tidak dijamin. |
Pilih kebijakan pengambilan sampel
ARMS menyediakan dua kebijakan head-based dan tiga kebijakan non-head based. Kebijakan head-based membuat keputusan pada root span dan menjamin jejak lengkap end-to-end. Kebijakan non-head based membuat keputusan di masing-masing layanan dan menangkap jejak yang mungkin terlewat oleh head-based sampling.
| Tujuan | Kebijakan yang direkomendasikan | Kategori |
|---|---|---|
| Ambil sampel persentase tetap dari semua jejak | Fixed-rate sampling | Head-based |
| Menyeimbangkan cakupan di seluruh antarmuka terlepas dari volume traffic | Adaptive sampling | Head-based |
| Menjamin setidaknya satu jejak per antarmuka per menit | Minimum sampling for all interfaces | Non-head based |
| Secara otomatis menangkap jejak error dan permintaan lambat | Sampling for failed or slow requests | Non-head based |
| Selalu ambil sampel antarmuka tertentu berdasarkan nama | Custom sampling | Non-head based |
Beberapa kebijakan dapat aktif secara bersamaan. ARMS mengevaluasinya dalam urutan tertentu. Lihat Bagan alir keputusan pengambilan sampel.
Kebijakan head-based sampling
Head-based sampling membuat keputusan tunggal pada root span suatu jejak. Jika jejak tersebut diambil sampelnya, semua rentang downstream mewarisi keputusan tersebut melalui span context, sehingga menjamin jejak lengkap end-to-end.
Fixed-rate sampling
Fixed-rate sampling memilih jejak berdasarkan persentase yang dikonfigurasi pada layanan ingress. Misalnya, laju pengambilan sampel 10% berarti sekitar 1 dari 10 jejak diambil sampelnya.
Rentang yang diambil sampelnya membawa atribut sample.reason: s4.
Konfigurasikan fixed-rate sampling
Masuk ke Konsol ARMS. Di panel navigasi kiri, pilih .
Pilih wilayah di bilah navigasi atas dan klik aplikasi tersebut.
Catatan Ikon di kolom Language menunjukkan bahasa pemrograman: -
: Java - 
: Go - 
: Python - - (Hyphen): aplikasi yang dipantau di Managed Service for OpenTelemetryDi bilah navigasi atas, pilih .
Pada bagian Sampling Settings, atur Sampling strategy ke Fixed sampling rate. Pada bidang Sample Rate Percentage, masukkan nilai. Misalnya, masukkan
10untuk laju pengambilan sampel 10%.CatatanNilai default adalah 10. Laju pengambilan sampel yang lebih tinggi mengonsumsi lebih banyak sumber daya sistem. Pertahankan nilai default kecuali workload Anda memerlukan cakupan jejak yang lebih luas.
Klik Save.
Adaptive sampling
Antarmuka berlalu lintas tinggi sering mendominasi hasil fixed-rate sampling, sedangkan antarmuka berlalu lintas rendah namun kritis menjadi kurang terwakili. Adaptive sampling mengatasi hal ini dengan mengalokasikan jumlah jejak tetap per antarmuka, terlepas dari volume permintaan.
Cara kerja: ARMS mengidentifikasi 1.000 antarmuka dengan volume permintaan tertinggi dan mengambil sampel 10 jejak per antarmuka per menit menggunakan algoritma Least Frequently Used (LFU). Semua antarmuka lainnya berbagi kuota gabungan sebesar 10 jejak per menit.
Contoh: Misalkan layanan Anda memiliki antarmuka /api/orders/list yang menangani 50.000 permintaan per menit dan antarmuka lain /api/orders/refund yang hanya menangani 100 permintaan per menit. Dengan adaptive sampling, keduanya mendapatkan 10 jejak yang diambil sampelnya per menit. Anda tetap memiliki visibilitas terhadap alur refund berlalu lintas rendah tanpa kewalahan oleh alur list berlalu lintas tinggi.
Rentang yang diambil sampelnya membawa atribut sample.reason: s6.
Konfigurasikan adaptive sampling
Masuk ke Konsol ARMS. Di panel navigasi kiri, pilih .
Pilih wilayah di bilah navigasi atas dan klik aplikasi tersebut.
Catatan Ikon di kolom Language menunjukkan bahasa pemrograman: -: Java - : Go - : Python - - (Hyphen): aplikasi yang dipantau di Managed Service for OpenTelemetryDi bilah navigasi atas, pilih .
Pada bagian Sampling Settings, atur Sampling strategy ke Adaptive Sampling.
Klik Save.
Kebijakan pengambilan sampel non-head-based
Non-head based sampling dipicu secara independen di setiap layanan ketika head-based sampling belum memilih jejak tersebut. Karena keputusan dibuat di tengah jejak dan bukan di root, jejak lengkap end-to-end tidak dijamin. Namun, kebijakan ini menangkap jejak yang mungkin terlewat oleh head-based sampling, seperti error, permintaan lambat, dan antarmuka yang jarang dipanggil.
Minimum sampling for all interfaces
ARMS secara otomatis mengambil sampel setidaknya satu jejak per antarmuka per menit. Hal ini menjamin visibilitas dasar ke setiap antarmuka, termasuk yang berlalu lintas sangat rendah yang mungkin sepenuhnya dilewati oleh fixed-rate atau adaptive sampling.
Rentang yang diambil sampelnya membawa atribut sample.reason: s2.
Sampling for failed or slow requests
Kebijakan ini secara otomatis menangkap jejak untuk permintaan gagal atau lambat, sehingga Anda selalu memiliki data jejak untuk panggilan yang perlu diselidiki.
Sebelum menggunakan kebijakan ini, pastikan sakelar Call chain compression telah diaktifkan. Buka halaman detail aplikasi, pilih dari bilah navigasi atas, lalu periksa bagian Advanced Settings. Sakelar ini aktif secara default.
Suatu jejak diambil sampelnya jika salah satu kondisi berikut terpenuhi:
Permintaan gagal: Antarmuka HTTP mengembalikan kode status selain 200, atau antarmuka non-HTTP melemparkan exception dari metode yang diinstrumentasi.
Exception internal yang tidak tertangani: Exception terjadi selama eksekusi internal tetapi tidak dipropagasi ke layanan ingress framework.
Permintaan lambat: Durasi panggilan melebihi ambang batas panggilan lambat yang dikonfigurasi di halaman Custom Configurations.
Jika persentil diaktifkan, panggilan dengan durasi di atas persentil ke-99 dari antarmuka tersebut juga sesuai dengan aturan pengambilan sampel panggilan lambat.
Nilai atribut sample.reason bergantung pada kondisi pemicunya:
| Kondisi | sample.reason nilai |
|---|---|
| Permintaan gagal | s9 |
| Panggilan abnormal (exception tidak tertangani) | s11 |
| Permintaan lambat | s10 |
Custom sampling
Custom sampling memungkinkan Anda menentukan antarmuka berdasarkan nama persis, awalan, atau akhiran, dan mengambil sampel semua jejaknya. Gunakan ini untuk antarmuka yang memerlukan cakupan jejak lengkap—misalnya, antarmuka pemrosesan pembayaran atau layanan yang baru saja dideploy.
Rentang yang diambil sampelnya membawa atribut sample.reason: s3.
Konfigurasikan custom sampling
Masuk ke Konsol ARMS. Di panel navigasi kiri, pilih .
Pilih wilayah di bilah navigasi atas dan klik aplikasi tersebut.
Catatan Ikon di kolom Language menunjukkan bahasa pemrograman: -: Java - : Go - : Python - - (Hyphen): aplikasi yang dipantau di Managed Service for OpenTelemetryDi bilah navigasi atas, pilih .
Pada bagian Sampling Settings, tentukan nama antarmuka, awalan, atau akhiran.
Klik Save.
Penanda pengambilan sampel
Ketika konteks jejak dilewatkan antar layanan menggunakan protokol EagleEye, ARMS menggunakan penanda pengambilan sampel untuk mengomunikasikan keputusan pengambilan sampel. Header permintaan EagleEye-Sampled membawa salah satu dari dua nilai berikut:
| Nilai | Makna |
|---|---|
s0 | Tidak diambil sampelnya |
s1 | Diambil sampelnya |
ARMS juga mencatat alasan suatu jejak diambil sampelnya dalam atribut rentang sample.reason. Gunakan atribut ini untuk memfilter dan menganalisis jejak di Trace Explorer. Misalnya, filter berdasarkan s10 untuk menemukan semua jejak yang diambil sampelnya karena permintaan lambat.
sample.reason value | Kebijakan Pengambilan sampel |
|---|---|
s2 | Pengambilan sampel minimum untuk semua antarmuka |
s3 | Pengambilan sampel kustom |
s4 | Pengambilan sampel laju tetap |
s5 | Direservasi |
s6 | Pengambilan sampel adaptif |
s7 | Direservasi |
s8 | Pengambilan sampel Edisi Dasar |
s9 | Pengambilan sampel permintaan gagal |
s10 | Pengambilan sampel permintaan lambat |
s11 | Pengambilan sampel panggilan abnormal |
Bagan alir keputusan pengambilan sampel
Diagram berikut menggambarkan cara ARMS mengevaluasi kebijakan pengambilan sampel untuk jejak yang mencakup layanan A, B, dan C.
Bagan alir ini menggunakan tiga jalur berkode warna:
Ungu (head-based sampling): Dievaluasi hanya pada root span jejak. Keputusan pengambilan sampel tunggal dibuat di layanan A dan dipropagasi ke semua layanan downstream.
Biru (custom sampling dan minimum sampling): Dievaluasi di setiap layanan jika head-based sampling tidak dipicu. Ketika layanan B mengambil sampel jejak melalui custom atau minimum sampling, atribut pengambilan sampelnya diteruskan ke layanan C. Setiap layanan (A, B, C) membuat keputusannya sendiri.
Hijau (failed or slow request sampling): Dievaluasi di setiap layanan jika kebijakan sebelumnya tidak memicu pengambilan sampel. Ketika layanan B mengambil sampel jejak karena kegagalan atau respons lambat, atribut pengambilan sampelnya tidak diteruskan ke layanan C. Setiap layanan membuat keputusan secara independen.
Lihat juga
Analisis data jejak di Trace Explorer: Filter berdasarkan
sample.reasondan atribut lainnya untuk menyelidiki jejak tertentu.Protokol tracing yang didukung: Detail mengenai protokol EagleEye dan format propagasi lain yang didukung.