Fondamenti e architettura Grafana Loki

Grafana Loki è un sistema di aggregazione di tronchi altamente scalabile o orizzontalmente. È progettato per semplicità ed efficienza in termini di costi. Creata da Grafana Labs nel 2018, Loki è rapidamente emerso come un’alternativa avvincente ai sistemi di registrazione tradizionali, in particolare per gli ambienti di nativo cloud e kubernetes.

Loki può fornire un percorso di registro completo. Possiamo selezionare i flussi di registro giusti e quindi filtrare per concentrarci sui registri pertinenti. Possiamo quindi analizzare i dati di registro strutturati da formattare per le nostre esigenze di analisi personalizzate. I registri possono anche essere trasformati in modo appropriato per la presentazione, advert esempio, o ulteriore elaborazione della pipeline.

Loki si integra perfettamente con il più ampio Ecosistema Grafana. Gli utenti possono fare question nei registri utilizzando Logql, un linguaggio di question intenzionalmente progettato per assomigliare a Prometheus Promql. Ciò offre un’esperienza familiare per gli utenti che già lavorano con le metriche Prometheus e consente una potente correlazione tra metriche e registri all’interno dei dashboard di Grafana.

Questo articolo inizia con i fondamenti Loki, seguiti da una panoramica architettonica di base. Seguono le basi di Logql e concludiamo con i compromessi coinvolti.

Fondamenti Loki

Per le organizzazioni che gestiscono sistemi complessi, Loki Fornisce una soluzione di registrazione unificata. Supporta l’ingestione di tronchi da qualsiasi fonte attraverso una vasta gamma di agenti o la sua API, garantendo una copertura completa di {hardware} e software program diversi. Loki memorizza i suoi registri come flussi di registro, come mostrato nel diagramma 1. Ogni voce ha quanto segue:

1. UN timestamp con precisione di nanosecondi
2. Coppie di valore chiave chiamate Etichette vengono utilizzati per cercare i registri. Le etichette forniscono i metadati per la linea di registro. Sono utilizzati per l’identificazione e il recupero dei dati. Formano l’indice per i flussi di registro e strutturano l’archiviazione del registro. Ogni combinazione unica di etichette e i loro valori definisce un flusso di registro distinto. Le voci di registro all’interno di un flusso sono raggruppate, compresse e memorizzate in segmenti.
3. Il vero Contenuto di registro. Questa è la linea di tronchi RAW. Non è indicizzato ed è archiviato in blocchi compressi.

Architettura

Analizzeremo l’architettura di Loki basata su tre funzionalità di base. Leggere, scrivere e conservare i registri. Loki può funzionare in modalità monolitica (single-binaria) o microservizi, in cui i componenti sono separati per il ridimensionamento indipendente. La funzionalità di lettura e scrittura può essere ridimensionata in modo indipendente per adattarsi a casi d’uso specifici. Consideriamo ogni percorso in modo più dettagliato.

Scrivere

Nel diagramma 2, il percorso di scrittura è il percorso verde. Quando i registri immettono loki, il distributore framme i registri in base alle etichette. L’ingester quindi memorizza i registri in memoria e il compattatore ottimizza l’archiviazione. I passaggi principali coinvolti sono i seguenti.

Passaggio 1: registri INVIO LOKI

Le scritture per i registri in arrivo arrivano al distributore. I registri sono strutturati come flussi, con etichette (come {job="nginx", stage="error"}). I registri del distributore framme, le partizioni registri e inviano registri agli inger. Hashs etichette di ogni flusso e lo assegna a un ingester usando hashing coerente. I distributori convalidano i registri e impediscono i dati malformati. L’hashing coerente può garantire una distribuzione di registro uniforme tra gli inger.

Passaggio 2: Archiviazione a breve termine

I negozi ingester registrano in memoria per un rapido recupero. I registri sono in lotta e scritti a Write-ahead Logs (WAL) per prevenire la perdita di dati. WAL aiuta con durata ma non è direttamente question: gli ingerve devono ancora rimanere on-line per interrogare i registri recenti.

Periodicamente, i registri vengono scaricati dagli inger -alla conservazione degli oggetti. The Quelier e Ruler hanno letto l’Ingester per accedere ai dati più recenti. Il Quelier può inoltre accedere ai dati di archiviazione degli oggetti.

Passaggio 3: i registri passano alla memoria a lungo termine

Il compattatore elabora periodicamente i registri memorizzati dalla memoria a lungo termine (object-storage). La memoria degli oggetti è economica e scalabile. Consente a Loki di archiviare enormi quantità di tronchi senza costi elevati. Il compattatore deduplica i registri ridondanti, comprime i registri per l’efficienza di archiviazione ed elimina i vecchi registri in base alle impostazioni di conservazione. I registri sono archiviati in formato a blocchi (non indicizzato a testo completo).

Lettura

