Beklenmedik Linux sunucusunun kapatılması nasıl araştırılır?


16

Debian 6 ile 10 baskısında 4xSSD'li yeni bir Xeon 55XX sunucusunda, sunucu kurulduktan sonra iki hafta içinde 2 rastgele kapanma yaşadım. Kapatılmadan önce bant genişliği günlüklerine bakmak olağandışı bir şey olduğunu göstermez. Sunucu yükü genellikle çok düşüktür (yaklaşık 1) ve uzak konumlandırılmıştır. Sunucu kapatılırken elektrik kesintisi görülmemektedir.

/ Var / log'a baktığımı biliyorum ama hangi günlükleri araştırmam ve ne aramam gerektiğinden emin değilim. Bu yüzden ipuçlarınızı takdir edin.


Sorunun ne olduğunu buldun mu?
cherouvim

Yanıtlar:


11

İlk olarak şunu sormalıyım: "kapatmalar"? Makinenin yeniden başlatıldığını mı, yoksa gerçekten durduğunu mu söylüyorsunuz? Durursa, yanlış yapılandırılmıştır (belki de BIOS'ta) veya bir şey makineyi aktif olarak kapatıyor (yani init 0).

Değilse, birincil adayınız / var / log / syslog ve /var/log/kern.log olacaktır. Tabii ki, sunucu bazı hizmetler (örneğin apache) çalıştırırsa size bir ipucu verebilir.

Genellikle, bu gibi durumlarda, oluşturulan günlük girişleri vardır, ancak makine zorluklarla karşılaştığından, girişleri diske yazmayı başaramaz. Kutu yerleştirilirse, büyük olasılıkla colo ortağı tarafından seri bir konsola bağlanma olasılığı vardır. Yukarıdaki günlüklerde şüpheli bir şey bulamazsam işte burada görünecektim.

Makine bir seri konsola bağlı değilse ve günlükte hiçbir şey yoksa, syslog'u ağ üzerinden farklı bir kutuya göndermeyi düşünebilirsiniz. Belki de ağ arabirimi biraz daha uzun süre kalır ve günlük iletileri syslog sunucusunda okunabilir. Rsyslog veya syslog-ng'ye bir göz atın.

GÜNCELLEME:

Aşağıdaki @Johann'a katılıyorum. Duruşun en olası nedeni işlemci sıcaklığı bekçi köpeğidir. Kutudaki sıcaklığı lmsensors veya smartctl (genellikle en kolay) ile kontrol etmeyi / çizmeyi deneyin. Collect'in zaman içinde çok sayıda değişkeni takip etmede benzersiz olduğunu düşünüyorum. Hem IPMI hem de lm sensörleri ve hddtemp yapabilir. Ayrıca, bazı BIOS: es sıcaklık durdurma olaylarını günlüğe kaydeder.


Makine gitti ve desteğin manuel olarak başlatmasını istedikten hemen sonra hayata döndü.
alfish

Sıcaklık söz konusuysa, eğilimleri tespit etmek için zaman içinde sıcaklık verilerini izlemek için munin kurun.
pkhamre

Sıcaklık sorunlarına +1. Bir veri merkezindeki sunucularımdan birinde aynı şey vardı - sistemi oluşturduklarında CPU fanlarından birini bağlamayı unuttular.
Hibe

9

İlk olarak kontrol etmek istersiniz /var/log/syslog. Eğer emin aramaya ne iseniz, sözcüklere bakarak başlayabilirsiniz error, panicve warning.

grep -i error /var/log/syslog

Sistem grafikleriniz varsa (örn. Munin). Onları kontrol edin ve anormal kalıplar arayın. Eğer yüklü munin yoksa, kurmak bir fikir olabilir ( apt-get install munin munin-node)

Ayrıca, sistem çökmenizle ilgili olabilecek ilginç iletiler için kök postaları da kontrol etmelisiniz.

Kontrol etmeniz gereken diğer günlük dosyaları uygulama hata günlükleridir. Örneğin /var/log/apache2/error.logveya benzer. Sizi soruna götüren bilgiler içerebilirler.


6

Deneyimlerime göre, "beklenmedik bir durma" neredeyse her zaman aşırı ısınmadan kaynaklanır. Sıcaklık ve fan hızlarınızı lm_sensors üzerinden kontrol edin ve iyi olduklarından emin olun.

Son zamanlarda aynı kalıp vardı: Bir sunucu, desteğin elle başlatılmasından yaklaşık bir saat sonra durdu. Bu saatlerden sonra CPU sıcaklığı BIOS'ta (iirc 60 veya 70 ° C) yapılandırılan eşik değerine ulaştı ve sistemi durdurdu. Tüm bu sorunlar, bozuk bir CPU fanının neden olduğu yerlerde. Fanı değiştirdikten sonra her şey normale döndü.


2

/ Var / log dizininde (ve alt dizinlerinde) bir dizi günlük dosyası vardır.

/var/log/boot

ve

/var/log/boot.log

Yukarıdaki dosyalarla başlayın.


Ve "ne" aramaya?
Pierre.Vriens

Bu, meydana gelen hatanın türüne bağlıdır. Çoğu durumda, temel neden bir çekirdek çökmesi, bir elektrik kesintisi veya aşırı ısınmaya bağlı CPU kapatmasıdır, bu da günlük dosyalarına bir giriş yazacak ve diske akıtacak kimse olmadığı anlamına gelir, bu yüzden orada hiç mesaj olmayacaktır. .
asdmin

1

Neyin tetiklendiğini kapatmanın kontrol edilmesinin 2 yolu vardır, ilk önce donanımdaki herhangi bir sorun için Bant Dışı Yönetim konsolunu kontrol edin, SNMP'yi yapılandırmanızı ve e-posta almanızı veya herhangi bir uyarı için bir izleme yazılımına tuzaklar eklemenizi öneririm.

Daha sonra İşletim Sistemi aracılığıyla /var/log/messages(RedHat tabanlı dağıtımlar) veya /var/log/syslog(Debian Tabanlı dağıtımlar) seçeneğini işaretleyebilirsiniz.


0

Disk alt sistemi, bir sorun oluştuğunda etkilenecek kadar karmaşıktır, çünkü günlük dosyalarınıza neredeyse hiç bir şey alamazsınız.

Seri konsolda oturum açmayı deneyin. Bu, kabloları almak için biraz kabloya ve başka bir sisteme ihtiyaç duyar, ancak sorunu yakalama şansınız daha yüksektir.

Tabii ki düğümünüzde Oracle'ın ALOM / ILOM'una benzer yerleşik bir yönetim sistemi varsa, olası sorunları ve günlük dosyalarını orada da kontrol edebilirsiniz.


-1

Sistemin sonraki komutlarla çalıştığını bilip bilmediğini bulabilirsiniz

sudo last -1x reboot
sudo last -1x shutdown

Hiçbir bilgi => değilse, güç kaybı veya harici bir şey olabilir

Eğer bilgi => yeniden başlatma / kapatma süresi etrafında günlüklerde arama

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.