El değmemiş bir unix sunucusu çılgına dönmeye başladığında kontrol ettiğiniz ilk şey nedir?

Bu düzgün kurulum unix sunucusuna sahipsiniz ve süper hızlı ve harika çalışıyor ve aylarca her şey harika ve birden çok farklı hizmet için her türlü garip hata ortaya çıkmaya başlıyor ve hiçbiri kendi başına çok anlam ifade etmiyor , çok daha az birlikte.

Ssh oturumunu makineye alır almaz kontrol etmeniz gereken ucuz şeyler nelerdir?

Özellikle belirgin olmayan komutları ve nadir durumları vurgulayan travma hikayeleriyle ilgileniyorum, ancak bariz olanın kişiden kişiye değiştiğini tahmin ediyorum, böylece hepsini özgürce listeleyebiliriz.

Birinci Düzen: Duyarlı mı?

Giriş yapamıyorsanız, daha büyük sorunlar var. Bu genellikle iki çeşittir: donanım arızası ve yazılım arızası. Her ikisi de potansiyel olarak felaket. DFA hatalarını önlemek için, önce genel donanım sağlığını kontrol edin - genellikle basit bir bakış yeterli olacaktır.

İkinci Düzen: Sistemin temel yapıları sağlıklı ve düzenli mi?

Sistemlerin "Altın Triadını" kontrol edin:

• İşlem için yeterli CPU süresi ücretsiz
• Depolama için yeterli disk alanı boş
• İş yükleri için yeterli bellek ücretsiz

Son birkaç on yılda, üçlü iletişim (ağ oluşturma) içeren bir "dörtlü" haline geldi:

• Bağlantı işlevsel, duyarlı ve kapasiteye sahip

Üçüncü Düzen: Sorunun şiddeti nedir?

Hangi programlar veya hizmetler etkilenir? Şiddeti azalan sırada, sistemik (sistem çapında), kümelenmiş (bir grup program) veya yalıtılmış (belirli bir program) mı? Belirli bir temel hizmet başarısız olduğu veya yanıt vermediği için program kümeleri genellikle açılır. Sistemik sorunlar bazen bununla ilgilidir (DNS veya IP çatışmalarını düşünün), ancak nereye bakılacağını bilmek genellikle anahtardır.

Dördüncü Düzen: Tanılama araçları, yararlı veriler sağlayan sorunla ilgili mi? Artık sistemin sağlığı (ikinci derece) ve hangi bölümlerinde sorun yaşandığı (üçüncü derece) hakkında bilgi sahibi olduğunuza göre, bu sorunun nerede olduğunu daraltmayı kolaylaştıracaktır.

Hata mesajları veya günlük dosyaları bu yolculukta ortak bir yol noktası olmalıdır.

CPU sorunları:

• loadav
• üst
• strace

Disk alanı / GÇ sorunları:

• df
• du
• lsof
• iostat
• vmstat

Bellek sorunları:

• Bedava

Bağlantı sorunları:

• ping
• rota (ve arp ve rarp ve arkadaşları)
• iptables, ipchains, ipfw (orada BSD millet için)
• traceroute veya mtr
• hosts, nslookup veya dig
• netstat

En yaygın şikayet (duyduğum):

E-posta yeterince hızlı teslim edilmiyor (alıcıdan makbuza gönderime bir dakikadan fazla) veya e-posta gönderme girişimimi reddediyor. Bu genellikle Postfix'teki spam fırtınası sırasındaki hız sınırlayıcısına iner ve bu da dahili teslimatı kabul etme yeteneğini etkiler.

Gerçek hayattan bir örnek:

Ancak, bu her zaman böyle değildir. Bir kez, hizmetin yeniden başlatılmasına bakılmaksızın sorun devam etti; 3 dakika sonra etrafa bakmanın zamanı gelmişti. CPU meşguldü, ancak% 100'ün altındaydı, ancak yük sadece 2 çekirdekli bir kutuda 15'e yükseldi ve daha yükseğe çıkmakla tehdit ediyordu. Üst komut, posta sisteminin posta tarayıcıyla birlikte aşırı hızda olduğunu, ancak görülmesi gereken amavis alt işlemleri olmadığını ortaya çıkardı. İpucu buydu - posta kuyruğu komutu (mailq), % 80'inden fazlası spam olan 150'den fazla teslim edilmemiş ileti gösterdi, son 20 dakika içinde. Alt e-posta tarayıcısı işlemlerinin sayısını artırırken (birikmiş işlenmeye yardımcı olmak için) hız sınırlayıcıyı düşürmek (spam fırtınasının alım oranını düşürmek) için hızlı bir ayarlama, ardından bir hizmetin yeniden başlatılması, sorunu çözdü ve sistem teslimatları kısa sürede tamamlamak.

