Bagaimana Pengembang Menggunakan Penelusuran di UI Untuk Menambahkan Backend Observability – Beragampengetahuan

Jika Anda pernah terjebak dengan aplikasi yang lambat, Anda mungkin bertanya -tanya: Di mana saya akan mulai mencari backend atau frontend?

Bagi sebagian besar tim, begitu mereka mencapai bagian belakang, pengamatan sudah berakhir. Kami telah mendistribusikan jejak, log, dan metrik yang memberikan tampilan yang jelas dari semua layanan microservices. Tapi ujung depan? Ini sering dianggap sebagai kotak hitam.

Kami tahu kapan harus masuk ke server dan mengalir melalui layanan kami, tetapi kami tidak tahu apa yang akan terjadi sebelum ini – durasi pengaturan yang diselesaikan UI, apakah pengguna melihat permintaan kembali dengan lancar, dll.

Itu sebabnya pelacakan front-end sangat penting. Dengan menggunakan sesuatu seperti OpenTelemetry (OTEL) untuk interaksi pengguna di browser, pengembang dapat menghubungkan rentang dari ujung depan dan menghubungkan ujung belakang ke satu jejak.

keuntungan? Visibilitas tumpukan penuh dan debugging yang lebih cepat.

Mengapa front-end perlu dilacak

Sistem front-end memiliki perbedaannya sendiri, yang mungkin tidak terlihat pada log back-end:

• Penundaan Interaksi Pengguna – Ketika pengguna mengklik tombol, rasanya “lambat”. Apakah ada terlalu banyak reaksi untuk dirender ulang? Apakah bundel JS terlalu berat? Apakah API lambat? Tanpa pelacakan, kami tidak tahu.
• Kompleksitas asinkron – Aplikasi satu halaman dapat memiliki banyak permintaan dan secara bersamaan memberikan tugas dan transisi negara. Tidak ada pelacakan, yang mirip dengan mencoba mengungkap pasta.
• Perbedaan lokal – Log backend tidak tahu apakah pengguna berada pada koneksi 3G pelambatan, berapa banyak CPU yang digunakan, atau jika ada perilaku modis di browser pengguna.

Penelusuran front-end menyatukan semua ini dan memungkinkan kita untuk:

• Hubungkan tindakan pengguna (klik, navigasi, atau acara input) ke permintaan jaringan yang dipicu.
• Ikuti permintaan melalui layanan backend.
• Ukur dan bandingkan latensi yang dirasakan (apa yang dipikirkan pengguna) dengan latensi sistem (apa yang digunakan backend).

Setelah kami menyatukan semua ini, menemukan bottleneck adalah masalah visibilitas. Kita dapat dengan jelas melihat bahwa debugging bukan lagi permainan menebak.

Komentar Cepat: Melacak cara kerja

Sebelum memasuki ujung depan, mari kita tinjau beberapa dasar.

• jejak: Trace adalah seluruh jalur eksekusi, seperti “Checkout Klik Pengguna”.
• menjangkau: Rentang adalah pekerjaan yang lebih kecil, dilakukan dalam jejak ini (rendering UI, panggilan API, permintaan DB).

Setiap trek memiliki ID unik yang disebarkan pada batas -batas dalam sistem (melalui header seperti Traceparent).

Contoh bor

• Pengguna Klik “Beli Sekarang” di aplikasi React Anda → peluncuran rentang front-end.
• Klik Get/Checkout → Otel secara otomatis membuat rentang jaringan.
• Ini akan mengirim permintaan menggunakan judul yang berisi ID pelacakan.
• Backend akan melanjutkan jejak dan kemudian membuat rentang untuk pemrosesan pesanan, tulis DB, dll.
• Alat pengamatan seperti Jaeger, Tempo atau Datadog akan menunjukkan kepada Anda seluruh perjalanan jejak dari ujung ke ujung.

