Samlar loggar med Loki

Vi på Badoo övervakar kontinuerligt nya teknologier och bedömer om de bör användas i vårt system. Ett av dessa studier vill vi dela med oss av till samhället. Den handlar om Loki – ett system för loggaggregation.

Loki är en lösning för lagring och visning av loggar, och denna stack erbjuder även ett flexibelt system för deras analys och dataskickning till Prometheus. I maj kom det senaste uppdateringen som aktivt marknadsförs av skaparna. Vi blev intresserade av vad Loki kan göra, vilka möjligheter den erbjuder och i vilken utsträckning den kan fungera som ett alternativ till ELK – stacken som vi använder idag.

Vad är Loki

Grafana Loki är en uppsättning komponenter för ett fullständigt system för arbete med loggar. Till skillnad från andra liknande system är Loki baserat på idén att endast indexera logglägets metadata – etiketter (precis som i Prometheus), medan själva loggarna komprimeras i separata block.

Startsidan, GitHub

Innan jag går över till att beskriva vad man kan göra med hjälp av Loki, vill jag förklara vad som menas med "idén att endast indexera metadata". Låt oss jämföra Loki:s metod och indexeringsmetoden i traditionella lösningar som Elasticsearch, med exempel på en rad från nginx-loggen:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Traditionella system parser hela raden, inklusive fält med många unika värden som user_id och item_id, och sparar allt i stora index. Fördelen med denna metod är att man kan utföra komplexa förfrågningar snabbt eftersom nästan all data finns i indexet. Men det får man betala med att indexet blir stort, vilket leder till minneskrav. I slutändan blir det fulltextsindex över loggarna jämförbart i storlek med loggarna själva. För att söka snabbt i det måste indexet vara laddat i minnet. Ju fler loggar, desto snabbare ökar indexet och desto mer minne kräver det.

Loki:s tillvägagångssätt kräver att endast de nödvändiga uppgifterna extraheras från strängen, vars värdenummer är litet. På så sätt får vi en liten index och kan söka data genom att filtrera dem efter tid och efter indexerade fält, och sedan skanna det som återstår med reguljära uttryck eller delsträngsökning. Processen verkar inte vara den snabbaste, men Loki delar upp förfrågan i flera delar och utför dem parallellt, vilket bearbetar stora mängder data på kort tid. Antalet shardar och parallella förfrågningar i dem kan konfigureras; därmed beror mängden data som kan bearbetas per tidsenhet linjärt på antalet tillhandahållna resurser.

Denna avvägning mellan en stor snabb index och en liten index med parallell fullständig genomsökning gör att Loki kan kontrollera systemkostnaden. Det kan flexibelt anpassas och skaleras enligt behov.

Loki-stack består av tre komponenter: Promtail, Loki, Grafana. Promtail samlar in loggar, bearbetar dem och skickar dem till Loki. Loki lagrar dem. Och Grafana kan begära data från Loki och visa dem. Generellt kan Loki användas inte bara för att lagra loggar och söka i dem. Hela stacken ger stora möjligheter för bearbetning och analys av inkommande data, med hjälp av Prometheus-metoden.
Beskrivningen av installationsprocessen finns att hitta här.

Sökning i loggar

Loggar kan sökas i det speciella Grafana-gränssnittet — Explorer. Förfrågningar använder LogQL-språket, som liknar PromQL som används i Prometheus. I princip kan det ses som en distribuerad grep.

Sökningsgränssnittet ser ut så här:

Själva förfrågan består av två delar: selector och filter. Selector är sökningen efter indexerade metadatan (etiketter) som är tilldelade loggarna, och filter är söksträngen eller regexen som används för att filtrera posterna som bestäms av selector. I det angivna exemplet: Inom klamrarna — selector, allt efteråt — filter.

{image_name="nginx.promtail.test"} |= "index"

På grund av hur Loki fungerar kan inga förfrågningar göras utan selector, men etiketterna kan vara så allmänna som man vill.

