Mimari ve çalışma modeli
eBPF, doğrulanmış programları kernel içindeki tracepoint, kprobe, fentry, network ve diğer hook'lara bağlayarak olayları düşük düzeyde ölçer. Verifier, register ve bellek erişim yollarını analiz eder; kabul edilen programın sınırlı bağlamda güvenli çalışmasını hedefler. Bu doğrulama, gözlem sorgusunun işletim etkisinin sıfır olduğu veya toplanan verinin hassas olmadığı anlamına gelmez.
bpftrace kısa teşhis sorgularını BPF programlarına dönüştürür. Stabil tracepoint'ler sürüm değişiminde kprobe ile iç kernel sembollerine bağlanmaktan daha dayanıklıdır. Wildcard ile binlerce fonksiyona probe eklemek, her olayda `printf` çalıştırmak veya yüksek kardinaliteli map anahtarları kullanmak CPU ve bellek tüketimini artırabilir. Önce agregasyon, örnekleme ve zaman sınırı seçin.
Üretim çalışmasında hipotezi tek cümleyle yazın: örneğin `p99 dosya açma gecikmesi NFS beklemesinden mi geliyor?` İlgili tracepoint'i listeleyin, alan adlarını BTF veya format dosyasından doğrulayın ve düşük trafikli canary hostta çalıştırın. Baseline CPU, load, dropped event ve hedef latency kaydedilir. Sorgu `timeout` ile otomatik durmalı ve map çıktısı sınırlı olmalıdır.
Yetki modeli dağıtıma göre CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN veya ayrıcalıklı servis gerektirebilir. Kalıcı araç için systemd unit, imzalı paket, değişiklik kaydı ve audit tercih edin. PID, path, ağ adresi veya komut argümanları kişisel/hassas veri içerebilir; toplama amacını, maskeleme ve saklama süresini belirleyin. Teşhis bitince probe ve pinned map kalmadığını doğrulayın.
- 1Ölçülebilir hipotez
- 2Sınırlı probe ve verifier
- 3Kernel map agregasyonu
- 4Süreli çıktı, karşılaştırma ve cleanup
Tasarım parametreleri
- Probe kararlılığı
- Önce tracepoint/fentry gibi tanımlı arayüzleri, gerekli olduğunda sürüme bağlı kprobe'u seçin.
- Olay oranı
- Saniyedeki event sayısını tahmin edin; printf yerine kernel map agregasyonu ve örnekleme kullanın.
- Map bütçesi
- Anahtar kardinalitesi × değer boyutu × CPU kopyalarını üst sınırla planlayın.
- Çalışma süresi
- Komuta timeout, canary kapsamı ve otomatik cleanup ekleyin.
- Veri yönetimi
- Path, PID, adres ve argümanların maskeleme, erişim ve retention kararını kaydedin.
Hesap ve uygulama örneği
Sunucuda saniyede 80.000 syscall varsa her olayda kullanıcı alanına satır yazmak büyük yük oluşturabilir. Kernel map içinde süreç adına göre sayaç tutup beş saniyede bir özetlemek event çıkışını 400.000 satırdan onlarca satıra düşürür. Yine de CPU ve lost event sayısını baseline ile karşılaştırın; düşük çıktı tek başına düşük overhead kanıtı değildir.
Latency histogramında 1 ms altı 900, 1–10 ms 90 ve 10–100 ms 10 olay varsa toplam 1.000 çağrının yüzde 1'i son banttadır. Bu dağılım yaklaşık p99 sınırını gösterir fakat daha ince bucket olmadan kesin p99 vermez. Histogramı uygulama metriği ve blok I/O/NFS kanıtıyla eşleştirin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
sudo bpftrace -l 'tracepoint:syscalls:sys_enter_openat'
sudo timeout 30 bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); } interval:s:5 { print(@); clear(@); }'
sudo bpftool prog show
sudo bpftool map show
sudo bpftool link showHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Program verifier tarafından reddediliyor | Alan erişimi, pointer sınırı, stack veya helper kullanımı program türüyle uyumsuz olabilir. | Verifier logunu ve kernel/BTF sürümünü kaydedin; doğrulamayı kapatmaya çalışmayın. |
| bpftrace çalışınca CPU artıyor | Olay oranı, wildcard probe, printf veya map kardinalitesi çok yüksek olabilir. | Probe hit sayısı, lost events, map boyutu ve süreç CPU'sunu baseline ile karşılaştırın. |
| Probe adı bulunamıyor | Kernel config, BTF, modül veya sembol adı kullanılan sürümde farklı olabilir. | `bpftrace -l`, tracefs events ve BTF varlığını doğrulayın. |
| Komut bitti fakat kaynak kalıyor | Pinned map/program veya ayrı servis attachment'ı temizlenmemiş olabilir. | `bpftool prog/map/link show` ile sahiplik ve pin yolunu inceleyin. |
Kabul ve doğrulama kontrolleri
- Teşhis hipotezini ve başarı ölçüsünü yazın.
- Probe ve alanları hedef kernelde listeleyip doğrulayın.
- Olay oranı ile map kardinalitesi için üst sınır hesaplayın.
- Canary hostta timeout ile CPU/lost-event etkisini ölçün.
- Toplanan hassas alanlar için maskeleme ve retention uygulayın.
- Bitişte BPF link, program ve pinned map temizliğini doğrulayın.
İlgili kavramlar
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.