Bugün projemizde monolitik kodun yanı sıra onlarca mikro hizmet de yer alıyor. Her birinin izlenmesi gerekiyor. DevOps mühendislerini kullanarak bunu bu kadar ölçekte yapmak sorunludur. Geliştiricilere hizmet olarak çalışan bir izleme sistemi geliştirdik. İzleme sistemine bağımsız olarak metrikler yazabilir, bunları kullanabilir, bunlara dayalı gösterge tabloları oluşturabilir ve bunlara eşik değerlerine ulaşıldığında tetiklenecek uyarılar ekleyebilirler. DevOps mühendisleri için yalnızca altyapı ve belgeler.
Bu yazı bizim ile yaptığım konuşmanın transkriptidir. RIT++'da. Birçok kişi bizden raporların metin versiyonlarını oradan yapmamızı istedi. Konferanstaysanız veya videoyu izlediyseniz yeni bir şey bulamazsınız. Ve diğer herkes - kediye hoş geldiniz. Sizlere böyle bir sisteme nasıl geldiğimizi, nasıl çalıştığını ve nasıl güncellemeyi planladığımızı anlatacağım.
Geçmiş: şemalar ve planlar
Mevcut izleme sistemine nasıl ulaştık? Bu soruyu cevaplamak için 2015 yılına gitmeniz gerekiyor. O zaman şöyle görünüyordu:
İzlemeden sorumlu yaklaşık 24 düğümümüz vardı. Bir şeyleri bir şekilde izleyen, mesaj gönderen ve işlevleri yerine getiren bir sürü farklı taç, komut dosyası ve arka plan programı var. Biz ne kadar ileri gidersek böyle bir sistemin uygulanabilirliğinin o kadar azalacağını düşündük. Bunu geliştirmenin bir anlamı yok: çok hantal.
Tutacağımız ve geliştireceğimiz izleme unsurlarını ve bırakacağımız unsurları seçmeye karar verdik. Bunlardan 19 tane vardı, geriye sadece grafit, toplayıcı ve gösterge paneli olarak Grafana kaldı. Peki yeni sistem nasıl görünecek? Bunun gibi:
Bir metrik depolama alanımız var: bunlar hızlı SSD sürücüleri temel alacak olan grafitlerdir, bunlar metrikler için belirli toplayıcılardır. Sonraki - Gösterge tablolarını görüntülemek için Grafana ve uyarı vermek için Moira. Ayrıca anormalliklerin aranmasına yönelik bir sistem geliştirmek istedik.
Standart: İzleme 2.0
2015 yılında planlar bu şekildeydi. Ama bunun için sadece altyapıyı ve hizmetin kendisini değil, dokümantasyonunu da hazırlamamız gerekiyordu. Kendimiz için izleme 2.0 dediğimiz kurumsal bir standart geliştirdik. Sistem gereksinimleri nelerdi?
- sürekli kullanılabilirlik;
- metrik depolama aralığı = 10 saniye;
- ölçümlerin ve gösterge tablolarının yapılandırılmış depolanması;
- SLA > %99,99
- UDP (!) aracılığıyla olay ölçümlerinin toplanması.
UDP'ye ihtiyacımız vardı çünkü büyük bir trafik akışımız ve metrikler oluşturan olaylar var. Hepsini birden grafite yazarsanız depo çöker. Ayrıca tüm metrikler için birinci düzey önekleri seçtik.
Öneklerin her birinin bir özelliği vardır. Sunucular, ağlar, kapsayıcılar, kaynaklar, uygulamalar vb. için ölçümler vardır. Birinci düzey metrikleri kabul ettiğimiz ve geri kalanını bıraktığımız açık, katı ve yazılı filtreleme uygulandı. 2015 yılında bu sistemi bu şekilde planladık. Şu anda ne var?
Mevcut: izleme bileşenlerinin etkileşiminin şeması
Öncelikle uygulamaları izliyoruz: PHP kodumuzu, uygulamalarımızı ve mikro hizmetlerimizi, kısacası geliştiricilerimizin yazdığı her şeyi. Tüm uygulamalar, metrikleri UDP aracılığıyla Brubeck toplayıcıya (statsd, C dilinde yeniden yazılmıştır) gönderir. Sentetik testlerde en hızlı olduğu ortaya çıktı. Ve halihazırda toplanmış ölçümleri TCP aracılığıyla Grafit'e gönderir.
Zamanlayıcılar adı verilen bir tür ölçüm vardır. Bu çok uygun bir şey. Örneğin, hizmete yapılan her kullanıcı bağlantısı için Brubeck'e yanıt süresini içeren bir ölçüm gönderirsiniz. Bir milyon yanıt geldi, ancak toplayıcı yalnızca 10 ölçüm döndürdü. Gelen kişi sayısını, maksimum, minimum ve ortalama yanıt süresini, medyanı ve yüzde 4'ü biliyorsunuz. Daha sonra veriler Graphite'e aktarılıyor ve hepsini canlı olarak görüyoruz.
Ayrıca donanım, yazılım, sistem ölçümleri ve eski Munin izleme sistemimiz (2015'e kadar bizim için çalıştı) ile ilgili ölçümler için toplamamız da var. Tüm bunları C daemon CollectD aracılığıyla topluyoruz (içinde yerleşik bir sürü farklı eklenti var, kurulu olduğu ana bilgisayar sisteminin tüm kaynaklarını yoklayabilir, sadece yapılandırmada verilerin nereye yazılacağını belirtin) ve verileri bunun aracılığıyla Grafit'e yazın. Aynı zamanda python eklentilerini ve kabuk komut dosyalarını da destekler, böylece kendi özel çözümlerinizi yazabilirsiniz: CollectD bu verileri yerel veya uzak bir ana bilgisayardan (Curl varsayarak) toplayacak ve Graphite'e gönderecektir.
Daha sonra topladığımız tüm metrikleri Carbon-c-relay'e gönderiyoruz. Bu, Graphite'in C dilinde değiştirilmiş Carbon Relay çözümüdür. Bu, toplayıcılarımızdan gönderdiğimiz tüm ölçümleri toplayan ve bunları düğümlere yönlendiren bir yönlendiricidir. Ayrıca yönlendirme aşamasında metriklerin geçerliliğini kontrol eder. Birincisi, daha önce gösterdiğim önek şemasına uygun olmaları ve ikincisi de grafit için geçerli olmalarıdır. Aksi halde düşecekler.
Karbon-c-rölesi daha sonra metrikleri Grafit kümesine gönderir. Metriklerin ana deposu olarak Go'da yeniden yazılan Carbon-cache'i kullanıyoruz. Go-karbon, çoklu iş parçacığı nedeniyle Carbon-önbellekten çok daha iyi performans gösterir. Verileri alır ve fısıltı paketini (standart, python ile yazılmış) kullanarak disklere yazar. Depolarımızdan veri okumak için Graphite API'yi kullanıyoruz. Standart Grafit WEB'den çok daha hızlıdır. Bundan sonra verilere ne olacak?
Grafana'ya gidiyorlar. Ana veri kaynağı olarak grafit kümelerimizi kullanıyoruz, ayrıca ölçümleri görüntülemek ve gösterge tabloları oluşturmak için bir web arayüzü olarak Grafana'ya sahibiz. Geliştiriciler, hizmetlerinin her biri için kendi kontrol panelini oluşturur. Daha sonra bunlara dayanarak, uygulamalarından yazdıkları ölçümleri gösteren grafikler oluştururlar. Grafana'nın yanı sıra SLAM'imiz de var. Bu, grafitten elde edilen verilere dayanarak SLA'yı hesaplayan bir python şeytanıdır. Daha önce de söylediğim gibi, her birinin kendi gereksinimleri olan birkaç düzine mikro hizmetimiz var. SLAM'i kullanarak belgelere gidip bunu Grafit'tekilerle karşılaştırıyoruz ve gereksinimlerin hizmetlerimizin kullanılabilirliğiyle ne kadar iyi eşleştiğini karşılaştırıyoruz.
Daha da ileri gidelim: uyarı. Güçlü bir sistem olan Moira kullanılarak organize edilmiştir. Bağımsızdır çünkü kaputunun altında kendi Grafit'i vardır. SKB "Kontur" adamları tarafından geliştirilen, python ve Go ile yazılmış, tamamen açık kaynak. Moira, grafitlere giden akışın aynısını alıyor. Herhangi bir nedenle depolama alanınız ölürse uyarılarınız çalışmaya devam edecektir.
Moira'yı Kubernetes'te konuşlandırdık; ana veritabanı olarak bir Redis sunucuları kümesini kullanıyor. Sonuç, hataya dayanıklı bir sistemdi. Metrik akışını tetikleyicilerin listesiyle karşılaştırır: İçinde hiç bahsedilmiyorsa metriği düşürür. Böylece dakikada gigabaytlarca ölçümü sindirebilir.
Ayrıca, kurumsal sistemin her kullanıcısının mevcut (veya yeni oluşturulan) tetikleyicilere göre kendileri için bildirimler oluşturabileceği kurumsal bir LDAP ekledik. Moira Grafit içerdiğinden tüm özelliklerini desteklemektedir. Yani önce satırı alıp Grafana'ya kopyalıyorsunuz. Verilerin grafiklerde nasıl görüntülendiğini görün. Sonra aynı satırı alıp Moira'ya kopyalıyorsunuz. Limitlere asıyorsunuz ve çıkışta uyarı alıyorsunuz. Tüm bunları yapmak için herhangi bir özel bilgiye ihtiyacınız yoktur. Moira SMS, e-posta, Jira, Slack yoluyla uyarı verebilir... Ayrıca özel komut dosyalarının yürütülmesini de destekler. Başına bir tetikleyici geldiğinde ve özel bir komut dosyasına veya ikili dosyaya abone olduğunda, onu çalıştırır ve bu ikili dosya için JSON'u stdin'e gönderir. Buna göre programınızın onu ayrıştırması gerekir. Bu JSON ile ne yapacağınız size kalmış. İsterseniz Telegram'a gönderin, isterseniz Jira'da görevler açın, ne yaparsanız yapın.
Ayrıca uyarı için kendi geliştirmemizi de kullanıyoruz: Imagotag. Genellikle mağazalarda elektronik fiyat etiketleri için kullanılan paneli ihtiyaçlarımıza uygun hale getirdik. Moira'dan tetikleyiciler getirdik. Hangi durumda olduklarını ve ne zaman meydana geldiklerini gösterir. Geliştirme uzmanlarından bazıları Slack'teki bildirimleri ve e-postaları bu panel lehine terk etti.
Peki biz ilerici bir firma olduğumuz için Kubernetes'i de bu sistemde takip ettik. Cluster'a kurduğumuz Heapster'ı kullanarak sisteme dahil ettik, verileri topluyor ve Graphite'e gönderiyor. Sonuç olarak diyagram şöyle görünür:
İzleme Bileşenleri
Bu görev için kullandığımız bileşenlerin bağlantılarının bir listesini burada bulabilirsiniz. Hepsi açık kaynaktır.
Grafit:
- go-karbon:
- fısıltı:
- grafit-api:
Karbon-c-rölesi:
- Brubeck:
Toplanan:
- Moira:
Grafana:
Yığın deposu:
istatistik
Ve burada sistemin bizim için nasıl çalıştığına dair bazı rakamlar var.
Toplayıcı (brubeck)
Metrik sayısı: ~300/sn
Metrikleri Grafit'e gönderme aralığı: 30 saniye
Sunucu kaynağı kullanımı: ~%6 CPU (tam teşekküllü sunuculardan bahsediyoruz); ~ 1 Gb RAM; ~3 Mb/sn LAN
Grafit (go-karbon)
Metrik sayısı: ~ 1 / dak
Metrik güncelleme aralığı: 30 saniye
Metrik depolama şeması: 30 saniye 35 gün, 5 dakika 90 gün, 10 dakika 365 gün (uzun bir süre içinde hizmete ne olacağı konusunda size bilgi verir)
Sunucu kaynağı kullanımı: ~%10 CPU; ~ 20Gb RAM; ~30 Mb/sn LAN
Esneklik
Biz Avito olarak izleme hizmetimizde esnekliğe gerçekten değer veriyoruz. Gerçekten neden bu hale geldi? İlk olarak, bileşenleri birbiriyle değiştirilebilir: hem bileşenlerin kendisi hem de versiyonları. İkincisi, desteklenebilirlik. Projenin tamamı açık kaynak olduğundan, kodu kendiniz düzenleyebilir, değişiklikler yapabilir ve kutudan çıktığı haliyle mevcut olmayan işlevleri uygulayabilirsiniz. Başta Go ve Python olmak üzere oldukça yaygın yığınlar kullanılır, bu nedenle bu oldukça basit bir şekilde yapılır.
İşte gerçek bir soruna bir örnek. Grafitteki bir metrik bir dosyadır. Bir adı var. Dosya adı = metrik adı. Ve oraya ulaşmanın bir yolu var. Linux'ta dosya adları 255 karakterle sınırlıdır. Ve ("dahili müşteriler" olarak) veritabanı departmanından adamlarımız var. Bize şunu söylüyorlar: “SQL sorgularımızı izlemek istiyoruz. Ve bunlar 255 karakter değil, her biri 8 MB. Bunları Grafana'da görüntülemek, bu isteğin parametrelerini görmek ve daha da iyisi bu tür isteklerin üstünü görmek istiyoruz. Gerçek zamanlı olarak görüntülenmesi harika olacaktır. Onları alarma geçirmek gerçekten harika olurdu.
Örnek SQL sorgusu örnek olarak alınmıştır.
Bir Redis sunucusu kuruyoruz ve Postgres'e gidip tüm verileri oradan alıp metrikleri Graphite'e gönderen Collectd eklentilerimizi kullanıyoruz. Ancak metrik adını karmalarla değiştiriyoruz. Aynı hash'i Redis'e anahtar olarak ve SQL sorgusunun tamamını değer olarak aynı anda gönderiyoruz. Tek yapmamız gereken Grafana'nın Redis'e gidip bu bilgiyi alabilmesini sağlamak. Grafit API'sini açıyoruz çünkü... bu, tüm izleme bileşenlerinin grafit ile etkileşimi için ana arayüzdür ve oraya aliasByHash() adı verilen yeni bir işleve giriyoruz - Grafana'dan metriğin adını alıyoruz ve bunu Redis'e bir istekte anahtar olarak kullanıyoruz. yanıt olarak "SQL sorgumuz" olan anahtarın değerini alıyoruz " Böylece, Grafana'da teorik olarak orada görüntülenmesi imkansız olan bir SQL sorgusunun görüntüsünü, üzerindeki istatistiklerle (çağrılar, satırlar, toplam_zaman, ...) birlikte gösterdik.
sonuçlar
Durumu. İzleme hizmetimize her uygulamadan ve her koddan 24/7 ulaşabilirsiniz. Depolama tesislerine erişiminiz varsa, hizmete veri yazabilirsiniz. Dil önemli değil, kararlar önemli değil. Sadece bir soketi nasıl açacağınızı, oraya bir metrik koyacağınızı ve soketi nasıl kapatacağınızı bilmeniz yeterlidir.
Güvenilirlik. Tüm bileşenler hataya dayanıklıdır ve yüklerimizi iyi bir şekilde taşır.
Girişe karşı düşük bariyer. Bu sistemi kullanabilmek için Grafana'da programlama dilleri ve sorguları öğrenmenize gerek yoktur. Uygulamanızı açın, içine metrikleri Graphite'e gönderecek bir soket girin, kapatın, Grafana'yı açın, orada kontrol panelleri oluşturun ve metriklerinizin davranışına bakın, Moira aracılığıyla bildirimler alın.
Bağımsızlık. Tüm bunları DevOps mühendislerinin yardımı olmadan kendiniz yapabilirsiniz. Bu da bir avantajdır, çünkü projenizi şu anda izleyebiliyorsunuz, kimseye işe başlamasını veya değişiklik yapmasını istemenize gerek yok.
Ne için çalışıyoruz?
Aşağıda sayılanların hepsi sadece soyut düşünceler değil, en azından ilk adımları atılmış olan şeylerdir.
- Anormallik dedektörü. Grafit depolarımıza gidecek ve her metriği çeşitli algoritmalar kullanarak kontrol edecek bir hizmet oluşturmak istiyoruz. Zaten görüntülemek istediğimiz algoritmalar var, veriler var, onlarla nasıl çalışacağımızı biliyoruz.
- Meta veriler. Pek çok hizmetimiz var, onlar da tıpkı onlarla çalışan insanlar gibi zamanla değişiyor. Belgelerin sürekli olarak manuel olarak bakımı bir seçenek değildir. Bu nedenle artık meta verileri mikro hizmetlerimize yerleştiriyoruz. Kimin geliştirdiğini, etkileşime girdiği dilleri, SLA gerekliliklerini, bildirimlerin nereye ve kime gönderilmesi gerektiğini belirtir. Bir hizmet dağıtılırken tüm varlık verileri bağımsız olarak oluşturulur. Sonuç olarak, biri tetikleyicilere, diğeri Grafana'daki kontrol panellerine olmak üzere iki bağlantı elde edersiniz.
- Her evde izleme. Tüm geliştiricilerin böyle bir sistemi kullanması gerektiğine inanıyoruz. Bu durumda trafiğinizin nerede olduğunu, başına neler geldiğini, nereye düştüğünü, zaaflarının nerede olduğunu her zaman anlarsınız. Örneğin, bir şey gelip hizmetinizi çökertirse, bunu yöneticiden gelen bir çağrı sırasında değil, bir uyarıdan öğreneceksiniz ve en son günlükleri hemen açıp orada ne olduğunu görebilirsiniz.
- Yüksek performans. Projemiz sürekli büyüyor ve bugün dakikada yaklaşık 2 metrik değeri işliyor. Bir yıl önce bu rakam 000 idi ve büyüme devam ediyor, bu da bir süre sonra Grafit'in (fısıltı) disk alt sistemini ağır bir şekilde yüklemeye başlayacağı anlamına geliyor. Daha önce de söylediğim gibi, bu izleme sistemi, bileşenlerin birbiriyle değiştirilebilirliği nedeniyle oldukça evrenseldir. Birisi Grafit için özel olarak altyapısını koruyor ve sürekli olarak genişletiyor, ancak biz farklı bir rota izlemeye karar verdik: ölçümlerimiz için bir depo olarak. Bu geçiş neredeyse tamamlandı ve çok yakında size bunun nasıl yapıldığını daha ayrıntılı olarak anlatacağım: Ne tür zorluklar vardı ve bunların nasıl aşıldığı, geçiş sürecinin nasıl ilerlediği, bağlayıcı olarak seçilen bileşenleri ve bunların konfigürasyonlarını anlatacağım.
İlginiz için teşekkür ederiz! Konuyla ilgili sorularınızı sorun, burada veya sonraki yazılarda cevaplamaya çalışacağım. Belki birisinin benzer bir izleme sistemi oluşturma veya benzer bir durumda Clickhouse'a geçme deneyimi vardır - bunu yorumlarda paylaşın.
Kaynak: habr.com