Ang pagsubaybay ay naging isang napakahalagang bahagi ng lumalagong mga solusyon sa ulap habang tumataas ang pagiging kumplikado ng mga distributed system. Ito ay kinakailangan upang maunawaan ang kanilang pag-uugali. Kailangan namin ng mga scalable na tool na maaaring mangolekta ng data mula sa lahat ng serbisyo - at magbigay sa mga espesyalista ng isang interface na may pagtatasa ng pagganap, pagpapakita ng error, availability at mga log.
Ang parehong mga tool na ito ay dapat na mahusay at produktibo. Sa artikulong ito, titingnan natin ang dalawang sikat na stack ng teknolohiya: EFK (Elasticsearch) at PLG (Loki) at susuriin ang kanilang mga arkitektura at pagkakaiba.
EFK stack
Maaaring narinig mo na ang tungkol sa napakasikat na ELK o EFK. Ang stack ay binubuo ng ilang natatanging bahagi: Elasticsearch (imbakan ng object), Logstash o FluentD (pagkolekta at pagsasama-sama ng log), at Kibana para sa visualization.
Ang isang karaniwang daloy ng trabaho ay ganito ang hitsura:
Elasticsearch β distributed object storage na may paghahanap at real-time na analytics. Napakahusay na solusyon para sa semi-structured na data tulad ng mga log. Sine-save ang impormasyon bilang mga dokumento ng JSON, na-index sa real time at ipinamamahagi sa mga cluster node. Ginagamit ang isang baligtad na index, na naglalaman ng lahat ng natatanging salita at nauugnay na mga dokumento para sa paghahanap ng buong teksto, na nakabatay naman sa search engine ng Apache Lucene.
MatatasD ay isang data collector na pinag-iisa ang data kapag nangongolekta at kumokonsumo nito. Sinusubukan nitong ayusin ang data sa JSON hangga't maaari. Extensible ang architecture nito, marami pa , suportado ng komunidad, para sa lahat ng okasyon.
Kibana - isang tool sa visualization ng data para sa Elasticsearch na may iba't ibang karagdagang kakayahan, halimbawa, pagsusuri ng serye ng oras, pagsusuri ng graph, pag-aaral ng makina at higit pa.
Elasticsearch na arkitektura
Ang data ng kumpol ng Elasticsearch ay iniimbak na kumalat sa lahat ng mga node nito. Binubuo ang isang cluster ng maraming node para mapahusay ang availability at resiliency. Ang anumang node ay maaaring gampanan ang lahat ng mga tungkulin ng cluster, ngunit sa malalaking scale-out na pag-deploy, ang mga node ay karaniwang nakatalaga ng mga indibidwal na gawain.
Mga uri ng cluster node:
- master node - namamahala sa kumpol, hindi bababa sa tatlo ang kailangan, ang isa ay palaging aktibo;
- data node - nag-iimbak ng na-index na data at nagsasagawa ng iba't ibang mga gawain kasama nito;
- ingest node - nag-aayos ng mga pipeline para sa pagbabago ng data bago ang pag-index;
- coordinating node - mga kahilingan sa pagruruta, pagbabawas ng yugto ng pagpoproseso ng paghahanap, pag-coordinate ng mass indexing;
- alerting node - paglulunsad ng mga gawaing alerto;
- machine learning node - pagpoproseso ng mga gawain sa machine learning.
Ipinapakita ng diagram sa ibaba kung paano iniimbak at ginagaya ang data sa mga node upang makamit ang mas mataas na availability ng data.
Ang data ng bawat replika ay naka-imbak sa isang baligtad na index, ang diagram sa ibaba ay nagpapakita kung paano ito nangyayari:
Instalasyon
Maaaring tingnan ang mga detalye , gagamit ako ng helm chart:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG stack
Huwag magtaka kung hindi mo mahanap ang acronym na ito, dahil mas kilala ito bilang Grafana Loki. Sa anumang kaso, ang stack na ito ay nagiging popular dahil gumagamit ito ng mga napatunayang teknikal na solusyon. Maaaring narinig mo na ang Grafana, isang sikat na tool sa visualization. Ang mga tagalikha nito, na binigyang inspirasyon ng Prometheus, ay bumuo ng Loki, isang horizontally scalable, high-performance na log aggregation system. Ang metadata lang ang ini-index ni Loki, hindi ang mga journal mismo, isang teknikal na solusyon na nagbibigay-daan sa pagiging madaling gamitin at cost-effective.
Promtail - isang ahente para sa pagpapadala ng mga log mula sa operating system patungo sa Loki cluster. grafana ay isang visualization tool batay sa data mula kay Loki.
Ang Loki ay itinayo sa parehong mga prinsipyo tulad ng Prometheus, na ginagawa itong angkop para sa pag-iimbak at pagsusuri ng mga log ng Kubernetes.
Arkitektura ng Loki
Maaaring patakbuhin ang Loki bilang isang proseso o bilang maramihang proseso, na nagbibigay-daan para sa pahalang na pag-scale.
Maaari rin itong gumana bilang isang monolitikong aplikasyon o bilang isang microservice. Ang pagpapatakbo bilang isang proseso ay maaaring maging kapaki-pakinabang para sa lokal na pag-unlad o para sa menor de edad na pagsubaybay. Para sa industriyal na pagpapatupad at scalable na workload, inirerekomendang gamitin ang opsyong microservice. Ang mga landas para sa pagsusulat at pagbabasa ng data ay pinaghihiwalay, kaya maaari itong maayos at mai-scale kung kinakailangan.
Tingnan natin ang arkitektura ng sistema ng pagkolekta ng log nang hindi nagdedetalye:
At narito ang paglalarawan (microservice architecture):
Mga Bahagi:
Promtail β isang ahente na naka-install sa mga node (bilang isang hanay ng mga serbisyo), inaalis nito ang mga log mula sa mga gawain at ina-access ang Kubernetes API upang makakuha ng metadata na magta-tag sa mga log. Pagkatapos ay ipinapadala nito ang log sa pangunahing serbisyo ng Loki. Sinusuportahan ng metadata mapping ang parehong mga panuntunan sa pag-tag gaya ng Prometheus.
tagapamahagi β isang distributor ng serbisyo na gumagana bilang isang buffer. Upang maproseso ang milyun-milyong talaan, nag-iimpake ito ng papasok na data, pini-compress ito sa mga bloke pagdating nito. Maraming data sink ang tumatakbo nang sabay-sabay, ngunit ang mga log na kabilang sa isang papasok na stream ng data ay dapat lang lumabas sa isa sa mga ito para sa lahat ng block nito. Ito ay isinaayos sa isang ring of sinks at sequential hashing. Para sa fault tolerance at redundancy, ginagawa ito ng n beses (3 kung hindi naka-configure).
Ingester β tumatanggap ng serbisyo. Dumating ang mga bloke ng data na naka-compress na may mga idinagdag na log. Kapag ang bloke ay may sapat na laki, ang bloke ay i-flush sa database. Ang metadata ay napupunta sa index, at ang data mula sa log block ay napupunta sa Chunks (karaniwang object storage). Pagkatapos ng pag-reset, ang receiver ay gagawa ng bagong block kung saan magdadagdag ng mga bagong entry.
Index - database, DynamoDB, Cassandra, Google BigTable, atbp.
Mga chunks β mga bloke ng log sa naka-compress na anyo, kadalasang nakaimbak sa imbakan ng bagay, halimbawa, S3.
Querier - ang landas sa pagbabasa na gumagawa ng lahat ng maruruming gawain. Tinitingnan nito ang hanay ng oras at timestamp, at pagkatapos ay tumitingin sa index upang makahanap ng mga tugma. Susunod, binabasa nito ang mga bloke ng data at sinasala ang mga ito upang makuha ang resulta.
Ngayon tingnan natin ang lahat sa pagkilos.
Instalasyon
Ang pinakamadaling paraan ng pag-install sa Kubernetes ay ang paggamit ng timon. Ipinapalagay namin na na-install at na-configure mo na ito ( tinatayang tagasalin)
Magdagdag ng repositoryo at mag-install ng stack.
$ 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=falseNasa ibaba ang isang halimbawang dashboard na nagpapakita ng data mula sa Prometheus for Etcd metrics at Loki for Etcd pod logs.
Ngayon talakayin natin ang arkitektura ng parehong mga sistema, at ihambing din ang kanilang mga kakayahan sa isa't isa.
Paghahambing
Wika ng pagtatanong
Gumagamit ang Elasticsearch ng Query DSL at Lucene query language upang magbigay ng mga kakayahan sa paghahanap ng buong teksto. Ito ay isang matatag, makapangyarihang search engine na may malawak na suporta sa operator. Gamit ito, maaari kang maghanap ayon sa konteksto at pagbukud-bukurin ayon sa kaugnayan.
Sa kabilang panig ng ring ay ang LogQL, na ginamit sa Loki, ang kahalili sa PromQL (Prometheus query language). Gumagamit ito ng mga log tag upang i-filter at piliin ang data ng log. Posibleng gumamit ng ilang operator at aritmetika gaya ng inilarawan , ngunit sa mga tuntunin ng mga kakayahan ay nahuhuli ito sa Elastic na wika.
Dahil nauugnay ang mga query sa Loki sa mga tag, madali silang maiugnay sa mga sukatan, at bilang resulta, mas madaling ayusin ang pagsubaybay sa pagpapatakbo.
Scalability
Ang parehong mga stack ay pahalang na nasusukat, ngunit ginagawang mas madali ng Loki dahil mayroon itong magkahiwalay na read at write path at isang microservice architecture. Maaaring i-customize ang Loki upang umangkop sa iyong mga pangangailangan at maaaring gamitin para sa napakalaking dami ng data ng log.
Multitenancy
Ang cluster multitenancy ay isang karaniwang tema sa OPEX abbreviation, ang parehong mga stack ay nagbibigay ng multitenancy. Mayroong ilang para sa Elasticsearch paghihiwalay ng kliyente: hiwalay na index para sa bawat kliyente, pagruruta na nakabatay sa kliyente, natatanging mga patlang ng kliyente, mga filter sa paghahanap. meron si Loki sa anyo ng isang header ng HTTP X-Scope-OrgID.
Gastos
Ang Loki ay medyo epektibo sa gastos dahil sa katotohanang hindi nito ini-index ang data, ang metadata lamang. Ito ay nakakamit at memorya (cache), dahil mas mura ang imbakan ng object kaysa sa block storage, na ginagamit sa mga cluster ng Elasticsearch.
Konklusyon
Ang EFK stack ay maaaring gamitin para sa iba't ibang layunin, na nagbibigay ng maximum na flexibility at isang feature-rich Kibana interface para sa analytics, visualization, at mga query. Maaari pa itong pahusayin ng mga kakayahan sa machine learning.
Ang Loki stack ay kapaki-pakinabang sa Kubernetes ecosystem dahil sa mekanismo ng pagtuklas ng metadata nito. Madali mong maiugnay ang data para sa pagsubaybay batay sa serye ng oras sa Grafana at mga log.
Pagdating sa gastos at pangmatagalang pag-iimbak ng log, ang Loki ay isang mahusay na punto ng pagpasok sa mga solusyon sa ulap.
Mayroong higit pang mga alternatibo sa merkado - ang ilan ay maaaring mas mahusay para sa iyo. Halimbawa, may Stackdriver integration ang GKE na nagbibigay ng mahusay na solusyon sa pagsubaybay. Hindi namin sila isinama sa aming pagsusuri sa artikulong ito.
Link:
Ang artikulo ay isinalin at inihanda para sa Habr ng mga empleyado β masinsinang kurso, video course at corporate na pagsasanay mula sa mga nagsasanay na espesyalista (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Pinagmulan: www.habr.com