Linux sistemler stabiliteleriyle bilinse dahi konfigürasyon hataları ve/veya donanım hataları neticesinde sorunlarla karşılaşabiliriz. Bu gibi durumlarda öncelikle sakinliğimizi koruyup en temel semptomları incelememiz ve hatanın nereyi işaret ettiğini bulmamız gerekir.

Hata gidermede olmazsa olmazlar:

– Tam olarak alınan hatanın çeşidi nedir? Servis (daemon) cevap mı vermiyor? Hata mı veriyor?
– Hata ne zaman oluşmaya başladı?
– Hata tekrarlanabiliyor mu? Örneğin servisi her başlatmak istediğimizde aynı hatayı mı veriyor?
– Herhangi bir paterni var mı? Örneğin her saat başı mı yaşanıyor?
– Sistemde en son yapılan değişiklikler nelerdir? Örneğin bir plugin kuruldu mu? Konfigürasyon değiştirildi mi? Elektrik kesintisi yaşandı mı?
– Sorun herkese mi etkiliyor yoksa belirli bir kullanıcı grubunu mu etkiliyor? Örneğin ofis içerisindeki bir bilgisayardan websitesi erişilemezken, başka bir ISS üzerinden erişilebiliyor mu?
– Sistemin fiziksel ve yazılımsal olarak herhangi bir dökümantasyonu var mı?

Öncelikle sistemde sizden başka çalışan biri var mı?

Eğer başka bir sistem yöneticisi de sistem üzerinde çalışıyorsa sistemi çalıştırmak adına reboot ettiğinizde diğer yöneticinin çalışmalarını kaybetmesine neden olabilirsiniz.

# w
# last

Bu komutlar sistemde login olmuş kullanıcıları gösterir.

Sizden önce hangi komutlar girilmiş?

# history

Bu komutla sistemde çalıştırılmış son komutlar incelenebilir. Apache’de hata alıyorsanız ve nano /usr/local/apache/conf/httpd.conf gibi bir komut görüyorsanız birileri Apache konfigürasyonunuzu değiştirmiş demektir ve burayı incelemeniz gerekir.

Sistemde neler çalışıyor?

# pstree -a
# ps aux

Bunlarla sistemde çalışan processleri gösterir ve hata kaynağını tespit etmenizde yardımcı olabilir.

Servisler nerelere bağlanıyor?

# netstat -ntlp
# netstat -nulp
# netstat -nxlp

Hangi servis hangi portta hangi IP ile iletişimde görebilirsiniz. Örneğin httpd üzerinde 1000 tane bağlantı varsa DDOS yaşıyor olabilirsiniz.

CPU ve RAM durumu nedir?

# free -m
# top

Bu komutlarla aşağıdaki sorulara cevap alabilirsiniz:

– Hangi process ne kadar cpu ve ram harcıyor?
– Toplam RAM’de ne kadar boş yer var?
– CPU kullanımı ne durumda?
– Load average nedir?

Sistem logları ve kernel mesajları uyarı veriyor mu?

# dmesg
# tail -f /var/log/messages
# tail -f /var/log/

Bu komutlarla aşağıdaki sorulara cevap alabilirsiniz:

– Özel bir yazılım veya donanım hatası var mı?
– Alınan hatayla loglarda karşılaştığınız hatalar arasında ilişki kurulabiliyor mu?

Sonuç:

Sadece basit bit checklist mahiyeti taşıyan bu yazıyla neler yapılabilir bir fikir vermeye çalıştık, özet olarak aşağıdakileri kontrol etmemiz gerekir:

– Ne çalışıyor?
– Sorun ne kaynaklı? IO/hardware/software/network veya konfigürasyon mu?
– Hatada bir pattern var mı?

Kolay gelsin.

Eğer Nagios, Solarwinds vb. gibi yazılımlara ayırabilecek ekstra bir sunucunuz yoksa ve sunucunuzda çalışan websitelerinin çalışırlığını kontrol etmek için basit bir çözüm arıyorsanız ücretsiz bir android uygulaması olan Network Tools işinizi görecektir.

Yazılımda kontrol etmek istediğiniz websitesini, kontrol aralıklarını ve kontrol metodunu (http get, ping vb.) belirtirseniz arka planda çalışarak websitesi erişilmez olduğunda sesli ve flaşlı uyarı vererek sizi bilgilendirecektir.

Sunucunuzda MySQL’in çok fazla işlemci ve memory harcadığını görüyorsanız aşağıdaki scripti kurarak olası nedenleri inceleyebilirsiniz:

# cd ~
# wget https://raw.github.com/rackerhacker/MySQLTuner-perl/master/mysqltuner.pl
# chmod 777 mysqltuner.pl
# ./mysqltuner.pl

Çıktısı sunucunuzda değişebileceği gibi bizdeki örnekte şekildedir:

root@server [~]# ./mysqltuner.pl

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (>= 8M)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 357M)

Çıktıdan görülebileceği gibi MySQL veritabanını defragment etmemiz gerekiyor ve query cache’i enable ederek %97’ye %3 olan okuma/yazma işlemlerini hızlandırabiliriz. InnoDB’nin ayarlarını da incelemek gerekir.