eBPF ile Linux Sunucuda Sorun Teşhisi

Bir sunucuda CPU kullanımı yükseldiğinde ilk bakılan yer genellikle uygulama loglarıdır. Ancak loglar çoğu zaman isteğin ne zaman reddedildiğini gösterir; çekirdeğin hangi süreçleri çalıştırmak için beklettiğini, bir diskin ne kadar süre kuyruğa girdiğini veya TCP bağlantısının hangi aşamada geciktiğini göstermez.

eBPF, Linux çekirdeğinde belirli olay noktalarına güvenli biçimde gözlem kodu bağlamanızı sağlayan bir teknolojidir. Çekirdek kaynak kodunu değiştirmeden sistem çağrılarını, zamanlayıcı davranışını, ağ paketlerini ve dosya erişimlerini izleyebilirsiniz. Bu yaklaşım, klasik logları değiştirmez; onların açıklayamadığı zaman çizelgesini tamamlar.

Buradaki amaç, her metriği aynı anda toplamak değil, belirti ile kök neden arasındaki boşluğu daraltmaktır. Örnek komutlar Linux sunucuda sudo yetkisi, eBPF ile uyumlu bir çekirdek ve ilgili araçların kurulu olduğu varsayımıyla verilir. Dağıtımınızın çekirdek sürümü, paket sürümleri ve yetki politikası nedeniyle komutlarda farklılık oluşabilir.

eBPF hangi soruları yanıtlar?

eBPF ile gözlem yaparken önce ölçmek istediğiniz davranışı bir soruya dönüştürün. “Sunucu yavaş” ifadesi teşhis için geniştir. “İstek işleyen süreç CPU için mi bekliyor, disk okuması mı gecikiyor?” daha ölçülebilir bir sorudur.

CPU yüksek ama süreç kullanımı açıklamıyor

Standart araçlar CPU yüzdesini gösterir, fakat bu yüzdelerin kullanıcı alanında mı, çekirdek alanında mı, yoksa sanal makinenin çalınan zamanında mı oluştuğunu her zaman ayırmaz. eBPF tabanlı profil örneklemesi, belirli aralıklarla çalışan çağrı yığınlarını toplar. Böylece süreç içinde hangi kod yolunun daha fazla zaman tükettiğine dair bir yön elde edersiniz.

Bu ölçüm, kesin bir işlem süresi hesabı değildir. Örnekleme sıklığı, sembol bilgisi ve derleyici optimizasyonları sonucu etkiler. Yine de uygulama loglarında görünmeyen yoğun döngü, kilit beklemesi veya çekirdek çağrısı eğilimini ortaya çıkarabilir.

Ağ gecikmesi uygulamadan mı kaynaklanıyor?

Bir HTTP isteğinin yavaş olması; DNS, TCP bağlantısı, TLS el sıkışması, uzak servis, yerel kuyruk veya uygulama işlem süresinden kaynaklanabilir. eBPF araçları TCP bağlantı kurulumu, yeniden iletim ve soket davranışı gibi olayları uygulama loglarından bağımsız olarak gözlemlemenize yardım eder.

Ağ katmanında görülen gecikme, doğrudan kullanıcıya dönen toplam yanıt süresi değildir. Ağ olayını uygulamanın istek süresiyle ve dış izleme verisiyle karşılaştırmanız gerekir.

Disk yavaş mı, süreç mi yanlış çalışıyor?

Disk kullanım yüzdesi yüksek değilken uygulama yine de bekleyebilir. Küçük ve rastgele I/O işlemleri, sanal disk katmanındaki kuyruklar veya tek bir dosyada kilitlenme bu durumu açıklayabilir. eBPF ile blok I/O gecikmesini, işlemi başlatan süreci ve okuma-yazma davranışını birlikte inceleyebilirsiniz.

Bu veriyi dosya içeriğiyle karıştırmayın. eBPF burada çoğunlukla olayın zamanını, sürecini ve sistem çağrısı bağlamını gösterir; hassas uygulama verilerini incelemeniz gerektiği anlamına gelmez.

Kurulumdan önce güvenli gözlem planı

