28.01.2026

eBPF Nedir? Linux’ta Performans ve Güvenliği Uçurun

eBPF nedir, ne işe yarar? Linux’ta izleme, ağ görünürlüğü ve güvenlik için eBPF’yi adım adım öğrenin ve örneklerle uygulayın.

eBPF Nedir? Linux’ta Performans ve Güvenliği Uçurun

Meta Description

eBPF nedir? Linux’ta observability, ağ izleme ve güvenlik için eBPF’yi hızlıca öğrenin. Örneklerle bugün deneyin.

Giriş (Introduction)

Prod ortamda “CPU niye zıpladı?”, “bu servis neden timeout veriyor?”, “hangi process bu portu dinliyor?” gibi sorulara cevap ararken çoğu ekip ya fazla genel metriklere takılır ya da sunucuyu yoran debug araçlarına mecbur kalır. Üstelik konteynerler, mikroservisler ve servis mesh’ler derken sorunlar daha da görünmez hale gelir.

İşte burada eBPF devreye girer: Linux çekirdeğinin içinde, çok düşük overhead ile izleme (observability), ağ görünürlüğü, güvenlik ve performans analizi yapmanızı sağlar. Bu yazı, eBPF’nin ne olduğunu, neden “game changer” sayıldığını ve bugün nasıl pratikte kullanabileceğinizi anlatır.


eBPF Nedir? (Temel Tanım)

eBPF (extended Berkeley Packet Filter), Linux kernel içinde güvenli şekilde çalışan küçük programlar yükleyip çalıştırmanıza izin veren bir teknolojidir. Başta ağ paket filtreleme için doğsa da bugün:

  • Tracing / profiling (hangi fonksiyon ne kadar çalıştı?)
  • Networking (hangi bağlantı nerede gecikiyor?)
  • Security (hangi process hangi syscall’ı çağırdı?)
  • Observability (log/metric/trace tamamlayıcı görünürlük)

gibi alanlarda yaygın kullanılır.

Kritik nokta: eBPF programları kernel içinde çalışsa bile verifier sayesinde belirli kurallara uymak zorundadır; bu da stabilite ve güvenlik için temel korumadır.


Neden eBPF Kullanmalıyım?

“Bunu neden yapmalıyım?” sorusunun pratik cevapları:

1) Prod’da düşük overhead ile görünürlük

Klasik debug yaklaşımları (ağ trafiğini dump’lamak, ağır profiller) prod’da risklidir. eBPF ile olay anında, hedefli ölçüm yapabilirsiniz.

2) Konteyner ve Kubernetes dünyasında daha iyi bağlam

Konteyner içinde çalışan process’lerin ağ trafiğini, syscalls’larını ve latency’sini daha net görürsünüz.

3) Güvenlikte davranış tabanlı izleme

İmza tabanlı yaklaşımlar yerine “bu servis normalde bunu yapmazdı” gibi davranışları yakalamak mümkündür.

4) Daha hızlı RCA (Root Cause Analysis)

Timeout’lar, tail latency, DNS sorunları, kernel scheduling problemleri… eBPF ile sorunun nerede olduğunu daha hızlı daraltırsınız.


eBPF Nasıl Çalışır? (Kavramsal Model)

Aşağıdaki parçalar eBPF’nin temelini oluşturur:

  • Hook noktaları: Kernel’de “şurada bir şey olduğunda” çalış (syscall, kprobe, tracepoint, network hook…)
  • BPF programı: Bu hook’a bağlanan küçük program
  • BPF maps: Kernel ile user-space arasında veri paylaşımı (hash map, array, ring buffer)
  • Loader / runtime: Programı derleyip yükleyen araç (libbpf, bcc, bpftool)

Basit akış:

  1. Bir olay olur (ör. connect() syscall)
  2. Hook tetiklenir
  3. eBPF programı çalışır ve sayacı artırır / event üretir
  4. User-space araç event’i okur ve raporlar

Gerçek Hayat Senaryoları (Nerede İşe Yarar?)

Aşağıdaki tabloda eBPF’nin sık görülen kullanım alanlarını özetleyelim:

Problem Klasik yaklaşım eBPF ile yaklaşım Kazanç
Ani CPU artışı Top/htop ile tahmin Kernel seviyesinde profiling Daha net “kim yiyor?”
Zaman zaman timeout Log artırma, redeploy Socket seviyesinde latency izleme Daha hızlı RCA
Şüpheli process davranışı Auditd + ağır log Syscall tracing + policy Daha düşük overhead
K8s network karmaşası Sidecar log’ları Node seviyesinde flow görünürlüğü Daha az kör nokta

Örnek: Ödeme servisinde arada bir 2-3 saniyelik gecikme var. Log’da görünmüyor. eBPF ile bağlantı kurulma süresi mi, DNS mi, kernel queue mu tıkanıyor görebilirsiniz.


15 Dakikada Pratik: eBPF Araçlarıyla Hızlı Teşhis

Sıfırdan eBPF programı yazmadan önce, hazır araçlarla değer üretmek en mantıklısı.

Adım 1) Linux sürümünüzü kontrol edin

Modern eBPF için nispeten güncel kernel avantaj sağlar.

uname -r

Adım 2) bpftrace ile hızlı sorgu