Nel diagramma 2, il percorso di lettura è il percorso blu. Le question vanno al frontend question e i registri di Quelier recuperano i registri. I registri vengono filtrati, analizzati e analizzati usando LogQL. I passaggi principali coinvolti sono i seguenti.

Passaggio 1: Question Frontend ottimizza le richieste

Registri di question degli utenti utilizzando LogQL in Grafana. Il frontend question rompe grandi question in blocchi più piccoli e le distribuisce su più querier poiché l’esecuzione parallela accelera le question. È responsabile dell’accelerazione dell’esecuzione delle question e della garanzia di tentativi in ​​caso di fallimento. Question Frontend aiuta a evitare timeout e sovraccarichi, mentre le domande non riuscite vengono riprodotte automaticamente.

Passaggio 2: querier recupera i registri

Queriers analizza i logql e le question inger e la conservazione degli oggetti. I registri recenti vengono recuperati dagli inger e i registri più vecchi vengono recuperati dalla memoria degli oggetti. I registri con lo stesso timestamp, etichette e contenuti sono de-duplicati.

I filtri Bloom e le etichette di indice vengono utilizzate per trovare i registri in modo efficiente. Question di aggregazione, come count_over_time() Esegui più velocemente perché Loki non indica completamente i registri. A differenza di ElaSticSearch, Loki non indicizza il contenuto di registro completo.

Invece, indicizza le etichette dei metadati ({app="nginx", stage="error"}), che aiuta a trovare i registri in modo efficiente ed economico. Le ricerche full-text vengono eseguite solo su blocchi di registro pertinenti, riducendo i costi di archiviazione.

Logql Fundamentals

Logql è il linguaggio delle question utilizzato in Grafana Loki per cercare, filtrare e trasformare i registri in modo efficiente. È costituito da due componenti principali:

1. Selettore di streaming – Seleziona i flussi di registro in base ai matcher etichetta
2. Filtraggio e trasformazione – Estrai linee di registro pertinenti, analisi di dati strutturati e formati di question

Combinando queste funzionalità, LogQL consente agli utenti di recuperare in modo efficiente i registri, estrarre approfondimenti e generare metriche utili dai dati dei registri.

Selettore di streaming

Un selettore di flusso è il primo passo in ogni question logQL. Seleziona i flussi di registro in base ai matcher etichetta. Per perfezionare i risultati delle question a specifici flussi di registro, possiamo utilizzare operatori di base per filtrare le etichette Loki. Il miglioramento della precisione della nostra selezione del flusso di registro riduce al minimo il quantity dei flussi scansionati, aumentando così la velocità delle question.

Esempi

{app="nginx"}             # Selects logs the place app="nginx"

staging"     # Selects logs from prod or staging environments

{job!="backend"}          # Excludes logs from the backend job

Filtri della linea

Una volta selezionati i registri, i filtri della linea perfezionano i risultati cercando un testo specifico o applicando condizioni logiche. I filtri di riga funzionano sul contenuto del registro, non sul fatto che non etichette.

Esempi

{app="nginx"} |= "error"       # Choose logs from nginx that comprise "error"

{app="db"} != "timeout"        # Exclude logs with "timeout"

{job="frontend"} |~ "5d{2}"   # Match HTTP 500-series errors (500-599)

Parser

Loki può accettare registri non strutturati, semi-strutturati o strutturati. Tuttavia, comprendere i formati di registro con cui stiamo lavorando è cruciale durante la progettazione e la costruzione di soluzioni di osservabilità. In questo modo, possiamo ingerire, archiviare e analizzare i dati di registro da utilizzare in modo efficace. Loki supporta JSON, Logfmt, Sample, Regexp e Unpack Parser.

Esempi

{app="funds"} | json                     # Extracts JSON fields

{app="auth"} | logfmt                       # Extracts key-value pairs

{app="nginx"} | regexp "(?Pd{3})"  # Extracts HTTP standing codes

Filtri dell’etichetta

Una volta analizzato, i registri possono essere filtrati da campi estratti. Le etichette possono essere estratte come parte della pipeline di registro utilizzando espressioni di parser ed formatter. L’espressione del filtro dell’etichetta può quindi essere utilizzata per filtrare la nostra linea di registro con una di queste etichette.

Esempi

{app="net"} | json | standing="500"   # Extract JSON, then filter by standing=500

{app="db"} | logfmt | person="admin"  # Extract key-value logs, filter by person=admin

Formato di linea

Utilizzato per modificare l’uscita del registro estraendo e formattando campi. Ciò formatta il modo in cui i registri vengono visualizzati in Grafana.

Esempio

{app="nginx"} | json | line_format "Person {person} encountered {standing} error"

Formato dell’etichetta

Utilizzato per rinominare, modificare, creare o rilasciare etichette. Accetta un elenco separato dalla virgola di operazioni di uguaglianza, consentendo di eseguire contemporaneamente operazioni a number of.

Esempi

1. {app="nginx"} | label_format new_label=old_label.    #If a log has {old_label="backend"}, it's renamed to {new_label="backend"}. The unique old_label is eliminated.