Tiba -tiba, ujung depan bukan lagi kotak hitam, itu adalah bagian dari narasi sistem terdistribusi.

Mengatur OpenTelemetry di browser Anda

Menyiapkan Otel di ujung depan sangat mudah.

Langkah 1: Pasang dependensi

npm install @opentelemetry/sdk-trace-web @opentelemetry/instrumentation-fetch @opentelemetry/exporter-trace-otlp-http

Langkah 2: Boot di aplikasi Anda

typescript
import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { FetchInstrumentation } from '@opentelemetry/instrumentation-fetch';
const provider = new WebTracerProvider();
const exporter = new OTLPTraceExporter({
  url: '
});
provider.addSpanProcessor(new BatchSpanProcessor(exporter));
provider.register();
registerInstrumentations({
  instrumentations: [new FetchInstrumentation()],
});
console.log('OpenTelemetry bootstrapped');

Ini berarti:

• Setiap panggilan GET atau XHR dilacak.
• Kirim rentang ke pengumpul pelacakan Anda (OTLP, Jaeger, DataDog, dll …).

Sebagai pengembang yang mengembangkan logika aplikasi tanpa mengelola konteks, konteksnya hilir.

Acara Pengguna Log

Sangat menyenangkan memiliki permintaan jaringan, tetapi pelacakan menjadi lebih berharga ketika Anda dapat menangkap acara pengguna. Maka Anda dapat bergaul:

typescript
import { trace } from '@opentelemetry/api';

const tracer = trace.getTracer('ui-tracer');

document.getElementById('checkout-btn')?.addEventListener('click', () => {
  const span = tracer.startSpan('user.click.checkout');
  
  setTimeout(() => {
    span.end();
  }, 200);
});

“Klik pengguna untuk checkout”

• → Panggilan API yang dipicu
• → Layanan pesanan backend
• → Kueri Basis Data

Anda cukup memasukkan seluruh konten ke dalam kait atau komponen canggih di React untuk memastikan bahwa pelacakan Anda tetap konsisten di seluruh aplikasi.

Hubungkan bagian depan dan backends

Di sinilah sihir terjadi secara terprogram saat melintasi batas.

• Otel akan secara otomatis menyuntikkan header traceparent.
• Ketika layanan backend menerima permintaan, mereka akan menerima dan terus melacak.
• Pemirsa pelacakan Anda akan menjahit semua ini bersama -sama untuk membuat jadwal yang terpadu.

Contoh jejak di Jaeger terlihat seperti ini:

