İzleme öldü mü? — Uzun süreli izleme

Şirketimiz 2008 yılından bu yana öncelikli olarak web projeleri için altyapı yönetimi ve 400 saat teknik destek hizmetleri vermektedir: 15'den fazla müşterimiz bulunmaktadır, bu da Rusya e-ticaretinin yaklaşık %15'ini oluşturmaktadır. Buna göre çok çeşitli bir mimari desteklenmektedir. Bir şey düşerse XNUMX dakika içinde tamir etmekle yükümlüyüz. Ancak bir kazanın meydana geldiğini anlamak için projeyi izlemeniz ve olaylara müdahale etmeniz gerekir. Bu nasıl yapılır?

Uygun bir izleme sisteminin organize edilmesinde bir sorun olduğuna inanıyorum. Eğer bir sorun olmasaydı konuşmam tek bir tezden oluşacaktı: “Lütfen Prometheus + Grafana ve eklenti 1, 2, 3'ü kurun.” Maalesef artık bu şekilde çalışmıyor. Ve asıl sorun, herkesin yazılım bileşenleri açısından 2008'de var olan bir şeye inanmaya devam etmesi.

İzleme sisteminin organizasyonuyla ilgili olarak şunu söylemeyi cüret edebilirim... yetkin izlemeye sahip projeler mevcut değil. Ve durum o kadar kötü ki, bir şey düşerse fark edilmeme riski var - sonuçta herkes "her şeyin izlendiğinden" emin.
Belki de her şey izleniyor. Ama nasıl?

Hepimiz şöyle bir hikayeyle karşılaşmışızdır: Bir devops, bir admin çalışıyor, bir geliştirme ekibi yanlarına gelip “serbest kaldık, şimdi izliyoruz” diyor. Neyi izlemek? Nasıl çalışır?

TAMAM. Eski yöntemle izliyoruz. Ve bu zaten değişiyor ve ortaya çıktı ki, C hizmetiyle etkileşime giren B hizmeti haline gelen A hizmetini izlediniz. Ancak geliştirme ekibi size şunu söylüyor: "Yazılımı yükleyin, her şeyi izlemesi gerekiyor!"

Peki ne değişti? - Her şey değişti!

2008 Herşey yolunda

Birkaç geliştirici, bir sunucu, bir veritabanı sunucusu var. Her şey buradan devam ediyor. Elimizde bazı bilgiler var, zabbix, Nagios, kaktüsler kuruyoruz. Daha sonra CPU, disk işlemi ve disk alanı hakkında net uyarılar ayarlıyoruz. Ayrıca sitenin yanıt verdiğinden ve siparişlerin veritabanına ulaştığından emin olmak için birkaç manuel kontrol de yapıyoruz. İşte bu kadar; az çok korunuyoruz.

Yöneticinin izleme sağlamak için yaptığı iş miktarını karşılaştırırsak, bunun %98'inin otomatik olduğunu görürüz: izlemeyi yapan kişinin Zabbix'i nasıl kuracağını, nasıl yapılandıracağını ve uyarıları nasıl yapılandıracağını anlaması gerekir. Ve %2 - harici kontroller için: sitenin yanıt vermesi ve veritabanına istekte bulunması, yeni siparişlerin gelmesi.

2010 Yük artıyor

Bir arama motoru ekleyerek web'i ölçeklendirmeye başlıyoruz. Ürün kataloğunun tüm ürünleri içerdiğinden emin olmak istiyoruz. Ve bu ürün araması işe yarıyor. Veritabanının çalıştığı, siparişlerin verildiği, sitenin dışarıdan yanıt verdiği ve iki sunucudan yanıt verdiği ve başka bir sunucuya yeniden dengelenirken kullanıcının siteden atılmadığı vb. Daha fazla varlık var.

Üstelik altyapıyla ilgili varlık hâlâ yöneticinin kafasındaki en büyük varlık olmaya devam ediyor. İzlemeyi yapan kişinin zabbix'i kuracak ve konfigürasyonunu yapabilecek kişi olduğu fikri hala kafamda var.

