Modern Linux Gözlemlenebilirliği (Observability): Debugging'den Sistem Düşüncesine Geçiş

Linux sistem programlama ve “low-level debugging” (derinlemesine hata ayıklama) üzerine çıktığımız bu uzun, teknik ve yer yer dolambaçlı yolculuğun son durağına hoş geldiniz.

Bu seriye başladığımızda, elimizde sadece paslı bir anahtar olan strace vardı. Onunla dosyaların kapısını zorladık, izinleri kontrol ettik. Ağ kablolarının içine sızıp paketleri dinledik. Sonra mikroskobumuzu (ltrace) çıkarıp uygulamaların beynine, User Space fonksiyonlarına girdik. En son ise bir “nükleer tıp” uzmanı titizliğiyle, eBPF teknolojisini kullanarak canlı sisteme neşter vurmadan MR çektik.

Şimdi ise sizden, masadaki tüm o cerrahi aletleri (strace, tcpdump, perf, gdb) bir kenara bırakmanızı istiyorum. Eldivenlerinizi çıkarın. Geriye yaslanın. Çünkü artık bir Teknisyen gibi değil, bir Mimar gibi düşünme zamanı.

Artık olaylara mikroskobik düzeyde (tek bir syscall, tek bir paket) bakmayı bırakıp, makroskobik düzeyde (sistemin genel sağlığı ve davranışları) bakmayı öğreneceğiz. Bu yazıda, “Bu süreç neden öldü?” (Debugging) sorusundan, “Bu sistem gerçekten sağlıklı mı?” (Observability) sorusuna nasıl evrileceğimizi konuşacağız. Bir sorunu çözmek ile o sorunun neden var olduğunu anlamak arasındaki devasa uçuruma bakacağız.

Eğer kariyerinizde “Senior” veya “Staff” mühendis olma hedefiniz varsa, bu yazı teknik komutlardan çok, o komutları ne zaman, nasıl ve neden kullanacağınızla ilgili zihinsel bir devrim niteliğindedir.

🕵️‍♂️ 1. Temel Ayrım: Debugging vs Observability

Sektörde bu iki terim sıklıkla birbirine karıştırılır, hatta eş anlamlı gibi kullanılır. Ama aralarında felsefi ve pratik olarak gece ile gündüz kadar fark vardır.

Debugging (Hata Ayıklama)

Debugging, bir dedektiflik işidir. (Sherlock Holmes) Elinizde bir ceset (Crash / Core Dump) veya somut bir şikayet (Müşteri Ticket’ı) vardır. Olay gerçekleşmiştir. Fail bellidir ya da aranmaktadır. Siz olay yerine gidersiniz, parmak izi ararsınız (grep ERROR), tanıkları sorgularsınız (strace), suçluyu bulup cezalandırırsınız (bugfix veya kill).

• Doğası: Reaktiftir (Tepkiseldir). Olay olduktan sonra başlar.
• Soru Bellidir: “Neden çöktü?”, “Neden yavaşladı?”, “Neden hata verdi?” (Known Unknowns - Bilinen Bilinmeyenler).
• Kapsamı Dardır: Genelde tek bir süreç, tek bir sunucu veya tek bir fonksiyon odaklıdır.

Observability (Gözlemlenebilirlik)

Observability, bir şehir planlamacısı veya Matrix’in Mimarı olmaktır. Olay henüz gerçekleşmemiştir veya gerçekleşiyorsa bile siz tek bir sokağa değil, şehrin tümüne hakimsinizdir. Dedektif gibi tek bir ipucunun peşinde değil, şehrin tüm kamera, trafik, elektrik ve su şebekesi verilerinin aktığı dev ekranların başındasınızdır.

• Doğası: Proaktiftir (Öngörülüdür). Sorun çıkmadan önce veya sorun anında bütünü gösterir.
• Soru Belirsizdir: “Sistemde şu an, şu saniyede garip giden ne var?” (“Unknown Unknowns” - Bilinmeyen Bilinmeyenler).
• Kapsamı Geniştir: Tüm sistemi (Kernel, Disk, Ağ, Uygulama, Dağıtık Servisler) canlı bir organizma, bir bütün olarak ele alır.