`pqsql
user.click.checkout (Frontend, 50ms)
 └── fetch /checkout (Frontend, 20ms)
       └── OrderService.processOrder (Backend, 120ms)
            └── Database query (DB, 80ms)

Dengan tampilan ini, jelas di mana perlambatan dalam permintaan, apakah itu di klien, di API, atau dalam database.

Debugging dan pemantauan dunia nyata

Debugging Sulit Menyalin Kesalahan

Setelah ada pengguna yang mengatakan “checkout lambat” dan Anda tidak dapat menyalinnya? Dengan melacak, Anda dapat mengetahui apakah masalahnya adalah:

• Waktu yang lebih lambat parsing bundel javascript
• Panggilan API lambat
• atau sesuatu dengan DB backend

Pemantauan Kinerja

Jejak Tunjukkan Kami:

• Rendering waktu dan waktu pemrosesan backend
• Tugas jangka panjang mencegah interaksi
• Koneksi antara pengukuran front-end (waktu interaktif) dan latensi API back-end

Wawasan Keandalan

Seiring waktu, jejak dengan sampel dapat menunjukkan kepada Anda:

• Api serpihan yang gagal hanya di bawah jalur UI tertentu
• Perlambatan mungkin terbatas pada browser tertentu

Lihat perlambatan khusus perangkat

Beyond Opentelemetry: Alat Lain

OpenElemetry adalah standar terbuka yang banyak digunakan dengan beberapa alat spesifik vendor populer yang bukan bagian dari spesifikasi OpenTelemetry yang dapat Anda gunakan.

• Kinerja sentinel – Alat kinerja dengan pelacakan transaksi dengan sangat sedikit pengaturan.
• Rum datadog – Alat pemantauan pengguna sejati yang menggabungkan rum dengan melacak backend.

Alat vendor lain dapat lebih mudah digunakan dan diimplementasikan daripada OpenElemetry. OpenElemetry dapat membawa portabilitas di masa depan.

Praktik terbaik observabilitas front-end

• Sampel dengan bijak
  Anda tidak perlu melacak setiap klik. Swerve akan merekomendasikan penggunaan sampel probabilitas untuk menemukan visibilitas yang sesuai dan menggunakan overhead yang dapat dikelola.
• Jangan menangkap data yang sensitif
  Anda tidak boleh menangkap penekanan tombol mentah, kata sandi, atau informasi pribadi yang berani. Selalu pastikan Anda mendisinfeksi rentang itu.
• Strategi komunikasi cross-stack
  Observability hanya dapat bekerja jika ada tingkat konsistensi tertentu antara tim front-end dan back-end di sini (Pro Tip: Othels Everywhere).
• Memberikan konteks visual
  Jika Anda tidak dapat mengaitkan metrik pengalaman pengguna (seperti LCP, TTI) dengan bentang backend, grafik api tidak berarti apa -apa.

Kesimpulan: Kotak hitam ditutup

Terlalu lama, kinerja front-end adalah renungan dari kemampuan diamati. Tapi harap diperhatikan! Pengguna tidak peduli dengan waktu respons API. Mereka hanya akan mengalami perjalanan logis ujung ke ujung (mis. Mengklik tombol, menunggu layar memuat dan melihat hasilnya).

Pelacakan latar depan (mungkin menggunakan sesuatu seperti OpenTelemetry) pada akhirnya akan memberi kita observabilitas gaya back-end dari UI.

Ini berarti:

• Hubungkan Interaksi Pengguna ke permintaan backend
• Debugging keseluruhan sistem terdistribusi
• Berikan pengalaman pengguna yang lebih baik dan dapat diprediksi

Dengan kata lain, pelacakan tidak hanya baik atau layak untuk diamati: itu adalah tautan yang hilang ke observabilitas full-stack.

Pertanyaan yang sering diajukan

T1: Apakah pelacakan terlalu berat untuk mengimplementasikan aplikasi front-end?

Dengan pengambilan sampel, sama sekali tidak. Anda tidak perlu semua jejak – Anda membutuhkan jejak yang cukup untuk mengidentifikasi pola.

T2: Apakah saya perlu membuat perubahan pada backend untuk melacak di frontend?

Di dunia yang sempurna, ya. Untuk menjahit jejak bersama -sama, backend Anda juga perlu memiliki Otel atau sesuatu yang kompatibel.

T3: Akankah pelacakan menggantikan logging dan metrik?

TIDAK. Pelacakan tidak menggantikan logging dan metrik. Log memberi Anda semua detail, metrik memberi Anda tren, dan jejak memberi Anda cerita di seluruh sistem.

Pertanyaan 4: Bagaimana jika tim saya sudah menggunakan Sentry atau Datadog?

Tidak masalah! Banyak alat vendor datang dengan out-of-the-box. Anda masih dapat membawa Otel untuk menghindari penguncian vendor di masa depan.

👉 Sekarang saya penasaran: Jika Anda dapat melacak apa pun di aplikasi front-end hari ini, apa yang akan Anda lacak? Klik tombol itu sepertinya selalu ada di belakang? Persyaratan jaringan misterius ini? Atau mungkin fase rendering yang tampaknya ada secara permanen saat menggunakan perangkat lama?

Ini adalah keindahan pelacakan: ini mengartikulasikan apa yang Anda butuhkan.