Ancak aynı zamanda, harici kontrollerin yapılması, bir dizi arama indeksleyici sorgu komut dosyası oluşturulması, indeksleme işlemi sırasında aramanın değiştiğini kontrol etmek için bir dizi komut dosyası, malların sunucuya aktarılıp aktarılmadığını kontrol eden bir dizi komut dosyası oluşturulması üzerinde çalışmalar ortaya çıkıyor. teslimat hizmeti vb. ve benzeri.

Not: 3 kez “bir dizi senaryo” yazdım. Yani izlemeden sorumlu kişi artık sadece zabbix'i kuran kişi değil. Bu kodlamaya başlayan bir kişidir. Ancak takımın kafasında henüz hiçbir şey değişmedi.

Ancak dünya değişiyor, giderek daha karmaşık hale geliyor. Bir sanallaştırma katmanı ve birkaç yeni sistem eklenir. Birbirleriyle etkileşime girmeye başlarlar. Kim "mikro hizmetler gibi kokuyor" dedi? Ancak her hizmet yine de ayrı ayrı bir web sitesi gibi görünüyor. Ona dönüp gerekli bilgileri sağladığını ve kendi kendine çalıştığını anlayabiliriz. Ve eğer 5-7-10 yıldır gelişen bir projeye sürekli dahil olan bir yönetici iseniz, bu bilgi birikir: yeni bir seviye ortaya çıkar - fark ettiniz, başka bir seviye belirir - fark ettiniz...

Ancak nadiren bir projeye 10 yıl boyunca eşlik eden olur.

Monitoringman'ın özgeçmişi

Diyelim ki hemen 20 geliştiriciyi işe alan, 15 mikro hizmet yazan yeni bir girişime geldiniz ve size şu söylenen bir yöneticisiniz: "CI/CD oluşturun. Lütfen." CI/CD'yi oluşturdunuz ve aniden şunu duydunuz: "Uygulamanın içinde nasıl çalışacağını anlamadan, bir "küp" içinde üretimle çalışmak bizim için zor. Bize aynı "küp" içinde bir sanal alan yapın.
Bu küpte bir sanal alan oluşturuyorsunuz. Size hemen şunu söylüyorlar: “Üretimden itibaren her gün güncellenen bir sahne veri tabanı istiyoruz ki veri tabanında çalıştığını anlayalım ama aynı zamanda üretim veri tabanını da bozmayalım.”

Bunların hepsini yaşıyorsun. Çıkışa 2 hafta kaldı, diyorlar ki: “Şimdi tüm bunları izleyelim…” Yani. küme altyapısını izleyin, mikro hizmet mimarisini izleyin, dış hizmetlerle çalışmayı izleyin...

Ve meslektaşlarım her zamanki planı kafalarından çıkarıp şöyle diyorlar: “Burada her şey açık! Tüm bunları izleyecek bir program yükleyin.” Evet, evet: Prometheus + Grafana + eklentileri.
Ve şunu ekliyorlar: “İki haftanız var, her şeyin güvende olduğundan emin olun.”

Gördüğümüz birçok projede izleme için bir kişi ayrılıyor. 2 hafta boyunca takip yapacak bir kişiyi işe almak istediğimizi ve onun için bir özgeçmiş yazdığımızı düşünün. Şu ana kadar söylediklerimize göre bu kişinin hangi becerilere sahip olması gerekir?

• Demir altyapısının işleyişinin izlenmesini ve özelliklerini anlamalıdır.
• Kubernetes'i izlemenin özelliklerini anlamalıdır (ve herkes "küp" e gitmek ister, çünkü her şeyden soyutlayabilirsiniz, gizleyebilirsiniz, çünkü yönetici geri kalanıyla ilgilenecektir) - kendisi, altyapısı ve uygulamaların nasıl izleneceğini anlamalıdır. içeri.
• Hizmetlerin birbirleriyle özel yollarla iletişim kurduğunu anlamalı ve hizmetlerin birbirleriyle nasıl etkileşim kurduğunun ayrıntılarını bilmelidir. Bazı servislerin senkronize olarak haberleştiği bir proje görmek oldukça mümkün çünkü başka yolu yok. Örneğin, arka uç REST aracılığıyla, gRPC aracılığıyla katalog hizmetine gider, bir ürün listesi alır ve onu geri gönderir. Burada bekleyemezsin. Ve diğer hizmetlerle eşzamansız olarak çalışır. Siparişi teslimat servisine aktarın, bir mektup gönderin vb.
  Muhtemelen tüm bunlardan zaten yüzdünüz? Ve bunu takip etmesi gereken yöneticinin kafası daha da karıştı.
