Yüksek oranda kullanılabilir bir uygulama sunmak için, bir şeyler ters giderse tetiklenecek alarmları ayarlamak standart uygulamadır. Alarmlar şu şekilde tetiklenebilir:
Son zamanlarda AWS uygulama yük dengeleyicimiz, birkaç kez alarmı tetikleyen çok sayıda 504 ve 502 hata kodu oluşturuyor. Soruşturmamız sırasında hiç tüten silah görmedik ve her şey yolundaydı. Bu alarmın gürültülü hale geldiğini fark ettik.
Bu yazıda, alarmı sağlıklı bir duruma getirmek için attığımız adımlardan bahsedeceğim. Bu makaleden kimler yararlanacak:
Yük dengeleyici - Yük dengeleyici, istekleri bir sunucu grubu arasında dağıtan mimari bir bileşendir, böylece hiçbir sunucu bunalmaz.
Yukarı akış hizmeti - Bir yukarı akış hizmeti, aynı iş mantığını çalıştıran bir veya daha fazla sunucuyu ifade eder. Yukarıdaki şemada, Sunucu A, B ve C bir yukarı akış hizmeti oluşturur (yük dengeleyici perspektifinden).
İşlem, PagerDuty'den ELB_5XX alarm bildirimi ile başlatılır:
Sorunu çözmeden önce, kullanıcıların yaşadığı hizmet düşüşü düzeyini düşürmek için atabileceğimiz herhangi bir acil adım olup olmadığını görmemiz gerekiyor. Süreci hızlandırmamıza yardımcı olan farklı hata senaryoları için "çalışma kitapları" yazdık. Uygun çalışma kitabına bağlantı, tetiklenen alarmın açıklamasına dahil edilmiştir. İlk yanıtlayanın, genellikle aşağıdaki yapıya sahip olan çalıştırma kitabını izlemesi yeterlidir:
Konuyu daha derinlemesine incelemeden önce, hataların etkisini belirlememiz ve paydaşlara sürekli durum güncellemeleri vermemiz gerekiyor. Bizim durumumuzda, isteklerin% 0,5'inden azı 502 hatayla sonuçlandı.
Artık paydaşları güncellediğimize göre, sorunu araştırma ve çözme zamanı. Araştırmamız sırasında tetiklenmediğinden emin olmak için alarm eşiğini geçici olarak yükselttim:
Bir yük dengeleyicinin 5XX hatası vermesinin birçok nedeni vardır:
5XX hatalarının aynı yukarı akış sunucusundan kaynaklanıp kaynaklanmadığını kontrol edelim. Bunu, istekleri hedef IP'lerine göre gruplayarak yapabiliriz. Yalnızca bir avuç IP adresi görmeliyiz.
Sorgu sonucu birçok farklı IP adresi içerir, bu nedenle hatanın tek bir yukarı akış sunucusundan kaynaklanmadığını biliyoruz. Araştırmamıza yardımcı olması için kullanabileceğimiz diğer bazı sorgular şunlardır:
5XX ile sonuçlanan taleplerin yanıt süresinin belirlenmesi:
Not: ELB günlüklerimiz için Athena tablosunu yıla, aya ve güne göre indeksledik. Tarih tabanlı bir dizin kullanmak, ilgilendiğimiz zaman diliminde günlük dosyalarını yükleyebildiğimiz ve sorgulayabildiğimiz için kesinlikle çok önemlidir. Bu izole sorgular aşağıdaki faydalara sahiptir:
ELB erişim günlüklerini kapsamlı bir şekilde sorguladıktan sonra, tüm 5XX isteklerimizin 60 saniyelik bir yanıt işleme süresine sahip olduğunu gördük (yani, ELB bir yukarı akış sunucusunun yanıt vermesi için 60 saniye bekledi). Yukarı akış sunucuları yeterince hızlı yanıt vermiyordu, bu da ELB'nin 5XX atmasına neden oldu. Yukarı akış sunucularımızı neden bu kadar yavaş yanıt verdiklerini anlamak için test ettik ve aslında yavaş yanıt vermediklerini gördük.
Biraz araştırma yaptıktan sonra, sorunun tutarsız bir ağ yapılandırması olduğunu keşfettik.
ELB bir yukarı akış sunucusuna bir istek ilettiğinde, bir bağlantı kurulur ve daha sonra bu bağlantı üzerinden veri iletilir ve alınır. Bir bağlantı kurmak yavaş ve pahalıdır; Her istek için yeni bir bağlantı açmamak için, ELB ve yukarı akış sunucularımız birkaç isteği ( canlı tutma bağlantıları olarak bilinir) işlemek için aynı bağlantıyı kullanıyordu .
Yukarı akış sunucularımız kaynakları boşaltmak için bir süre sonra bu bağlantıları kapatacak şekilde yapılandırıldı. Bir yarış durumu nedeniyle ELB'miz bazen bu bağlantıların hala açık olduğunu düşünürdü. ELB bu "hayalet" bağlantı üzerinden veri göndermeyi deneyecek ve yanıt verecek hiçbir şey olmadığından istek zaman aşımına uğrayacaktır.
Bu sorunu gidermek için, yukarı akış sunucumuzun ELB'nin boşta kalma bağlantı zaman aşımından daha büyük bir canlı tutma zaman aşımına sahip olmasını sağladık ve ELB'nin hayalet bağlantıları korumasını sağladık. Bu değişikliği yaptıktan sonra periyodik uyarıları almayı bıraktık ve alarmımız bir kez daha sağlıklı hale geldi.
Bir alarm çözüldüğünde, bir uyarının önemini değerlendirirken dikkate aldığımız bazı ölçümler vardır:
Bu alarmın önemsiz koşullar altında bir daha asla tetiklenmemesini neden istediğimizi özetleyelim:
Verimsizlik dünyanın en büyük işverenidir. Verimsizliği teknoloji ile çok hızlı bir şekilde ortadan kaldırın ve büyük bir sivil huzursuzluğa hazırsınız.
Instagram'ın kullanıcı merkezli tasarım yaklaşımının onu nasıl en popüler sosyal medya platformlarından biri haline getirdiğine dair bilgileri derledim. Basit, sezgisel bir arayüzden kişiselleştirme ve topluluk oluşturma özelliklerine kadar, tasarımcıların Instagram'dan alabilecekleri önemli kullanıcı deneyimi derslerini keşfedin.
Kasım 2020'nin başlarında SalesForce, açıklanamayacak şekilde JARM adlı yeni bir aktif TLS parmak izi alma aracını duyurdu. JARM'ın temeli, bir hedef sunucu özel olarak hazırlanmış çeşitli farklı TCP "İstemci merhaba" paketleri kullanılarak tarandığında, elde edilen yanıtların birleştirilip, paylaşılan veya benzer bir uygulama veya sunucunun göstergesi olan bir parmak izi sağlamak için karma hale getirilebilmesidir. yığını.
Harika geliştiriciler yapan teknik olmayan şeyler Bir süredir bu makaleyi yazmayı erteliyorum - yazmak için hiç nitelikli hissetmedim. Bugün onu yazma zamanının geldiğini düşündüm.
Teknoloji endüstrisindeki bir pozisyon için mülakat yaparken, herhangi bir teklif değerlendirilmeden önce genellikle en az üç tur mülakattan geçeceksiniz. Mermiler genellikle şuna benzer: Eğer öyle düşünüyorsan, yanılıyorsun.
Pragmatik Programcı ilk olarak 1999'da yayınlandı ve o zamandan beri tüm zamanların en iyi programlama kitabı seçildi. Yazarlar Andy Hunt ve David Thomas, Agile Manifesto'nun orijinal yazarları arasındaydı ve bazı ciddi referanslara sahipler.