Selector är nyckel-värde-par i klamrar. Selector kan kombineras och olika sökvillkor kan ställas in genom att använda operatorerna =, != eller reguljära uttryck:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Hittar loggar med etiketten instance som har värdena kafka-2, kafka-3 och utesluter dev 

En filter är en text eller ett reguljärt uttryck som filtrerar bort all data som mottagits av selektorn.

Det finns möjlighet att få ad-hoc-diagram baserade på de mottagna data i metrics-läget. Till exempel kan man ta reda på frekvensen av att en post som innehåller strängen index dyker upp i nginx-loggar.

En fullständig beskrivning av funktionerna finns i dokumentationen. LogQL.

Loggparsning

Det finns flera sätt att samla loggar:

• Genom att använda Promtail, standardkomponenten i stacken för logginsamling.
• Direkt från Docker-containern med hjälp av Loki Docker Logging Driver.
• Använd Fluentd eller Fluent Bit, som kan skicka data till Loki. Till skillnad från Promtail har de färdiga parsers för nästan alla typer av loggar och hanterar även multiline-loggar.

Vanligtvis används Promtail för parsning. Den gör tre saker:

• Hittar datakällor.
• Fäster etiketter på dem.
• Skickar data till Loki.

För närvarande kan Promtail läsa loggar från lokala filer och systemd-journal. Den måste installeras på varje maskin där loggar samlas in.

Det finns integration med Kubernetes: Promtail tar automatiskt reda på tillståndet i klustret genom Kubernetes REST API och samlar in loggar från noden, tjänsten eller podden, samtidigt som etiketter tilldelas baserat på metadata från Kubernetes (podnamn, filnamn osv.).

Det går också att tilldela etiketter baserat på data från loggen med hjälp av Pipeline. En Promtail-pipeline kan bestå av fyra typer av steg. Mer information finns i den officiella dokumentationen, här noterar jag några detaljer.

1. Parsningstadier. Detta är steg för RegEx och JSON. I detta steg extraherar vi data från loggarna till den så kallade extracted map. Vi kan extrahera från JSON genom att bara kopiera de fält vi behöver till extracted map, eller genom reguljära uttryck (RegEx), där namngivna grupper kartläggs i extracted map. Extracted map är ett key-value-lagringssystem, där key är fältnamnet och value är dess värde från loggarna.
2. Transformationsstadier. Detta steg har två alternativ: transform, där vi anger transformationsregler, och source — datakällan för transformation från extracted map. Om det inte finns något sådant fält i extracted map kommer det att skapas. På så sätt kan vi skapa etiketter som inte är baserade på extracted map. I detta steg kan vi manipulera data i extracted map med hjälp av en tillräckligt kraftfull Golang-mall. Det är också viktigt att komma ihåg att den extraherade mappen laddas helt vid parsning, vilket gör det möjligt att till exempel kontrollera värdet i den: “{{if .tag}tag value exists{end}}”. Mallen stöder villkor, loopar och vissa strängfunktioner som Replace och Trim.
3. Åtgärdssteg. I det här steget kan man göra något med det extraherade:
   • Skapa en etikett från extraherade data som kommer att indexeras av Loki.
   • Ändra eller ställ in händelsetiden från loggen.
   • Ändra data (loggtexten) som kommer att skickas till Loki.
   • Skapa metrik.
4. Filtreringssteg. Matchningssteget där man antingen kan skicka poster som vi inte behöver till /dev/null, eller skicka dem för vidare bearbetning.

Jag visar med exempel på hur vanliga nginx-loggar kan parsas med hjälp av Promtail.

För testet tar vi en modifierad bild av nginx jwilder/nginx-proxy:alpine som nginx-proxy och en liten demon som kan fråga sig själv via HTTP. Villkoren för demon ställs in med flera slutpunkter som den kan ge svar av olika storlek, med olika HTTP-statuskoder och med olika fördröjningar.

Vi kommer att samla loggar från Docker-containrar som kan hittas på vägen /var/lib/docker/containers//-json.log