• İş gittikçe daha fazla hale geldikçe, doğru bir şekilde planlayabilmeli ve planlayabilmelidir.
• Bu nedenle, oluşturulan hizmetin özel olarak nasıl izleneceğini anlamak için oluşturulan hizmetten bir strateji oluşturması gerekir. Projenin mimarisini ve gelişimini anlaması + geliştirmede kullanılan teknolojileri anlaması gerekiyor.

Kesinlikle normal bir durumu hatırlayalım: bazı hizmetler PHP'de, bazı hizmetler Go'da, bazı hizmetler JS'de. Bir şekilde birbirleriyle çalışıyorlar. “Mikro hizmet” terimi buradan geliyor: O kadar çok bireysel sistem var ki geliştiriciler projeyi bir bütün olarak anlayamıyor. Ekibin bir kısmı JS'de kendi başına çalışan hizmetler yazıyor ve sistemin geri kalanının nasıl çalıştığını bilmiyor. Diğer kısım ise hizmetleri Python'da yazıyor ve diğer hizmetlerin işleyişine müdahale etmiyor; kendi alanlarında izole edilmiş durumdalar. Üçüncüsü, PHP veya başka bir şeyle hizmetler yazmaktır.
Bu 20 kişinin tamamı 15 hizmete bölünmüştür ve tüm bunları anlaması gereken tek bir yönetici vardır. Durmak! 15 kişi tüm sistemi anlayamadığından sistemi 20 mikro hizmete ayırdık.

Ama bir şekilde takip edilmesi gerekiyor...

Sonuç nedir? Sonuç olarak, tüm geliştirici ekibinin anlayamadığı her şeyi ortaya çıkaran bir kişi var ve aynı zamanda yukarıda belirttiğimiz şeyleri de bilmesi ve yapabilmesi gerekiyor - donanım altyapısı, Kubernetes altyapısı vb.

Ne diyebilirim ki... Houston, sorunlarımız var.

Modern bir yazılım projesinin izlenmesi başlı başına bir yazılım projesidir

İzlemenin yazılım olduğuna dair yanlış inançtan mucizelere olan inancımızı geliştiriyoruz. Ama ne yazık ki mucizeler olmuyor. Zabbix'i kurup her şeyin çalışmasını bekleyemezsiniz. Grafana'yı kurup her şeyin yoluna gireceğini ummanın bir anlamı yok. Zamanın çoğu, hizmetlerin işleyişinin ve birbirleriyle etkileşimlerinin kontrollerini organize etmek, dış sistemlerin nasıl çalıştığını kontrol etmek için harcanacaktır. Aslında zamanın %90'ı senaryo yazmaya değil, yazılım geliştirmeye harcanacak. Ve projenin çalışmasını anlayan bir ekip tarafından ele alınmalıdır.
Bu durumda bir kişi gözetim altına alınırsa felaket olur. Her yerde olan budur.

Örneğin Kafka üzerinden birbirleriyle iletişim kuran birçok servis var. Sipariş geldi, Kafka'ya siparişle ilgili mesaj gönderdik. Siparişle ilgili bilgileri dinleyen ve malları gönderen bir servis var. Siparişle ilgili bilgileri dinleyen ve kullanıcıya mektup gönderen bir servis var. Ve sonra bir sürü hizmet daha ortaya çıkıyor ve kafamız karışmaya başlıyor.