eBPF araçlarının kurulması ile eBPF programının çekirdeğe bağlanması farklı aşamalardır. Kurulum, paket yöneticisi ve dağıtım depolarına bağlıdır. Gözlem sırasında ise yetkiler, çekirdek desteği, semboller ve araç sürümleri belirleyici olur.

Ön koşulları doğrulayın

İlk adım, mevcut sistemi değiştirmeden çekirdeğin ve araçların durumunu kaydetmektir. Aşağıdaki komutlar yalnızca bilgi toplar:

uname -r
command -v bpftrace
command -v bpftool
sudo bpftool feature probe kernel

bpftool bulunmuyorsa komut çalışmaz; bu tek başına çekirdeğin eBPF desteklemediğini göstermez. Dağıtımınızın uygun paketini kurmanız gerekebilir. Bazı araçlar BCC kitaplıklarını, bazıları LLVM/Clang bileşenlerini kullanır. Araç sürümlerini dağıtımınızın desteklediği paketlerden seçin.

Üretim sunucusunda paket kurulumu yapacaksanız önce paket yöneticisinin değişiklik listesini inceleyin, bakım prosedürünüzü ve geri dönüş planınızı uygulayın. Sadece gözlem için çekirdek güncellemek, teşhis edilmemiş bir gecikmeyi çözmekten daha geniş bir değişikliktir.

Yetki ve güvenlik sınırlarını belirleyin

Birçok eBPF gözlem komutu root veya özel yetenekler gerektirir. Komutu sudo ile çalıştırmak, kullanıcıya sınırsız ve kalıcı erişim vermek anlamına gelmemelidir. Sadece gerekli yöneticilerin kullanacağı ayrı bir teşhis prosedürü tanımlayın ve çıktılarda komut satırı, dosya adı veya ağ adresi gibi hassas bilgilerin bulunabileceğini hesaba katın.

Üretim ortamında ilk denemeyi kısa süreli ve dar kapsamlı yapın. Tüm süreçleri ve tüm sistem çağrılarını sınırsız toplamak yerine belirli bir PID, komut adı, port veya zaman aralığı kullanın. Çıktıyı ortak kanallara aktarmadan önce erişim izinlerini kontrol edin.

FPM, CLI ve kuyruk süreçlerini ayırın

Web isteğini işleyen PHP-FPM çalışanı ile cron veya kuyruk tüketicisi olarak çalışan CLI süreci aynı çalışma modeline sahip değildir. HTTP isteği yapmayan bir CLI işi PHP-FPM web işçisi tüketmez. Bu ayrım, yanlış süreci ölçüp yanlış sonuca ulaşmamanız için gereklidir.

Önce süreçleri görün:

ps -eo pid,ppid,comm,args,%cpu,%mem --sort=-%cpu | head -n 20

Burada PHP-FPM ana sürecinin PID’si ile çalışan işçilerin PID’lerini, cron komutunu veya kuyruk tüketicisini ayırın. eBPF filtresini mümkünse tek bir çalışan PID’sine uygulayın. Ana süreçte görülen düşük aktivite, işçilerin davranışını temsil etmeyebilir.

CPU ve süreç davranışını eBPF ile inceleme

CPU belirtisini incelerken önce standart ölçümle zaman aralığını belirleyin. top, pidstat veya mevcut izleme sisteminiz hangi PID’nin yükseldiğini ve artışın ne kadar sürdüğünü göstermelidir. eBPF bundan sonra “bu süreç hangi çağrı yığınında örnekleniyor?” sorusunu yanıtlamak için kullanılmalıdır.

Dar kapsamlı profil örneği

Aşağıdaki bpftrace örneği, PID’si 1234 olan süreci saniyede 49 örnekle profiller. PID’yi kendi teşhisinizde belirlediğiniz çalışan süreçle değiştirin:

sudo bpftrace -e 'profile:hz:49 /pid == 1234/ { @[ustack] = count(); }'

Komut, siz durdurana kadar örnekleri toplar; kısa bir gözlem penceresi için Ctrl+C ile sonlandırabilirsiniz. Kullanıcı alanı çağrı yığınlarının anlamlı görünmesi için ilgili ikili dosyada sembol bilgisi veya uygun debug sembolleri gerekebilir. Sembol yoksa adresler ya da eksik adlar görebilirsiniz.