I docker-compose.yml konfigurerar vi Promtail och anger vägen till konfigurationen:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Vi lägger till i promtail.yml vägen till loggarna (i konfigurationen finns det en option "docker" som gör samma sak med en rad, men det skulle inte vara lika tydligt):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # endast för linux

När en sådan konfiguration aktiveras kommer loggar från alla containrar att hamna i Loki. För att undvika detta ändrar vi inställningarna för den testande nginx i docker-compose.yml – vi lägger till loggning med fältet tag:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Vi redigerar promtail.yml och konfigurerar Pipelines. Loggar av följande slag matas in:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] \"GET /api/index HTTP/1.1\" 200 0 \"-\" \"Stub_Bot/0.1\" \"0.096\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] \"GET /200 HTTP/1.1\" 200 0 \"-\" \"Stub_Bot/0.1\" \"0.000\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

Pipeline steg:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Vi extraherar fälten stream, attrs, attrs.tag från den inkommande JSON och lägger dem i extracted-map.

 - regex:
     expression: ^(?P([^|]+))|(?P([^|]+))$
     source: "tag"

Om vi lyckas lägga fältet tag i extracted-map, så extraherar vi bilderna och containernamn med hjälp av regex.

 - labels:
     image_name:
     container_name:

Vi tilldelar etiketter. Om nycklarna image_name och container_name finns i den extraherade datan kommer deras värden att tilldelas motsvarande etiketter.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Vi slänger alla loggar för vilka inga angivna etiketter image_name och container_name påträffades.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

För alla loggar där image_name är nginx.promtail.test extraherar vi fältet log från den ursprungliga loggen och lägger det i extracted-map med nyckeln row.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P[a-z_.-]+) +(?P.+)
         source: logrow