Ve bunu, yayına kısa bir süre kaldığı aşamada yönetici ve geliştiricilere de verirseniz, kişinin bu protokolün tamamını anlaması gerekecektir. Onlar. Bu ölçekte bir proje önemli miktarda zaman alır ve bunun sistem geliştirme sürecine dahil edilmesi gerekir.
Ancak sıklıkla, özellikle de start-up'larda, izlemenin nasıl daha sonraya ertelendiğini görüyoruz. “Şimdi bir Kavram Kanıtı hazırlayacağız, onunla birlikte yola çıkacağız, bırakın düşsün; fedakarlık yapmaya hazırız. Daha sonra hepsini izleyeceğiz." Proje para kazanmaya başladığında (ya da eğer) işletme daha da fazla özellik eklemek ister; çünkü çalışmaya başlamıştır ve bu nedenle daha da yaygınlaştırılması gerekmektedir! Ve ilk önce önceki her şeyi izlemeniz gereken noktadasınız, bu da zamanın %1'ini değil, çok daha fazlasını alır. Bu arada, izleme için geliştiricilere ihtiyaç duyulacak ve onların yeni özellikler üzerinde çalışmasına izin vermek daha kolay olacak. Sonuç olarak yeni özellikler yazılıyor, her şey altüst oluyor ve sonsuz bir çıkmaza giriyorsunuz.

Peki bir projeyi en başından nasıl izleyeceksiniz ve izlenmesi gereken bir projeniz varsa ancak nereden başlayacağınızı bilmiyorsanız ne yapmalısınız?

İlk önce planlamanız gerekir.

Lirik ara söz: Çoğu zaman altyapı izlemeyle başlarlar. Örneğin Kubernetes'imiz var. Prometheus'u Grafana ile kurarak, "küpü" izlemek için eklentiler kurarak başlayalım. Yalnızca geliştiricilerin değil, yöneticilerin de şu talihsiz uygulaması var: "Bu eklentiyi kuracağız, ancak eklenti muhtemelen nasıl yapılacağını biliyordur." İnsanlar önemli eylemlerden ziyade basit ve anlaşılır olanlarla başlamayı severler. Altyapı izlemesi de kolaydır.

Öncelikle neyi ve nasıl izlemek istediğinize karar verin ve ardından bir araç seçin çünkü diğer insanlar sizin yerinize düşünemez. Peki yapmalılar mı? Diğer insanlar evrensel bir sistem hakkında kendi kendilerine düşündüler ya da bu eklenti yazıldığında hiç düşünmediler. Ve bu eklentinin 5 bin kullanıcısı olması onun herhangi bir işe yaradığı anlamına gelmiyor. Belki de daha önce orada 5001 kişi olduğu için 5000'inci olacaksınız.

Altyapıyı izlemeye başlarsanız ve uygulamanızın arka ucu yanıt vermeyi durdurursa tüm kullanıcıların mobil uygulamayla bağlantısı kesilir. Bir hata görünecektir. Yanınıza gelip “Uygulama çalışmıyor, burada ne işiniz var?” diyecekler. - "İzliyoruz." — “Uygulamanın çalışmadığını görmezseniz nasıl takip edeceksiniz?!”

1. İzlemeye tam olarak kullanıcının giriş noktasından başlamanız gerektiğine inanıyorum. Kullanıcı uygulamanın çalıştığını görmüyorsa bu bir başarısızlıktır. Ve izleme sistemi öncelikle bu konuda uyarıda bulunmalıdır.
2. Ve ancak o zaman altyapıyı izleyebiliyoruz. Veya paralel olarak yapın. Altyapıyla daha kolay - burada nihayet zabbix'i kurabiliyoruz.
3. Artık işlerin nerede yolunda gitmediğini anlamak için uygulamanın köklerine gitmeniz gerekiyor.

Benim ana fikrim izlemenin geliştirme süreciyle paralel gitmesi gerektiğidir. İzleme ekibinin dikkatini başka görevler (CI/CD oluşturma, korumalı alan oluşturma, altyapının yeniden düzenlenmesi) için dağıtırsanız, izleme gecikmeye başlayacak ve geliştirme sürecine asla yetişemeyebilirsiniz (veya er ya da geç onu durdurmak zorunda kalacaksınız).

Seviyelere göre her şey

Bir izleme sisteminin organizasyonunu böyle görüyorum.

1) Uygulama düzeyi:

• uygulama iş mantığını izleme;
• hizmetlerin sağlık ölçümlerinin izlenmesi;
• entegrasyon izleme.

