Monitorinq paylanmış sistemlərin artan mürəkkəbliyi ilə artan bulud həllərinin çox vacib komponentinə çevrilmişdir. Onların davranışlarını başa düşmək lazımdır. Bizə bütün xidmətlərdən məlumat toplaya bilən və mütəxəssislərə performans təhlili, səhv nümayişi, əlçatanlıq və qeydlər ilə vahid interfeys təqdim edən miqyaslana bilən alətlərə ehtiyacımız var.
Eyni alətlər səmərəli və məhsuldar olmalıdır. Bu yazıda biz iki məşhur texnologiya yığınına baxacağıq: EFK (Elasticsearch) və PLG (Loki) və onların arxitekturasını və fərqlərini təhlil edəcəyik.
EFK yığını
Çox məşhur ELK və ya EFK haqqında artıq eşitmisiniz. Yığın bir neçə ayrı hissədən ibarətdir: Elasticsearch (obyekt saxlama), Logstash və ya FluentD (logların toplanması və yığılması) və vizuallaşdırma üçün Kibana.
Tipik bir iş prosesi belə görünür:
Elasticsearch — real vaxt axtarışı və analitika ilə paylanmış obyekt yaddaşı. Jurnallar kimi yarı strukturlaşdırılmış məlumatlar üçün əla həlldir. Məlumat JSON sənədləri kimi saxlanılır, real vaxt rejimində indekslənir və klaster qovşaqları arasında paylanır. Tam mətnli axtarış üçün bütün unikal sözləri və əlaqəli sənədləri ehtiva edən ters çevrilmiş indeks istifadə olunur ki, bu da öz növbəsində Apache Lucene axtarış sisteminə əsaslanır.
səlis D toplanan və istehlak edilən məlumatları birləşdirən məlumat toplayıcısıdır. O, JSON-da məlumatları mümkün qədər təşkil etməyə çalışır. Onun memarlığı genişlənir, daha çox var , bütün hallarda cəmiyyət tərəfindən dəstəklənir.
Kibana zaman sıralarının təhlili, qrafiklər, maşın öyrənməsi və s. kimi müxtəlif əlavə xüsusiyyətləri olan Elasticsearch üçün verilənlərin vizuallaşdırılması vasitəsidir.
Elasticsearch Arxitektura
Elasticsearch klaster məlumatları bütün qovşaqlarında yayılmış şəkildə saxlanılır. Çoxluq əlçatanlığı və dayanıqlığı yaxşılaşdırmaq üçün çoxlu qovşaqlardan ibarətdir. İstənilən qovşaq bütün klaster rollarını yerinə yetirə bilər, lakin böyük, miqyaslana bilən yerləşdirmələrdə qovşaqlara adətən fərdi tapşırıqlar verilir.
Klaster node növləri:
- master node - klasteri idarə edir, ən azı üç lazımdır, biri həmişə aktivdir;
- verilənlər qovşağı - indeksləşdirilmiş məlumatları saxlayır və onlarla müxtəlif tapşırıqları yerinə yetirir;
- ingest node - indeksləşdirmədən əvvəl məlumatların transformasiyası üçün boru kəmərlərini təşkil edir;
- koordinasiya qovşağı - sorğunun yönləndirilməsi, axtarışın emalı mərhələsinin azaldılması, toplu indeksləşdirmənin əlaqələndirilməsi;
- xəbərdarlıq qovşağı - bildiriş tapşırıqlarının işə salınması;
- maşın öyrənmə qovşağı - maşın öyrənmə tapşırıqlarını emal edir.
Aşağıdakı diaqram daha yüksək məlumat əldə etmək üçün verilənlərin necə saxlanıldığını və qovşaqlar arasında təkrarlandığını göstərir.
Hər bir replikanın məlumatları ters çevrilmiş indeksdə saxlanılır, aşağıdakı diaqram bunun necə baş verdiyini göstərir:
Quraşdırma
Detallara baxmaq olar , mən dəbilqə cədvəlindən istifadə edəcəyəm:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG yığını
Bu abbreviaturanı tapa bilmirsinizsə, təəccüblənməyin, çünki o, daha çox Grafana Loki kimi tanınır. Hər halda, bu stek yaxşı tənzimlənmiş texniki həllərdən istifadə etdiyi üçün populyarlıq qazanır. Populyar vizuallaşdırma vasitəsi olan Grafana haqqında artıq eşitmisiniz. Onun yaradıcıları, Prometeydən ilham alaraq, üfüqi olaraq genişlənə bilən, yüksək performanslı log toplama sistemi olan Loki-ni inkişaf etdirdilər. Loki jurnalların özlərini deyil, yalnız metaməlumatları indeksləşdirir, bu texniki həll istifadəni asanlaşdırıb və qənaətcil edib.
Promtail - əməliyyat sistemindən Loki klasterinə qeydlər göndərmək üçün agent. Qrafana Loki məlumatlarına əsaslanan vizuallaşdırma vasitəsidir.
Loki Prometey ilə eyni prinsiplər üzərində qurulub, ona görə də Kubernetes jurnallarının saxlanması və təhlili üçün çox uyğundur.
Loki memarlığı
Loki üfüqi miqyaslamaya imkan verən tək bir proses və ya çoxlu proses kimi işlədilə bilər.
O, həm monolit proqram, həm də mikroservis kimi işləyə bilər. Vahid bir proses kimi işləmək yerli inkişaf və ya dəqiq monitorinq üçün faydalı ola bilər. Sənaye tətbiqi və genişləndirilə bilən iş yükü üçün mikroservis seçimindən istifadə etmək tövsiyə olunur. Məlumatların yazılması və oxunma yolları ayrılıb, beləliklə, lazım olduqda onu dəqiq şəkildə sazlamaq və miqyaslaşdırmaq olar.
Təfərrüatsız log toplama sisteminin arxitekturasına baxaq:
Və burada təsvir (mikroservis arxitekturası):
Komponentlər:
Promtail - qovşaqlarda quraşdırılmış agent (xidmətlər dəsti kimi), logları tapşırıqlardan silir və qeydləri qeyd etmək üçün istifadə olunacaq metadata əldə etmək üçün Kubernetes API-yə daxil olur. Sonra jurnalı əsas Loki xidmətinə göndərir. Metadata uyğunluğu üçün Prometeydə olduğu kimi eyni etiketləmə qaydaları dəstəklənir.
Paylayıcı - bufer kimi işləyən xidmət-distributor. Milyonlarla qeydi emal etmək üçün o, daxil olan məlumatları yığır, gələn kimi bloklara sıxır. Birdən çox məlumat yuvası eyni vaxtda işləyir, lakin eyni gələn məlumat axınına aid qeydlər bütün blokları üçün onlardan yalnız birində bitməlidir. Bu, qəbuledicilər və ardıcıl hashing halqası kimi təşkil edilir. Arızaya dözümlülük və artıqlıq üçün n dəfə edilir (konfiqurasiya edilmədikdə 3).
udmaq — xidmət qəbuledicisi. Məlumat blokları əlavə qeydlərlə sıxılır. Blok kifayət qədər ölçüyə çatan kimi blok verilənlər bazasına yuyulur. Metaməlumatlar indeksə, log blokundan məlumatlar isə Chunks-a (adətən obyektin saxlanmasına) gedir. Sıfırlamadan sonra qəbuledici yeni qeydlərin əlavə olunacağı yeni blok yaradır.
indeks - verilənlər bazası, DynamoDB, Cassandra, Google BigTable və s.
Qoşunlar - adətən obyekt anbarında saxlanılan sıxılmış formada log blokları, məsələn, S3.
Sorğuçu bütün çirkin işləri görən oxu yoludur. O, vaxt diapazonuna və vaxt damğasına baxır, sonra uyğunluqları axtarmaq üçün indeksə baxır. Sonra, məlumat bloklarını oxuyur və nəticə əldə etmək üçün onları süzür.
İndi işdə hər şeyi görək.
Quraşdırma
Kubernetes-də quraşdırmanın ən asan yolu sükandan istifadə etməkdir. Güman edirik ki, siz onu artıq quraşdırmısınız və konfiqurasiya etmisiniz ( təqribən. tərcüməçi)
Bir anbar əlavə edirik və bir yığın qoyuruq.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falseAşağıda Etcd üçün Prometheus və Etcd pod jurnalları üçün Loki göstəricilərini göstərən nümunə tablosudur.
İndi isə hər iki sistemin arxitekturasını müzakirə edək, eləcə də onların imkanlarını bir-biri ilə müqayisə edək.
Müqayisə
Sorğu dili
Elasticsearch tam mətn axtarış imkanını təmin etmək üçün Query DSL və Lucene sorğu dilindən istifadə edir. Geniş operator dəstəyi ilə qurulmuş güclü axtarış motorudur. Bununla siz kontekst üzrə axtarış edə və uyğunluğa görə sıralaya bilərsiniz.
Üzüyün digər tərəfində PromQL-in (Prometheus sorğu dili) davamçısı olan Loki-nin LogQL-i var. O, jurnal məlumatlarını süzgəcdən keçirmək və seçmək üçün jurnal etiketlərindən istifadə edir. Bəzi operatorlardan və arifmetikadan təsvir edildiyi kimi istifadə etmək mümkündür , lakin imkanlarına görə Elastik dildən geri qalır.
Loki-dəki sorğular etiketlərlə əlaqəli olduğundan, onları metriklərlə əlaqələndirmək asandır, nəticədə onlarla əməliyyat monitorinqini təşkil etmək daha asandır.
Ölçeklenebilirlik
Hər iki yığın üfüqi olaraq genişləndirilə bilər, lakin Loki ilə bu daha asandır, çünki ayrı-ayrı oxumaq və yazma yolları var və mikroservis arxitekturasına malikdir. Loki ehtiyaclarınıza uyğunlaşdırıla bilər və çox böyük həcmdə log məlumatları üçün istifadə edilə bilər.
Çox kirayəlik
Klaster multi-icarəçilik OPEX-in azaldılması üçün ümumi mövzudur, hər iki yığın çoxlu icarəni təmin edir. Elasticsearch üçün bir neçə var müştərinin ayrılması: hər bir müştəri üçün ayrıca indeks, müştəriyə əsaslanan marşrutlaşdırma, müştərinin unikal sahələri, axtarış filtrləri. Loki var HTTP X-Scope-OrgID başlığı kimi.
dəyəri
Loki, məlumatları indeksləşdirmədiyinə görə çox sərfəlidir, yalnız metadata. Beləliklə, və yaddaş (kesh), çünki obyektin saxlanması Elasticsearch klasterlərində istifadə olunan blok yaddaşından daha ucuzdur.
Nəticə
EFK yığını müxtəlif məqsədlər üçün istifadə oluna bilər, maksimum çeviklik və analitika, vizuallaşdırma və sorğular üçün zəngin Kibana interfeysi təmin edir. O, maşın öyrənmə imkanları ilə daha da təkmilləşdirilə bilər.
Loki yığını metadata aşkarlama mexanizminə görə Kubernetes ekosistemində faydalıdır. Siz Grafana və qeydlərdəki zaman sıralarına əsasən monitorinq üçün məlumatları asanlıqla əlaqələndirə bilərsiniz.
Xərclərə və uzunmüddətli jurnalın saxlanmasına gəldikdə, Loki buluda daxil olmaq üçün əla seçimdir.
Bazarda daha çox alternativ var - bəziləri sizin üçün daha yaxşı ola bilər. Məsələn, GKE əla monitorinq həllini təmin edən Stackdriver inteqrasiyasına malikdir. Bu yazıda onları təhlilimizə daxil etmədik.
Referanslar:
Yazı işçilər tərəfindən tərcümə edilərək Habr üçün hazırlanmışdır — praktikantlardan intensiv, video kurslar və korporativ təlimlər (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Mənbə: www.habr.com