Çıktıda tek başına en yüksek satırı kök neden olarak kabul etmeyin. Aynı gözlemi uygulama isteği oranı, CPU bekleme durumu ve ilgili dağıtım zamanı ile karşılaştırın. Profil, yoğun kod yolunu işaret eder; iş kuralının hatalı olduğunu kanıtlamaz.

Sistem çağrı yoğunluğunu görün

Bir süreç çok sayıda dosya açıyor, zamanlayıcı çağrısı yapıyor veya beklenenden fazla sistem çağrısı üretiyor olabilir. Aşağıdaki örnek, çalışan komut adına göre openat çağrılarını sayar:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }'

Bu örnekte PID filtresi yoktur; bu nedenle kısa süreli teşhis ve düşük yoğunluklu sunucularda kullanın. Üretim sisteminde tek bir süreçle sınırlandırmak daha güvenlidir:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat /pid == 1234/ { @[comm] = count(); }'

Yüksek çağrı sayısı her zaman performans sorunu değildir. Uygulamanın beklenen çalışma biçimi çok sayıda küçük dosya erişimi gerektirebilir. Şüpheli sonucu sistem çağrısı süresi ve uygulama davranışıyla doğrulayın.

Ağ gecikmesini katmanlarına ayırma

Ağ sorunu bildirildiğinde önce hangi bağlantının geciktiğini belirleyin. Tek bir sunucuda aynı anda istemci istekleri, veritabanı bağlantıları, DNS sorguları ve dış API çağrıları bulunabilir. Tüm TCP olaylarını toplamak yerine bağlantı kuran süreci ve hedef portu daraltın.

TCP bağlantı girişimlerini izleme

BCC paketi kuruluysa tcpconnect aracı yeni TCP bağlantılarını özetlemek için kullanılabilir. Örneğin PID 1234 için:

sudo tcpconnect -p 1234

Bu komutun sözdizimi BCC sürümüne göre küçük farklılıklar gösterebilir; çalıştırmadan önce tcpconnect --help çıktısını kontrol edin. Araç bağlantı girişimini gösterebilir, fakat uzak servisin uygulama düzeyinde yanıt verdiğini kanıtlamaz.

BCC yoksa aynı soruyu bpftrace ile daha düşük ayrıntıyla inceleyebilirsiniz:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect /pid == 1234/ { @[comm] = count(); }'

Bu komut bağlantı sistemi çağrılarının sayısını verir; hedef adresi ve gecikme süresini tek başına açıklamaz. Amaç, kısa sürede olağandışı bağlantı üretimi olup olmadığını görmektir.

Yeniden iletim ve ağ kaybını yorumlayın

TCP yeniden iletimleri, paket kaybı veya ağ yolundaki yoğunluk ihtimalini güçlendirebilir. Ancak yeniden iletim tek başına uzak sunucunun yavaş olduğunu göstermez; yerel ağ kartı, sanal ağ, güvenlik duvarı ve hedef sistem birlikte değerlendirilmelidir.

Bu aşamada eBPF çıktısını ss -s, bağlantı durumu, uygulama zaman aşımı ve dış izleme verisiyle karşılaştırın. Bir portta bekleyen çok sayıda bağlantı görüyorsanız hemen çekirdek veya ağ ayarı değiştirmeyin. Önce bağlantıların hangi süreçten çıktığını ve bunun beklenen trafikle uyumlu olup olmadığını doğrulayın.

Web performansını incelerken ağ ölçümünü tarayıcı ve uygulama süreleriyle birleştirmek gerekir. Sunucu loglarıyla Core Web Vitals iyileştirme çalışması, eBPF gözlemini kullanıcı tarafındaki algılanan performansla ilişkilendirmenize yardımcı olabilir; eBPF tek başına tarayıcı metriklerinin yerine geçmez.

Disk erişimi ve I/O beklemelerini ayırma

Disk gecikmesinde iki soruyu ayırın: Depolama katmanı gerçekten geç mi yanıtlıyor, yoksa uygulama çok fazla I/O isteği mi üretiyor? iostat veya benzeri araçlarla genel görünümü alın; ardından eBPF ile süreç ve gecikme dağılımını daraltın.

