Bir sunucu aniden yan\u0131t vermeyi mi kesti? Uygulaman\u0131z sebepsiz yere yava\u015flad\u0131 m\u0131 veya beklenmedik hatalar m\u0131 f\u0131rlatt\u0131? Linux sistemlerde kar\u015f\u0131la\u015f\u0131lan bu t\u00fcr sorunlar, genellikle tam bir \u00e7ekirdek pani\u011fi (kernel panic) olmasa da, m\u00fchendisler i\u00e7in ciddi bir “panik” an\u0131na d\u00f6n\u00fc\u015febilir. Bu makale, karma\u015f\u0131k uygulama y\u0131\u011f\u0131nlar\u0131n\u0131n (great stack) Linux ortamlar\u0131nda neden “\u00e7al\u0131\u015fmaz” hale geldi\u011fini, bu t\u00fcr durumlar\u0131n k\u00f6kenlerini anlaman\u0131za ve \u00e7\u00f6z\u00fcm yollar\u0131 bulman\u0131za yard\u0131mc\u0131 olacak pratik bilgiler sunacakt\u0131r.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda “b\u00fcy\u00fck y\u0131\u011f\u0131nlar” (great stacks) terimi, genellikle birden fazla teknolojinin, servisin ve uygulaman\u0131n bir araya gelerek belirli bir i\u015flevi yerine getirdi\u011fi karma\u015f\u0131k sistem mimarilerini ifade eder. Bu y\u0131\u011f\u0131nlar, web sunucular\u0131ndan veritabanlar\u0131na, \u00f6nbellekleme katmanlar\u0131ndan mesaj kuyruklar\u0131na kadar geni\u015f bir yelpazeyi kapsar ve genellikle Linux i\u015fletim sistemi \u00fczerinde \u00e7al\u0131\u015f\u0131r. Ancak bu karma\u015f\u0131kl\u0131k, beraberinde beklenmedik davran\u0131\u015flar ve te\u015fhisi zor sorunlar getirebilir. Bir uygulaman\u0131n aniden yava\u015flamas\u0131, bir servisin \u00e7\u00f6kmesi veya sistemin genel yan\u0131t s\u00fcresinin artmas\u0131 gibi durumlar, bir \u00e7ekirdek pani\u011fi kadar dramatik olmasa da, m\u00fchendisler i\u00e7in en az onun kadar stresli olabilir.<\/p>\n
Bu t\u00fcr “m\u00fchendis panikleri”nin temelinde genellikle birka\u00e7 ana neden yatar. \u0130lk olarak, kaynak t\u00fcketimi sorunlar\u0131 \u00f6ne \u00e7\u0131kar. Bellek s\u0131z\u0131nt\u0131lar\u0131 (memory leaks), bir uygulaman\u0131n zamanla gere\u011finden fazla bellek kullanmas\u0131na ve sonunda sistem kaynaklar\u0131n\u0131 t\u00fcketmesine yol a\u00e7abilir. Ayn\u0131 \u015fekilde, y\u00fcksek CPU kullan\u0131m\u0131, sonsuz d\u00f6ng\u00fcler, verimsiz algoritmalar veya a\u015f\u0131r\u0131 i\u015f y\u00fck\u00fc nedeniyle ortaya \u00e7\u0131kabilir. Disk G\/\u00c7 (I\/O) darbo\u011fazlar\u0131 ise, veritaban\u0131 i\u015flemleri, g\u00fcnl\u00fck yazma (logging) veya dosya okuma\/yazma yo\u011fun uygulamalarda performans\u0131 ciddi \u015fekilde etkileyebilir. Bu durumlar, sistemin genel yan\u0131t verme h\u0131z\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr ve kullan\u0131c\u0131 deneyimini olumsuz etkiler.<\/p>\n
\u0130kinci olarak, yanl\u0131\u015f yap\u0131land\u0131rmalar (misconfigurations) b\u00fcy\u00fck bir sorun kayna\u011f\u0131d\u0131r. Bir uygulama sunucusunun, veritaban\u0131 ba\u011flant\u0131 havuzunun veya i\u015fletim sistemi parametrelerinin yanl\u0131\u015f ayarlanmas\u0131, sistemin karars\u0131z \u00e7al\u0131\u015fmas\u0131na neden olabilir. \u00d6rne\u011fin, a\u00e7\u0131k dosya tan\u0131mlay\u0131c\u0131 (file descriptor) limitlerinin d\u00fc\u015f\u00fck olmas\u0131, y\u00fcksek e\u015fzamanl\u0131 ba\u011flant\u0131 gerektiren web sunucular\u0131n\u0131n yeni ba\u011flant\u0131lar\u0131 kabul edememesine yol a\u00e7abilir. Benzer \u015fekilde, g\u00fcvenlik duvar\u0131 (firewall) kurallar\u0131n\u0131n yanl\u0131\u015f yap\u0131land\u0131r\u0131lmas\u0131, servisler aras\u0131 ileti\u015fimi engelleyebilir veya d\u0131\u015far\u0131dan eri\u015fimi kesintiye u\u011fratabilir. Bu t\u00fcr sorunlar, genellikle ilk bak\u0131\u015fta belirgin de\u011fildir ve detayl\u0131 inceleme gerektirir.<\/p>\n
\u00dc\u00e7\u00fcnc\u00fc olarak, a\u011f ve ba\u011flant\u0131 sorunlar\u0131, da\u011f\u0131t\u0131k sistemlerde s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir problemdir. DNS \u00e7\u00f6z\u00fcmleme hatalar\u0131, a\u011f gecikmeleri, paket kayb\u0131 veya yanl\u0131\u015f y\u00f6nlendirme (routing) kurallar\u0131, uygulamalar aras\u0131ndaki ileti\u015fimi bozabilir. Bir mikroservisin ba\u015fka bir mikroservise ula\u015famamas\u0131 veya bir veritaban\u0131 sunucusuna ba\u011flant\u0131 kurulamamas\u0131, t\u00fcm y\u0131\u011f\u0131n\u0131n i\u015flevselli\u011fini sekteye u\u011fratabilir. Bu t\u00fcr durumlar, genellikle a\u011f katman\u0131nda derinlemesine bir analiz gerektirir ve basit bir Son olarak, uygulama katman\u0131ndaki hatalar ve beklenmedik davran\u0131\u015flar, “m\u00fchendis pani\u011fi”nin en yayg\u0131n nedenlerindendir. Bir yaz\u0131l\u0131m hatas\u0131 (bug), bir istisna (exception) veya veritaban\u0131 kilitlenmeleri (deadlocks), uygulaman\u0131n \u00e7\u00f6kmesine veya hatal\u0131 sonu\u00e7lar \u00fcretmesine neden olabilir. Bu t\u00fcr sorunlar, genellikle uygulama g\u00fcnl\u00fckleri (application logs) ve hata ay\u0131klama (debugging) ara\u00e7lar\u0131 kullan\u0131larak tespit edilir. Bu ba\u011flamda, \u00e7ekirdek pani\u011fi, i\u015fletim sisteminin kendisinin kritik bir hata nedeniyle durmas\u0131 anlam\u0131na gelirken, “m\u00fchendis pani\u011fi”, i\u015fletim sistemi \u00e7al\u0131\u015fmaya devam etse bile, \u00fczerindeki uygulaman\u0131n veya servislerin beklendi\u011fi gibi \u00e7al\u0131\u015fmamas\u0131 durumudur. Bu ayr\u0131m, sorun giderme s\u00fcrecini do\u011fru y\u00f6nlendirmek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Linux sistemlerde kar\u015f\u0131la\u015f\u0131lan “m\u00fchendis pani\u011fi” durumlar\u0131n\u0131n b\u00fcy\u00fck bir k\u0131sm\u0131, sistem kaynaklar\u0131n\u0131n verimsiz veya a\u015f\u0131r\u0131 kullan\u0131m\u0131yla ilgilidir. Bellek (RAM), Merkezi \u0130\u015flem Birimi (CPU) ve Disk G\/\u00c7 (I\/O) performans\u0131, bir uygulaman\u0131n veya t\u00fcm sistem y\u0131\u011f\u0131n\u0131n\u0131n sorunsuz \u00e7al\u0131\u015fmas\u0131 i\u00e7in hayati \u00f6neme sahiptir. Bu kaynaklar\u0131n nas\u0131l izlenece\u011fini ve olas\u0131 sorunlar\u0131n nas\u0131l \u00e7\u00f6z\u00fclece\u011fini anlamak, bir\u00e7ok ba\u015f a\u011fr\u0131s\u0131n\u0131 \u00f6nleyebilir.<\/p>\n Bellek s\u0131z\u0131nt\u0131s\u0131, bir program\u0131n ayr\u0131lm\u0131\u015f belle\u011fi serbest b\u0131rakmamas\u0131 ve zamanla giderek daha fazla bellek t\u00fcketmesi durumudur. Bu durum, sonunda sistemin yava\u015flamas\u0131na, di\u011fer uygulamalar\u0131n kilitlenmesine veya hatta sistemin tamamen donmas\u0131na neden olabilir. Bellek kullan\u0131m\u0131n\u0131 izlemek i\u00e7in \u00e7e\u015fitli komutlar mevcuttur:<\/p>\n E\u011fer bir bellek s\u0131z\u0131nt\u0131s\u0131 tespit edilirse, uygulama kodunun incelenmesi ve hata ay\u0131klama ara\u00e7lar\u0131 (\u00f6rne\u011fin, C\/C++ i\u00e7in Valgrind, Java i\u00e7in JProfiler) kullan\u0131larak s\u0131z\u0131nt\u0131n\u0131n kayna\u011f\u0131n\u0131n bulunmas\u0131 gerekir. Ge\u00e7ici bir \u00e7\u00f6z\u00fcm olarak, bellek s\u0131z\u0131nt\u0131s\u0131 yapan uygulaman\u0131n periyodik olarak yeniden ba\u015flat\u0131lmas\u0131 d\u00fc\u015f\u00fcn\u00fclebilir, ancak bu kal\u0131c\u0131 bir \u00e7\u00f6z\u00fcm de\u011fildir.<\/p>\n Y\u00fcksek CPU kullan\u0131m\u0131, bir veya birden fazla s\u00fcrecin i\u015flemci kaynaklar\u0131n\u0131 yo\u011fun bir \u015fekilde kullanmas\u0131 anlam\u0131na gelir. Bu, sistemin genel yan\u0131t s\u00fcresini d\u00fc\u015f\u00fcrebilir ve di\u011fer g\u00f6revlerin performans\u0131n\u0131 olumsuz etkileyebilir. CPU kullan\u0131m\u0131n\u0131 izlemek i\u00e7in:<\/p>\n Yukar\u0131daki \u00f6rnekte, Disk G\/\u00c7 (Input\/Output) darbo\u011fazlar\u0131, bir uygulaman\u0131n veya sistemin diskten veri okuma ve yazma h\u0131z\u0131n\u0131n yetersiz kalmas\u0131 durumunda ortaya \u00e7\u0131kar. Bu, \u00f6zellikle veritaban\u0131 sunucular\u0131, g\u00fcnl\u00fck sunucular\u0131 veya b\u00fcy\u00fck dosyalarla \u00e7al\u0131\u015fan uygulamalar i\u00e7in kritik bir performans sorunudur. Disk I\/O’yu izlemek i\u00e7in:<\/p>\n Yukar\u0131daki \u00f6rnekte, Bu ara\u00e7lar ve teknikler, Linux sistemlerdeki kaynak t\u00fcketimi sorunlar\u0131n\u0131 te\u015fhis etmek ve gidermek i\u00e7in ilk ad\u0131mlar\u0131 olu\u015fturur. Unutulmamal\u0131d\u0131r ki, sorun giderme s\u00fcreci genellikle bir detektiflik i\u015fidir ve birden fazla arac\u0131n bir arada kullan\u0131lmas\u0131, sorunun k\u00f6k nedenini bulmada daha etkili sonu\u00e7lar verir.<\/p>\n Da\u011f\u0131t\u0131k sistemler ve mikroservis mimarileri g\u00fcn\u00fcm\u00fczde olduk\u00e7a yayg\u0131n. Bu yap\u0131lar, bile\u015fenlerin birbirleriyle a\u011f \u00fczerinden ileti\u015fim kurmas\u0131na dayan\u0131r. Dolay\u0131s\u0131yla, a\u011f ve ba\u011flant\u0131 problemleri, “b\u00fcy\u00fck y\u0131\u011f\u0131nlar\u0131n” \u00e7al\u0131\u015fmamas\u0131na neden olan en sinsi ve te\u015fhisi zor sorunlardan biri olabilir. Bir uygulaman\u0131n ba\u015fka bir servise ula\u015famamas\u0131, yava\u015f yan\u0131t s\u00fcreleri veya tamamen ba\u011flant\u0131 kesintileri, m\u00fchendisler i\u00e7in ciddi bir ba\u015f a\u011fr\u0131s\u0131d\u0131r. Bu b\u00f6l\u00fcmde, a\u011f sorunlar\u0131n\u0131 nas\u0131l tespit edece\u011finizi ve \u00e7\u00f6zece\u011finizi inceleyece\u011fiz.<\/p>\n A\u011f sorunlar\u0131 genellikle birka\u00e7 katmanda ortaya \u00e7\u0131kabilir: DNS \u00e7\u00f6z\u00fcmlemesi, g\u00fcvenlik duvar\u0131 kurallar\u0131, a\u011f aray\u00fcz\u00fc yap\u0131land\u0131rmas\u0131, y\u00f6nlendirme (routing) tablolar\u0131 veya fiziksel ba\u011flant\u0131 sorunlar\u0131. \u0130\u015fte bu sorunlar\u0131 te\u015fhis etmek i\u00e7in kullanabilece\u011finiz temel ara\u00e7lar:<\/p>\n Yukar\u0131daki \u00f6rnekte, Apache web sunucusunun 80 numaral\u0131 portu ve MySQL veritaban\u0131n\u0131n 3306 numaral\u0131 portu dinledi\u011fi g\u00f6r\u00fclmektedir. E\u011fer bir uygulaman\u0131z bu portlara ba\u011flanam\u0131yorsa, bu \u00e7\u0131kt\u0131y\u0131 kontrol etmek, servisin ger\u00e7ekten \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 veya do\u011fru portu dinleyip dinlemedi\u011fini anlaman\u0131za yard\u0131mc\u0131 olur.<\/p>\n G\u00fcvenlik duvarlar\u0131 (firewalls) ve y\u00f6nlendirme tablolar\u0131, a\u011f trafi\u011fini kontrol eden \u00f6nemli bile\u015fenlerdir. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f bir g\u00fcvenlik duvar\u0131, me\u015fru trafi\u011fi engelleyerek uygulamalar aras\u0131 ileti\u015fimi kesebilir. Linux’ta genellikle Bir vaka analizi olarak, bir web uygulamas\u0131n\u0131n arka u\u00e7 (backend) veritaban\u0131na ba\u011flanamad\u0131\u011f\u0131 bir senaryoyu ele alal\u0131m. \u0130lk olarak Daha karma\u015f\u0131k a\u011f sorunlar\u0131 i\u00e7in Bu komut, Linux sistemlerdeki b\u00fcy\u00fck y\u0131\u011f\u0131nlar\u0131n beklenmedik \u015fekilde \u00e7al\u0131\u015fmamas\u0131na neden olan bir di\u011fer yayg\u0131n sorun kategorisi, uygulama ve sistem yap\u0131land\u0131rma hatalar\u0131d\u0131r. Bu hatalar, genellikle do\u011frudan bir \u00e7\u00f6kme yerine, uygulaman\u0131n yava\u015flamas\u0131na, belirli i\u015flevlerin \u00e7al\u0131\u015fmamas\u0131na veya sistemin karars\u0131z davran\u0131\u015flar sergilemesine yol a\u00e7ar. “Sessiz katiller” olarak adland\u0131rabilece\u011fimiz bu yap\u0131land\u0131rma hatalar\u0131, uzun s\u00fcre fark edilmeyebilir ve ancak belirli ko\u015fullar alt\u0131nda kendini g\u00f6sterir. Bu b\u00f6l\u00fcmde, bu t\u00fcr hatalar\u0131 nas\u0131l tespit edece\u011fimizi ve d\u00fczeltece\u011fimizi ele alaca\u011f\u0131z.<\/p>\n \u00c7o\u011fu uygulama, davran\u0131\u015f\u0131n\u0131 yap\u0131land\u0131rma dosyalar\u0131 (configuration files) arac\u0131l\u0131\u011f\u0131yla belirler. Bu dosyalar genellikle Ortam de\u011fi\u015fkenleri (environment variables) de uygulamalar\u0131n \u00e7al\u0131\u015fma zaman\u0131 davran\u0131\u015f\u0131n\u0131 etkileyen \u00f6nemli bir yap\u0131land\u0131rma mekanizmas\u0131d\u0131r. Yanl\u0131\u015f ayarlanm\u0131\u015f veya eksik bir ortam de\u011fi\u015fkeni, uygulaman\u0131n belirli bir kayna\u011f\u0131 bulamamas\u0131na veya yanl\u0131\u015f bir modda \u00e7al\u0131\u015fmas\u0131na neden olabilir. \u00d6rne\u011fin, Bu t\u00fcr sorunlar\u0131 te\u015fhis etmek i\u00e7in:<\/p>\n Linux’ta dosya ve dizin izinleri (permissions) ile sahiplikleri (ownership), sistem g\u00fcvenli\u011fi ve uygulama i\u015flevselli\u011fi i\u00e7in temeldir. Bir uygulaman\u0131n bir dosyay\u0131 okuma, yazma veya bir dizin olu\u015fturma izni olmad\u0131\u011f\u0131nda, beklenmedik hatalar ortaya \u00e7\u0131kar. Bu durum, \u00f6zellikle web sunucular\u0131 (Apache, Nginx) ve veritabanlar\u0131 (MySQL, PostgreSQL) i\u00e7in s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir sorundur.<\/p>\n Bir web uygulamas\u0131n\u0131n resimleri y\u00fckleyemedi\u011fi bir senaryoda, ilgili y\u00fckleme dizininin sahipli\u011fi ve yazma izinleri kontrol edilmelidir. Genellikle, web sunucusunun \u00e7al\u0131\u015ft\u0131\u011f\u0131 kullan\u0131c\u0131n\u0131n (\u00f6rne\u011fin, Modern Linux da\u011f\u0131t\u0131mlar\u0131n\u0131n \u00e7o\u011fu, sistem hizmetlerini (system services) y\u00f6netmek i\u00e7in Bu Yap\u0131land\u0131rma hatalar\u0131, genellikle k\u00fc\u00e7\u00fck detaylarda gizlidir ve dikkatli bir inceleme gerektirir. Otomasyon ara\u00e7lar\u0131 (Ansible, Chef, Puppet) kullanarak yap\u0131land\u0131rmalar\u0131n tutarl\u0131 olmas\u0131n\u0131 sa\u011flamak ve versiyon kontrol sistemleri ile t\u00fcm yap\u0131land\u0131rma dosyalar\u0131n\u0131 y\u00f6netmek, bu t\u00fcr “sessiz katillerin” \u00f6n\u00fcne ge\u00e7mek i\u00e7in en iyi stratejilerdendir.<\/p>\n “M\u00fchendis pani\u011fi” anlar\u0131nda, y\u00fczeydeki belirtiler yeterli olmad\u0131\u011f\u0131nda, sistemin derinliklerine inmek ve sorunlar\u0131n k\u00f6k nedenini bulmak i\u00e7in daha geli\u015fmi\u015f hata ay\u0131klama teknikleri ve ara\u00e7lar\u0131 kullanmak gerekir. Bu teknikler, uygulaman\u0131n i\u015fletim sistemiyle nas\u0131l etkile\u015fim kurdu\u011funu, hangi dosyalar\u0131 a\u00e7t\u0131\u011f\u0131n\u0131, hangi a\u011f ba\u011flant\u0131lar\u0131n\u0131 kurdu\u011funu ve \u00e7ekirde\u011fin (kernel) neler d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fc anlamam\u0131z\u0131 sa\u011flar. Bu b\u00f6l\u00fcmde, kritik anlarda ba\u015fvurabilece\u011finiz ileri d\u00fczey hata ay\u0131klama ara\u00e7lar\u0131n\u0131 ve y\u00f6ntemlerini inceleyece\u011fiz.<\/p>\n \u00d6rne\u011fin, bir uygulaman\u0131n belirli bir yap\u0131land\u0131rma dosyas\u0131n\u0131 bulamad\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Bir uygulaman\u0131n “Too many open files” (\u00c7ok fazla a\u00e7\u0131k dosya) hatas\u0131 verdi\u011fini varsayal\u0131m. E\u011fer bir uygulama aniden ve sebepsiz yere sonlan\u0131yorsa, Uygulama ve sistem g\u00fcnl\u00fckleri (logs), hata ay\u0131klaman\u0131n en temel ve \u00e7o\u011fu zaman en \u00f6nemli kayna\u011f\u0131d\u0131r. Modern Linux sistemlerinde Uygulama \u00e7\u00f6kmelerinde veya beklenmedik davran\u0131\u015flarda, ilgili hizmetin Bu derinlemesine hata ay\u0131klama teknikleri, y\u00fczeydeki belirtilerin \u00f6tesine ge\u00e7erek sorunlar\u0131n k\u00f6k nedenlerini bulman\u0131z\u0131 sa\u011flar. Karma\u015f\u0131k sistemlerde, tek bir araca g\u00fcvenmek yerine, farkl\u0131 ara\u00e7lar\u0131 bir arada kullanarak ve elde edilen verileri birle\u015ftirerek daha kapsaml\u0131 bir analiz yapmak, “m\u00fchendis pani\u011fini” y\u00f6netmenin anahtar\u0131d\u0131r.<\/p>\n Linux ortamlar\u0131nda “b\u00fcy\u00fck y\u0131\u011f\u0131nlar\u0131n” \u00e7al\u0131\u015fmamas\u0131 durumu, nadiren ger\u00e7ek bir \u00e7ekirdek pani\u011fiyle sonu\u00e7lansa da, bir m\u00fchendisin kar\u015f\u0131 kar\u015f\u0131ya kalabilece\u011fi en stresli senaryolardan biridir. Bu makalede, bellek s\u0131z\u0131nt\u0131lar\u0131ndan CPU darbo\u011fazlar\u0131na, a\u011f ba\u011flant\u0131 kesintilerinden yanl\u0131\u015f yap\u0131land\u0131rma dosyalar\u0131na kadar bir\u00e7ok yayg\u0131n sorunu ve bunlar\u0131n nas\u0131l te\u015fhis edilip \u00e7\u00f6z\u00fclece\u011fini ele ald\u0131k. G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, sorunlar genellikle tek bir nedene ba\u011fl\u0131 olmay\u0131p, sistemin farkl\u0131 katmanlar\u0131ndaki etkile\u015fimlerden kaynaklan\u0131r. Kaynak y\u00f6netimi, a\u011f ileti\u015fimi, dosya sistemi izinleri ve uygulama yap\u0131land\u0131rmalar\u0131, bir b\u00fct\u00fcn olarak incelenmelidir.<\/p>\n Bu t\u00fcr “m\u00fchendis panikleri”ni en aza indirmek ve daha etkin bir \u015fekilde y\u00f6netmek i\u00e7in proaktif stratejiler benimsemek hayati \u00f6nem ta\u015f\u0131r. \u00d6ncelikle, kapsaml\u0131 izleme (monitoring) sistemleri kurmak, potansiyel sorunlar\u0131 daha ortaya \u00e7\u0131kmadan \u00f6nce tespit etmenizi sa\u011flar. Bellek, CPU, disk I\/O ve a\u011f trafi\u011fi gibi temel metriklerin yan\u0131 s\u0131ra, uygulama katman\u0131 metriklerini de izlemek, anormallikleri erken fark etmek i\u00e7in kritik \u00f6neme sahiptir. Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana) gibi ara\u00e7lar, bu konuda size b\u00fcy\u00fck fayda sa\u011flayabilir.<\/p>\n \u0130kinci olarak, yap\u0131land\u0131rma y\u00f6netimi ve otomasyon, tutars\u0131zl\u0131klar\u0131 ve insan hatalar\u0131n\u0131 azaltmada kilit rol oynar. Ansible, Chef, Puppet gibi ara\u00e7larla sistem yap\u0131land\u0131rmalar\u0131n\u0131 kod olarak (Infrastructure as Code) y\u00f6netmek, t\u00fcm sunucular\u0131n\u0131zda standart ve hatas\u0131z bir yap\u0131land\u0131rma sa\u011flar. Bu, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k y\u0131\u011f\u0131nlarda tutarl\u0131l\u0131\u011f\u0131 korumak i\u00e7in vazge\u00e7ilmezdir. Ayr\u0131ca, t\u00fcm yap\u0131land\u0131rma dosyalar\u0131n\u0131 versiyon kontrol sistemlerinde (Git) tutmak, yap\u0131lan de\u011fi\u015fiklikleri izlemenizi ve gerekti\u011finde geri alman\u0131z\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc olarak, kapsaml\u0131 g\u00fcnl\u00fckleme (logging) ve g\u00fcnl\u00fck analizi, sorun giderme s\u00fcrecinin temelidir. Uygulamalar\u0131n\u0131z\u0131n yeterli detay seviyesinde (INFO, DEBUG, ERROR) g\u00fcnl\u00fck tuttu\u011fundan emin olun ve bu g\u00fcnl\u00fckleri merkezi bir yerde toplayarak kolayca aranabilir hale getirin. Son olarak, d\u00fczenli testler ve felaket kurtarma (disaster recovery) senaryolar\u0131n\u0131n prova edilmesi, beklenmedik durumlar i\u00e7in haz\u0131rl\u0131kl\u0131 olman\u0131z\u0131 sa\u011flar. Y\u00fck testleri (load testing), stres testleri ve hata enjeksiyonu (fault injection) gibi teknikler, sisteminizin zay\u0131f noktalar\u0131n\u0131 \u00f6nceden belirlemenize yard\u0131mc\u0131 olur. Bu sayede, ger\u00e7ek bir \u00fcretim ortam\u0131nda kar\u015f\u0131la\u015faca\u011f\u0131n\u0131z sorunlara kar\u015f\u0131 daha diren\u00e7li bir sistem in\u015fa edebilirsiniz.<\/p>\n Unutmay\u0131n, Linux’ta sorun giderme bir sanatt\u0131r ve deneyimle geli\u015fir. Her yeni problem, \u00f6\u011frenme ve sisteminizi daha iyi anlama f\u0131rsat\u0131d\u0131r. Bu makalede sunulan ara\u00e7lar ve teknikler, bu yolculukta size rehberlik edecek bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. Sistematik bir yakla\u015f\u0131m, sab\u0131r ve do\u011fru ara\u00e7lar\u0131 kullanma becerisi, en karma\u015f\u0131k “m\u00fchendis paniklerini” bile y\u00f6netilebilir bir hale getirecektir.<\/p>\n Bu b\u00f6l\u00fcmde, Linux sistemlerdeki sorun giderme s\u00fcre\u00e7leriyle ilgili en \u00e7ok merak edilen sorular\u0131 ve cevaplar\u0131n\u0131 bulacaks\u0131n\u0131z.<\/p>\n Cevap:<\/strong> Cevap:<\/strong> Bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 tespit etmek i\u00e7in Cevap:<\/strong> Sorun gidermede en temel Linux ara\u00e7lar\u0131 \u015funlard\u0131r:<\/p>\n Cevap:<\/strong> Uygulama yava\u015flamalar\u0131n\u0131n ba\u015fl\u0131ca nedenleri \u015funlard\u0131r:<\/p>\n Cevap:<\/strong> Proaktif izleme, potansiyel sorunlar\u0131 daha ortaya \u00e7\u0131kmadan veya kullan\u0131c\u0131lar\u0131 etkilemeden \u00f6nce tespit etmenizi sa\u011flar. Sistem kaynaklar\u0131n\u0131n (CPU, bellek, disk, a\u011f) ve uygulama metriklerinin s\u00fcrekli olarak izlenmesi, anormal davran\u0131\u015flar\u0131 ve trendleri erken fark etmenize olanak tan\u0131r. Bu sayede, k\u00fc\u00e7\u00fck bir sorunun b\u00fcy\u00fcmesini engelleyebilir, sistem kesinti s\u00fcrelerini azaltabilir ve “m\u00fchendis pani\u011fi” anlar\u0131n\u0131 minimize edebilirsiniz. Ayr\u0131ca, performans e\u011filimlerini anlamak ve kapasite planlamas\u0131 yapmak i\u00e7in de kritik bilgiler sunar.<\/p>\n #Linux #SorunGiderme #SistemY\u00f6netimi #DevOps #M\u00fchendisPanik<\/p>\nping<\/code> komutuyla her zaman tespit edilemeyebilir.<\/p>\nKaynak T\u00fcketimi Sorunlar\u0131: Bellek, CPU ve Disk I\/O Nas\u0131l \u0130zlenir ve \u00c7\u00f6z\u00fcl\u00fcr?<\/h2>\n
Bellek S\u0131z\u0131nt\u0131lar\u0131 ve Y\u00fcksek Bellek Kullan\u0131m\u0131 Nas\u0131l Tespit Edilir?<\/h3>\n
\n
free -h<\/code>: Toplam, kullan\u0131lan ve bo\u015f fiziksel belle\u011fi (RAM) ve takas alan\u0131 (swap space) kullan\u0131m\u0131n\u0131 insan taraf\u0131ndan okunabilir formatta g\u00f6sterir. Ani ve s\u00fcrekli artan “used” bellek miktar\u0131, bir s\u0131z\u0131nt\u0131n\u0131n i\u015faret\u00e7isi olabilir.<\/li>\ntop<\/code> veya htop<\/code>: \u00c7al\u0131\u015fan s\u00fcre\u00e7leri (processes) ve bunlar\u0131n CPU, bellek ve di\u011fer kaynak kullan\u0131mlar\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak g\u00f6sterir. htop<\/code>, daha renkli ve etkile\u015fimli bir aray\u00fcz sunar. Belirli bir s\u00fcrecin bellek kullan\u0131m\u0131n\u0131n s\u00fcrekli artt\u0131\u011f\u0131n\u0131 g\u00f6zlemlemek, s\u0131z\u0131nt\u0131 yapan uygulamay\u0131 i\u015faret edebilir. \u00d6zellikle VIRT<\/code> (sanal bellek), RES<\/code> (yerle\u015fik set boyutu – fiziksel bellek) ve SHR<\/code> (payla\u015f\u0131lan bellek) s\u00fctunlar\u0131na dikkat edilmelidir.<\/li>\npmap -x <PID><\/code>: Belirli bir s\u00fcrecin (PID) bellek haritas\u0131n\u0131 ve her bir bellek alan\u0131n\u0131n boyutunu detayl\u0131 olarak g\u00f6sterir. Bu, hangi k\u00fct\u00fcphanelerin veya veri segmentlerinin ne kadar bellek kulland\u0131\u011f\u0131n\u0131 anlamak i\u00e7in faydal\u0131d\u0131r.<\/li>\n<\/ul>\nY\u00fcksek CPU Kullan\u0131m\u0131: Hangi S\u00fcre\u00e7ler \u0130\u015flemciyi T\u00fcketiyor?<\/h3>\n
\n
top<\/code> veya htop<\/code>: CPU kullan\u0131m\u0131na g\u00f6re s\u00fcre\u00e7leri s\u0131ralar. En \u00fcstteki s\u00fcre\u00e7ler, i\u015flemciyi en \u00e7ok kullananlard\u0131r. %CPU<\/code> s\u00fctununu izlemek, anormallikleri h\u0131zla fark etmenizi sa\u011flar.<\/li>\nsar -u 1<\/code>: CPU kullan\u0131m istatistiklerini belirli aral\u0131klarla (\u00f6rne\u011fin 1 saniye) raporlar. Bu, uzun vadeli trendleri ve zirve noktalar\u0131n\u0131 g\u00f6zlemlemek i\u00e7in faydal\u0131d\u0131r.<\/li>\n<\/ul>\n\n# htop \u00e7\u0131kt\u0131s\u0131 \u00f6rne\u011fi\nPID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ COMMAND\n1234 user 20 0 1500M 500M 100M R 98.0 12.5 12:34.56 \/usr\/bin\/python3 my_app.py\n5678 root 20 0 100M 10M 5M S 1.0 0.2 0:01.23 \/usr\/sbin\/apache2 -k start\n <\/code><\/pre>\n<\/p><\/div>\nmy_app.py<\/code> uygulamas\u0131n\u0131n CPU’nun neredeyse tamam\u0131n\u0131 (%98) kulland\u0131\u011f\u0131 g\u00f6r\u00fclmektedir. Bu durumda, uygulaman\u0131n kodundaki performans darbo\u011fazlar\u0131n\u0131n veya sonsuz d\u00f6ng\u00fclerin ara\u015ft\u0131r\u0131lmas\u0131 gerekir. Bazen, k\u00f6t\u00fc optimize edilmi\u015f veritaban\u0131 sorgular\u0131 veya a\u015f\u0131r\u0131 hesaplama gerektiren i\u015flemler de y\u00fcksek CPU kullan\u0131m\u0131na neden olabilir.<\/p>\nDisk I\/O Darbo\u011fazlar\u0131: Disk Performans\u0131 Neden D\u00fc\u015f\u00fcyor?<\/h3>\n
\n
iostat -x 1<\/code>: CPU, disk ve a\u011f G\/\u00c7 istatistiklerini raporlar. \u00d6zellikle %util<\/code> (diskin ne kadar me\u015fgul oldu\u011fu), r\/s<\/code> (saniyedeki okuma iste\u011fi), w\/s<\/code> (saniyedeki yazma iste\u011fi), rkB\/s<\/code> (saniyede okunan kilobayt) ve wkB\/s<\/code> (saniyede yaz\u0131lan kilobayt) s\u00fctunlar\u0131 \u00f6nemlidir. Y\u00fcksek %util<\/code> de\u011ferleri, diskin darbo\u011faz ya\u015fad\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/li>\niotop<\/code>: S\u00fcre\u00e7 baz\u0131nda disk G\/\u00c7 kullan\u0131m\u0131n\u0131 g\u00f6sterir. Hangi uygulaman\u0131n diski en \u00e7ok kulland\u0131\u011f\u0131n\u0131 belirlemek i\u00e7in faydal\u0131d\u0131r.<\/li>\ndf -i<\/code>: Dosya sistemi (filesystem) \u00fczerindeki inode (index node) kullan\u0131m\u0131n\u0131 g\u00f6sterir. \u00d6zellikle k\u00fc\u00e7\u00fck dosyalar\u0131n \u00e7ok oldu\u011fu durumlarda (\u00f6rne\u011fin, web sunucusu \u00f6nbellekleri), disk alan\u0131 olmas\u0131na ra\u011fmen inode yetersizli\u011fi nedeniyle yeni dosya olu\u015fturulamayabilir.<\/li>\n<\/ul>\n\n# iostat \u00e7\u0131kt\u0131s\u0131 \u00f6rne\u011fi\nDevice r\/s w\/s rkB\/s wkB\/s %util\nsda 10.5 500.2 100.0 5000.0 95.0\n <\/code><\/pre>\n<\/p><\/div>\nsda<\/code> diskinin %95 oran\u0131nda kullan\u0131ld\u0131\u011f\u0131 ve yo\u011fun yazma i\u015flemleri (wkB\/s<\/code>) oldu\u011fu g\u00f6r\u00fclmektedir. Bu, diskin bir darbo\u011faz oldu\u011funu ve uygulaman\u0131n disk performans\u0131n\u0131 iyile\u015ftirmesi gerekti\u011fini veya daha h\u0131zl\u0131 bir depolama \u00e7\u00f6z\u00fcm\u00fcne ihtiya\u00e7 duydu\u011funu i\u015faret eder. \u00c7\u00f6z\u00fcm olarak, daha h\u0131zl\u0131 diskler (SSD), RAID yap\u0131land\u0131rmalar\u0131, veritaban\u0131 optimizasyonu veya disk G\/\u00c7’yi azaltacak \u00f6nbellekleme stratejileri uygulanabilir.<\/p>\nA\u011f ve Ba\u011flant\u0131 Problemleri: \u0130leti\u015fim Kesintileri Nas\u0131l Te\u015fhis Edilir?<\/h2>\n
Temel A\u011f Ba\u011flant\u0131 Sorunlar\u0131 ve Te\u015fhis Ara\u00e7lar\u0131<\/h3>\n
\n
ping <hedef_ip_veya_hostname><\/code>: Bir hedefe temel a\u011f ba\u011flant\u0131s\u0131n\u0131 test eder. Paketlerin hedefe ula\u015f\u0131p ula\u015fmad\u0131\u011f\u0131n\u0131 ve gecikme s\u00fcresini (latency) g\u00f6sterir. E\u011fer ping<\/code> ba\u015far\u0131s\u0131z olursa, temel IP ba\u011flant\u0131s\u0131nda bir sorun var demektir.<\/li>\ntraceroute <hedef_ip_veya_hostname><\/code>: Paketlerin hedefe ula\u015fana kadar ge\u00e7ti\u011fi a\u011f d\u00fc\u011f\u00fcmlerini (hop) listeler. Bu, a\u011fdaki bir darbo\u011faz\u0131 veya belirli bir noktada ba\u011flant\u0131 kopuklu\u011funu tespit etmeye yard\u0131mc\u0131 olabilir.<\/li>\nnslookup <hostname><\/code> veya dig <hostname><\/code>: DNS (Domain Name System) \u00e7\u00f6z\u00fcmleme sorunlar\u0131n\u0131 kontrol etmek i\u00e7in kullan\u0131l\u0131r. Bir uygulaman\u0131n bir servise IP adresi yerine alan ad\u0131 (domain name) ile ba\u011flanmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumlarda, DNS \u00e7\u00f6z\u00fcmleme hatas\u0131 t\u00fcm ileti\u015fimi durdurabilir.<\/li>\nnetstat -tulnp<\/code> veya ss -tulnp<\/code>: Sistemdeki a\u00e7\u0131k portlar\u0131 ve hangi s\u00fcre\u00e7lerin bu portlar\u0131 dinledi\u011fini (listening) g\u00f6sterir. Bir servisin ba\u015flamad\u0131\u011f\u0131 veya yanl\u0131\u015f portta dinledi\u011fi durumlarda bu komutlar kritik bilgi sa\u011flar. -t<\/code> TCP, -u<\/code> UDP, -l<\/code> dinleyen, -n<\/code> say\u0131sal, -p<\/code> s\u00fcre\u00e7 bilgilerini g\u00f6sterir.<\/li>\n<\/ul>\n\n# netstat -tulnp \u00e7\u0131kt\u0131s\u0131 \u00f6rne\u011fi\nProto Recv-Q Send-Q Local Address Foreign Address State PID\/Program name\ntcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1234\/apache2\ntcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 5678\/mysqld\n <\/code><\/pre>\n<\/p><\/div>\nG\u00fcvenlik Duvar\u0131 ve Y\u00f6nlendirme Sorunlar\u0131<\/h3>\n
iptables<\/code> veya firewalld<\/code> kullan\u0131l\u0131r.<\/p>\n\n
sudo iptables -L -n -v<\/code>: Mevcut iptables<\/code> kurallar\u0131n\u0131 listeler. -L<\/code> listeleme, -n<\/code> say\u0131sal IP ve portlar, -v<\/code> detayl\u0131 bilgi i\u00e7in kullan\u0131l\u0131r. E\u011fer bir servisin portu g\u00fcvenlik duvar\u0131 taraf\u0131ndan engellenmi\u015fse, bu listede ilgili bir DROP<\/code> kural\u0131 g\u00f6rebilirsiniz.<\/li>\nsudo firewall-cmd --list-all<\/code>: firewalld<\/code> kullanan sistemlerde aktif b\u00f6lgelerdeki (zones) t\u00fcm kurallar\u0131 listeler. Bir portun veya servisin a\u00e7\u0131k olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek i\u00e7in bu komut kullan\u0131labilir.<\/li>\nip route show<\/code>: Sistemdeki y\u00f6nlendirme tablosunu g\u00f6sterir. Paketlerin do\u011fru hedefe y\u00f6nlendirilip y\u00f6nlendirilmedi\u011fini anlamak i\u00e7in \u00f6nemlidir. Yanl\u0131\u015f bir varsay\u0131lan a\u011f ge\u00e7idi (default gateway) veya eksik bir rota, d\u0131\u015f a\u011flara eri\u015fimi engelleyebilir.<\/li>\n<\/ul>\nping<\/code> ile veritaban\u0131 sunucusuna eri\u015fim test edilir. Ard\u0131ndan nslookup<\/code> ile veritaban\u0131 sunucusunun alan ad\u0131n\u0131n do\u011fru \u00e7\u00f6z\u00fcmlenip \u00e7\u00f6z\u00fcmlenmedi\u011fi kontrol edilir. E\u011fer bunlar ba\u015far\u0131l\u0131ysa, veritaban\u0131 sunucusunda netstat -tulnp<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131larak MySQL servisinin 3306 portunu dinleyip dinlemedi\u011fi kontrol edilir. Son olarak, hem web sunucusunda hem de veritaban\u0131 sunucusunda g\u00fcvenlik duvar\u0131 kurallar\u0131 (iptables -L<\/code> veya firewall-cmd --list-all<\/code>) incelenerek 3306 portunun trafi\u011fe a\u00e7\u0131k oldu\u011fundan emin olunur. Bu ad\u0131mlar, sorunun a\u011f katman\u0131nda nerede oldu\u011funu belirlemeye yard\u0131mc\u0131 olur.<\/p>\nDerinlemesine A\u011f Analizi: tcpdump<\/h3>\n
tcpdump<\/code> gibi paket yakalama (packet sniffing) ara\u00e7lar\u0131 devreye girer. tcpdump<\/code>, a\u011f aray\u00fcz\u00fcnden ge\u00e7en t\u00fcm paketleri yakalayarak detayl\u0131 analiz yapman\u0131z\u0131 sa\u011flar. \u00d6rne\u011fin, bir sunucunun belirli bir porta paket g\u00f6nderip g\u00f6ndermedi\u011fini veya ald\u0131\u011f\u0131 yan\u0131tlar\u0131 incelemek i\u00e7in kullan\u0131labilir.<\/p>\n\n# tcpdump ile belirli bir host ve port \u00fczerindeki trafi\u011fi yakalama\nsudo tcpdump -i eth0 host <hedef_ip> and port <hedef_port>\n <\/code><\/pre>\n<\/p><\/div>\neth0<\/code> a\u011f aray\u00fcz\u00fcnden ge\u00e7en, belirli bir IP adresine giden veya gelen ve belirli bir portu kullanan t\u00fcm TCP\/UDP paketlerini yakalar. Bu \u00e7\u0131kt\u0131y\u0131 inceleyerek, paketlerin hedefe ula\u015f\u0131p ula\u015fmad\u0131\u011f\u0131n\u0131, hangi protokollerin kullan\u0131ld\u0131\u011f\u0131n\u0131 ve olas\u0131 ba\u011flant\u0131 hatalar\u0131n\u0131 (\u00f6rne\u011fin, TCP SYN\/ACK el s\u0131k\u0131\u015fma hatalar\u0131) g\u00f6rebilirsiniz. tcpdump<\/code> \u00e7\u0131kt\u0131s\u0131 genellikle \u00e7ok detayl\u0131 oldu\u011fundan, belirli filtreler kullanarak sadece ilgili trafi\u011fi yakalamak \u00f6nemlidir. A\u011f sorunlar\u0131 genellikle karma\u015f\u0131k bir yap\u0131ya sahip oldu\u011fundan, bu ara\u00e7lar\u0131 sistematik bir \u015fekilde kullanmak ve her katman\u0131 tek tek kontrol etmek, sorunun k\u00f6k nedenini bulmada anahtard\u0131r.<\/p>\nUygulama ve Sistem Konfig\u00fcrasyonu Hatalar\u0131: Sessiz Katiller Nas\u0131l Bulunur?<\/h2>\n
Yanl\u0131\u015f Yap\u0131land\u0131rma Dosyalar\u0131 ve Ortam De\u011fi\u015fkenleri<\/h3>\n
.conf<\/code>, .yaml<\/code>, .json<\/code> veya .env<\/code> uzant\u0131lar\u0131na sahip olabilir. Yanl\u0131\u015f bir de\u011fer, eksik bir parametre veya hatal\u0131 bir format, uygulaman\u0131n do\u011fru \u015fekilde ba\u015flat\u0131lmamas\u0131na veya beklenmedik sonu\u00e7lar \u00fcretmesine neden olabilir. \u00d6rne\u011fin, bir veritaban\u0131 ba\u011flant\u0131 dizesinin (connection string) yanl\u0131\u015f olmas\u0131, uygulaman\u0131n veritaban\u0131na ba\u011flanamamas\u0131na yol a\u00e7ar.<\/p>\nJAVA_HOME<\/code> de\u011fi\u015fkeninin yanl\u0131\u015f ayarlanmas\u0131, Java uygulamalar\u0131n\u0131n ba\u015flat\u0131lmas\u0131n\u0131 engelleyebilir.<\/p>\n\n
systemd<\/code> birim dosyalar\u0131n\u0131 inceleyin. Ortam de\u011fi\u015fkenlerinin nas\u0131l ayarland\u0131\u011f\u0131n\u0131 kontrol edin.<\/li>\nsudo -u <kullan\u0131c\u0131> env<\/code><\/li>\n<\/ul>\n\u0130zin ve Sahiplik Sorunlar\u0131: Dosya Sistemi Engelleri<\/h3>\n
\n
ls -l <dosya_yolu><\/code>: Bir dosya veya dizinin izinlerini ve sahipli\u011fini g\u00f6sterir. \u00d6rne\u011fin, bir web sunucusunun log dosyas\u0131na yazma izni yoksa, loglama durabilir.<\/li>\nchown <kullan\u0131c\u0131>:<grup> <dosya_yolu><\/code>: Dosya veya dizinin sahipli\u011fini de\u011fi\u015ftirir.<\/li>\nchmod <izinler> <dosya_yolu><\/code>: Dosya veya dizinin izinlerini de\u011fi\u015ftirir (\u00f6rne\u011fin, chmod 644<\/code> veya chmod 755<\/code>).<\/li>\n<\/ul>\nwww-data<\/code> veya nginx<\/code>) bu dizine yazma izni olmas\u0131 gerekir.<\/p>\nSistem Hizmetleri ve systemd Y\u00f6netimi<\/h3>\n
systemd<\/code> kullan\u0131r. Bir hizmetin d\u00fczg\u00fcn \u015fekilde ba\u015flat\u0131lamamas\u0131, s\u00fcrekli yeniden ba\u015flamas\u0131 veya tamamen durmas\u0131, yap\u0131land\u0131rma hatalar\u0131ndan kaynaklanabilir. systemd<\/code> birim dosyalar\u0131 (unit files), hizmetlerin nas\u0131l ba\u015flat\u0131laca\u011f\u0131n\u0131, hangi ba\u011f\u0131ml\u0131l\u0131klara sahip oldu\u011funu ve hangi kullan\u0131c\u0131 alt\u0131nda \u00e7al\u0131\u015faca\u011f\u0131n\u0131 tan\u0131mlar.<\/p>\n\n
systemctl status <servis_ad\u0131><\/code>: Bir hizmetin mevcut durumunu, en son g\u00fcnl\u00fck (log) \u00e7\u0131kt\u0131lar\u0131n\u0131 ve varsa hata mesajlar\u0131n\u0131 g\u00f6sterir. Bu komut, bir hizmetin neden ba\u015flamad\u0131\u011f\u0131n\u0131 veya neden \u00e7\u00f6kt\u00fc\u011f\u00fcn\u00fc anlamak i\u00e7in ilk ba\u015fvurulacak yerdir.<\/li>\njournalctl -u <servis_ad\u0131><\/code>: Belirli bir hizmete ait t\u00fcm g\u00fcnl\u00fck mesajlar\u0131n\u0131 g\u00f6sterir. Bu, hizmetin ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca olu\u015fan t\u00fcm olaylar\u0131 ve hatalar\u0131 detayl\u0131 olarak incelemenizi sa\u011flar.<\/li>\nsudo systemctl edit --full <servis_ad\u0131><\/code>: Bir hizmetin systemd<\/code> birim dosyas\u0131n\u0131 d\u00fczenlemenizi sa\u011flar. Burada yap\u0131lan yanl\u0131\u015f bir de\u011fi\u015fiklik, hizmetin \u00e7al\u0131\u015fmamas\u0131na neden olabilir.<\/li>\n<\/ul>\n\n# systemctl status nginx \u00e7\u0131kt\u0131s\u0131 \u00f6rne\u011fi\n\u25cf nginx.service - A high performance web server and a reverse proxy server\n Loaded: loaded (\/lib\/systemd\/system\/nginx.service; enabled; vendor preset: enabled)\n Active: failed (Result: exit-code) since Mon 2023-10-26 10:30:00 UTC; 10min ago\n Docs: man:nginx(8)\n Process: 1234 ExecStart=\/usr\/sbin\/nginx -g \"daemon on; master_process on;\" (code=exited, status=1\/FAILURE)\n Main PID: 1235 (code=exited, status=0\/SUCCESS)\n CPU: 1.234s\n\nOct 26 10:30:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...\nOct 26 10:30:00 server nginx[1234]: nginx: [emerg] open() \"\/etc\/nginx\/nginx.conf\" failed (2: No such file or directory)\nOct 26 10:30:00 server nginx[1234]: nginx: configuration file \/etc\/nginx\/nginx.conf test failed\nOct 26 10:30:00 server systemd[1]: nginx.service: Control process exited, code=exited, status=1\/FAILURE\nOct 26 10:30:00 server systemd[1]: nginx.service: Failed with result 'exit-code'.\nOct 26 10:30:00 server systemd[1]: Failed to start A high performance web server and a reverse proxy server.\n <\/code><\/pre>\n<\/p><\/div>\nsystemctl status<\/code> \u00e7\u0131kt\u0131s\u0131, Nginx servisinin ba\u015flat\u0131lamad\u0131\u011f\u0131n\u0131 ve hatan\u0131n nginx: [emerg] open() \"\/etc\/nginx\/nginx.conf\" failed (2: No such file or directory)<\/code> oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Bu, yap\u0131land\u0131rma dosyas\u0131n\u0131n eksik oldu\u011fu veya yanl\u0131\u015f bir yolda arand\u0131\u011f\u0131 anlam\u0131na gelir. Bu t\u00fcr log mesajlar\u0131, sorunun k\u00f6k nedenini h\u0131zl\u0131ca bulmak i\u00e7in alt\u0131n de\u011ferindedir.<\/p>\nDerinlemesine Hata Ay\u0131klama Teknikleri: M\u00fchendis Panik Anlar\u0131n\u0131 Y\u00f6netmek<\/h2>\n
Sistem \u00c7a\u011fr\u0131lar\u0131n\u0131 \u0130zleme: strace<\/h3>\n
strace<\/code>, bir s\u00fcrecin yapt\u0131\u011f\u0131 t\u00fcm sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 (system calls) ve ald\u0131\u011f\u0131 sinyalleri (signals) izleyen g\u00fc\u00e7l\u00fc bir hata ay\u0131klama arac\u0131d\u0131r. Bir uygulama neden belirli bir dosyay\u0131 a\u00e7am\u0131yor, neden bir a\u011f ba\u011flant\u0131s\u0131 kuram\u0131yor veya neden beklenmedik bir hatayla kar\u015f\u0131la\u015f\u0131yor gibi sorular\u0131n cevaplar\u0131n\u0131 bulmak i\u00e7in paha bi\u00e7ilmezdir. strace<\/code>, s\u00fcrecin i\u015fletim sistemiyle olan t\u00fcm etkile\u015fimini detayl\u0131 bir \u015fekilde g\u00f6sterir.<\/p>\n\n# Bir s\u00fcrecin sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 izleme\nstrace -p <PID>\n\n# Bir komutu ba\u015flat\u0131rken sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 izleme\nstrace <komut_ad\u0131> <arg\u00fcmanlar>\n\n# A\u011f ile ilgili sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 filtreleme\nstrace -e network <komut_ad\u0131>\n\n# Dosya G\/\u00c7 ile ilgili sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 filtreleme\nstrace -e file <komut_ad\u0131>\n <\/code><\/pre>\n<\/p><\/div>\nstrace -e openat,open <uygulama_komutu><\/code> komutunu \u00e7al\u0131\u015ft\u0131rarak, uygulaman\u0131n hangi dosya yollar\u0131n\u0131 denedi\u011fini ve hangi hata kodlar\u0131n\u0131 (\u00f6rne\u011fin, ENOENT<\/code> – No such file or directory) ald\u0131\u011f\u0131n\u0131 g\u00f6rebilirsiniz. Bu, yanl\u0131\u015f dosya yolu veya izin sorunlar\u0131n\u0131 h\u0131zla tespit etmenizi sa\u011flar.<\/p>\nA\u00e7\u0131k Dosyalar\u0131 ve Soketleri Listeleme: lsof<\/h3>\n
lsof<\/code> (list open files), bir sistemdeki t\u00fcm a\u00e7\u0131k dosyalar\u0131 ve a\u011f soketlerini (sockets) listeler. Linux’ta her \u015fey bir dosya oldu\u011fundan, bu ara\u00e7 sadece disk \u00fczerindeki dosyalar\u0131 de\u011fil, ayn\u0131 zamanda a\u011f ba\u011flant\u0131lar\u0131n\u0131, borular\u0131 (pipes), cihazlar\u0131 ve dizinleri de g\u00f6sterir. Bir s\u00fcrecin neden belirli bir kayna\u011f\u0131 serbest b\u0131rakmad\u0131\u011f\u0131n\u0131 veya hangi portlar\u0131 dinledi\u011fini anlamak i\u00e7in \u00e7ok faydal\u0131d\u0131r.<\/p>\n\n# Belirli bir PID'e ait t\u00fcm a\u00e7\u0131k dosyalar\u0131 listeleme\nlsof -p <PID>\n\n# Belirli bir porta ait a\u00e7\u0131k soketleri listeleme\nlsof -i :<PORT>\n\n# Belirli bir dosya yolunu kullanan s\u00fcre\u00e7leri bulma\nlsof <dosya_yolu>\n <\/code><\/pre>\n<\/p><\/div>\nlsof -p <PID> | wc -l<\/code> komutuyla ilgili s\u00fcrecin ka\u00e7 dosya a\u00e7t\u0131\u011f\u0131n\u0131 g\u00f6rebilirsiniz. Bu say\u0131, sistemin varsay\u0131lan a\u00e7\u0131k dosya limiti (genellikle 1024) ile kar\u015f\u0131la\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, sorunun kayna\u011f\u0131n\u0131 belirlemenize yard\u0131mc\u0131 olur. Ayr\u0131ca, bu limit ulimit -n<\/code> komutuyla kontrol edilebilir ve \/etc\/security\/limits.conf<\/code> dosyas\u0131ndan art\u0131r\u0131labilir.<\/p>\n\u00c7ekirdek Mesajlar\u0131n\u0131 Kontrol Etme: dmesg<\/h3>\n
dmesg<\/code> (display message), \u00e7ekirdek mesaj arabelle\u011fini (kernel message buffer) g\u00f6r\u00fcnt\u00fcler. Bu arabellek, \u00e7ekirdek taraf\u0131ndan ba\u015flatma s\u0131ras\u0131nda ve \u00e7al\u0131\u015fma zaman\u0131nda \u00fcretilen t\u00fcm mesajlar\u0131 i\u00e7erir. Donan\u0131m hatalar\u0131, s\u00fcr\u00fcc\u00fc sorunlar\u0131, bellek sorunlar\u0131 (OOM Killer – Out Of Memory Killer mesajlar\u0131) ve di\u011fer d\u00fc\u015f\u00fck seviyeli sistem olaylar\u0131 genellikle dmesg<\/code> \u00e7\u0131kt\u0131s\u0131nda bulunur.<\/p>\n\n# T\u00fcm \u00e7ekirdek mesajlar\u0131n\u0131 g\u00f6r\u00fcnt\u00fcleme\ndmesg | less\n\n# Hata mesajlar\u0131n\u0131 filtreleme\ndmesg | grep -i \"error\"\n\n# OOM Killer mesajlar\u0131n\u0131 kontrol etme\ndmesg | grep -i \"oom-killer\"\n <\/code><\/pre>\n<\/p><\/div>\ndmesg | grep -i \"oom-killer\"<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 kontrol etmek faydal\u0131 olabilir. OOM Killer, sistem belle\u011fi t\u00fckendi\u011finde, en \u00e7ok bellek t\u00fcketen s\u00fcreci sonland\u0131rarak sistemi kurtarmaya \u00e7al\u0131\u015fan bir \u00e7ekirdek mekanizmas\u0131d\u0131r. E\u011fer OOM Killer uygulaman\u0131z\u0131 sonland\u0131r\u0131yorsa, bu, ciddi bir bellek s\u0131z\u0131nt\u0131s\u0131n\u0131n veya yetersiz sistem belle\u011finin bir g\u00f6stergesidir.<\/p>\nLog Analizi ve Journalctl<\/h3>\n
systemd<\/code> ile birlikte gelen journalctl<\/code>, merkezi bir g\u00fcnl\u00fck y\u00f6netim arac\u0131d\u0131r. T\u00fcm sistem ve hizmet g\u00fcnl\u00fcklerini tek bir yerde toplar ve sorgulanabilir hale getirir.<\/p>\n\n# T\u00fcm g\u00fcnl\u00fckleri g\u00f6r\u00fcnt\u00fcleme\njournalctl | less\n\n# Belirli bir hizmetin g\u00fcnl\u00fcklerini g\u00f6r\u00fcnt\u00fcleme\njournalctl -u <servis_ad\u0131>\n\n# Son 1 saatteki hatalar\u0131 g\u00f6r\u00fcnt\u00fcleme\njournalctl -p err -S \"1 hour ago\"\n\n# Belirli bir zaman aral\u0131\u011f\u0131ndaki g\u00fcnl\u00fckleri g\u00f6r\u00fcnt\u00fcleme\njournalctl --since \"2023-10-26 10:00:00\" --until \"2023-10-26 11:00:00\"\n <\/code><\/pre>\n<\/p><\/div>\njournalctl -u <servis_ad\u0131><\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 incelemek, genellikle hatan\u0131n ne zaman ve neden meydana geldi\u011fine dair kritik ipu\u00e7lar\u0131 sa\u011flar. Uygulama geli\u015ftiricileri taraf\u0131ndan \u00fcretilen \u00f6zel g\u00fcnl\u00fck dosyalar\u0131 (\u00f6rne\u011fin, \/var\/log\/apache2\/error.log<\/code> veya uygulaman\u0131n kendi log dizini) da mutlaka kontrol edilmelidir. Loglar\u0131n do\u011fru seviyede (INFO, WARNING, ERROR, DEBUG) tutulmas\u0131, hata ay\u0131klama s\u00fcrecini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131r.<\/p>\nSonu\u00e7: \u00c7ekirdek Pani\u011finden \u00d6\u011frenilen Dersler ve \u0130leriye Y\u00f6nelik Stratejiler<\/h2>\n
journalctl<\/code>, grep<\/code> ve di\u011fer log analizi ara\u00e7lar\u0131n\u0131 etkin bir \u015fekilde kullanmak, sorunun k\u00f6k nedenini belirleme s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h3>\n
1. Kernel panic ile “m\u00fchendis pani\u011fi” aras\u0131ndaki temel fark nedir?<\/h4>\n
Kernel panic<\/code>, Linux \u00e7ekirde\u011finin kurtar\u0131lamaz bir hata ile kar\u015f\u0131la\u015fmas\u0131 ve sistemin tamamen durmas\u0131 durumudur. Bu, genellikle donan\u0131m ar\u0131zalar\u0131, \u00e7ekirdek mod\u00fcl\u00fc uyumsuzluklar\u0131 veya ciddi i\u015fletim sistemi hatalar\u0131ndan kaynaklan\u0131r. “M\u00fchendis pani\u011fi” ise, i\u015fletim sistemi \u00e7al\u0131\u015fmaya devam etse bile, \u00fczerindeki bir uygulaman\u0131n, servisin veya t\u00fcm sistem y\u0131\u011f\u0131n\u0131n\u0131n (stack) beklendi\u011fi gibi \u00e7al\u0131\u015fmamas\u0131, yava\u015flamas\u0131 veya hata vermesi durumudur. Bu durumlar genellikle bellek s\u0131z\u0131nt\u0131lar\u0131, y\u00fcksek CPU kullan\u0131m\u0131, a\u011f sorunlar\u0131, yanl\u0131\u015f yap\u0131land\u0131rmalar veya uygulama hatalar\u0131ndan kaynaklan\u0131r ve m\u00fchendisler i\u00e7in ciddi bir sorun giderme m\u00fccadelesi anlam\u0131na gelir.<\/p>\n2. Bir bellek s\u0131z\u0131nt\u0131s\u0131n\u0131 nas\u0131l tespit edebilirim?<\/h4>\n
free -h<\/code> komutuyla genel bellek kullan\u0131m\u0131n\u0131, top<\/code> veya htop<\/code> ile s\u00fcre\u00e7 baz\u0131nda bellek t\u00fcketimini izleyebilirsiniz. E\u011fer belirli bir s\u00fcrecin RES<\/code> (resident set size) de\u011feri zamanla s\u00fcrekli art\u0131yorsa, bu bir bellek s\u0131z\u0131nt\u0131s\u0131n\u0131n g\u00fc\u00e7l\u00fc bir i\u015faretidir. Daha derinlemesine analiz i\u00e7in pmap -x <PID><\/code> kullan\u0131labilir. Uygulama katman\u0131nda ise, dile \u00f6zg\u00fc hata ay\u0131klama ara\u00e7lar\u0131 (Java i\u00e7in JProfiler, C\/C++ i\u00e7in Valgrind) s\u0131z\u0131nt\u0131n\u0131n kayna\u011f\u0131n\u0131 bulmada yard\u0131mc\u0131 olur.<\/p>\n3. Hangi Linux ara\u00e7lar\u0131 sorun gidermede en temeldir?<\/h4>\n
\n
top<\/code> \/ htop<\/code>: CPU ve bellek kullan\u0131m\u0131.<\/li>\nfree -h<\/code>: Bellek ve takas alan\u0131 durumu.<\/li>\niostat<\/code> \/ iotop<\/code>: Disk I\/O performans\u0131.<\/li>\nnetstat<\/code> \/ ss<\/code>: A\u011f ba\u011flant\u0131lar\u0131 ve a\u00e7\u0131k portlar.<\/li>\nping<\/code> \/ traceroute<\/code>: A\u011f ba\u011flant\u0131 testi.<\/li>\njournalctl<\/code> \/ tail -f \/var\/log\/*<\/code>: Sistem ve uygulama g\u00fcnl\u00fckleri.<\/li>\nsystemctl status <servis><\/code>: Hizmet durumu.<\/li>\nstrace<\/code>: Sistem \u00e7a\u011fr\u0131lar\u0131n\u0131 izleme.<\/li>\nlsof<\/code>: A\u00e7\u0131k dosyalar\u0131 ve soketleri listeleme.<\/li>\ndmesg<\/code>: \u00c7ekirdek mesajlar\u0131.<\/li>\n<\/ul>\n4. Uygulama yava\u015flamalar\u0131n\u0131n en yayg\u0131n nedenleri nelerdir?<\/h4>\n
\n
5. Proaktif izleme (monitoring) neden \u00f6nemlidir?<\/h4>\n