Takip et

Linux Sunucu Sorun Giderme: Zihnimdeki Kontrol Listesi

Linux Sunucu Sorun Giderme: Zihnimdeki Kontrol Listesi Bir Linux sunucusunda beklenmedik bir sorunla karşılaştığınızda, paniklemek yerine sistematik …

Linux Sunucu Sorun Giderme: Zihnimdeki Kontrol Listesi

Bir Linux sunucusunda beklenmedik bir sorunla karşılaştığınızda, paniklemek yerine sistematik bir yaklaşımla hareket etmek, sorunu hızlı ve etkili bir şekilde çözmenin anahtarıdır. Bu makalede, yılların tecrübesiyle edindiğim ve her sorun giderme senaryosunda zihnimde otomatik olarak devreye giren kontrol listesini sizinle paylaşacağım. Bu liste, sadece bir rehber olmakla kalmayacak, aynı zamanda karmaşık sorunları basitleştirmenize ve çözüm sürecini hızlandırmanıza yardımcı olacaktır.

İlk Adım: Sakin Kalmak ve Bilgi Toplamak

Sorun gidermenin ilk ve en kritik adımı, sakin kalmak ve aceleci kararlar vermekten kaçınmaktır. Panik, genellikle yanlış adımlara ve daha büyük sorunlara yol açar. Derin bir nefes alın ve ardından mevcut durumu anlamak için gerekli bilgileri toplamaya odaklanın.

Sorunu Anlamak ve Kapsamını Belirlemek

Öncelikle, sorunun tam olarak ne olduğunu ve hangi kullanıcıları veya servisleri etkilediğini net bir şekilde anlamalısınız. “Sunucu yavaş” gibi genel ifadeler yerine, “Web sitesi X, son 5 dakikadır 503 hatası veriyor” veya “SSH bağlantısı kurulamıyor” gibi spesifik tanımlamalar yapın. Sorunun ne zaman başladığı, herhangi bir uyarı olup olmadığı gibi detaylar çok değerlidir.

Son Yapılan Değişiklikleri Sorgulamak

Deneyimlerime göre, sorunların büyük bir kısmı, son yapılan bir değişiklikten kaynaklanır. Bir yama uygulandı mı? Yeni bir yazılım yüklendi mi? Bir konfigürasyon dosyası değiştirildi mi? Ağ ayarları güncellendi mi? Bu soruların cevapları, sorunun kök nedenine ulaşmak için genellikle en kısa yolu sunar. Change management (değişiklik yönetimi) süreçleri bu yüzden hayati önem taşır.

Temel Sağlık Kontrolleri

Sorunun genel bir sistem sorunu mu yoksa belirli bir servise mi ait olduğunu anlamak için hızlıca temel sistem kontrolleri yapın.

  • Sunucuya SSH ile erişebiliyor musunuz?
  • uptime komutu ile sunucunun ne kadar süredir çalıştığını kontrol edin.
  • ping komutu ile dış ağ bağlantısını test edin.
  • df -h ve free -h komutları ile disk ve bellek durumuna hızlıca göz atın.

Sistem Kaynaklarını Kontrol Etmek

Çoğu performans sorunu veya servis kesintisi, sistem kaynaklarının tükenmesinden kaynaklanır. CPU, bellek, disk G/Ç ve ağ bant genişliği gibi kaynakları dikkatlice incelemek, sorunun kaynağını bulmada kritik öneme sahiptir.

CPU Kullanımı

Yüksek CPU kullanımı, bir uygulamanın döngüye girmesi, yoğun hesaplama gerektiren bir işlemin çalışması veya kötü optimize edilmiş bir kod parçası nedeniyle olabilir.

top
htop # Daha interaktif bir araç
mpstat -P ALL # Her çekirdeğin kullanımını gösterir
sar 1 10 # Sistem aktivitesini belirli aralıklarla raporlar