Blok I/O gecikmesini ölçme

BCC araçları kuruluysa biolatency, blok aygıtı işlemlerinin gecikme dağılımını görmek için kullanılabilir:

sudo biolatency 1 10

Bu örnekte aracın sürümüne bağlı olarak bir saniyelik aralıklarla on çıktı alınması beklenir. Desteklenen seçenekleri kendi sisteminizde biolatency --help ile doğrulayın. Çıktıyı disk cihazı, sanal depolama katmanı ve aynı zamandaki uygulama istek sayısıyla karşılaştırın.

Belirli bir sürecin dosya erişimini izlemek için geniş bir sistem çağrısı yakalama komutu kullanabilirsiniz:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read /pid == 1234/ { @[comm] = count(); }'

Bu örnek yalnızca read çağrılarının sayısını gösterir; okuma işleminin ne kadar beklediğini göstermez. Sayı yüksek diye doğrudan disk arızası sonucuna varmayın. Uygulama önbelleği, veritabanı sorgu planı veya dosya erişim paterni de aynı belirtiyi üretebilir.

Veri değişikliğinden önce sınırı koruyun

Disk sorunu şüphesiyle dosya silmek, önbellek temizlemek, veritabanı ayarı değiştirmek veya I/O zamanlayıcısını değiştirmek teşhis adımı değildir; sistem davranışını değiştirir. Önce mevcut yapılandırmayı, disk sağlığı bilgisini ve geri dönüş planını kaydedin. Veri değiştiren adım gerekiyorsa yedeğin güncel olduğunu ve geri yükleme yolunun test edildiğini doğrulayın.

Süreç, dosya ve çekirdek olaylarını birlikte doğrulama

Tek bir araç nadiren kök nedeni kanıtlar. Örneğin PHP-FPM bekliyorsa bunun nedeni disk, veritabanı soketi, dosya kilidi veya dış API olabilir. eBPF size olay zamanlarını verir; süreç listesi, uygulama logu, ağ bağlantısı ve depolama verisi bu zaman çizelgesini anlamlandırır.

Bir teşhis akışı kurun

1. Belirtiyi zamanlayın: Sorunun başladığı ve bittiği dakikaları, etkilenen servisleri ve trafik değişimini kaydedin.
2. Süreci belirleyin: FPM çalışanı, CLI cron işi, kuyruk tüketicisi ve veritabanı sürecini birbirine karıştırmayın.
3. Tek hipotez seçin: Örneğin “PID 1234, disk okumasında bekliyor” gibi sınırları belli bir soru yazın.
4. En dar eBPF ölçümünü çalıştırın: PID, olay türü ve kısa zaman aralığı kullanın.
5. Bağımsız veriyle karşılaştırın: Uygulama süresi, sistem metriği, ağ durumu ve ilgili log satırlarını aynı zaman penceresinde inceleyin.
6. Dar düzeltme uygulayın: Ayar değişikliği gerekiyorsa yalnızca doğruladığınız nedene dokunun ve mevcut yapılandırmayı yedekleyin.
7. Tekrar ölçün: Aynı belirti ortadan kalktı mı, yoksa yalnızca başka bir katmana mı taşındı kontrol edin.

Bu akışta gözlem ile düzeltme arasındaki sınır korunur. Örneğin bir sürecin çok sayıda dosya açtığını görmek, hemen dosya tanıtıcı limitini artırmayı gerektirmez. Önce uygulamanın beklenen davranışını ve hata koşulunu doğrulayın.

Kernel seviyesindeki belirtilerde dikkat

Çekirdek hatası, kilitlenme veya beklenmeyen yeniden başlatma gibi olaylarda eBPF tek başına kurtarma aracı değildir. Kalıcı loglar, konsol çıktısı, watchdog ve çekirdek dökümleri ayrıca incelenmelidir. Sistem daha önce kernel panic yaşadıysa kernel panic kök neden analizi için açılış günlüklerini ve donanım/sanal altyapı kayıtlarını da birlikte değerlendirin.