bpftrace, “tek satırlık eBPF script’leri” çalıştırmanızı sağlar.

Ubuntu/Debian örneği:

sudo apt-get update
sudo apt-get install -y bpftrace

Örnek: En çok çalışan syscall’ları say

Aşağıdaki script, syscall’ları sayar ve Ctrl+C’de özet basar:

sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
  • comm: process adı
  • @[comm] = count(): process bazlı sayaç

Bu size “hangi process sistem çağrılarını patlatıyor?” sorusuna hızlı bir cevap verir.

Adım 3) Bağlantı (TCP) problemlerini görünür kılın

Çoğu ekip “timeout var” dediğinde sadece uygulama log’una bakar. Oysa sorun TCP seviyesinde olabilir.

bcc araçları (dağıtıma göre paket adı değişebilir) veya alternatif olarak Cilium/Hubble gibi eBPF tabanlı ürünler kullanılabilir. Eğer ortamınızda mevcutsa şu tip araçlar çok iş görür:

  • tcpconnect: yeni TCP connect olaylarını izleme
  • tcpretrans: retransmission tespiti (ağ kalitesi / packet loss sinyali)

Not: Kurulum paketleri dağıtıma göre farklılaştığı için burada komutları “konsept” olarak veriyorum; üretimde en yaygın yol, distro reposu veya container üzerinden bcc/bpftrace çalıştırmaktır.


Kubernetes’te eBPF: Cilium/Hubble ile Trafiği Okunur Hale Getirme

Kubernetes’te eBPF denince en popüler pratik kullanım Cilium (CNI) ve Hubble (network observability).

Neler kazanırsınız?

  • Pod-to-pod trafik görünürlüğü (L3-L7)
  • Servis bağımlılık haritası
  • Network policy enforcement (iptables yerine eBPF datapath)

Ne zaman mantıklı?

  • Mikroservis sayınız arttıysa
  • “Hangi servis kime gidiyor?” sorusu cevaplanamıyorsa
  • Network policy’leriniz karmaşıklaşıyorsa

Kısa karar rehberi:

  • Sadece temel metrik istiyorum → Prometheus + basit dashboard
  • Node seviyesinde “gerçek” network görünürlüğü istiyorum → eBPF tabanlı observability
  • Network policy performansı kritik → Cilium değerlendir

eBPF’ye Geçerken Dikkat Edilmesi Gerekenler

1) Güvenlik ve yetkilendirme

eBPF güçlüdür; yükleme yetkisi olan bir kullanıcı ciddi etki yaratabilir. Root/privileged erişimi ve cluster security policy’leri iyi tasarlanmalı.

2) Kernel uyumluluğu

Her kernel özelliği her sürümde yoktur. Prod ortamınızın kernel versiyonlarını standardize etmek işinizi kolaylaştırır.

3) “Her şeyi eBPF ile çözerim” tuzağı

eBPF bir sihir değil. Uygulama metrikleri, doğru log tasarımı ve tracing ile birlikte düşünülmeli.

4) Veri hacmi ve maliyet

Event üretimini kontrol etmezseniz çok veri çıkar. Örnek stratejiler:

  • Sampling (örnekleme)
  • Sadece problem anında kısa süreli aktif etme
  • Filtreleme (sadece belirli process/pod/port)

Sık Sorulan Sorular (FAQ)

1) eBPF nedir, kısaca ne işe yarar?

eBPF, Linux kernel içinde güvenli şekilde çalışan küçük programlarla sistem davranışını izleme, ağ görünürlüğü ve güvenlik politikaları uygulama imkânı verir.

2) eBPF performansı düşürür mü?

Doğru kullanılırsa overhead genelde düşüktür. Ancak çok sık event üretmek veya filtrelememek veri hacmini artırıp maliyet yaratabilir.

3) eBPF öğrenmek için C bilmek şart mı?

Şart değil. bpftrace ile script yazarak başlayabilirsiniz. İleri seviye için C/libbpf bilgisi faydalıdır.

4) eBPF sadece Kubernetes için mi?

Hayır. Bare-metal, VM, klasik Linux sunucularda da çok değerlidir. K8s sadece en popüler kullanım alanlarından biridir.

5) eBPF ile güvenlik ürünü yapılır mı?

Evet. Syscall izleme, runtime policy, anomali tespiti gibi alanlarda eBPF yaygın kullanılır (ör. Falco’nun eBPF tabanlı yaklaşımları).


Sonuç

eBPF, Linux’ta performans, observability ve güvenliği bir üst seviyeye taşıyan modern bir altyapı teknolojisi. Özellikle “prod’da sorun var ama nerede?” dediğiniz anlarda, düşük overhead ile doğru noktayı görmenizi sağlar.

Bugün aksiyon olarak:

  1. Bir sunucuda bpftrace kurup basit bir trace çalıştırın
  2. En çok syscall üreten process’leri görün
  3. Ardından ağ gecikmesi/timeout vakalarında TCP olaylarını izlemeyi deneyin

Denediğiniz senaryoyu (kernel sürümü, hangi problem, hangi çıktıyı aldınız) yorum olarak yazın; aynı senaryo için daha hedefli eBPF script’i önerip birlikte netleştirebilirim.