2) Altyapı seviyesi:

• orkestrasyon seviyesi izleme;
• sistem yazılımı izleme;
• demir seviyesi izleme.

3) Yine uygulama düzeyi - ancak bir mühendislik ürünü olarak:

• uygulama günlüklerinin toplanması ve izlenmesi;
• EYLEM SAYISI;
• izleme.

4) Uyarı:

• bir uyarı sisteminin organizasyonu;
• görev sisteminin organizasyonu;
• Olayların işlenmesi için bir “bilgi tabanının” ve iş akışının organizasyonu.

Bu çok önemli: Uyarıya sonradan değil, hemen ulaşıyoruz! İzlemeyi başlatmaya ve "bir şekilde daha sonra" kimin uyarı alacağını bulmaya gerek yok. Sonuçta izlemenin görevi nedir: Sistemde bir şeyin nerede yanlış çalıştığını anlamak ve doğru kişilerin bunu bilmesini sağlamak. Bunu sonuna kadar bırakırsanız, o zaman doğru kişiler bir şeylerin ters gittiğini ancak "bizim için hiçbir şey yolunda gitmiyor" diyerek anlayacaklardır.

Uygulama Katmanı - İş Mantığı İzleme

Burada uygulamanın kullanıcı için çalışıp çalışmadığını kontrol etmekten bahsediyoruz.

Bu seviye geliştirme aşamasında yapılmalıdır. Örneğin, koşullu bir Prometheus'umuz var: kontrolleri yapan sunucuya gider, uç noktayı çeker ve uç nokta gidip API'yi kontrol eder.

Sitenin çalıştığından emin olmak için ana sayfayı izlemeleri sıklıkla istendiğinde programcılar, API'nin çalıştığından emin olmak için her ihtiyaç duyduklarında çekilebilecek bir tanıtıcı verir. Ve şu anda programcılar hala /api/test/helloworld alıp yazıyor
Her şeyin çalıştığından emin olmanın tek yolu mu? - HAYIR!

• Bu tür kontroller oluşturmak aslında geliştiricilerin görevidir. Birim testleri kodu yazan programcılar tarafından yazılmalıdır. Çünkü bunu yöneticiye sızdırırsanız, "Dostum, işte 25 işlevin tamamı için API protokollerinin listesi, lütfen her şeyi izle!" - hiçbir şey işe yaramayacak.
• "Merhaba dünya" yazarsanız hiç kimse API'nin çalışması gerektiğini ve çalıştığını bilemez. Her API değişikliği, kontrollerde bir değişikliğe yol açmalıdır.
• Zaten böyle bir sorununuz varsa, özellikleri durdurun ve bu çekleri yazacak geliştiricilere tahsis edin veya kayıpları kabul edin, hiçbir şeyin kontrol edilmediğini ve başarısız olmayacağını kabul edin.

Teknik İpuçları:

• Kontrolleri düzenlemek için harici bir sunucu düzenlediğinizden emin olun; projenizin dış dünya tarafından erişilebilir olduğundan emin olmalısınız.
• Denetimleri yalnızca bireysel uç noktalarda değil, API protokolünün tamamında düzenleyin.
• Test sonuçlarıyla bir prometheus uç noktası oluşturun.

Uygulama katmanı - sağlık ölçümlerinin izlenmesi

Artık hizmetlerin dış sağlık metriklerinden bahsediyoruz.

Uygulamanın tüm "tanımlayıcılarını" harici bir izleme sisteminden çağırdığımız harici kontrolleri kullanarak izlemeye karar verdik. Ancak bunlar kullanıcının "gördüğü" "tutamaçlardır". Hizmetlerimizin çalıştığından emin olmak istiyoruz. Burada daha iyi bir hikaye var: K8'lerin sağlık kontrolleri var, böylece en azından "küpün" kendisi hizmetin çalıştığına ikna edilebilir. Ama gördüğüm çeklerin yarısı aynı "merhaba dünya" yazısı. Onlar. Bu yüzden konuşlandırıldıktan sonra bir kez çekti, her şeyin yolunda olduğunu söyledi - hepsi bu. Ve hizmet, eğer kendi API'sini sağlıyorsa, aynı API için çok sayıda giriş noktasına sahiptir ve bunların da izlenmesi gerekir çünkü çalıştığını bilmek isteriz. Zaten içeriden de bunu takip ediyoruz.

