Topik wawancara representatif

Wawancara system design: Bagaimana Anda mengevaluasi dan menerapkan OpenTelemetry Profiles secara bertahap?

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Tim Anda menginginkan continuous profiling di OpenTelemetry. Profiles berstatus Alpha; bagaimana Anda mengevaluasi nilainya dan merancang rencana adopsi yang dapat dibatalkan (reversible)?

Skenario

Anda mengelola platform microservice poliglot. Jejak (traces), metrik (metrics), dan log sudah ada, tetapi regresi performa masih memerlukan pembuatan profil (profiling) manual per host. Tim ingin OpenTelemetry Profiles mengirimkan data CPU, off-CPU, dan heap melalui OTLP ke Collector dan mengorelasikannya dengan trace dan span. Sinyal ini memasuki Public Alpha pada tahun 2026. Rancang evaluasi, uji coba (pilot), jalur data, dan rencana rollback.

Hal yang dievaluasi oleh pewawancara

  • Membedakan pertanyaan yang dijawab oleh profil, log, metrik, dan trace.
  • Menyadari tingkat kematangan Alpha, kesiapan backend, dan celah pengumpulan data spesifik bahasa pemrograman.
  • Mengontrol overhead pengambilan sampel, biaya penyimpanan, data sensitif, dan akses.
  • Menentukan batas kelayakan (pilot gates) yang terukur, batas isolasi, dan rollback.

Pertanyaan klarifikasi

Konfirmasikan apakah masalah target berkaitan dengan CPU, memori, lock wait, atau tail latency; bahasa dan runtime apa saja yang harus dicakup; profiler saat ini, SLO, anggaran sampling, retensi, dan batasan kepatuhan (compliance). Tanyakan apakah ada backend yang mendukung OTLP Profiles dan apakah pprof, JFR, atau APM saat ini dapat dipertahankan selama terjadi kegagalan.

Jawaban 30 detik

Saya akan menjalankan uji coba percontohan tetapi menjauhkan sinyal Alpha dari peringatan (alerting) kritis. Pilih beberapa layanan Linux, kumpulkan pada frekuensi rendah melalui Collector terpisah, dan pertahankan pprof/JFR sebagai baseline. Ukur waktu diagnosis (time to diagnosis), overhead CPU, cakupan sampling, biaya per GB, tingkat korelasi trace, dan defek redaksi data. Perluas implementasi hanya setelah pengujian backend, kontrol akses, dan simulasi rollback berhasil. Kegagalan format atau Collector harus dapat menghentikan ekspor tanpa memengaruhi lalu lintas permintaan pengguna.

Penalaran langkah demi langkah

1. Tentukan batasan sinyal

Log mendeskripsikan peristiwa diskret, metrik mendeskripsikan nilai tingkat sistem, trace mendeskripsikan jalur permintaan, dan profil mendeskripsikan kode mana yang mengonsumsi sumber daya. Profil melengkapi sinyal lain alih-alih menggantikannya; korelasikan profil melalui pengidentifikasi sumber daya, trace, atau span untuk mempersingkat analisis akar masalah (root-cause analysis).

2. Rancang pengumpulan data

Sampling profiler secara berkala mencatat stack untuk overhead yang rendah dan berkelanjutan. Instrumentation profiler dapat mencatat peristiwa runtime seperti alokasi memori, lock, atau garbage collection. Mulai dengan agen eBPF atau alat bawaan bahasa pada node yang terisolasi, lalu biarkan Collector memfilter, membatasi laju (rate-limit), mengelompokkan (batch), dan merutekan data sebelum diekspor melalui OTLP.

3. Kontrol biaya dan privasi

Tetapkan tingkat sampling dan anggaran CPU berdasarkan tingkatan layanan (service tier), dengan memprioritaskan layanan yang memiliki anomali latensi persentil ke-99. Batasi simbol, argumen, dan data jalur sensitif; isolasi penyewa (tenants); dan gunakan retensi terpisah untuk profil mentah dan profil yang diagregasi. Pantau drop rate, antrean Collector, bandwidth keluar (egress), dan biaya penyimpanan.

4. Tangani risiko Alpha

Dokumentasi resmi melabeli Profiles sebagai Alpha, dan pengumuman tersebut menyatakan bahwa fitur ini tidak boleh digunakan untuk beban kerja produksi yang kritis selama backend yang siap untuk produksi masih terus berkembang. Gunakan feature flag, kuota sumber daya independen, baseline alat lama, dan rollback yang hanya berbasis konfigurasi. Jangan memigrasikan setiap bahasa dan backend hanya demi standardisasi.

Contoh jawaban berkualitas tinggi

Saya akan mengoptimalkan pengurangan waktu diagnosis performa, bukan penggantian langsung terhadap profiler yang ada. Tahap pertama memilih dua layanan Linux, satu Go dan satu JVM, mempertahankan output pprof/JFR, serta mencatat waktu diagnosis dasar dan biaya sumber daya. Tahap kedua menerapkan Collector terisolasi dengan profil CPU frekuensi rendah; tingkatkan laju sampling hanya untuk anomali SLO atau CPU. Collector memfilter berdasarkan lingkungan, menerapkan batasan, menyunting (redact) bidang sensitif, dan merutekan OTLP melalui antrean yang terpisah dari lalu lintas produksi. Tahap ketiga mengaktifkan korelasi trace/span dan menguji apakah span yang lambat dapat menelusuri hingga ke stack yang bertanggung jawab. Syarat kelulusan (gates) mencakup batas overhead CPU yang terkontrol, cakupan yang memadai, waktu diagnosis P95 yang lebih rendah, biaya bulanan yang dapat diterima, dan tidak ada kebocoran bidang sensitif. Karena Profiles berstatus Alpha, pertahankan backend dan alat saat ini. Jika Collector mengalami penumpukan data (back up), backend menolak data, atau batasan akses gagal, nonaktifkan ekspor; permintaan bisnis tidak boleh bergantung pada jalur ini.

Kesalahan umum

  • Memperlakukan Alpha Profiles sebagai pengganti universal yang stabil.
  • Mengganti trace, metrik, atau log dengan profil tanpa menjelaskan korelasinya.
  • Menyimpan setiap stack dan simbol mentah tanpa batas waktu terlepas dari biaya dan sensitivitas data.
  • Berbagi antrean penting untuk bisnis dengan ekspor profil sehingga kegagalan menyebabkan keterlambatan permintaan.
  • Mengatakan “terapkan eBPF” tanpa anggaran sampling, kompatibilitas backend, atau sakelar pemutus (kill switch).

Pertanyaan lanjutan dan tanggapan

“Mengapa tidak mempertahankan pprof atau JFR saja?”

Pertahankan keduanya sebagai baseline dan fallback. Profiles menambahkan model umum, pipeline OTLP, dan korelasi antarsinyal; migrasi hanya dapat dibenarkan jika uji coba pilot membuktikan manfaat-manfaat tersebut.

“Bagaimana Anda mengorelasikan trace dan profil?”

Catat metadata resource serta trace_id atau span_id yang tersedia pada sampel profil dan pertahankan bidang-bidang tersebut melalui Collector dan backend. Terima kenyataan bahwa tidak setiap sampel dapat dipetakan ke suatu permintaan.

“Kapan Anda akan menghentikan uji coba pilot?”

Nonaktifkan ekspor jika risiko CPU, biaya, atau privasi melebihi ambang batasnya, atau stabilitas backend tidak dapat mendukung jendela rollback. Pertahankan alat yang ada dan tinjau kembali setelah sinyal tersebut matang.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat