Her Saniye Çalışma Süresi İzleme - Sunucu İçin Kötü mü?


11

Her saniye bir "HTTP GET İsteği" yaparak bir sunucunun UP olup olmadığını kontrol etmenin avantajları olup olmadığını merak ediyorum?

Herhangi bir sunucu üstesinden gelebilir mi?


Diğer bir seçenek ise bunun tam tersini yapıyor: sunucuyu dışarıdan izlemek yerine ru-on.com gibi sunucuyu içeriden izleyin . Temel olarak sunucunuza başka bir sunucuya çok sık ping uygulayan küçük bir komut dosyası yüklersiniz, böylece çalışma sürenizi web sunucunuz için hayatı zorlaştırmadan izleyebilirsiniz.
Maxim Zaslavsky

3
@Maxim, önerinizle ilgili birkaç sorun var. İlk olarak, HTTP hizmetinin sunucuda çalışıp çalışmadığını kontrol etmez. İkincisi, sunucunun kendisi kapalı olduğunda ne olacağı sorunu var. Bunun hala izlenmesi gerekiyor. Ayrıca, aynı sonuç yerel makineye karşı basit bir hareketle elde edilebilir.
John Gardeniers

Yanıtlar:


26

"Herhangi bir" sunucu bunu halledebilir mi? Muhtemelen.

Yapmalı mısın? Muhtemelen değil.

Kendinize birkaç soru sorun:

  1. Bir kesintiye ne kadar hızlı cevap vereceksiniz?
  2. Saniyede normal olarak kaç sayfa görüntüleme alıyorsunuz?
  3. "Aşağı" çağırmadan ve uyarı göndermeden önce kaç ardışık hatayı görmek istersiniz?
  4. Onurlandırılması gereken dahili veya harici müşterilerle SLA'nız var mı?
  5. Yukarıda listelenen soruları temel alarak makul bir izleme ve yanıt süresi gibi görünen bir şey var mı?

Programlamayı ilk öğrendiğimde, bir kronometre yapmaya karar verdim. Sonunda çalışan bir uygulama aldığımda, dizüstü bilgisayarımdaki CPU kullanımının her çalıştırdığımda% 100 olduğunu fark ettim.

Yürütme döngümün bekleme döngüsü yoktu. Sadece zaman fonksiyonu üzerinden çalışmaya devam etti.

O gün değerli bir ders öğrendim: Sonsuz olarak doğru bir ölçüm diye bir şey yoktur.


6

Diğer herkes gibi ben de teknik tarafı bu kadar sık ​​izlemek istemenin nedenini sormamaya çalışıyorum. Saniyede bir GET isteği, tipik bir sayfa yüküne kıyasla kesinlikle önemsizdir.

Sunucunuz halledebilir mi? Böyle bir soruyu cevaplayacak hiçbir şeyimiz yok, ancak sunucunuzda bir sorun varsa, o zaman başka bir hizmet için tamamen yetersiz olacağını öneririm.


3

Nagios veya munin muhtemelen her saniye testi çalıştırmayı başarabilir, ancak biraz takıntılıdır. Bu kadar sık ​​kontrol etmeniz için bir neden var mı? Sunucunuz bu dengesizse muhtemelen daha derin sorunlarınız vardır.


1

Çoğu ticari izleme yazılımı varsayılan olarak 1 dakikalık veya 5 dakikalık aralık sunar. Bu iyi bir kontrol aralığı gibi görünüyor.


Örneğin Pingdom, bir aralık belirlemenize ve ardından ilk kesintiyi algılamanıza, sunucunun yedeklenip yedeklenmediğini görmek için ping sıklığını artırmanıza izin verir.
Ankur Banerjee

>, frekansı artırın .. => ama minimum hala 1 dak., veya?
sapguy

Ücretsiz hesaplarda Pingdom'un sunduğu en düşük fiyatın 1 dakika olduğunu düşünüyorum. Premium hesabım yok, bu yüzden onlar için daha sık kontroller için bir seçenek sunup sunmadıklarını söyleyemem.
Ankur Banerjee

1

Sunucuyu her saniye izlemede yanlış bir şey yok, özellikle Apache sorgusunun birkaç saniye boyunca askıda kalabileceği yüksek yüke sahip sunucularda çok verimli değil, isteklerinizin o an için yedeklemesine veya yanlış uyarı vermesine neden oluyor, ancak bu Yanlış değil'. Bir saniyelik kontroller yanıt vermenizi hızlandırmaz ve tüm koşulların% 99,9'unda, 10 veya 30 saniyelik bir kontrol de aynı derecede önemlidir.


0

Burada Joseph'e% 100 katılıyorum. Hala bir çeşit gerçek zamanlı izleme yapmak istiyorsanız, web sunucusu günlüğünü hem sunucu hataları hem de günlükte yeni girişlerin olmaması için belirli bir süre koklamayı düşünebilirsiniz. Sunucuya yük yüklemez, ancak uyarıları buna göre tetiklemek zor bir iştir :)


0

1 saniyelik çözünürlük gerçekten yüksek ve muhtemelen gerekmiyor. Ancak munin (5 dakika) gibi diğer OSS araçlarından çok daha yüksek çözünürlük (şimdiye kadar 10 saniye) için tasarlandığı için koleksiyon toplamayı tercih ediyorum.

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.