Bunu teknik olarak doğru bir şekilde nasıl uygulayabiliriz: Her hizmet, mevcut performansıyla ilgili bir uç noktayı ortaya çıkarır ve Grafana'nın (veya başka herhangi bir uygulamanın) grafiklerinde tüm hizmetlerin durumunu görürüz.

• Her API değişikliği, kontrollerde bir değişikliğe yol açmalıdır.
• Sağlık ölçümleriyle hemen yeni bir hizmet oluşturun.
• Bir yönetici geliştiricilere gelip "bana birkaç özellik ekleyin böylece her şeyi anlayabileyim ve bununla ilgili bilgileri izleme sistemime ekleyeyim" diye sorabilir. Ancak geliştiriciler genellikle şu yanıtı verir: "Yayınlanmadan iki hafta önce hiçbir şey eklemeyeceğiz."
  Geliştirme yöneticilerine bu tür kayıplar olacağını bildirin, geliştirme yöneticilerinin yönetimine de bildirin. Çünkü her şey düştüğünde, birileri yine de arayacak ve "sürekli düşen hizmeti" izlemeyi talep edecek (c)
• Bu arada, geliştiricilerin Grafana için eklentiler yazmasını sağlayın; bu, yöneticiler için iyi bir yardımcı olacaktır.

Uygulama Katmanı - Entegrasyon İzleme

Entegrasyon izleme, iş açısından kritik sistemler arasındaki iletişimin izlenmesine odaklanır.

Örneğin birbiriyle haberleşen 15 servis var. Bunlar artık ayrı siteler değil. Onlar. servisi tek başına çekemeyiz, /helloworld alıp servisin çalıştığını anlayamayız. Sipariş web hizmetinin siparişle ilgili bilgileri otobüse göndermesi gerektiğinden, depo hizmetinin bu mesajı alması ve onunla daha fazla çalışması gerekir. Ve e-posta dağıtım hizmetinin bunu bir şekilde daha ileri düzeyde işlemesi gerekir, vb.

