Бөлінген жүйелердің күрделілігі артқан сайын мониторинг өсіп келе жатқан бұлттық шешімдердің өте маңызды құрамдас бөлігі болды. Олардың мінез-құлқын түсіну керек. Бізге барлық қызметтерден деректерді жинай алатын және мамандарға өнімділікті талдау, қателерді көрсету, қолжетімділік және журналдар бар бір интерфейсті қамтамасыз ететін масштабталатын құралдар қажет.
Дәл осы құралдар тиімді және өнімді болуы керек. Бұл мақалада біз екі танымал технологиялық стектерді қарастырамыз: EFK (Elasticsearch) және PLG (Loki) және олардың архитектурасы мен айырмашылықтарын қарастырамыз.
EFK стек
Сіз өте танымал ELK немесе EFK туралы естіген шығарсыз. Стек бірнеше бөлек бөліктерден тұрады: Elasticsearch (нысанды сақтау), Logstash немесе FluentD (журнал жинау және біріктіру) және визуализацияға арналған Kibana.
Әдеттегі жұмыс процесі келесідей көрінеді:
Elasticearch — іздеу және нақты уақыттағы аналитикасы бар бөлінген нысанды сақтау. Журналдар сияқты жартылай құрылымдық деректер үшін тамаша шешім. Ақпарат JSON құжаттары ретінде сақталады, нақты уақытта индекстеледі және кластер түйіндері бойынша таратылады. Толық мәтінді іздеу үшін барлық бірегей сөздерді және байланысты құжаттарды қамтитын инверттелген индекс пайдаланылады, ол өз кезегінде Apache Lucene іздеу жүйесіне негізделген.
еркін D деректерді жинау және тұтыну кезінде деректерді біріктіретін деректер жинаушы. Ол JSON ішіндегі деректерді мүмкіндігінше ұйымдастыруға тырысады. Оның архитектурасы кеңейеді, одан да көп , қауымдастықтың қолдауымен, барлық жағдайларда.
Кибана - әртүрлі қосымша мүмкіндіктері бар Elasticsearch үшін деректерді визуализациялау құралы, мысалы, уақыттық қатарларды талдау, графикалық талдау, машиналық оқыту және т.б.
Elasticsearch архитектурасы
Elasticsearch кластерінің деректері оның барлық түйіндері бойынша таратылады. Кластер қолжетімділік пен тұрақтылықты жақсарту үшін бірнеше түйіндерден тұрады. Кез келген түйін кластердің барлық рөлдерін орындай алады, бірақ кең ауқымды орналастыруларда түйіндерге әдетте жеке тапсырмалар тағайындалады.
Кластер түйіндерінің түрлері:
- негізгі түйін - кластерді басқарады, кем дегенде үшеуі қажет, біреуі әрқашан белсенді;
- деректер түйіні – индекстелген мәліметтерді сақтайды және онымен әртүрлі тапсырмаларды орындайды;
- қабылдау түйіні – индекстеу алдында деректерді түрлендіру үшін конвейерлерді ұйымдастырады;
- үйлестіру түйіні – сұраныстарды бағыттау, іздеуді өңдеу фазасын қысқарту, массаны индекстеуді үйлестіру;
- ескерту түйіні — ескерту тапсырмаларын іске қосу;
- машиналық оқыту түйіні – машиналық оқыту тапсырмаларын өңдеу.
Төмендегі диаграмма деректердің жоғарырақ қолжетімділігіне қол жеткізу үшін түйіндер бойынша деректердің қалай сақталатынын және қайталанатынын көрсетеді.
Әрбір репликаның деректері инверттелген индексте сақталады, төмендегі диаграмма мұның қалай болатынын көрсетеді:
параметр
Мәліметтерді қарауға болады , Мен руль диаграммасын қолданамын:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG стек
Бұл аббревиатураны таба алмасаңыз, таң қалмаңыз, өйткені ол Графана Локи деген атпен танымал. Қалай болғанда да, бұл стек танымал болуда, өйткені ол дәлелденген техникалық шешімдерді пайдаланады. Сіз танымал визуализация құралы Grafana туралы естіген шығарсыз. Прометейден шабыттанған оны жасаушылар көлденең масштабталатын, жоғары өнімді журналдарды біріктіру жүйесі Loki әзірледі. Loki журналдардың өзін емес, тек метадеректерді индекстейді, бұл техникалық шешімді пайдалану оңай және үнемді болуға мүмкіндік береді.
Promtail - операциялық жүйеден Loki кластеріне журналдарды жіберуге арналған агент. Графана Loki деректеріне негізделген визуализация құралы болып табылады.
Loki Prometheus сияқты принциптерге негізделген, бұл оны Kubernetes журналдарын сақтау және талдау үшін өте қолайлы етеді.
Локи архитектурасы
Loki бір процесс ретінде немесе көлденең масштабтауға мүмкіндік беретін бірнеше процесс ретінде іске қосылуы мүмкін.
Ол монолитті қолданба ретінде де, микросервис ретінде де жұмыс істей алады. Бір процесс ретінде іске қосу жергілікті даму немесе шағын мониторинг үшін пайдалы болуы мүмкін. Өндірістік енгізу және масштабталатын жұмыс жүктемесі үшін микросервис опциясын пайдалану ұсынылады. Деректерді жазу мен оқуға арналған жолдар бөлінген, сондықтан оны қажетінше дәл реттеуге және масштабтауға болады.
Егжей-тегжейлі ақпарат бермей, журналдарды жинау жүйесінің архитектурасын қарастырайық:
Міне, сипаттама (микросервис архитектурасы):
Компоненттер:
Promtail — түйіндерде орнатылған агент (қызметтердің жиынтығы ретінде), ол тапсырмалардан журналдарды жояды және журналдарды белгілейтін метадеректерді алу үшін Kubernetes API интерфейсіне қатынасады. Содан кейін ол журналды негізгі Loki қызметіне жібереді. Метадеректерді салыстыру Prometheus сияқты тегтеу ережелерін қолдайды.
Таратушы — буфер ретінде жұмыс істейтін сервис дистрибьюторы. Миллиондаған жазбаларды өңдеу үшін ол кіріс деректерді жинақтайды, келген кезде оларды блоктарға қысады. Бірнеше деректер қабылдағыштары бір уақытта жұмыс істейді, бірақ бір кіріс деректер ағынына жататын журналдар оның барлық блоктары үшін олардың біреуінде ғана пайда болуы керек. Бұл раковиналар сақинасы және дәйекті хэшинг түрінде ұйымдастырылған. Ақауларға төзімділік пен артықшылық үшін бұл n рет орындалады (конфигурацияланбаған жағдайда 3).
Ингестер — қызмет алушы. Деректер блоктары қосылған журналдармен қысылған түрде келеді. Блок жеткілікті өлшемге ие болғаннан кейін блок дерекқорға тазартылады. Метадеректер индекске өтеді, ал журнал блогындағы деректер Chunks (әдетте нысанды сақтау) бөліміне өтеді. Қалпына келтіруден кейін ресивер жаңа жазбалар қосылатын жаңа блок жасайды.
көрсеткіш - мәліметтер базасы, DynamoDB, Cassandra, Google BigTable және т.б.
Тыңдаулар — сығылған түрдегі журнал блоктары, әдетте объектілерді сақтауда сақталады, мысалы, S3.
Сұраушы - барлық лас жұмыстарды жасайтын оқу жолы. Ол уақыт диапазоны мен уақыт белгісін қарайды, содан кейін сәйкестіктерді табу үшін индексті қарайды. Содан кейін ол деректер блоктарын оқиды және нәтиже алу үшін оларды сүзеді.
Енді барлығын іс жүзінде көрейік.
параметр
Kubernetes-те орнатудың ең оңай жолы - рульді пайдалану. Сіз оны әлдеқашан орнатып, конфигурациялаған деп есептейміз ( шамамен. аудармашы)
Репозиторийді қосып, стек орнатыңыз.
$ 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=falseТөменде Etcd метрикасына арналған Prometheus және Etcd қосқыш журналдарына арналған Loki деректерін көрсететін мысал бақылау тақтасы берілген.
Енді екі жүйенің де архитектурасын талқылайық, сондай-ақ олардың мүмкіндіктерін бір-бірімен салыстырайық.
Салыстыру
Сұрау тілі
Elasticsearch толық мәтінді іздеу мүмкіндіктерін қамтамасыз ету үшін Query DSL және Lucene сұрау тілін пайдаланады. Бұл кең операторлық қолдауы бар құрылған, қуатты іздеу жүйесі. Оның көмегімен контекст бойынша іздеуге және өзектілігі бойынша сұрыптауға болады.
Сақинаның екінші жағында PromQL (Prometheus сұрау тілі) мұрагері Локиде қолданылатын LogQL бар. Ол журнал деректерін сүзу және таңдау үшін журнал тегтерін пайдаланады. Кейбір операторлар мен арифметиканы сипатталғандай пайдалануға болады , бірақ мүмкіндіктері жағынан ол Эластикалық тілден артта қалады.
Loki ішіндегі сұраулар тегтермен байланысты болғандықтан, оларды метрикамен байланыстыру оңай және нәтижесінде олармен операциялық бақылауды ұйымдастыру оңайырақ.
Масштабтылық
Екі стек көлденең масштабталады, бірақ Loki оны жеңілдетеді, өйткені оның оқу және жазу жолдары бөлек және микросервис архитектурасы бар. Loki сіздің қажеттіліктеріңізге сәйкес реттелуі мүмкін және журнал деректерінің өте үлкен көлемі үшін пайдаланылуы мүмкін.
Көп жалдау
Кластерлік көп жалға алу - OPEX аббревиатурасындағы жалпы тақырып, екі стек көп жалға алуды қамтамасыз етеді. Elasticsearch үшін бірнеше нұсқа бар клиентті бөлу: әрбір клиент үшін жеке индекс, клиентке негізделген маршруттау, бірегей клиент өрістері, іздеу сүзгілері. Локи бар HTTP X-Scope-OrgID тақырыбы түрінде.
құны
Loki деректерді индекстемейді, тек метадеректерге байланысты өте тиімді. Бұл қол жеткізеді және жад (кэш), өйткені нысанды сақтау Elasticsearch кластерлерінде қолданылатын блоктық сақтаудан арзанырақ.
қорытынды
EFK стегі барынша икемділік пен аналитика, визуализация және сұраулар үшін мүмкіндіктерге бай Kibana интерфейсін қамтамасыз ететін әртүрлі мақсаттарда пайдаланылуы мүмкін. Оны машиналық оқыту мүмкіндіктері арқылы одан әрі жақсартуға болады.
Loki стегі метадеректерді табу механизміне байланысты Kubernetes экожүйесінде пайдалы. Grafana және журналдардағы уақыт қатарларына негізделген бақылау үшін деректерді оңай корреляциялауға болады.
Құны мен ұзақ мерзімді журналды сақтау туралы айтатын болсақ, Loki бұлтты шешімдерге тамаша кіру нүктесі болып табылады.
Нарықта көбірек балама нұсқалар бар - кейбіреулері сіз үшін жақсырақ болуы мүмкін. Мысалы, GKE тамаша бақылау шешімін қамтамасыз ететін Stackdriver интеграциясына ие. Біз оларды осы мақаладағы талдауымызға қоспадық.
сілтемелер:
Мақаланы қызметкерлер аударып, Хабрға дайындаған — тәжірибелі мамандардан қарқынды курстар, бейне курстар және корпоративтік тренингтер (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Ақпарат көзі: www.habr.com