Hangi sürecin CPU'yu en çok kullandığını belirleyin. Bu süreç, uygulamanızın kendisi olabileceği gibi, bir veritabanı sorgusu veya bir arka plan görevi de olabilir.

Bellek (RAM) Kullanımı

Bellek tükenmesi (OOM - Out Of Memory) hataları, sunucunun yavaşlamasına veya kritik servislerin çökmesine neden olabilir.

free -h # Toplam, kullanılan ve boş belleği gösterir
vmstat # Sanal bellek istatistiklerini raporlar
ps aux --sort=-%mem # Bellek kullanımına göre sıralanmış süreçler


Swap alanının yoğun kullanımı da bellek yetersizliğine işaret edebilir. Aşırı bellek tüketen bir uygulama varsa, onu tespit edip optimize etmek veya sunucuya daha fazla RAM eklemek gerekebilir.

Disk G/Ç ve Alanı

Disk performansı, özellikle veritabanı veya dosya sunucuları gibi G/Ç yoğun uygulamalar için hayati öneme sahiptir. Disk alanının dolması ise çoğu zaman sistemin çalışmasını tamamen durdurabilir.

df -h # Disk kullanımını gösterir
du -sh /path/to/directory # Belirli bir dizinin boyutunu gösterir
iostat -xz 1 # Disk G/Ç istatistiklerini gösterir
lsof +L1 # Silinmiş ancak hala bir süreç tarafından kullanılan dosyaları listeler


Eğer disk alanı doluysa, gereksiz dosyaları (eski loglar, geçici dosyalar, yedekler) silerek yer açın. Yüksek G/Ç bekleme süreleri (iowait) gözlemliyorsanız, bu diskin bir darboğaz olduğunu gösterir.

Süreçler ve İş Yükü

Sistemdeki aktif süreçleri ve genel iş yükünü anlamak, sorunun kaynağını belirlemede yardımcı olur.

w # Kimin bağlı olduğunu ve ne yaptıklarını gösterir
uptime # Ortalama yükü (load average) gösterir
ps aux # Tüm çalışan süreçleri gösterir
pstree # Süreç ağacını gösterir


Yüksek yük ortalaması (load average), sistemin işleyemediği çok sayıda sürecin olduğunu gösterir. Belirli bir sürecin anormal davranışını (örneğin, çok fazla alt süreç oluşturması) tespit etmek önemlidir.

Ağ ve Bağlantı Sorunlarını İncelemek

Uygulama veya sunucu erişim sorunlarının önemli bir kısmı ağ katmanından kaynaklanır. Bağlantı sorunları, DNS çözümlemesi, güvenlik duvarı kuralları veya yanlış yönlendirmeler nedeniyle ortaya çıkabilir.

Temel Ağ Bağlantısı Kontrolleri

Sunucunun dış dünya ile veya diğer dahili sistemlerle iletişim kurup kuramadığını test edin.

ip a # Ağ arayüzlerinin IP adreslerini gösterir
ping google.com # Dış bağlantıyı test eder
ping 8.8.8.8 # DNS bağımsız dış bağlantıyı test eder
traceroute google.com # Paketin hedefe ulaşana kadar geçtiği rotayı gösterir


Eğer ping başarısız olursa, ağ kablosunu, sanal ağ ayarlarını veya fiziksel ağ cihazlarını kontrol edin.

Port Durumları ve Güvenlik Duvarı

Bir servise erişemiyorsanız, ilgili portun açık olup olmadığını ve güvenlik duvarı tarafından engellenip engellenmediğini kontrol edin.

netstat -tulnp # Dinleyen TCP/UDP portlarını ve ilgili süreçleri gösterir
ss -tulnp # netstat'a modern bir alternatif
firewall-cmd --list-all # firewalld kullanan sistemlerde kuralları listeler
iptables -L -n -v # iptables kurallarını listeler


Eğer bir servis belirli bir portta dinlemiyorsa veya güvenlik duvarı tarafından engelleniyorsa, istemciler ona bağlanamaz.