Buna göre, her bir hizmeti tek tek inceleyerek hepsinin işe yaradığını anlayamayız. Çünkü her şeyin iletişim kurduğu ve etkileşime girdiği belli bir veri yolumuz var.
Dolayısıyla bu aşama, hizmetlerin diğer hizmetlerle etkileşiminin test edilmesi aşamasını işaret etmelidir. Mesaj komisyoncusunu izleyerek iletişim izlemeyi organize etmek imkansızdır. Veri veren bir hizmet ve onu alan bir hizmet varsa, aracıyı izlerken yalnızca bir yandan diğer yana uçan verileri göreceğiz. Bu verilerin etkileşimini bir şekilde dahili olarak izlemeyi başarmış olsak bile (belirli bir üreticinin verileri yayınlaması, birisinin okuması, bu akışın Kafka'ya gitmeye devam etmesi), eğer bir hizmet mesajı tek bir versiyonda göndermişse, bu yine de bize bilgi vermeyecektir. ancak diğer hizmet bu sürümü beklemiyordu ve atladı. Hizmetler bize her şeyin çalıştığını söyleyeceğinden bunu bilmeyeceğiz.

Yapmanızı tavsiye ettiğim şey:

• Senkronize iletişim için: uç nokta ilgili hizmetlere istekte bulunur. Onlar. bu uç noktayı alıyoruz, servisin içine tüm noktalara giden ve "Şuraya çekebilirim, oraya çekebilirim, oraya çekebilirim..." diyen bir script çekiyoruz.
• Asenkron iletişim için: gelen mesajlar - uç nokta, veri yolunu test mesajları açısından kontrol eder ve işlem durumunu görüntüler.
• Asenkron iletişim için: giden mesajlar - uç nokta veri yoluna test mesajları gönderir.

Genellikle olduğu gibi: verileri veri yoluna atan bir hizmetimiz var. Biz bu hizmete geliyoruz ve entegrasyon sağlığını bize anlatmanızı istiyoruz. Ve eğer hizmetin daha ileri bir yerde (WebApp) bir mesaj üretmesi gerekiyorsa, o zaman bu test mesajını üretecektir. Ve eğer OrderProcessing tarafında bir servis çalıştırıyorsak, önce bağımsız olarak ne gönderebileceğini yayınlar ve bazı bağımlı şeyler varsa, veri yolundan bir dizi test mesajını okur, bunları işleyebileceğini anlar, rapor eder ve , gerekirse bunları daha da yayınlayın ve bunun hakkında diyor ki - her şey yolunda, yaşıyorum.

“Bunu savaş verileri üzerinde nasıl test edebiliriz?” sorusunu sıklıkla duyuyoruz. Örneğin aynı sipariş hizmetinden bahsediyoruz. Sipariş, malların silindiği depoya mesajlar gönderiyor: Bunu savaş verileri üzerinde test edemiyoruz çünkü "mallarım silinecek!" Çözüm: Bu testin tamamını başlangıçta planlayın. Ayrıca alay eden birim testleriniz de var. Yani bunu, işletmenin işleyişine zarar vermeyecek bir iletişim kanalına sahip olduğunuz daha derin bir seviyede yapın.

Altyapı katmanı

Altyapı izleme, uzun süredir izlemenin kendisi olarak kabul edilen bir şeydir.

• Altyapı izleme ayrı bir süreç olarak başlatılabilir ve başlatılmalıdır.
• Gerçekten isteseniz bile, çalışan bir projede altyapı izlemeye başlamamalısınız. Bu tüm devop'lar için bir acıdır. “Önce kümeyi izleyeceğim, altyapıyı izleyeceğim” – yani. Öncelikle aşağıda ne olduğunu izleyecek ancak uygulamaya girmeyecek. Çünkü uygulama devops için anlaşılmaz bir şey. Ona sızdırıldı ve nasıl çalıştığını anlamıyor. Ve altyapıyı anlıyor ve onunla başlıyor. Ancak hayır; her zaman önce uygulamayı izlemeniz gerekir.
• Uyarıların sayısında aşırıya kaçmayın. Modern sistemlerin karmaşıklığı göz önüne alındığında, uyarılar sürekli uçuşuyor ve bir şekilde bu uyarı yığınıyla yaşamak zorundasınız. Ve nöbetçi kişi, sonraki yüzlerce uyarıya baktıktan sonra "Bunun hakkında düşünmek istemiyorum" kararına varacaktır. Uyarılar yalnızca kritik şeyler hakkında bildirimde bulunmalıdır.

Bir iş birimi olarak uygulama düzeyi

Anahtar noktalar:

• ELK. Bu endüstri standardıdır. Herhangi bir nedenle günlükleri toplamıyorsanız bunu hemen yapmaya başlayın.
• EYLEM SAYISI. Uygulama izlemeyi hızla kapatmanın bir yolu olarak harici APM'ler (NewRelic, BlackFire, Datadog). En azından bir şekilde size neler olduğunu anlamak için bu şeyi geçici olarak kurabilirsiniz.
• İzleme. Düzinelerce mikro hizmette her şeyin izini sürmek zorundasınız çünkü istek artık kendi başına yaşamıyor. Daha sonra eklemek çok zordur, bu nedenle geliştirme aşamasında izlemeyi hemen planlamak daha iyidir - bu, geliştiricilerin işi ve faydasıdır. Henüz uygulamadıysanız uygulayın! Jaeger/Zipkin'e bakın

Uyarı

• Bir bildirim sisteminin organizasyonu: Bir dizi şeyin izlenmesi koşullarında, bildirimlerin gönderilmesi için birleşik bir sistem bulunmalıdır. Grafana'da yapabilirsiniz. Batı'da herkes PagerDuty'yi kullanıyor. Uyarılar açık olmalıdır (örneğin nereden geldikleri...). Ayrıca bildirimlerin alınıp alınmadığının kontrol edilmesi tavsiye edilir.
• Görev sisteminin organizasyonu: herkese uyarı gönderilmemelidir (ya kalabalıkta herkes tepki verecektir ya da kimse tepki vermeyecektir). Geliştiricilerin de hazır olmaları gerekir: sorumluluk alanlarını tanımladığınızdan, net talimatlar verdiğinizden ve Pazartesi ve Çarşamba günleri tam olarak kimi arayacaklarını ve Salı ve Cuma günleri kimi arayacaklarını yazdığınızdan emin olun (aksi takdirde kimseyi aramazlar bile) büyük bir sorun olması durumunda - sizi uyandırmaktan veya rahatsız etmekten korkacaklar: insanlar genellikle aramayı ve diğer insanları uyandırmayı sevmezler, özellikle geceleri). Ve yardım istemenin beceriksizlik göstergesi olmadığını açıklayın (“Yardım istiyorum, bu kötü bir çalışan olduğum anlamına gelir”), yardım isteklerini teşvik edin.
• Olayların işlenmesi için bir "bilgi tabanı" ve iş akışının düzenlenmesi: Her ciddi olay için bir otopsi planlanmalı ve geçici bir önlem olarak olayı çözecek eylemler kaydedilmelidir. Tekrarlanan uyarıların günah olduğunu bir alışkanlık haline getirin; kod veya altyapı çalışmalarında düzeltilmeleri gerekiyor.

