Derinlemesine Master Nginx izleme işlemi ve bakımı, bu makale yeterlidir!
Nginx, açık kaynaklı, ücretsiz, yüksek performanslı bir HTTP ve ters proxy sunucusudur ve ayrıca bir IMAP / POP3 proxy sunucusu olarak da kullanılabilir. Nginx'in özelliklerinden tam olarak yararlanmak, yüksek trafik eşzamanlı istekleri ve cc saldırıları gibi sorunları etkili bir şekilde çözebilir.
Bu makale, e-ticaret senaryosunda Nginx izleme programını tartışmakta ve kullanım sürecinde karşılaşılan sorunları ve çözümleri herkesle paylaşmaktadır.
Nginx özellikleri
Bir web sunucusu olarak Nginx, Apache ile karşılaştırılmalıdır.
Apache sunucusuyla karşılaştırıldığında, Nginx, eşzamansız ve engellemesiz çalışma modeli nedeniyle yüksek eşzamanlılık ve düşük kaynak tüketimi özelliklerine sahiptir.Yüksek modüler tasarım, Nginx'i çok genişletilebilir kılar; statik dosyaları ve ters proxy isteklerini işlerken Diğer yönlerden Nginx büyük avantajlar gösteriyor.
Nginx'i kullanmanın yaygın yolları
Nginx, kullanıcı isteklerini iletmek için bir ters proxy sunucusu olarak kullanılabilir ve istekleri dağıtma işlevini gerçekleştirmek için istekleri işleme sürecinde arka uç örnek yük dengeleme uygulayabilir; Nginx ayrıca statik istekleri işlemek için yerel bir statik sunucu olarak yapılandırılabilir.
Nginx izleme
İzleme göstergelerinin sıralanması
Hizmetin zamanında düzgün çalışıp çalışmadığını öğrenebilmemiz için Nginx işleme taleplerinin tüm süreci izlenmelidir.
Nginx işleme taleplerinin süreci ayrıntılı olarak access.log ve error.log dosyalarına kaydedilir.İzlenmesi gereken aşağıdaki (Tablo 1) temel göstergeleri veriyoruz:
Tablo 1: Temel göstergeler
İzleme uygulaması
Aşağıda, gecikme, hata, akış ve doygunluğun dört göstergesinden Nginx izleme uygulaması açıklanmaktadır.
Gecikme izleme
Gecikme izleme esas olarak $ request_time'ın izlenmesine odaklanır ve TP99 gösterge değerini doğrulamak için TP gösterge grafiğini çizer.
Ek olarak, gecikme sorununun nedenini bulmaya yardımcı olmak için $ upstream_response_time göstergesinin izlenmesini de artırabiliriz.
Şekil 1: TP göstergesi
Şekil 1, son 15 dakika içinde Nginx'in kullanıcı taleplerini işlemek için harcadığı süreyi göstermektedir.Kullanıcı taleplerinin% 90'ının 0.1s'de işlenebildiği ve taleplerin% 99'unun 0.3s'de tamamlanabildiği görülebilmektedir.
TP endeks değerine ve belirli işletmenin gecikme toleransına göre gecikme alarmı eşiğini ayarlayın.
Hata izleme
Bir web sunucusu olarak Nginx, yalnızca Nginx'in kendi çalışma durumunu izlemekle kalmamalı, aynı zamanda Nginx'in çeşitli hata yanıtlarını da izlemelidir. HTTP hata durum kodları ve error.log'da kaydedilen ayrıntılı hata günlükleri, sorunların çözülmesine yardımcı olmak için izlenmelidir .
HTTP semantiğine dayalı Nginx port izleme
Basit Nginx bağlantı noktası izleme, hizmetin gerçek çalışma durumunu yansıtamaz. Dikkat etmemiz gereken şey, Nginx'in kendisinin hayatta kalması ve normal hizmet sağlayıp sağlayamayacağıdır.
Uygulamamıza dayanarak, döndürülen veri biçiminin, içeriğin ve HTTP durum kodunun beklentileri karşılayıp karşılamadığını doğrulamak için bağlantı noktası izleme yerine anlamsal izleme, yani http: // local_ip: port / adresindeki Nginx yerel makinesinden erişim kullanmanızı öneririz.
Hata kodu izleme
Hizmetin kendisiyle ilgili bir sorun olduğunu bize bildiren 500/502/504 gibi 5xx hizmet hata durum kodlarının izlenmesini eklemek gerekir.
Şekil 2: Durum kodu izleme
5xx hatalarının sıklığı dakikada tek basamaklı olmalıdır. Çok fazla sayıda 5xx hatası zamanında araştırılmalı ve çözülmelidir; 4xx hataları bazı beklenmedik izin hatalarının, kaynak kaybının veya performans sorunlarının çözülmesine yardımcı olabilir.
301/302 yeniden yönlendirme türünü seçerek izleyebilir ve özel yapılandırma atlamalarının izlenmesine yanıt verebilirsiniz.Örneğin, arka uç sunucusu 5xx'i döndürdükten sonra, Nginx yeniden yönlendirme atlamasını yapılandırır ve atlamadan sonra istek sonucunu döndürür.
Hata günlüğünü izleyin
Nginx, istek işleme hatalarının ayrıntılı kayıtlarını dahili olarak uygular ve bunları error.log dosyasına kaydeder.
Pek çok hata türü vardır. Sorun gidermede bize yardımcı olmak için esas olarak sunucu tarafı istisnalarını yansıtabilecek kritik hataları toplar ve izleriz:
Tablo 2: Hata günlüğü bilgileri
veri izleme
Nginx tarafından kabul edilen toplam istek sayısını izleme
Trafik dalgalanmaları döngüsüne dikkat edin ve trafikteki ani artış ve düşüşleri yakalayın; genellikle, sabit durumda% 20'lik düşük tepe ve tepe dalgalanmaları dikkat gerektirir.
Belirgin dalgalanma döngüleri olan hizmetler için, zaman içindeki trafik değişikliklerini tespit etmek için aynı çeyrekte halka artırma / azaltma uyarısı stratejisini de kullanabiliriz.
Şekil 3: PV akış şeması
Şekil 4: Temel akış şeması
Şekil 3, belirli bir JD Cloud platformunun bir hafta içindeki akış dalgalanma diyagramını göstermektedir Akışın belirgin düşük zirveleri ve zirveleri vardır ve belirli bir gün periyoduna sahiptir.
Web sitesinin çalışma özelliklerine bağlı olarak, web sitesi trafiğindeki dalgalanmayı düşük ve tepe değerlere göre izler ve sorun gidermeye yardımcı olmak için web sitesinin ana sayfalarının trafik grafiğini kendi izleme panosu (Şekil 4) aracılığıyla yapılandırır.
Şekil 5: Ağ kartı akış şeması
Ağ kartı IO gibi makine düzeyinde trafiği izleyin
Sunucu donanım yükünün baskısı zamanında bulunabilir.Nginx bir dosya sunucusu oluşturmak için kullanıldığında, bu izleme göstergesi özel dikkat göstermemizi gerektirir.
Doygunluk izleme
Google SRE'de belirtildiği gibi, doygunluk, kaynakların hizmet tarafından kullanımına ve hizmetin mevcut çalışma koşullarında ne kadar yüke dayanabileceğine odaklanmalıdır.
Nginx düşük kaynak tüketimi olan yüksek performanslı bir sunucudur ancak e-ticaret senaryolarında yeni ürünlerin yakalanması CPU kullanımında, talep edilen bağlantı sayısında ve kısa sürede disk yazımlarında artışa neden olacaktır.
CPU kullanımı ayrıca, Worker işlemlerinin worker_cpu_affinity aracılığıyla belirli CPU çekirdeklerine bağlanmasının kullanımını da dikkate almalıdır.Yüksek trafik işlenirken, bu yapılandırma CPU anahtarlamasının performans kaybını azaltabilir.
Nginx'in kabul edebileceği maksimum bağlantı sayısı, nginx.conf yapılandırma dosyasındaki iki parametrenin worker_processes ve worker_connections ürününe göre belirlenir.
Şekil 6
Nginx'in kendi modülü http_stub_status_module, Nginx'in gerçek zamanlı çalışma bilgisini izlemek için kullanılabilir (Şekil 6).
Mevcut Nginx operasyonu hakkında daha fazla endişe duyduğumuz ve işlenen taleplere çok fazla dikkat etmediğimiz için, yalnızca aşağıdaki göstergeleri topluyor ve izliyoruz:
Tablo 3: Gösterge anlamı
Açık kaynaklı yazılıma dayalı Nginx görsel izleme sistemi oluşturun
Görsel günlük izleme oluşturmak için Elasticsearch + Logstash + Kibana kullanın
Şekil 7: ELK yığın mimarisi diyagramı
Yukarıdaki dört altın izleme göstergesi için, ELK yığını kontrol panelini oluşturun ve sorunları hızlı bir şekilde bulmak ve analiz etmek için ortak Nginx günlük filtreleme kuralları (Şekil 8) oluşturun.
Şekil 8: ELK kontrol paneli
Görsel günlük izleme oluşturmak için Kibana + Elasticsearch + Rsyslog + Grafana kullanın
Şekil 9: Grafana görsel mimari diyagramı
Kibana'nın günlükleri hızlı bir şekilde alma yeteneği ile karşılaştırıldığında Grafana, veri görüntüleme konusunda daha fazla esnekliğe sahiptir ve bazı durumlarda ikisi birbirini tamamlayabilir.
Şekil 10: Grafana kontrol paneli
Uygulamada, yukarıdaki iki mimarinin Nginx log görsel izlemesini uyguluyoruz; gereksinimlerin kendisinden, ELK yığın modeli, temelde Nginx günlük izleme ihtiyaçlarını karşılayabilen gerçek zamanlı günlük alma, çeşitli günlük kurallarının filtrelenmesi ve veri görüntüleme sağlayabilir.
Grafana mimari modeli, günlük alma ve tarama gerçekleştiremez, ancak bazı hassas verilere erişimi korumak için rol izinleri işlevi sağlar.
Ayrıca, Grafana'nın daha zengin grafik türleri ve veri kaynağı desteği, daha fazla uygulama senaryosuna sahip olmasını sağlar.
Nginx izlemeye dayalı sorun durumlarını bulun ve bulun
Durum 1: Büyük akış etkisi
Soru: Belirli bir platform yeni bir ürün için panik satın alma faaliyeti gerçekleştirdi. Etkinlik sırasında, trafikteki artış nedeniyle, ürün detay sayfaları ve sipariş verme gibi temel işlevler için işlem süresi arttı.
Şekil 11: PV dalgalanma grafiği
Çözüm: Sipariş izleme ve Nginx'in PV'si, istek zamanı ve diğer izleme göstergeleri bir alarm verdikten sonra, işletme ve bakım personeli web sitesi trafiğindeki değişikliklere dikkat etmek ve en iyi IP ve üst URL için kullanıcı isteklerini kontrol etmek için kendi kendine oluşturulmuş ELK izleme panosunu hızlı bir şekilde kullandı; çok sayıda scalper bulundu Kötü niyetli panik satın alma davranışı, hizmetin arka uç işlemesinde gecikmelere neden olur.
Bu nedenle, yüksek savunma ürünlerinde ve Nginx mevcut sınırlayıcı yapılandırmada ilgili arayüzlerin anti-saldırı eşiklerini düşürerek, sistem yüküne baskı yapan sipariş kaydırma davranışını zamanında yakaladık ve yeni ürün promosyonlarının sorunsuz bir şekilde geliştirilmesini sağladık.
Durum 2: Nginx hata durum kodu uyarısı hizmet istisnası
Sorun: Belirli bir platform, arka uç sunucusunu ayarlıyor ve belirli bir Nginx'in yukarı akışının işaret ettiği arka uç sunucusu, beklenmedik bir arka uç hizmetine işaret edecek şekilde yanlış yapılandırılmış.
Yanlış yapılandırma çevrimiçi olarak yayınlandığında, web sitesi, artan sayıda 500 ve 302 hata durum koduyla birlikte olasılık anormallikleri göstermeye başladı.
Şekil 12: 302 hata kodu istatistikleri
Çözüm: Nginx hata durum kodu alarma geçtikten sonra 302 hata kodu altında kullanıcı tarafından talep edilen URL ELK platformu üzerinden filtrelenerek istenen URL'nin belirli bir arka uç modülü ile ilgili olduğu tespit edilerek talebin web sitesinin ana sayfasına yönlendirildiği tespit edilir.
Daha fazla konumlandırma, belirli bir Nginx'in yanlış arka uç sunucuyu işaret ettiğini ve sunucunun çok sayıda 500 hata döndürmesine neden olduğunu, ancak Nginx yapılandırmasındaki 500 hatanın yeniden yönlendirilmesi nedeniyle birçok 302 durum kodu üretildiğini buldu.
Şekil 13: Yukarı akış durum izlemeyi yapılandırın
Sonraki iyileştirmelerde, Nginx'i yükselttik ve yukarı akıştaki sunucuyu dinamik olarak güncellemek için arka uç sunucunun sağlığını izlemek için openresty + lua yöntemini uyguladık (Şekil 13), bu da hızlı durdurma kaybı elde etmek için anormal arka uç sunucuları hızla kaldırabilir amaç.
Durum 3: Nginx sunucu disk alanı tükendi ve hizmet anormal
Sorun: Nginx, görüntü sunucusunun ön ucu olarak görev yapıyor Bir gün, örneklerden biri, üretim ortamında hiçbir değişiklik olmadığında bir alarm mesajı aldı: 500 durum kodu, genel trafiğin çok fazlasını oluşturuyordu.
Çözüm: Bu makineyi hızlı bir şekilde üretim ortamından kaldırın ve artık hizmet sağlamayın. Nginx hata günlüğünü kontrol ettikten sonra aşağıdaki hata bulundu:
open () "/ home / work / upload / client_body_temp / 0000030704" başarısız oldu (28: Cihazda yer kalmadı)Nginx isteği işlediğinde, client_body_buffer_size isteğini aşan istemci POST isteğinin içeriğinin bir kısmını veya tamamını client_body_temp_path dizininde geçici olarak depolayacaktır Disk alanı dolduğunda, yukarıdaki hata üretilir.
Sonunda, bu anormalliğin, desteklenen resim boyutunun ürün yükseltmesinden sonra 15MB'den 50MB'ye değiştirilmesinden ve operatörün yeni bir ürün tanıtım faaliyeti gerçekleştirmesinden ve kullanıcılar tarafından yüklenen görüntülerin miktarının artarak disk alanını hızla doldurmasından kaynaklandığını doğruladık.