DNS Çözümlemesi

Uygulamaların veya kullanıcıların host isimlerini IP adreslerine çevirememesi, yaygın bir sorundur.

dig google.com # DNS sorgusu yapar
cat /etc/resolv.conf # DNS sunucu ayarlarını gösterir


Eğer DNS çözümlemesi başarısız olursa, /etc/resolv.conf dosyasındaki DNS sunucularını kontrol edin veya geçici olarak bilinen bir DNS sunucusunu (örn. 8.8.8.8) kullanmayı deneyin.

Rota ve Gecikme Sorunları

Ağdaki gecikmeler veya yanlış yönlendirmeler de sorunlara yol açabilir.

ip r # Yönlendirme tablosunu gösterir
mtr google.com # Ping ve traceroute'un birleşimi, ağdaki sorunlu noktaları daha iyi gösterir


Yüksek gecikmeler (latency) veya paket kayıpları (packet loss) görüyorsanız, ağ altyapınızda bir sorun olabilir.

Uygulama ve Servis Sorunlarını Gidermek

Sistem kaynakları ve ağ sorunları giderildikten sonra, sorun hala devam ediyorsa, büyük olasılıkla uygulamanın veya servisin kendisinde bir problem vardır.

Servis Durumlarını Kontrol Etmek

İlgili servisin (web sunucusu, veritabanı, uygulama sunucusu vb.) çalışır durumda olup olmadığını kontrol edin.

systemctl status apache2 # systemd kullanan sistemlerde servis durumunu kontrol eder
service apache2 status # SysVinit/Upstart kullanan sistemlerde
ps aux | grep apache2 # Servis süreçlerini kontrol eder


Servis durmuşsa, yeniden başlatmayı deneyin: systemctl restart apache2. Eğer başlamazsa, loglarına bakın.

Uygulama Logları ve Konfigürasyonları

Uygulamaların kendi logları, genellikle sorunun nedenini en net şekilde ortaya koyar.

  • Web sunucusu logları (Apache: /var/log/apache2/error.log, Nginx: /var/log/nginx/error.log)
  • Veritabanı logları (MySQL: /var/log/mysql/error.log, PostgreSQL: /var/log/postgresql/...)
  • Uygulamanızın kendi logları (genellikle /var/log/ altında veya uygulama dizininde)

Konfigürasyon dosyalarındaki hatalar da servislerin başlamamasına veya yanlış çalışmasına neden olabilir. Son değişiklikleri kontrol edin ve gerekirse yedekten geri dönün.

Bağımlılıklar ve Kütüphaneler

Bir uygulamanın düzgün çalışması için gerekli olan kütüphanelerin veya bağımlılıkların eksik olması veya yanlış versiyonlarının yüklü olması sorunlara yol açabilir.

ldd /path/to/executable # Bir yürütülebilir dosyanın bağımlılıklarını gösterir
apt list --installed | grep package-name # Debian/Ubuntu
yum list installed | grep package-name # CentOS/RHEL


Özellikle yeni bir kurulum veya yükseltme sonrası bu tür sorunlar sıkça görülür.

Güvenlik ve İzinleri Gözden Geçirmek

Bazen sorunlar, gözden kaçan güvenlik kısıtlamaları veya yanlış dosya izinleri nedeniyle ortaya çıkar.

Dosya ve Dizin İzinleri

Uygulamaların, log dosyalarına yazma veya konfigürasyon dosyalarını okuma gibi işlemleri gerçekleştirebilmesi için doğru dosya ve dizin izinlerine sahip olması gerekir.

ls -l /path/to/file_or_directory # İzinleri, sahipliği ve grubu gösterir
namei -mo /path/to/file_or_directory # Daha detaylı bilgi


Yanlış izinler (örn. bir web sunucusunun bir dizine yazamaması) 403 (Forbidden) veya 500 (Internal Server Error) gibi hatalara yol açabilir.

SELinux/AppArmor Durumu