Sorunun nedeni, amavis ebeveyn sürecinin ölü olarak sallanması ve çocuk süreçlerinin sonunda kendi yollarını çalıştırmalarıydı (bellek sızıntılarını önlemek için birçok taramadan sonra kendiliğinden sona erdi). Bu yüzden postfix'te ihtiyaç duyulan spam / virüs taramasını yapmak için ... ince hava ... ile temas kurmaya çalışan SMTP süreçleri vardı. Kullandığım dağıtımda hiç güncellenmeyecek güncel olmayan paketler vardı; Kurulumun bir yıl içinde değiştirilmesi nedeniyle, kurulumu birkaç hata düzeltmesi içeren en son sürüme manuel olarak "aştım". O zamandan beri aynı problemi yaşamadım.

genellikle "kim" ve ardından "son"

zaman zaman yönettiğim makinelerde bir yığın sorun "el değmemiş" çok gevşek bir tanımı nedeniyle olmuştur - genellikle birisi bir şey yaptı :)

Ben başlayacağım.

Bu beni bir kez ısırdı, binlerce farklı şeyi denemek, burada ve orada hizmetleri devre dışı bırakmak, yeniden başlatmak vb. Saatler harcadım. Sorun neydi? Tamamen disk alanı yetersiz.

İşte, aniden sorunlu bir sunucuda hata ayıklarken yazdığım ilk şey:

df -h

Bunu asla unutmam. Sadece boşa harcanan çabayı kurtardı. Paylaşacağımı düşündüm.

üst (veya htop)

Mümkünse her zaman yönetim NICs çubuğu kapatmayı deneyin.

Kontrol ettiğim ilk şey 'üst' (garip süreçler var mı? Hafızayı veya CPU saatini domuzlayanlar var.)

Orada hiçbir şey ortaya çıkmazsa, herhangi bir nedenle makinemde başka birinin olup olmadığını görmek için 'kimi' kontrol edeceğim.

Belki bir dosya sistemi sökülmüştür; 'cat / etc / mtab' çağrısıyla kontrol edin ve ardından her şeyin önyüklemede doğru olduğundan emin olmak için 'fstab'.

Kutudaki kullanıcı sayısının makul olduğundan emin olmak için çalışma süresini kontrol edin (yalnızca siz olmalısınız) ve orada bir şey olup olmadığını görmek için var / log / auth.log aracılığıyla gözden geçirin.

Bunlar her şeyi yakalar. Kutunuzun attığı hatalara bağlı olarak, soruna neden olan belirli işlemleri incelemeniz gerekebilir.

Ana bilgisayarda (at) sar gibi bir şey çalıştırmak neredeyse zorunludur. CPU, ağ, bellek ve disk I / O'nun (diğerlerinin yanı sıra) tarihsel anlık görüntülerini alabilmenin faydası anlaşılamaz.

Son 24 saat içinde ev sahibinin ne yaptığını inceleyerek ve işlerin ne zaman ters gittiğini görerek bir hatayı teşhis edebildiğim birçok kez oldu.

Dmesg'i herhangi bir hata için kontrol etme - Genellikle bir ile başlarım dmesg | tail, çünkü şanslar hala yanlış gidiyor ve sunucu hala hataya neden olan her şeyi yapmaya çalışıyor.

top df -h ve DAİMA kontrol / var / log bölümünün doldurulmadığından emin olun. Bu birkaç kez üzerimde tamamen erimeye neden oldu.

df -ha

sürücülerin dolu olup olmadığını ve birisinin uyarı almadığını kontrol etmek için

htop veya üst

bellek ve işlemci kullanımını kontrol etmek anormal derecede yüksek değil.

Alternatif olarak, kutu yanıt vermiyorsa vm-ware istemcisine gidip oradan cpu / ram'ı kontrol ederim.

Linux'ta genellikle dmesg ve / var / log / messages veya / var / log / syslog'u kontrol ederim. dmesg ani bir donanım hatası olup olmadığını gösterecektir; sistem günlüklerinde diğer birçok sorun ortaya çıkacaktır.

Sanırım ilk yaptığım şey (diğerlerinin de belirttiği gibi) bir disk alanı kontrolü. Basit kontroller "ortak" bir sorun ortaya çıkarmazsa, daha sonra araştıracağım.

Yapmayı sevdiğim bir şey sistemin anlık görüntüsünü yakalamak. Daha sonra gözüme çarpan herhangi bir şeyi aramak için bunları grep edebilirim.

lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &

Oradan sorun giderme 101 ama kaydedilen günlükleri grep biraz daha hızlı buluyorum ve oturum açtığımda durum temizlenirse devam etmek veya değişiklikleri aramak için bir şey var.