Vi rengör ingångssträngen med reguljära uttryck och extraherar den virtuella värden för nginx och nginx-loggsträngen.

     - regex:
         source: nginxlog
         expression: ^(?P[w.]+) - (?P[^ ]*) [(?P[^ ]+).*] "(?P[^ ]*) (?P[^ ]*) (?P[^ ]*)" (?P[d]+) (?P[d]+) "(?P[^"]*)" "(?P[^"]*)"( "(?P[d.]+)")?

Vi analyserar nginx-loggen med reguljära uttryck.

    - regex:
           source: request_url
           expression: ^.+.(?Pjpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P[^/?]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P[^/?]+).*$

Vi undersöker request_url. Med hjälp av regex bestämmer vi syftet med förfrågan: till statiska resurser, bilder, API och sätter motsvarande nyckel i extracted-map.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

Med hjälp av villkorssatser i mallen kontrollerar vi de inställda fälten i extracted-map och tilldelar rätt värden till request_type-fältet: photo, static, API. Vi sätter other om ingen framgång. Nu innehåller request_type typ av förfrågan.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Vi ställer in etiketterna api_request, virtual_host, request_type och status (HTTP-status) baserat på vad som kunde läggas i extracted-map.

       - output:
           source: nginx_log_row

Vi ändrar output. Nu skickas den rengjorda nginx-loggen från extracted-map till Loki.

Efter att ha startat den angivna konfigurationen kan man se att varje post har tilldelats etiketter baserat på uppgifterna i loggen.

Det är viktigt att notera att extrahering av etiketter med hög kardinalitet kan avsevärt sänka prestandan hos Loki. Det innebär att man inte bör indexera, till exempel, user_id. Läs mer om detta i artikeln “Hur etiketter i Loki kan göra loggfrågor snabbare och enklare”. Men det betyder inte att man inte kan söka på user_id utan index. Man måste använda filter vid sökningar ("grep"). Indexet fungerar här som en strömningsidentifierare.

Visualisering av loggar

Loki kan fungera som datakälla för Grafana-diagram användandes LogQL. Följande funktioner stöds:

• rate — mängd poster per sekund;
• count over time — antal poster inom ett specificerat intervall.

Dessutom finns det aggregerande funktioner såsom Sum, Avg och andra. Man kan skapa ganska komplexa diagram, till exempel diagram över antalet HTTP-fel:

Den standardiserade datakällan Loki är något begränsad i funktionalitet jämfört med datakällan Prometheus (till exempel kan man inte ändra legenden), men Loki kan kopplas in som en källa av Typ Prometheus. Jag är osäker på om detta är dokumenterat beteende, men enligt svaret från utvecklarna “Hur konfigurerar man Loki som Prometheus datakälla? · Issue #1222 · grafana/loki”, till exempel, är detta fullt legitimt, och Loki är helt kompatibel med PromQL.

Lägg till Loki som datakälla av typ Prometheus och lägg till URL /loki:

Och man kan skapa diagram som om vi arbetade med mätvärden från Prometheus:

Jag tror att skillnaden i funktionalitet är tillfällig och att utvecklarna kommer att åtgärda detta i framtiden.

Mätvärden

I Loki finns möjlighet att extrahera numeriska mätvärden från loggar och skicka dem till Prometheus. Till exempel innehåller nginx-loggen antalet byte för svaret, samt, vid viss modifiering av det standardiserade loggformatet, även tiden i sekunder som togs för svaret. Dessa data kan extraheras och skickas till Prometheus.

Lägg till ännu en sektion i promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "svartid ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "total svardata bytes"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "antal svardata bytes"
           source: bytes_out
           config:
             action: inc

Denna funktion gör det möjligt att definiera och uppdatera metrik baserat på data från den extraherade kartan. Dessa metrik skickas inte till Loki — de visas på Promtail /metrics endpoint. Prometheus måste vara konfigurerad för att hämta data som erhållits vid detta steg. I det givna exemplet för request_type=“api” samlar vi in histogrammmetrik. Detta typ av metrik gör det lätt att få percentiler. För statiska resurser och bilder samlar vi summan av byte och antalet rader där vi mottog byte, för att beräkna medelvärdet.

Läs mer om metrik här.

Öppna porten på Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Se till att metrik med prefixet promtail_custom har dykt upp:

Konfigurera Prometheus. Lägg till jobb promtail:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

Och rita upp en graf:

På så sätt kan man till exempel ta reda på de fyra långsammaste förfrågningarna. Dessutom kan man ställa in övervakning baserat på dessa metrik.

Skalning

Loki kan köras antingen i en enkel läge (single binary mode) eller i en skalbar läge (horizontally-scalable mode). I det andra fallet kan det lagra data i molnet, där chunkar och index lagras separat. I version 1.5 infördes möjligheten att lagra på en plats, men det rekommenderas fortfarande att inte använda det i produktion.

Chunkar kan lagras i en S3-kompatibel lagring, för indexlagring bör man använda horisontellt skalbara databaser: Cassandra, BigTable eller DynamoDB. Övriga delar av Loki — Distributors (för skrivning) och Querier (för förfrågningar) — är stateless och kan även skalas horisontellt.

Vid DevOpsDays konferensen i Vancouver 2019 nämnde en deltagare, Callum Styan, att hans projekt med Loki har petabytes av loggar med ett index som är mindre än 1% av den totala storleken: “Hur Loki korrelerar metrik och loggar — Och sparar dig pengar”.

Jämförelse mellan Loki och ELK

Indexstorlek

För att testa den erhållna indexstorleken använde jag loggar från en nginx-container, för vilken pipelinen som beskrevs ovan konfigurerades. Loggfilen innehöll 406 624 rader med en total storlek på 109 MB. Loggarna genererades under en timme, ungefär 100 poster per sekund.

Exempel på två rader från loggen:

Vid indexering i ELK gav detta en indexstorlek på 30,3 MB:

I fallet med Loki gav det ungefär 128 kB index och ungefär 3,8 MB data i chunkar. Det är värt att notera att loggen var konstgjord och inte uppvisade stor datamångfald. En enkel gzip på den ursprungliga dockerska JSON-loggen med data gav en kompression på 95,4 %, och med tanke på att endast den rensade nginx-loggen skickades till Loki, är kompressionen ner till 4 MB förklarlig. Det totala antalet unika värden för Loki:s etiketter var 35, vilket förklarar den lilla storleken på indexet. För ELK rensades loggen också. Således komprimerade Loki de ursprungliga uppgifterna med 96 %, medan ELK komprimerade med 70 %.

Minneförbrukning

Om man jämför hela Prometheus- och ELK-stacken, så "äter" Loki flera gånger mindre. Det är uppenbart att en tjänst på Go använder mindre än en tjänst på Java, och att jämföra storleken på JVM Heap i Elasticsearch med den dedikerade minnesanvändningen för Loki är oegentligt, men det är ändå värt att notera att Loki använder mycket mindre minne. Dess fördel när det gäller CPU är inte lika uppenbar, men finns också.

Hastighet

Loki "slukar" loggar snabbare. Hastigheten beror på många faktorer — vilka loggar det handlar om, hur sofistikerat vi parsar dem, nätverket, disken osv. — men den är definitivt högre än för ELK (i mitt test ungefär två gånger snabbare). Detta förklaras av att Loki lägger mycket mindre data i indexet och därmed lägger mindre tid på indexering. Med sökhastigheten är situationen den motsatta: Loki saktar ner på data som är större än flera gigabyte, medan ELK:s sökhastighet inte beror på datastorleken.

Sökning i loggar

Loki ligger avsevärt efter ELK när det gäller sökmöjligheter i loggarna. Grep med reguljära uttryck är kraftfullt, men det slår inte en mogen databas. Avsaknaden av range-frågor, aggregering endast efter etiketter, och oförmågan att söka utan etiketter — allt detta begränsar vår förmåga att hitta intressant information i Loki. Detta innebär inte att du inte kan hitta något med Loki, men det definierar arbetsflödet kring loggar, där du först hittar problem i graferna i Prometheus och sedan söker efter vad som hände i loggarna baserat på dessa etiketter.

Gränssnitt

För det första, det är vackert (ursäkta, jag kunde inte hålla mig). Grafana har ett ögonvänligt gränssnitt, men Kibana är mycket mer funktionellt.

Fördelar och nackdelar med Loki

Bland fördelarna kan nämnas att Loki integreras med Prometheus, vilket innebär att vi får metrik och larm direkt. Den är bra för insamling och lagring av loggar från Kubernetes Pods, då den ärver service discovery från Prometheus och automatiskt lägger till etiketter.

Bland nackdelarna - svag dokumentation. Vissa saker, som Promtails funktioner och möjligheter, upptäckte jag bara genom att studera koden, tack och lov för open-source. En annan nackdel är svaga parseringsmöjligheter. Till exempel kan Loki inte parsa multiline-loggar. Ytterligare en nackdel är att Loki är en relativt ung teknologi (version 1.0 släpptes i november 2019).

Slutsats

Loki är en 100% intressant teknologi som passar för små och medelstora projekt, och gör det möjligt att hantera många uppgifter för loggaggregering, loggsökning, övervakning och analys av loggar.

Vi använder inte Loki på Badoo, eftersom vi har en ELK-stack som passar oss och som under många år har byggts ut med olika skräddarsydda lösningar. För oss är sökningen i loggar en kritisk fråga. Med nästan 100 GB loggar per dag är det viktigt för oss att snabbt kunna hitta allt och lite till. För att bygga diagram och övervaka använder vi andra lösningar som är skräddarsydda för våra behov och som är integrerade med varandra. Loki-stacken har påtagliga fördelar, men den kommer inte att ge oss mer än vad vi redan har, och dess fördelar kommer definitivt inte att överväga kostnaden för migreringen.

Och även om det efter undersökningen blev klart att vi inte kan använda Loki, hoppas vi att detta inlägg kan hjälpa dig i ditt val.

Repository med koden som används i artikeln finns ). Ett typiskt exempel på användning:.

Källa: habr.com