Mandatory Access Control (MAC) sistemleri olan SELinux veya AppArmor, uygulamaların belirli sistem kaynaklarına erişimini kısıtlayabilir. Bu, güvenlik için harika olsa da, yanlış yapılandırıldığında sorun giderme sürecini karmaşıklaştırabilir.

getenforce # SELinux durumunu gösterir (Enforcing, Permissive, Disabled)
sestatus # Daha detaylı SELinux bilgisi
audit2allow -a # SELinux denetim loglarından izinler oluşturmaya yardımcı olur
aa-status # AppArmor durumunu gösterir


Sorun giderme sırasında geçici olarak setenforce 0 komutuyla SELinux'u Permissive moda almak, sorunun SELinux'tan kaynaklanıp kaynaklanmadığını anlamanıza yardımcı olabilir. Ancak bu, kalıcı bir çözüm değildir ve güvenlik riski taşır.

Güvenlik Duvarı Kuralları (iptables/firewalld)

Daha önce ağ bölümünde bahsedildiği gibi, sunucunun yerel güvenlik duvarı kuralları da belirli portlara veya IP adreslerine erişimi engelleyebilir. Güvenlik duvarı kurallarını dikkatlice inceleyin ve gerekli portların açık olduğundan emin olun.

Logları Derinlemesine İncelemek

Loglar, sunucunun "günlüğü" gibidir ve sorunların kök nedenini bulmak için en zengin bilgi kaynağıdır.

Sistem Logları (syslog, journald)

İşletim sistemi seviyesindeki hatalar, çekirdek mesajları, kimlik doğrulama denemeleri gibi bilgiler burada bulunur.

journalctl -xe # systemd tabanlı sistemlerde tüm logları gösterir, -xe ile hata mesajlarına odaklanır
tail -f /var/log/syslog # Gerçek zamanlı olarak logları takip eder (Debian/Ubuntu)
tail -f /var/log/messages # Gerçek zamanlı olarak logları takip eder (CentOS/RHEL)


Özellikle sorunun başladığı zaman dilimine odaklanarak ilgili logları filtrelemek, çok sayıda log arasından işinize yarayan bilgiyi bulmanızı sağlar.

Uygulama ve Web Sunucusu Logları

Uygulamanızın veya web sunucunuzun kendi logları, genellikle sorunun uygulamanın kendisinden mi yoksa dış bir etkenden mi kaynaklandığını anlamak için en iyi yerdir.

tail -f /var/log/apache2/error.log
tail -f /var/log/nginx/access.log
grep "ERROR" /var/log/my_app/app.log


HTTP durum kodları (5xx hataları), veritabanı bağlantı hataları veya uygulama içi istisnalar gibi detaylar burada aranmalıdır.

Kimlik Doğrulama Logları

Eğer sorun bir servise veya sunucuya erişimle ilgiliyse, kimlik doğrulama logları faydalı olabilir.

tail -f /var/log/auth.log # Debian/Ubuntu
tail -f /var/log/secure # CentOS/RHEL


Başarısız SSH giriş denemeleri, sudo hataları veya diğer kimlik doğrulama sorunları burada kaydedilir.

Değişiklikleri Yönetmek ve Belgelemek

Sorun giderme süreci boyunca yaptığınız her adımı dikkatlice yönetmek ve belgelemek, hem mevcut sorunu çözmek hem de gelecekte benzer sorunları önlemek için kritik öneme sahiptir.

Adım Adım Geri Dönüş Planı

Bir değişiklik yapmadan önce, her zaman bir geri dönüş planınız olmalıdır. Bir konfigürasyon dosyasını değiştirmeden önce yedekleyin. Bir servisi yeniden başlatmadan önce, eğer mümkünse, etkilerini değerlendirin. Yaptığınız her değişikliği not alın, böylece bir sorun daha da kötüleşirse geri alabilirsiniz.

Belgeleme ve Bilgi Paylaşımı

