Benim adım Anton Baderin. Yüksek Teknoloji Merkezi'nde çalışıyorum ve sistem yöneticiliği yapıyorum. Bir ay önce, birikmiş deneyimlerimizi şehrimizin BT topluluğuyla paylaştığımız kurumsal konferansımız sona erdi. Web uygulamalarının izlenmesinden bahsetmiştim. Materyal, bu süreci sıfırdan inşa etmeyen orta ve genç seviyelere yönelikti.
Herhangi bir izleme sisteminin temelindeki temel taşı iş sorunlarını çözmektir. İzleme uğruna izlemenin kimseyi ilgilendirmez. İşletme ne istiyor? Böylece her şey hızlı ve hatasız çalışır. İşletmeler proaktif olmak isterler, böylece hizmetteki sorunları kendimiz tespit edip mümkün olan en kısa sürede çözebiliriz. Aslında bunlar, geçen yıl müşterilerimizden birinin projesinde çözdüğüm problemler.
Proje hakkında
Proje, ülkedeki en büyük sadakat programlarından biridir. Bonus kartları gibi çeşitli pazarlama araçlarıyla perakende zincirlerinin satış sıklığını artırmalarına yardımcı oluyoruz. Toplamda proje, on sunucuda çalışan 14 uygulamayı içeriyor.
Görüşme sürecinde, yöneticilerin web uygulamalarını izlemeye her zaman doğru yaklaşmadıklarını defalarca fark ettim: birçoğu hala işletim sistemi ölçümlerine odaklanıyor ve ara sıra hizmetleri izliyor.
Benim durumumda müşterinin izleme sistemi daha önce Icinga'ya dayanıyordu. Yukarıdaki sorunları hiçbir şekilde çözmedi. Çoğunlukla müşterinin kendisi bizi sorunlar hakkında bilgilendirdi ve çoğu zaman da sorunun temeline inmek için yeterli veriye sahip değildik.
Ek olarak, daha fazla gelişmesinin yararsızlığı konusunda da net bir anlayış vardı. Icinga'ya aşina olanların beni anlayacağını düşünüyorum. Bu nedenle proje için web uygulaması izleme sistemini tamamen yeniden tasarlamaya karar verdik.
Prometheus
Prometheus'u üç ana göstergeye dayanarak seçtik:
- Çok sayıda kullanılabilir ölçüm. Bizim durumumuzda 60 bin tane var. Elbette bunların büyük çoğunluğunu (muhtemelen yaklaşık %95'ini) kullanmadığımızı belirtmekte fayda var. Öte yandan hepsi nispeten ucuz. Bizim için bu, daha önce kullanılan Icinga ile karşılaştırıldığında diğer uç noktadır. Bunda metrik eklemek özellikle sıkıntılıydı: Mevcut olanlar pahalıydı (herhangi bir eklentinin kaynak koduna bakmanız yeterli). Herhangi bir eklenti, tüketilen kaynaklar açısından pahalı olan Bash veya Python'daki bir komut dosyasıydı.
- Bu sistem nispeten az miktarda kaynak tüketir. 600 MB RAM, %15 tek çekirdek ve birkaç düzine IOPS tüm ölçümlerimiz için yeterli. Elbette metrik aktarıcıları çalıştırmanız gerekir, ancak bunların hepsi Go'da yazılmıştır ve aynı zamanda çok fazla güce aç değildirler. Modern gerçekliklerde bunun bir sorun olduğunu düşünmüyorum.
- Kubernetes'e geçiş olanağı sağlar. Müşterinin planları göz önüne alındığında seçim açıktır.
ELK
Daha önce günlükleri toplamıyor veya işlemiyorduk. Eksiklikler herkesin malumudur. ELK'yi seçtik çünkü bu sistemle ilgili zaten deneyimimiz vardı. Burada yalnızca uygulama günlüklerini saklıyoruz. Ana seçim kriterleri tam metin araması ve hızıydı.
Clickhouse
Başlangıçta seçim InfluxDB'ye düştü. Nginx günlüklerini, pg_stat_statements'tan istatistik toplama ve Prometheus geçmiş verilerini saklama ihtiyacını fark ettik. Influx'ı sevmiyorduk çünkü periyodik olarak büyük miktarda hafıza tüketmeye başladı ve çöktü. Ayrıca sorguları Remote_addr'a göre gruplamak istedim ancak bu DBMS'de gruplama yalnızca etiketlere göre yapılıyor. Etiketler pahalıdır (bellek), sayıları koşullu olarak sınırlıdır.
Aramalarımıza yeniden başladık. İhtiyaç duyulan şey, minimum kaynak tüketimine sahip, tercihen diskte veri sıkıştırmalı analitik bir veritabanıydı.
Clickhouse tüm bu kriterleri karşılıyor ve seçimimizden hiçbir zaman pişman olmadık. İçine olağanüstü miktarda veri yazmıyoruz (ekleme sayısı dakikada yalnızca beş bin civarında).
NewRelic
NewRelic geçmişten beri bizimle birlikteydi çünkü bu müşterinin tercihiydi. APM olarak kullanıyoruz.
Zabbix
Zabbix'i yalnızca çeşitli API'lerin Kara Kutularını izlemek için kullanıyoruz.
İzleme Yaklaşımının Tanımlanması
Görevi ayrıştırmak ve böylece izleme yaklaşımını sistematize etmek istedik.
Bunu yapmak için sistemimizi aşağıdaki seviyelere ayırdım:
- donanım ve VMS;
- işletim sistemi;
- sistem hizmetleri, yazılım yığını;
- başvuru;
- iş mantığı.
Bu yaklaşım neden uygundur:
- her seviyedeki çalışmalardan kimin sorumlu olduğunu biliyoruz ve buna dayanarak uyarılar gönderebiliriz;
- uyarıları bastırırken bu yapıyı kullanabiliriz; sanal makine bir bütün olarak kullanılamadığında veritabanının kullanılamadığı konusunda bir uyarı göndermek garip olurdu.
Görevimiz sistemin işleyişindeki ihlalleri tespit etmek olduğundan, her düzeyde, uyarı kuralları yazarken dikkat etmeye değer belirli bir dizi metriği vurgulamamız gerekir. Daha sonra “VMS”, “İşletim sistemi” ve “Sistem hizmetleri, yazılım yığını” seviyelerini inceleyelim.
Sanal makineler
Hosting bize bir işlemci, disk, bellek ve ağ ayırır. İlk ikisinde sorun yaşadık. Yani, ölçümler:
CPU çalınma süresi - Amazon'da bir sanal makine (örneğin t2.micro) satın aldığınızda, size işlemci çekirdeğinin tamamının değil, yalnızca zamanının bir kotasının tahsis edildiğini anlamalısınız. Ve onu tükettiğinizde işlemci elinizden alınacaktır.
Bu metrik bu tür anları takip etmenize ve karar vermenize olanak sağlar. Örneğin, daha yüksek bir tarife almak mı gerekiyor yoksa arka plan görevlerinin ve API isteklerinin işlenmesini farklı sunuculara dağıtmak mı gerekiyor?
IOPS + CPU iobekleme süresi - bazı nedenlerden dolayı, birçok bulut barındırma yeterli IOPS sağlamayarak günah işler. Üstelik düşük IOPS'ye sahip bir program onlar için bir argüman değildir. Bu nedenle CPU iowait'i toplamaya değer. Düşük IOPS ve yüksek I/O bekleme süresine sahip bu grafik çiftiyle, barındırma hizmetiyle zaten konuşabilir ve sorunu çözebilirsiniz.
İşletim sistemi
İşletim sistemi ölçümleri:
- % cinsinden kullanılabilir bellek miktarı;
- takas kullanım etkinliği: vmstat takas, takas;
- % olarak dosya sistemindeki kullanılabilir düğüm sayısı ve boş alan
- ortalama yük;
- tw durumundaki bağlantı sayısı;
- tablonun doluluğunu izleyin;
- Ağın kalitesi ss yardımcı programı iproute2 paketi kullanılarak izlenebilir - çıkışından RTT bağlantılarının bir göstergesini alın ve bunu hedef bağlantı noktasına göre gruplayın.
Ayrıca işletim sistemi düzeyinde süreçler diye bir varlığımız var. Sistemde, işleyişinde önemli rol oynayan bir dizi süreci tanımlamak önemlidir. Örneğin, birden fazla pgpool'unuz varsa, bunların her biri için bilgi toplamanız gerekir.
Metrik kümesi aşağıdaki gibidir:
- İŞLEMCİ;
- bellek öncelikle yerleşiktir;
- IO - tercihen IOPS cinsinden;
- FileFd - aç ve sınırla;
- önemli sayfa hataları - bu şekilde hangi işlemin değiştirildiğini anlayabilirsiniz.
Tüm izlemeyi Docker'da dağıtıyoruz ve ölçüm verilerini toplamak için Advisor'ı kullanıyoruz. Diğer makinelerde süreç ihracatçısını kullanıyoruz.
Sistem hizmetleri, yazılım yığını
Her uygulamanın kendine has özellikleri vardır ve belirli bir metrik kümesini belirlemek zordur.
Evrensel küme:
- talep oranı;
- hata sayısı;
- gecikme;
- doyma.
Bu düzeydeki izleme konusunda en çarpıcı örneklerimiz Nginx ve PostgreSQL'dir.
Sistemimizde en çok yüklü servis veritabanıdır. Geçmişte veritabanının ne yaptığını anlamakta sık sık sorun yaşıyorduk.
Disklerde yüksek bir yük olduğunu gördük ancak yavaş günlükler aslında hiçbir şey göstermedi. Bu sorunu, sorgu istatistiklerini toplayan bir görünüm olan pg_stat_statements'ı kullanarak çözdük.
Adminin ihtiyacı olan tek şey bu.
Okuma ve yazma isteklerinin etkinliğinin grafiklerini oluşturuyoruz:
Her şey basit ve net, her isteğin kendine has rengi var.
Aynı derecede çarpıcı bir örnek de Nginx günlükleridir. Çok az kişinin bunları ayrıştırması veya olmazsa olmazlar listesinde bunlardan bahsetmesi şaşırtıcı değil. Standart format çok bilgilendirici değildir ve genişletilmesi gerekmektedir.
Kişisel olarak request_time, upstream_response_time, body_bytes_sent, request_length, request_id'yi ekledim. Yanıt süresini ve hata sayısını çiziyoruz:
Tepki süresi ve hata sayısı grafikleri oluşturuyoruz. Hatırlamak? Ticari görevlerden bahsettim mi? Hızlı ve hatasız mı? Bu konuları daha önce iki grafikte ele almıştık. Ve bunları kullanarak zaten görevdeki yöneticileri arayabilirsiniz.
Ancak olayın nedenlerinin hızla ortadan kaldırılmasını sağlamak için bir sorun daha var.
Olay çözümü
Bir sorunu tanımlamaktan çözmeye kadar tüm süreç birkaç adıma ayrılabilir:
- sorunun belirlenmesi;
- görev yöneticisine bildirim;
- bir olaya tepki;
- nedenlerin ortadan kaldırılması.
Bunu mümkün olduğu kadar çabuk yapmamız önemlidir. Ve eğer sorunu tanımlama ve bildirim gönderme aşamalarında fazla zaman kazanamazsak - her halükarda bunlara iki dakika harcanacak, o zaman sonrakiler iyileştirmeler için basitçe sürülmemiş alanlardır.
Görevli memurun telefonunun çaldığını hayal edelim. Ne yapacak? Ne kırıldı, nerede kırıldı, nasıl tepki verilecek gibi soruların yanıtlarını arayın. Bu sorulara şu şekilde cevap vereceğiz:
Tüm bu bilgileri bildirim metnine dahil ediyoruz ve bu soruna nasıl müdahale edileceğini, sorunun nasıl çözüleceğini ve üst kademeye iletileceğini açıklayan bir wiki sayfasının bağlantısını veriyoruz.
Henüz uygulama katmanına ve iş mantığına dair bir şey söylemedim. Ne yazık ki uygulamalarımız henüz metrik toplamayı uygulamamaktadır. Bu düzeylerdeki bilgilerin tek kaynağı günlüklerdir.
Birkaç nokta.
İlk önce yapılandırılmış günlükler yazın. Mesajın metnine bağlam eklemeye gerek yoktur. Bu onların gruplandırılmasını ve analiz edilmesini zorlaştırır. Logstash'ın tüm bunları normalleştirmesi uzun zaman alıyor.
İkinci olarak önem düzeylerini doğru kullanın. Her dilin kendine has standardı vardır. Şahsen ben dört seviyeyi ayırt ediyorum:
- hata yok;
- istemci tarafı hatası;
- hata bizden yana, para kaybetmiyoruz, riske girmiyoruz;
- Hata bizden yana, para kaybediyoruz.
Özetleyeyim. İzlemeyi iş mantığına dayalı olarak oluşturmaya çalışmanız gerekir. Uygulamanın kendisini izlemeye çalışın ve satış sayısı, yeni kullanıcı kayıt sayısı, mevcut aktif kullanıcı sayısı gibi metriklerle çalışın.
İşletmenizin tamamı tarayıcıdaki tek bir düğme ise, tıklanıp düzgün çalışıp çalışmadığını izlemeniz gerekir. Geri kalan her şey önemli değil.
Eğer buna sahip değilseniz, bizim yaptığımız gibi uygulama günlüklerinde, Nginx günlüklerinde vb. yakalamayı deneyebilirsiniz. Uygulamaya mümkün olduğunca yakın olmalısınız.
İşletim sistemi metrikleri elbette önemli ama iş dünyası bunlarla ilgilenmiyor, bunların karşılığında bize ödeme yapılmıyor.
Kaynak: habr.com