💡 Analoji: Debugging, arabanız bozulup dumanlar çıkardığında kaputu açıp “Hangi kablo yandı?” diye bakmaktır. Monitoring, arabanın panelindeki “Motor Arıza Lambası”nın yanmasıdır. Size sadece “Bir sorun var” der. Observability, arabanızda giderken ön panelde anlık motor sıcaklığını, lastik basıncını, yağ viskozitesini ve devir sayısını sürekli görmektir. Duman çıkmadan 10 dakika önce “Motor sıcaklığı normalin %5 üzerine çıktı ve yağ basıncı düşüyor, 5 km sonra motor şişebilir” diyebilmektir.

🧱 2. Süreç Odaklılıktan Sistem Odaklılığına

Kariyerinin başındaki bir sistemci (Junior/Mid), doğal olarak Süreç (Process) odaklıdır. Eğitimi ve tecrübesi ona bunu öğretmiştir:

• “Apache servisi çalışmıyor, loglarına bak.”
• “MySQL çok RAM yiyor, config dosyasını incele.”
• “Python scriptim hata verdi, kodunu debug et.”

Bu bakış açısı, elinizde strace ve gdb varken işe yarar. Tekil sorunları harika çözersiniz. Ama modern dünyada (Microservices, Kubernetes, Distributed Cloud Architectures), sorunlar nadiren tek bir süreçte başlar ve biter.

Kelebek Etkisi (The Butterfly Effect)

Bir e-ticaret sitesinde ödeme sayfasının (%1 ihtimalle) 5 saniye geciktiğini (Latency Spike) düşünün.

1. Süreç Odaklı Debugging: Ödeme servisine (Payment Service) bakarsınız. CPU %10. Kod hatası yok. Log temiz. “Sorun yok” dersiniz. Ama müşteri hala bekliyor.
2. Sistem Odaklı Observability: Staff Engineer, sisteme kuş bakışı bakar ve şunu görür: “Evet, ödeme servisi (Process) sağlıklı. Ama bu servisin çalıştığı sunucuda (Node), tamamen alakasız bir ‘Log Backup’ işlemi çalışıyor. Bu işlem diski o kadar meşgul ediyor ki (iowait), Kernel’ın I/O kuyruğu şişmiş. Ödeme servisi CPU beklemiyor, diske 1 KB log yazabilmek için Disk I/O Slot’u bekliyor.”

İşte bu, top komutundaki %wa (I/O Wait) değerini veya perf çıktısındaki kernel fonksiyonlarını (Block Layer) okuyabilme becerisidir. Tek bir ağaca değil, ormana (Ekosisteme, Node’un kendisine, Kernel’ın Scheduler’ına, Resource Contention’a) bakmaktır. “Noisy Neighbor” (Gürültülü Komşu) problemini ancak sistem odaklı düşünerek çözebilirsiniz.

🔬 3. Metodolojiler: USE ve RED

Peki, yüzlerce sunucu ve binlerce metrik arasında kaybolmadan doğru yere nasıl bakacağız? Rastgele top veya htop açmak amatörlüktür. Profesyonellerin metodolojileri vardır.

A. USE Metodu (Utilization, Saturation, Errors)

Netflix performans gurusu Brendan Gregg tarafından geliştirilen bu metod, Altyapı (Infrastructure) analizi için kullanılır. Bir sisteme (CPU, Disk, RAM, Ağ) yaklaştığınızda şu 3 soruyu sorarsınız:

1. Utilization (Kullanım): Kaynak ne kadar meşgul? (Örn: CPU %90). %100 utilization her zaman kötü değildir, verimli kullanıldığını da gösterebilir.
2. Saturation (Doygunluk/Sıkışıklık): Sırada bekleyen var mı? İşte kilit nokta budur. CPU %100 olabilir ama kuyrukta bekleyen yoksa işler yürüyordur. Ama CPU %50 iken, “Load Average” 20 ise (yani işlemci boşta olsa bile 20 süreç çalışmak için sıra bekliyorsa), sistem kilitlenmiştir.
3. Errors (Hatalar): Donanım veya sürücü seviyesinde fiziksel hata var mı? (Örn: Disk errors, Network packet drops).