Sorunu çözdükten sonra, neyin yanlış gittiğini, nasıl teşhis ettiğinizi ve nasıl çözdüğünüzü belgeleyin. Bu, hem sizin hem de ekibinizdeki diğer kişilerin gelecekte benzer sorunlarla daha hızlı başa çıkmasına yardımcı olur. Bir bilgi tabanı oluşturmak, tekrarlayan sorunların çözümü için büyük bir zaman tasarrufu sağlar.

Otomasyon ve Önleyici Tedbirler

Tekrarlayan sorunları veya yaygın darboğazları tespit ettikten sonra, bunları otomatikleştirmek veya önleyici tedbirler almak için fırsatlar arayın.

  • Otomatik log analizi araçları
  • Kaynak kullanımını izleyen izleme sistemleri (Prometheus, Grafana, Zabbix)
  • Konfigürasyon yönetimi araçları (Ansible, Puppet, Chef) ile tutarlılığı sağlamak
  • Düzenli yedeklemeler ve felaket kurtarma planları

Bu tür önlemler, sorunların ortaya çıkmasını engeller veya en azından etkilerini minimize eder.

Sonuç

Linux sunucu sorun giderme, bir sanattır ve zamanla gelişen bir beceridir. Bu zihinsel kontrol listesi, size yapılandırılmış bir yaklaşım sunarak, paniklemek yerine mantıklı ve sistematik adımlarla ilerlemenizi sağlar. Unutmayın, her sorun bir öğrenme fırsatıdır. Her çözülen sorun, gelecekteki zorluklara karşı sizi daha donanımlı hale getirecektir. Bu adımları takip ederek, karmaşık görünen sorunları bile daha yönetilebilir parçalara ayırabilir ve çözüme ulaşabilirsiniz.

SSS (Sık Sorulan Sorular)

1. Bir sorunla karşılaştığımda ilk ne yapmalıyım?

Sakin kalın ve sorunun tam olarak ne olduğunu, ne zaman başladığını ve hangi servisleri/kullanıcıları etkilediğini anlamaya çalışın. Ardından, son yapılan değişiklikleri sorgulayın.

2. Hangi log dosyalarına bakmalıyım?

Genel sistem sorunları için /var/log/syslog veya journalctl -xe'ye, web sunucusu sorunları için Apache/Nginx hata loglarına ve uygulamanızın kendi loglarına bakmalısınız. Kimlik doğrulama sorunları için /var/log/auth.log veya /var/log/secure faydalıdır.

3. Sunucuya SSH ile erişemiyorsam ne yapmalıyım?

Öncelikle ağ bağlantısını kontrol edin (ping). Eğer ağda sorun yoksa, sunucunun fiziksel/sanal konsoluna erişmeyi deneyin. Güvenlik duvarı kurallarını veya SSH servisi durumunu kontrol edin.

4. Yüksek CPU kullanımı görüyorum, ne yapmalıyım?

top veya htop kullanarak hangi sürecin CPU'yu en çok kullandığını belirleyin. Bu sürecin ne olduğunu ve neden bu kadar CPU tükettiğini araştırın. Gerekirse süreci durdurup yeniden başlatmayı veya optimize etmeyi düşünün.

5. Disk alanı dolu uyarısı alıyorum, ne yapmalıyım?

df -h ile hangi dizinin dolu olduğunu belirleyin. du -sh * komutuyla büyük dosyaları veya dizinleri bulun. Genellikle eski log dosyaları, geçici dosyalar veya yedekler çok yer kaplar. Gereksiz dosyaları silerek yer açın.

Yorumlar
İçeriği beğendiniz mi? Bir tartışma başlatın veya görüşlerinizi paylaşın.
Yorum Yaz

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

E-posta Bülteni
Yazılım Topluluğuna Katılın
En son güncellemeleri, yaratıcı ipuçlarını ve özel kaynakları doğrudan e-posta kutunuza alın. Tasarım ve inovasyonun geleceğini birlikte keşfedelim.