Monitorado fariĝis tre grava ero de kreskantaj nubaj solvoj kun la kreskanta komplekseco de distribuitaj sistemoj. Necesas kompreni ilian konduton. Ni bezonas skaleblajn ilojn, kiuj povas kolekti datumojn de ĉiuj servoj - kaj provizi specialistojn per ununura interfaco kun rendimenta analizo, erarmonstro, havebleco kaj protokoloj.
Ĉi tiuj samaj iloj devas esti efikaj kaj produktivaj. En ĉi tiu artikolo, ni rigardos du popularajn teknologiajn stakojn: EFK (Elasticsearch) kaj PLG (Loki) kaj analizos iliajn arkitekturojn kaj diferencojn.
EFK-stako
Vi eble jam aŭdis pri la tre populara ELK aŭ EFK. La stako konsistas el pluraj apartaj partoj: Elasticsearch (objektostokado), Logstash aŭ FluentD (kolekto kaj agregado de ŝtipoj) kaj Kibana por bildigo.
Tipa laborfluo aspektas jene:
Elasta esploro - distribuita objektostokado kun realtempa serĉo kaj analizo. Bonega solvo por duonstrukturaj datumoj kiel ŝtipoj. La informoj estas konservitaj kiel JSON-dokumentoj, indeksitaj en reala tempo, kaj distribuitaj tra la grapolnodoj. Inversa indekso enhavanta ĉiujn unikajn vortojn kaj rilatajn dokumentojn por plenteksta serĉo estas uzata, kiu siavice baziĝas sur la serĉilo Apache Lucene.
FluaD estas datumkolektanto kiu unuigas datumojn kiam ĝi estas kolektita kaj konsumita. Ĝi provas organizi la datumojn en JSON kiel eble plej multe. Ĝia arkitekturo estas etendebla, estas pli , subtenata de la komunumo, por ĉiuj okazoj.
Kibana estas datuma bildiga ilo por Elasticsearch kun diversaj kromaj funkcioj, kiel analizo de temposerio, grafikaĵoj, maŝinlernado kaj pli.
Elasticsearch Arkitekturo
Elasticsearch-aretdatenoj estas stokitaj disigitaj tra ĉiuj ĝiaj nodoj. La areto konsistas el multoblaj nodoj por plibonigi haveblecon kaj rezistecon. Ĉiu nodo povas plenumi ĉiujn grapolrolojn, sed en grandaj, skaleblaj deplojoj, al nodoj kutime estas asignitaj apartaj taskoj.
Klaspaj nodoj:
- master node - administras la areton, vi bezonas almenaŭ tri, unu ĉiam aktivas;
- data node - konservas indeksitajn datumojn kaj plenumas diversajn taskojn kun ili;
- ingest node - organizas duktoj por datumtransformo antaŭ indeksado;
- coordinating node - peto-vojigo, reduktado de la serĉ-prilabora fazo, kunordigado de amasa indeksado;
- alerting node - lanĉi sciigajn taskojn;
- machine learning node - prilaborado de maŝinlernado taskoj.
La diagramo malsupre montras kiel datumoj estas persistitaj kaj reproduktitaj trans nodoj por atingi pli altan datumhaveblecon.
La datumoj de ĉiu kopio estas stokitaj en inversa indekso, la diagramo malsupre montras kiel tio okazas:
fikso
Detaloj videblas , mi uzos stirilon:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG-stako
Ne miru se vi ne povas trovi ĉi tiun akronimon, ĉar ĝi estas pli konata kiel Grafana Loki. Ĉiukaze, ĉi tiu stako gajnas popularecon ĉar ĝi uzas bone ĝustigitajn teknikajn solvojn. Vi eble jam aŭdis pri Grafana, populara bildilo. Ĝiaj kreintoj, inspiritaj de Prometeo, evoluigis Lokion, horizontale skaleblan, alt-efikecan registro-agregadsistemon. Loki nur indeksas la metadatenojn, ne la revuojn mem, ĉi tiu teknika solvo faciligis uzi kaj koste efika.
Promtail - agento por sendi protokolojn de la operaciumo al la Loki-grupo. grafana estas bildiga ilo bazita sur datumoj de Lokio.
Lokio estas konstruita laŭ la samaj principoj kiel Prometheus, do ĝi taŭgas por stoki kaj analizi Kubernetes-protokolojn.
Loki-arkitekturo
Lokio povas esti prizorgita kiel ununura procezo aŭ kiel multoblaj procezoj, permesante horizontalan skalon.
Ĝi ankaŭ povas funkcii kaj kiel monolita aplikaĵo kaj kiel mikroservo. Kuri kiel ununura procezo povas esti utila por loka evoluo aŭ por fajna monitorado. Por industria efektivigo kaj skalebla laborkvanto, oni rekomendas uzi la mikroservan opcion. La datumskribado kaj legado vojoj estas apartigitaj, tiel ke ĝi povas esti fajne agorditaj kaj skalitaj laŭbezone.
Ni rigardu la arkitekturon de la registro-kolekta sistemo sen detalo:
Kaj jen la priskribo (mikroserva arkitekturo):
Komponentoj:
Promtail - agento instalita sur nodoj (kiel aro de servoj), ĝi forigas protokolojn de taskoj kaj aliras la Kubernetes API por akiri metadatenojn, kiuj estos uzataj por marki la protokolojn. Ĝi tiam sendas la protokolon al la ĉefa Loki-servo. Por metadatenoj kongruaj, la samaj etikedreguloj estas subtenataj kiel en Prometheus.
Distributor - servo-distribuisto, funkcianta kiel bufro. Por prilabori milionojn da rekordoj, ĝi pakas envenantajn datumojn, kunpremante ĝin en blokoj kiam ĝi alvenas. Multoblaj datumlavujoj funkcias samtempe, sed ŝtipoj apartenantaj al la sama envenanta datumfluo devus finiĝi en nur unu el ili por ĉiuj ĝiaj blokoj. Ĉi tio estas organizita kiel ringo de riceviloj kaj sinsekva hashing. Por faŭltoleremo kaj redundo, ĝi estas farita n fojojn (3 se ne agordita).
ingesti — serva ricevilo. Datumblokoj venas kunpremitaj kun aldonitaj protokoloj. Tuj kiam la bloko estas de sufiĉa grandeco, la bloko estas fluigita al la datumbazo. La metadatenoj iras al la indekso, kaj la datumoj de la protokolo-bloko iras al Chunks (kutime objektostokado). Post la restarigo, la ricevilo kreas novan blokon kie novaj rekordoj estos aldonitaj.
indekso - datumbazo, DynamoDB, Cassandra, Google BigTable kaj pli.
Blokoj - blokoj de ŝtipoj en kunpremita formo, kutime stokitaj en objektostokado, ekzemple, S3.
Demandanto estas legovojo kiu faras la tutan malpuran laboron. Ĝi rigardas la tempoperiodon kaj tempomarkon, kaj poste rigardas la indekson por serĉi kongruojn. Poste, ĝi legas blokojn da datumoj kaj filtras ilin por ricevi la rezulton.
Nun ni vidu ĉion en la laboro.
fikso
La plej facila maniero instali sur Kubernetes estas uzi stirilon. Ni supozas, ke vi jam instalis kaj agordis ĝin ( ĉ. tradukisto)
Ni aldonas deponejon kaj ni metas stakon.
$ 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=falseMalsupre estas ekzempla panelo montranta datumojn de Prometheus por Etcd kaj Loki-metrikoj por Etcd pod protokoloj.
Kaj nun ni diskutu la arkitekturon de ambaŭ sistemoj, kaj ni komparu iliajn kapablojn unu kun la alia.
Komparo
Demanda Lingvo
Elasticsearch uzas la serĉlingvon Query DSL kaj Lucene por provizi plentekstan serĉkapablon. Ĝi estas establita potenca serĉilo kun larĝa operatora subteno. Per ĝi, vi povas serĉi laŭ kunteksto kaj ordigi laŭ graveco.
Sur la alia flanko de la ringo estas LogQL de Lokio, posteulo de PromQL (Prometheus demandlingvo). Ĝi uzas protokolaj etikedoj por filtri kaj elekti protokolojn. Eblas uzi iujn operatorojn kaj aritmetikon kiel priskribite , sed laŭ kapabloj, ĝi postrestas malantaŭ la Elasta lingvo.
Ĉar petoj en Lokio estas asociitaj kun etikedoj, ili estas facile korelacieblaj kun metrikoj, kiel rezulto, estas pli facile organizi funkcian monitoradon kun ili.
Skalebleco
Ambaŭ stakoj estas horizontale skaleblaj, sed kun Lokio ĝi estas pli facila ĉar ĝi havas apartajn legajn kaj skribajn vojojn, kaj ĝi havas mikroservan arkitekturon. Lokio povas esti personecigita laŭ viaj bezonoj kaj povas esti uzata por tre grandaj volumoj de protokolaj datumoj.
Plurtenanto
Areto plurluado estas ofta temo por OPEX-redukto, ambaŭ stakoj disponigas plurluadon. Estas pluraj por Elasticsearch disiĝo de kliento: aparta indekso por kliento, klient-bazita vojigo, kliento unikaj kampoj, serĉfiltriloj. Lokio havas kiel HTTP X-Scope-OrgID-kapo.
kosto de
Lokio estas tre kostefika pro la fakto ke ĝi ne indeksas datumojn, nur metadatenojn. Tiel, kaj memoro (kaŝmemoro), ĉar objektostokado estas pli malmultekosta ol blokstokado, kiu estas uzita en Elasticsearch-aretoj.
konkludo
La EFK-stako povas esti uzata por diversaj celoj, provizante maksimuman flekseblecon kaj riĉan Kibana-interfacon por analizo, bildigo kaj demandoj. Ĝi povas esti plu plibonigita per maŝinlernado-kapabloj.
La Lokio-stako estas utila en la Kubernetes-ekosistemo pro la metadatuma malkovra mekanismo. Vi povas facile korelacii datumojn por monitorado surbaze de temposerio en Grafana kaj protokoloj.
Se temas pri kosto kaj longtempa konservado de ŝtipoj, Loki estas bonega elekto por eniri la nubon.
Estas pli da alternativoj sur la merkato - kelkaj eble estos pli bonaj por vi. Ekzemple, GKE havas Stackdriver-integriĝon, kiu provizas bonegan monitoran solvon. Ni ne inkludis ilin en nia analizo en ĉi tiu artikolo.
Referencoj
La artikolon tradukis kaj preparis por Habr dungitoj - intensaj, videokursoj kaj kompania trejnado de praktikistoj (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
fonto: www.habr.com