B. RED Metodu (Rate, Errors, Duration)

Tom Wilkie tarafından geliştirilen bu metod ise Servisler (Services / Microservices) için kullanılır.

1. Rate (Hız): Saniyede kaç istek geliyor? (RPS - Requests Per Second). Trafik artışı var mı?
2. Errors (Hatalar): İsteklerin yüzde kaçı 5xx hatasıyla dönüyor?
3. Duration (Süre): İsteklerin cevaplanması ne kadar sürüyor? (Latency). Özellikle 99. yüzdelik dilim (P99) nedir?

Bir sistemci olarak, altyapıya USE, üzerindeki servislere RED metoduyla yaklaşırsanız, sorunun kaynağını dakikalar içinde izole edebilirsiniz.

🛠️ 4. Üç Sütun (Three Pillars) ve Linux Karşılıkları

Modern dünyada Observability denince akla Logs, Metrics, Traces gelir. Bunlar genelde pahalı SaaS ürünleriyle (Datadog, New Relic) özdeşleşir. Ama özünde bunlar Linux Kernel’ından çıkan basit verilerdir.

A. Logs (Kayıtlar) - “Ne Oldu?”

Bir olay gerçekleşir ve (genelde metin olarak) diske yazılır.

• High Level: ELK Stack (Elasticsearch), Splunk, Graylog.
• Low Level: journalctl -xe, /var/log/syslog, /var/log/dmesg, Uygulama logları (tail -f).
• Risk: Loglar pahalıdır. Her DEBUG logu diske I/O yükü bindirir, CPU harcar, ağ trafiği yaratır. Loglar sadece “bilinen (kodlanmış) hataları” gösterir. Yazılımcı if (error) log("Hata") yazmadıysa, o hatayı loglarda asla göremezsiniz.

B. Metrics (Metrikler) - “Şu an Durum Ne?”

Zaman içinde değişen sayılardır (Time-Series Data). Depolaması çok ucuzdur.

• High Level: Prometheus, Grafana, VictoriaMetrics.
• Low Level: /proc dosya sistemi.
  • /proc/meminfo: RAM kullanımı.
  • /proc/stat: CPU sayaçları.
  • /sys/class/net/eth0/statistics: Ağ kartı paket sayaçları.
• Modern eBPF araçları, bu metrikleri Kernel’dan (syscall’lardan) minimum maliyetle çekip Prometheus formatına dönüştürür.

C. Traces (İzler) - “Nereye Gitti?”

Bir isteğin sistemdeki veya sistemler arası yaşam döngüsü.

• High Level: Jaeger, Zipkin, OpenTelemetry (Distributed Tracing).
• Low Level: strace (System Call Tracing), tcpdump (Network Packet Tracing), perf (CPU Profiling).
• Trace’ler, “Neden yavaş?” sorusunun cevabını verir. “İstek geldi, 2 saniye DNS’te bekledi, 50ms veritabanında bekledi, 3 saniye de diskin dönmesini bekledi” gibi detaylı haritayı çıkarır.

🧠 5. “Unknown Unknowns” (Bilinmeyen Bilinmeyenler)

Debugging, “Bilinen Bilinmeyenleri” (Known Unknowns) çözmektir: “Web sunucusu yavaş (Bu biliniyor), ama nedenini bilmiyorum (Bu bilinmiyor).”

Observability ise “Bilinmeyen Bilinmeyenleri” (Unknown Unknowns) keşfetmektir. Siz ofiste kahvenizi içerken, hiçbir müşteri şikayeti yokken, hiçbir alarm çalmazken dashboard’a bakıp şunu diyebilmelisiniz: “Bir dakika… Neden her Salı saat 14:00’te Kernel’ın TCP Retransmission sayacı %0.5 artıyor? Müşteri fark etmiyor, latency artmıyor ama burada gizli bir ağ paket kaybı var.”

İşte bu, Staff Engineer bakış açısıdır. Yangın çıkmasını beklemez. Duman dedektörünün pilini kontrol eder. Kabloların ısınmasını fark eder. Kriz gelmeden krizi önler.