eBPF ile olay yakalamak, geçmişte oluşmuş ve kaydedilmemiş bir arızayı geriye dönük olarak üretmez. Ölçümü belirti yeniden oluşurken planlayın; ancak güvenlik, performans ve veri gizliliği sınırlarını aşmadan uygulayın.

Araç seçimi: bpftrace, BCC ve hazır gözlem araçları

bpftrace, kısa ve tek amaçlı gözlem komutları için pratik bir başlangıçtır. Sistem çağrısı, tracepoint ve profil örnekleriyle hipotezi hızlıca test edebilirsiniz. Bunun karşılığında sözdizimi, olay adları ve çekirdek sürümü arasındaki uyumluluğu kontrol etmeniz gerekir.

BCC, ağ, disk ve süreç davranışı için hazırlanmış araçlar sunar. tcpconnect, biolatency ve benzeri araçlar, her olayı sıfırdan yazmadan ölçüm yapmanızı sağlar. Dağıtım paketinin BCC sürümü ile çekirdek ve Python bağımlılıkları uyumlu olmayabilir; her komutu önce yardım çıktısıyla doğrulayın.

bpftool ise haritaları, programları ve çekirdek özelliklerini incelemek için daha düşük seviyeli bir yönetim aracıdır. Geliştirici veya sunucu yöneticisi olarak eBPF programının gerçekten yüklendiğini doğrulamanız gerektiğinde kullanışlıdır. Kalıcı gözlem sistemi kuracaksanız veri modeli, örnekleme, yetki ve yükseltme prosedürünü ayrıca tasarlayın.

Sık Sorulan Sorular

eBPF kullanmak için uygulamanın kodunu değiştirmek gerekir mi?

Temel gözlem komutları için çoğu zaman gerekmez. Çekirdek olaylarını ve süreç davranışını dışarıdan izleyebilirsiniz. Uygulama içi özel iş akışlarını anlamak için ek sembol, enstrümantasyon veya uygulama metriği gerekebilir.

eBPF üretim sunucusunu yavaşlatır mı?

Etkisi kullanılan programın olay yoğunluğuna, filtrelerine ve topladığı veriye bağlıdır. Tek PID ve kısa süreli bir trace, geniş kapsamlı sürekli toplamadan daha kontrollüdür. Yine de ölçüm sırasında CPU, bellek ve çıktı hacmini izleyin.

eBPF logların yerini alır mı?

Hayır. Loglar iş kuralı, hata mesajı ve işlem bağlamı sunar; eBPF çekirdek ve süreç olaylarının zamanlamasını tamamlar. İki veri kaynağını aynı zaman aralığında karşılaştırmak daha güvenilir teşhis sağlar.

Her Linux dağıtımında aynı komutlar çalışır mı?

Hayır. Çekirdek sürümü, BCC veya bpftrace paketi, tracepoint adları ve yetki politikaları farklı olabilir. Komutu üretimden önce aynı dağıtım ve çekirdek ailesine sahip bir test ortamında doğrulayın.

Uygulanabilir son kontrol listesi

• Belirtiyi CPU, ağ, disk veya süreç davranışı olarak sınırlandırın.
• Çekirdek sürümünü, araçların kurulu olduğunu ve gerekli yetkileri doğrulayın.
• PHP-FPM, CLI cron ve kuyruk süreçlerinin PID’lerini ayırın.
• İlk ölçümü kısa süreli, tek PID veya tek olay türüyle yapın.
• eBPF çıktısını log, standart sistem metriği ve uygulama süresiyle karşılaştırın.
• Yapılandırma veya veri değiştiren adımdan önce yedek ve geri dönüş planını kontrol edin.
• Düzeltmeden sonra aynı ölçümle sonucu doğrulayın ve geçici gözlem programını sonlandırın.

Bir sonraki adım, tekrar eden belirtiniz için tek bir teşhis hipotezi yazıp uygun aracı seçmektir. Örneğin CPU yükselmesi için PID sınırlı profil, ağ gecikmesi için bağlantı gözlemi, disk beklemesi için I/O gecikme ölçümüyle başlayın. Gözlem kapsamı daraldıkça eBPF Linux sunucu izleme, belirsiz bir “sunucu yavaş” şikâyetini doğrulanabilir bir zaman çizelgesine dönüştürür.

Emre