2. {app="net"} | label_format standing="HTTP {{.standing}}" #If {standing="500"}, it turns into {standing="HTTP 500"}.

3. {app="db"} | label_format severity="essential".       #Provides {severity="essential"} to all logs.

4. {app="api"} | drop log_level                         # Drops log_level 

Compromessi

Grafana Loki Offre una soluzione di registrazione scalabile e efficiente in termini di costi che memorizza i registri in blocchi compressi con indicizzazione minima. Ciò viene fornito con compromessi nella efficiency delle question e nella velocità di recupero. A differenza dei tradizionali sistemi di gestione dei registri che indicizzano il contenuto completo del registro, l’indicizzazione basata sull’etichetta di Loki accelera il filtro.

Tuttavia, può rallentare complesse ricerche di testo. Inoltre, mentre Loki eccelle nel gestire ambienti distribuiti advert alto rendimento, si basa sulla memoria degli oggetti per la scalabilità. Ciò può introdurre latenza e richiede un’attenta selezione di etichette per evitare problemi di cardinalità elevata.

Scalabilità e multi-tenancy

Loki è progettato per scalabilità e multi-tenancy. Tuttavia, la scalabilità viene fornita con compromessi architettonici. Il ridimensionamento delle scritture (ingerratrici) è semplice a causa della capacità di frammenti di tronchi basati sul partizionamento basato sull’etichetta. Il ridimensionamento delle letture (querier) è più complicato perché può essere lenta interrogare set di dati di grandi dimensioni dalla memoria degli oggetti. È supportata la multi-tenancy, ma la gestione delle quote specifiche degli inquilini, dell’esplosione delle etichette e della sicurezza (isolamento dei dati per tenant) richiede un’attenta configurazione.

Ingestione semplice senza pre-parametri

Loki non richiede pre-parametri perché non indicizza il contenuto di registro completo. Memorizza i registri in formato grezzo in blocchi compressi. Poiché a Loki manca di indicizzazione full-text, la question Structured Logs (EG, JSON) richiede l’analisi LogQL. Ciò significa che le prestazioni di question dipende da quanto bene sono strutturati prima dell’ingestione. Senza registri strutturati, l’efficienza delle question soffre perché il filtraggio deve avvenire al momento del recupero, non all’ingestione.

Memorizzazione nel negozio di oggetti

LOKI lava i pezzi di log su memoria degli oggetti (EG, S3, GCS, Azure BLOB). Ciò riduce la dipendenza da una costosa conservazione a blocchi come, advert esempio, richiede Elasticsearch.

Tuttavia, la lettura dei registri dall’archiviazione degli oggetti può essere lento rispetto alla question direttamente da un database. Loki ne compensa mantenendo registri recenti negli inger -per un recupero più rapido. La compattazione riduce le spese generali di archiviazione, ma la latenza di recupero dei registri può ancora essere un problema per le domande su larga scala.

Etichette e cardinalità

Poiché le etichette vengono utilizzate per cercare registri, sono fondamentali per question efficienti. La scarsa etichettatura può portare a problemi di cardinalità elevata. Utilizzando etichette advert alta cardinalità (advert es. user_id, session_id) aumenta l’utilizzo della memoria e rallenta le question. LOKI Hashes Etichette per distribuire tronchi tra gli inger, quindi un cattivo design di etichette può causare distribuzione dei registri irregolari.

Filtraggio presto

Poiché Loki memorizza i registri grezzi compressi nella memoria degli oggetti, è importante filtrare in anticipo se vogliamo che le nostre domande siano veloci. L’analisi complessa di elaborazione su set di dati più piccoli aumenterà i tempi di risposta. Secondo questa regola, una buona domanda sarebbe una question 1 e una pessima domanda sarebbe una domanda 2.

Domanda 1

{job="nginx", status_code=~"5.."} | json

Question 1 filtri registri dove job="nginx" e il status_code inizia con 5 (500–599 errori). Quindi, estrae i campi JSON strutturati usando | json. Ciò riduce al minimo il numero di registri elaborati dal parser JSON, rendendolo più veloce.

Domanda 2

{job="nginx"} | json | status_code=~"5.."

Question 2 prima recupera tutti i registri da nginx. Questo potrebbe essere milioni di voci. Quindi analizza JSON per ogni singola voce di registro prima di filtrare status_code. Questo è inefficiente e significativamente più lento.

Avvolgimento

Grafana Loki è un sistema di aggregazione di tronchi potente ed economico progettato per la scalabilità e la semplicità. Indicizzando solo i metadati, mantiene bassi i costi di archiviazione consentendo question rapide utilizzando LogQL.

La sua architettura di microservizi supporta distribuzioni flessibili, rendendolo ideale per gli ambienti nativi cloud. Questo articolo ha affrontato le basi di Loki e la sua lingua di question. Navigando attraverso le caratteristiche salienti dell’architettura di Loki, possiamo comprendere meglio i compromessi coinvolti.