Monitoring is een zeer belangrijk onderdeel geworden van de groeiende cloudoplossingen naarmate de complexiteit van gedistribueerde systemen toeneemt. Het is noodzakelijk om hun gedrag te begrijpen. We hebben schaalbare tools nodig die gegevens van alle services kunnen verzamelen en specialisten één enkele interface kunnen bieden met prestatieanalyse, foutdemonstratie, beschikbaarheid en logbestanden.
Deze zelfde hulpmiddelen moeten efficiënt en productief zijn. In dit artikel zullen we twee populaire technologieën bekijken: EFK (Elasticsearch) en PLG (Loki) en hun architecturen en verschillen onderzoeken.
EFK-stapel
Misschien heb je al gehoord van de zeer populaire ELK of EFK. De stapel bestaat uit verschillende afzonderlijke delen: Elasticsearch (objectopslag), Logstash of FluentD (logverzameling en aggregatie) en Kibana voor visualisatie.
Een typische workflow ziet er als volgt uit:
Elasticsearch — gedistribueerde objectopslag met zoeken en realtime analyses. Uitstekende oplossing voor semi-gestructureerde gegevens zoals logs. Informatie wordt opgeslagen als JSON-documenten, in realtime geïndexeerd en gedistribueerd over clusterknooppunten. Er wordt gebruik gemaakt van een omgekeerde index, die alle unieke woorden en bijbehorende documenten bevat voor full-text zoeken, die op zijn beurt gebaseerd is op de Apache Lucene zoekmachine.
VloeiendD is een dataverzamelaar die gegevens verenigt bij het verzamelen en consumeren ervan. Het probeert de gegevens zoveel mogelijk in JSON te organiseren. De architectuur is uitbreidbaar, er zijn er meer , door de gemeenschap ondersteund, voor alle gelegenheden.
Kibana - een datavisualisatietool voor Elasticsearch met verschillende extra mogelijkheden, bijvoorbeeld tijdreeksanalyse, grafiekanalyse, machine learning en meer.
Elasticsearch-architectuur
Elasticsearch-clustergegevens worden verspreid over alle knooppunten opgeslagen. Een cluster bestaat uit meerdere knooppunten om de beschikbaarheid en veerkracht te verbeteren. Elk knooppunt kan alle rollen van het cluster uitvoeren, maar bij grootschalige implementaties worden knooppunten doorgaans aan individuele taken toegewezen.
Typen clusterknooppunten:
- masternode - beheert het cluster, er zijn er minstens drie nodig, één is altijd actief;
- dataknooppunt - slaat geïndexeerde gegevens op en voert er verschillende taken mee uit;
- ingest-knooppunt - organiseert pijplijnen voor het transformeren van gegevens vóór indexering;
- het coördineren van knooppunt-routeringsverzoeken, het verminderen van de zoekverwerkingsfase, het coördineren van massa-indexering;
- waarschuwingsknooppunt — waarschuwingstaken starten;
- machine learning-knooppunt - verwerking van machine learning-taken.
Het onderstaande diagram laat zien hoe gegevens worden opgeslagen en gerepliceerd tussen knooppunten om een hogere gegevensbeschikbaarheid te bereiken.
De gegevens van elke replica worden opgeslagen in een omgekeerde index. Het onderstaande diagram laat zien hoe dit gebeurt:
installatie
Details kunnen worden bekeken , ik gebruik de roergrafiek:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG-stapel
Wees niet verbaasd als u dit acroniem niet kunt vinden, want het is beter bekend als Grafana Loki. Deze stack wint in ieder geval aan populariteit omdat er gebruik wordt gemaakt van bewezen technische oplossingen. Misschien heb je al gehoord van Grafana, een populaire visualisatietool. De makers hebben, geïnspireerd door Prometheus, Loki ontwikkeld, een horizontaal schaalbaar, krachtig logaggregatiesysteem. Loki indexeert alleen de metadata, niet de tijdschriften zelf, een technische oplossing die het mogelijk maakt om gebruiksvriendelijk en kosteneffectief te zijn.
Promtail - een agent voor het verzenden van logboeken van het besturingssysteem naar het Loki-cluster. grafana is een visualisatietool gebaseerd op gegevens van Loki.
Loki is gebouwd op dezelfde principes als Prometheus, waardoor het zeer geschikt is voor het opslaan en analyseren van Kubernetes-logboeken.
Loki-architectuur
Loki kan worden uitgevoerd als een enkel proces of als meerdere processen, waardoor horizontale schaalvergroting mogelijk is.
Het kan ook werken als een monolithische applicatie of als een microservice. Het uitvoeren als één proces kan nuttig zijn voor lokale ontwikkeling of voor kleine monitoring. Voor industriële implementatie en schaalbare werklast wordt aanbevolen om de microservice-optie te gebruiken. De paden voor het schrijven en lezen van gegevens zijn gescheiden, zodat deze indien nodig nauwkeurig kunnen worden afgestemd en geschaald.
Laten we eens kijken naar de architectuur van het logverzamelingssysteem zonder in detail te treden:
En hier is de beschrijving (microservice-architectuur):
componenten:
Promtail — een agent die op knooppunten is geïnstalleerd (als een reeks services), deze verwijdert logboeken van taken en heeft toegang tot de Kubernetes API om metagegevens te verkrijgen die de logboeken zullen taggen. Vervolgens stuurt het het logboek naar de hoofdservice van Loki. Metadata-toewijzing ondersteunt dezelfde taggingregels als Prometheus.
Distributeur — een dienstendistributeur die als buffer werkt. Om miljoenen records te verwerken, worden binnenkomende gegevens verpakt en in blokken gecomprimeerd zodra ze binnenkomen. Er zijn meerdere data-sinks tegelijkertijd actief, maar logs die tot één inkomende datastroom behoren, mogen voor al zijn blokken slechts in één daarvan verschijnen. Dit is georganiseerd in een ring van putten en sequentiële hashing. Voor fouttolerantie en redundantie wordt dit n keer gedaan (3 indien niet geconfigureerd).
Inslikken - dienstontvanger. Datablokken arriveren gecomprimeerd met toegevoegde logs. Zodra het blok voldoende groot is, wordt het blok naar de database gespoeld. Metagegevens gaan naar de index en gegevens uit het logblok gaan naar Chunks (meestal objectopslag). Na de reset maakt de ontvanger een nieuw blok aan waarin nieuwe vermeldingen worden toegevoegd.
Index - database, DynamoDB, Cassandra, Google BigTable, enz.
brokken — logblokken in gecomprimeerde vorm, meestal opgeslagen in objectopslag, bijvoorbeeld S3.
Querier - het leespad dat al het vuile werk doet. Er wordt gekeken naar het tijdsbereik en het tijdstempel, en vervolgens naar de index om overeenkomsten te vinden. Vervolgens leest het gegevensblokken en filtert deze om het resultaat te verkrijgen.
Laten we nu alles in actie zien.
installatie
De eenvoudigste manier om Kubernetes te installeren is door helm te gebruiken. We gaan ervan uit dat je het al hebt geïnstalleerd en geconfigureerd ( ca. vertaler)
Voeg een repository toe en installeer een stapel.
$ 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=falseHieronder ziet u een voorbeelddashboard met gegevens uit Prometheus voor Etcd-statistieken en Loki voor Etcd-podlogboeken.
Laten we nu de architectuur van beide systemen bespreken en ook hun mogelijkheden met elkaar vergelijken.
Сравнение
Query-taal
Elasticsearch gebruikt Query DSL en Lucene-querytaal om zoekmogelijkheden in volledige tekst te bieden. Het is een gevestigde, krachtige zoekmachine met brede ondersteuning door operators. Hiermee kun je zoeken op context en sorteren op relevantie.
Aan de andere kant van de ring bevindt zich LogQL, gebruikt in Loki, de opvolger van PromQL (Prometheus-querytaal). Het gebruikt logtags om loggegevens te filteren en te selecteren. Het is mogelijk om enkele operatoren en rekenkundige bewerkingen te gebruiken, zoals beschreven , maar qua mogelijkheden blijft het achter bij Elastic-taal.
Omdat zoekopdrachten in Loki aan tags zijn gekoppeld, zijn ze gemakkelijk te correleren met statistieken, en als gevolg daarvan is het eenvoudiger om operationele monitoring te organiseren.
Schaalbaarheid
Beide stapels zijn horizontaal schaalbaar, maar Loki maakt het eenvoudiger omdat het afzonderlijke lees- en schrijfpaden en een microservice-architectuur heeft. Loki kan worden aangepast aan uw behoeften en kan worden gebruikt voor zeer grote hoeveelheden loggegevens.
Multitenancy
Cluster multitenancy is een veel voorkomend thema in de afkorting OPEX, beide stacks bieden multitenancy. Er zijn er verschillende voor Elasticsearch klantscheiding: aparte index voor elke klant, klantgebaseerde routing, unieke klantvelden, zoekfilters. Loki heeft in de vorm van een HTTP X-Scope-OrgID-header.
kosten
Loki is behoorlijk kosteneffectief vanwege het feit dat het de gegevens niet indexeert, alleen de metadata. Dit bereikt en geheugen (cache), aangezien objectopslag goedkoper is dan blokopslag, die wordt gebruikt in Elasticsearch-clusters.
Conclusie
De EFK-stack kan voor verschillende doeleinden worden gebruikt en biedt maximale flexibiliteit en een veelzijdige Kibana-interface voor analyse, visualisatie en query's. Het kan verder worden verbeterd door machine learning-mogelijkheden.
De Loki-stack is nuttig in het Kubernetes-ecosysteem vanwege het mechanisme voor het ontdekken van metagegevens. Gegevens voor monitoring kunt u eenvoudig correleren op basis van tijdreeksen in Grafana en logs.
Als het gaat om kosten en langdurige logopslag, is Loki een uitstekend instappunt voor cloudoplossingen.
Er zijn meer alternatieven op de markt, sommige zijn misschien beter voor u. GKE heeft bijvoorbeeld een Stackdriver-integratie die een uitstekende monitoringoplossing biedt. We hebben ze niet meegenomen in onze analyse in dit artikel.
referenties:
Het artikel is door medewerkers vertaald en voorbereid voor Habr — intensieve cursussen, videocursussen en bedrijfstrainingen van praktijkspecialisten (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Bron: www.habr.com