GitHub Radar — Coroot
Linux çekirdeğinde eBPF ile çalışan, kod değişikliği gerektirmeyen sıfır enstrümantasyonlu APM ve dağıtık gözlemlenebilirlik platformu.
Coroot, modern mikroservis ve Kubernetes altyapıları için kaynak kodda tek satır değişiklik, SDK entegrasyonu veya servis yeniden başlatması gerektirmeden tam kapsamlı uygulama performansı izleme (APM) ve hata kök neden analizi sunan açık kaynaklı bir gözlemlenebilirlik platformudur 1. Geleneksel APM araçlarının ağır ajanlar, dil bazlı bayt kodu yamalamaları (monkey patching) ve yüksek CPU ek yükü getirdiği mimarilerin aksine Coroot; Linux çekirdeğinin ağ ve işlem katmanına doğrudan eBPF ile tutunarak servis haritalarını, L7 protokol metriklerini ve dağıtık izleri (distributed traces) şeffaf biçimde derler. Dağıtık sistemlerde telemetri toplama maliyetini ve karmaşıklığını çekirdek seviyesinde çözen özelleşmiş bir sistem gözlem motorudur 2.
Açık kaynak ekosisteminde 7.9 bin yıldız ve son commit 2 gün önce düzeyinde istikrarlı bir ilgiye sahip olan repo, aktif olarak yönetilen 116 açık issue ve düzenli yayın takvimini belgeleyen son sürüm v1.26.0 (Eylül 2026) metrikleriyle gelişimini sürdürmektedir.
Mimari Deep-Dive: Coroot
Coroot’un temel mühendislik başarısı, dağıtık sistem gözlemlenebilirliğini uygulama katmanından tamamen soyutlayıp doğrudan Linux çekirdeğinin (kernel space) ağ yığınına yerleştirmesinden kaynaklanır. Proje iki ana katmandan oluşur: Düğüm seviyesinde çekirdek olaylarını yakalayan coroot-node-agent C ve Go dilleriyle yazılmıştır; toplanan telemetriyi analiz eden, servis topolojisini çıkaran ve otomatik kök neden tespiti yapan merkezi Coroot sunucusu ise Go ve ClickHouse sütun tabanlı veritabanı üzerine kuruludur 1.
Geleneksel APM ajanlarının aksine Coroot, uygulamaların bellek alanına müdahale etmez. Bunun yerine Linux çekirdeğindeki kararlı tracepoint kancalarını (sock/inet_sock_set_state, sched/sched_process_exit, task/task_newtask) ve optimize edilmiş kprobes çağrılarını (tcp_v4_connect, tcp_sendmsg, tcp_recvmsg) dinler 3. Çekirdek sürüm değişikliklerinden etkilenmemek adına CO-RE (Compile Once, Run Everywhere) mimarisini ve BPF Tip Formatını (BTF) etkin biçimde kullanır. Ağ paketleri çekirdeğin TCP/IP yığınından geçerken eBPF programı giden ve gelen soket tamponlarını (socket buffers) inceler. HTTP/1.x, HTTP/2 (gRPC), PostgreSQL, MySQL, Redis, Memcached ve MongoDB protokollerinin başlıklarını uçuş anında (in-flight) ayrıştırır; istek metodunu, URL yolunu, durum kodunu ve yanıt süresini hesaplar.
Bu mimarinin en çarpıcı yanı, ham ağ paketlerini asla kullanıcı alanına (userspace) kopyalamamasıdır. eBPF haritalarında (maps) ve ring buffer yapılarında yalnızca özet işlem istatistikleri ve yuvarlanmış gecikme histogramları tutulur. Böylece CPU tüketimi %1 seviyesinin altında kalır ve ağ bant genişliği tüketimi önlenir. Aynı zamanda çekirdeğin cgroup hiyerarşisi taranarak her soket dosya tanımlayıcısı (socket fd) anında ait olduğu Kubernetes podu, konteyner kimliği ve ad alanı ile eşleştirilir. Yanıt gecikmelerinde yaşanan artışlar, çekirdeğin TCP yeniden iletim (retransmit) sayaçları ve CPU runqueue gecikmeleriyle çapraz sorgulanarak sorunun ağdan mı, veritabanı kilitlerinden mi yoksa yetersiz CPU limitlerinden mi kaynaklandığı anında doğrulanır. Bu durum Istio veya Linkerd gibi harici servis ağı (service mesh) yan araçlarının (sidecars) getirdiği bellek şişmesini ve çift yönlü TCP proxy gecikmesini tamamen ortadan kaldırır. Çekirdek içinde çalışan L7 ayrıştırıcıları, TLS olmayan tüm dahili trafiği donanım seviyesinde yakalayarak mikroservis mimarilerinde sıfır enstrümantasyonla uçtan uca çağrı zinciri oluşturur.
Kod ve Topluluk Sağlığı
Coroot, yüksek trafikli internet platformlarında ve devasa altyapılarda çalışmış tecrübeli sistem mimarları tarafından kurulan ve kurumsal bir şirket çatısı altında geliştirilen olgun bir açık kaynak projesidir 1. Projenin açık kaynak topluluk sürümü (Community Edition), kurumsal sürümle aynı çekirdek eBPF telemetri omurgasını paylaşmaktadır.
Kod kalitesi ve sürüm yönetimi yüksek standartlara sahiptir. Çekirdek depoya sunulan PR’lar sıkı eBPF bytecode doğrulayıcı testlerinden, çoklu Linux çekirdek sürüm matrisinden ve Kubernetes entegrasyon testlerinden geçer. Dış katkıların çekirdek bellek sınırlarını ve eBPF verifier kurallarını ihlal etmemesi otomatik CI süreçleriyle güvenceye alınır. Geliştirici ekibi açık issue kayıtlarına son derece hızlı dönüş yapmakta, topluluktan gelen hata bildirimleri ve protokol ayrıştırıcı talepleri şeffaf bir şekilde ele alınmaktadır. Sürüm notları her güncellemede ClickHouse şema optimizasyonlarını, yeni L7 protokol desteklerini ve eBPF bellek sınırlandırmalarını ayrıntılı olarak belgeler 4. Maintainer ekibi, karmaşık dağıtık sistem mimarilerinden gelen geri bildirimleri doğrudan yol haritasına yansıtarak topluluk odaklı bir mühendislik kültürü yürütmektedir. health_score bu bölümden türer: issue kapanma hızı, sürüm düzeni, bakımcı ekibi. Ajanın tahminidir; künyede öyle yazılır. Projenin aktif bakım döngüsü, düşük hata kapanma süresi ve kararlı sürüm temposu dikkate alınarak mimari güvenilirlik skoru health_score: 8.7 olarak takdir edilmiştir.
Production Riski: Gerçekten Kullanılır mı?
Coroot’u üretim ortamına dahil etmeyi planlayan bir sistem mimarının operasyonel sınırları ve mimari ödünleşimleri iyi analiz etmesi gerekir. Lisanslama tarafında kurumsal risk bulunmamaktadır; projenin topluluk sürümü temiz bir Apache 2.0 lisansı ile dağıtılmaktadır ve şirket içi kullanımda herhangi bir kısıtlama içermez 5.
Coroot’un üretimde hayat kurtardığı senaryo, yüzlerce mikroservisin farklı dillerde (Go, Java, Node.js, Python, Rust) yazıldığı ve her servise ayrı ayrı APM SDK’sı entegre etmenin aylar süreceği heterojen Kubernetes kümeleridir. Sıfır kod dokunuşuyla birkaç dakikada tüm servis bağımlılık grafiğini çıkarmak ve veritabanı darboğazlarını nokta atışı yakalamak benzersiz bir operasyonel avantajdır.
Bununla birlikte, iki temel teknik kısıt göz önünde bulundurulmalıdır. İlk kısıt, şifrelenmiş TLS/HTTPS trafiğidir. eBPF soket kancaları işletim sistemi çekirdeğindeki ham baytları dinlediğinden, servisler arası mTLS veya doğrudan uygulama içi şifreleme kullanıldığında L7 protokol başlıkları düz metin olarak görülemez; bu durumlarda servis haritası L4 TCP seviyesinde kalır veya uprobe ile kullanıcı alanı kripto kütüphanelerine (OpenSSL gibi) kanca atmak gerekir ki bu da ek işlemci yükü demektir. İkinci kısıt ise çekirdek uyumluluğudur. BTF ve modern eBPF özelliklerinden tam verim alabilmek için kümedeki işçi düğümlerinin en az Linux 5.4 veya tercihen Linux 5.10+ çekirdeğine sahip olması ve ajana CAP_BPF ile CAP_NET_ADMIN yetkilerinin verilmesi zorunludur. Doğru yapılandırıldığında ise geleneksel APM araçlarının maliyet ve bakım yükünü sıfırlayan olağanüstü bir çözümdür.