🧩 6. Vaka Analizi: Görünmez Duvara Toslamak

Gerçek bir hikaye ile parçaları birleştirelim. Bir ödeme sistemi API’si, rastgele zamanlarda (haftada 1-2 kez) “Timeout” (Zaman Aşımı) hatası veriyor. Loglarda (“Logs”) hiçbir hata yok. Exception yok. Metrics tarafında CPU %40, RAM %60. Gayet normal. Senior SRE ekibi “Debugging” modundan “Observability” moduna geçiyor.

1. Şüpheli: Uygulama kodu mu?
   • strace (Sampling) ile bakıyorlar. Timeout anında uygulama poll çağrısında bekliyor. Yani uygulama “Ben hazırım, bana sıra gelsin” diyor. Suçlu kod değil.
2. Şüpheli: Sistem kaynakları mı?
   • Prometheus (Metrics) verilerine detaylı bakılıyor. Timeout anlarında sunucudaki “Context Switch” sayısının fırladığı görülüyor (Saturation ilkesi).
3. Teşhis (Derin Dalış - eBPF):
   • runqlen (BCC aracı) veya perf sched kullanılarak Kernel’ın CPU kuyruğu (Scheduler Queue Length) izleniyor.
   • Görülüyor ki, tam o timeout anlarında sistemde binlerce minik, kısa ömürlü Cron job (Monitor scriptleri, yedekleme ajanları) aynı anda çalışıyor.
4. Sonuç:
   • Ödeme uygulaması CPU’da çalışmak istiyor ama sırada (Run Queue) o kadar çok minik süreç var ki, Kernel sıra ona gelene kadar 50 milisaniye (Scheduling Latency) geçiyor.
   • Uygulamanın timeout süresi çok düşük olduğu için bu gecikme hataya dönüşüyor.

Çözüm: Cron job’ların saatini dağıtmak ve cgroups (CPU Shares) ile ödeme uygulamasına Kernel seviyesinde “High Priority” vermek. Bu sorunu tail -f error.log yaparak veya Java kodunu debug ederek ASLA bulamazdınız. Sisteme, Kernel Scheduler’a ve Scheduler Latency kavramına hakim olarak buldunuz.

👋 7. Son Söz: Linux Senin Takım Arkadaşın

Bu blog serisini buraya kadar okuduysanız, tebrik ederim. Artık Linux terminaline baktığınızda sadece yanıp sönen bir imleç veya siyah bir ekran görmüyorsunuz. Arka planda dönen devasa dişlileri, akan nehirleri (Streams), bekleyen dosya tanımlayıcılarını (FD), birbirine fısıldayan sinyalleri (Signals) ve her şeyi kaydeden o muazzam muhasebeciyi (Kernel) görüyorsunuz.

Linux, korkulacak, ezberlenecek komutlardan oluşan bir kara kutu değildir. Verdiği o soğuk hatalar (ENOENT, EACCES, EPIPE, OOM Killed) sizi engellemek için değil, size yol göstermek için oradadır. Hata mesajları, Kernel’ın “Bak burada bir şeyler ters gidiyor” deme şeklidir.

Artık:

• strace ile o fısıltıları duyabilirsiniz.
• ltrace ile kelimeleri anlayabilirsiniz.
• perf ve eBPF ile o çığlık atılmadan önce hissedebilirsiniz.
• Ve Observability zihniyetiyle, tüm bu seslerden anlamlı bir senfoni çıkarabilirsiniz.

Sistem mühendisliği (veya SRE/DevOps), sadece araçları bilmek değildir. Araçları kullanarak, kaosun içinde bir düzen (Pattern) bulma sanatıdır. Verinin içindeki hikayeyi okuma sanatıdır.

Yolculuğunuz burada bitmiyor. Aslında yeni başlıyor. Artık Root yetkisine sadece dosya sisteminde (sudo) değil, zihinsel olarak da sahipsiniz.

Kazasız belasız deploy’lar, yüksek uptime’lar, düşük latency’ler ve bol “Insight”lı günler dilerim. Hoşçakalın.