Teknoloji yığını

Yığımızın aşağıdaki gibi olduğunu düşünelim:

• veri toplama - Prometheus + Grafana;
• günlük analizi - ELK;
• APM veya İzleme için - Jaeger (Zipkin).

Seçeneklerin seçimi kritik değildir. Çünkü başlangıçta sistemi nasıl izleyeceğinizi anladıysanız ve bir plan yazdıysanız, gereksinimlerinize uygun araçları seçmeye başlarsınız. Soru, ilk etapta neyi izlemeyi seçtiğinizdir. Çünkü belki de başlangıçta seçtiğiniz araç gereksinimlerinize hiç uymuyor.

Son zamanlarda her yerde gördüğüm birkaç teknik nokta:

Prometheus Kubernetes'in içine itiliyor - bunu kim buldu?! Kümeniz çökerse ne yapacaksınız? İçerisinde karmaşık bir kümeniz varsa, kümenin içinde ve dışında kümenin içinden veri toplayacak bir tür izleme sistemi bulunmalıdır.

Kümenin içinde günlükleri ve diğer her şeyi topluyoruz. Ancak izleme sistemi dışarıda olmalı. Çoğu zaman, dahili olarak Promtheus'un kurulu olduğu bir kümede, sitenin çalışmasının harici kontrollerini gerçekleştiren sistemler de vardır. Peki ya dış dünyayla bağlantınız koptuysa ve uygulama çalışmıyorsa? İçeride her şeyin yolunda olduğu anlaşılıyor ancak bu, kullanıcıların işini hiç de kolaylaştırmıyor.

Bulgular

• Geliştirmenin izlenmesi, yardımcı programların kurulumu değil, bir yazılım ürününün geliştirilmesidir. Bugünkü izlemenin %98'i kodlamadır. Hizmetlerde kodlama, dış kontrolleri kodlama, dış hizmetleri kontrol etme ve hepsi bu.
• Geliştiricilerinizin zamanını izlemeyle harcamayın: bu onların işlerinin %30'unu alabilir ama buna değer.
• Devops, bir şeyi izleyemeyeceğin için endişelenme çünkü bazı şeyler tamamen farklı bir düşünme şeklidir. Siz bir programcı değildiniz ve işi izlemek tam olarak onların işi.
• Proje zaten çalışıyorsa ve izlenmiyorsa (ve siz bir yöneticiyseniz), izleme için kaynakları tahsis edin.
• Ürün zaten üretimdeyse ve size "izlemeyi kurmanız" söylenen bir devops iseniz - tüm bunları ne hakkında yazdığımı yönetime açıklamaya çalışın.

Bu, Saint Highload++ konferansındaki raporun genişletilmiş versiyonudur.

Bu konu ve ilgili konular hakkındaki fikirlerim ve düşüncelerim ilginizi çekiyorsa, buradan ulaşabilirsiniz. kanalı oku 🙂

Kaynak: habr.com