Logboeken verzamelen van Loki

Bij Badoo houden we voortdurend nieuwe technologieën in de gaten en evalueren we of ze de moeite waard zijn om in ons systeem te gebruiken. Eén van deze onderzoeken willen wij graag delen met de gemeenschap. Het is gewijd aan Loki, een logaggregatiesysteem.

Loki is een oplossing voor het opslaan en bekijken van logboeken, en deze stapel biedt ook een flexibel systeem om deze te analyseren en gegevens naar Prometheus te verzenden. In mei is er weer een update uitgebracht, die actief wordt gepromoot door de makers. We waren geïnteresseerd in wat Loki kan doen, welke mogelijkheden het biedt en in hoeverre het kan fungeren als alternatief voor ELK, de stack die we nu gebruiken.

Wat is Loki

Grafana Loki is een set componenten voor een compleet systeem voor het werken met boomstammen. In tegenstelling tot andere soortgelijke systemen is Loki gebaseerd op het idee om alleen logmetadata (labels) te indexeren (hetzelfde als in Prometheus), en de logs zelf in afzonderlijke delen te comprimeren.

Beginpagina, GitHub

Voordat we ingaan op wat je met Loki kunt doen, wil ik verduidelijken wat we bedoelen met ‘het idee om alleen metadata te indexeren’. Laten we de Loki-aanpak vergelijken met de benadering van indexering in traditionele oplossingen zoals Elasticsearch, met behulp van het voorbeeld van een regel uit het nginx-logboek:

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"

Traditionele systemen analyseren de hele rij, inclusief velden met een groot aantal unieke user_id- en item_id-waarden, en slaan alles op in grote indexen. Het voordeel van deze aanpak is dat u complexe queries snel kunt uitvoeren, aangezien bijna alle gegevens in de index staan. Maar dit brengt kosten met zich mee omdat de index groot wordt, wat zich vertaalt in geheugenvereisten. Als gevolg hiervan is de volledige tekstlogindex qua grootte vergelijkbaar met de logbestanden zelf. Om er snel doorheen te kunnen zoeken, moet de index in het geheugen worden geladen. En hoe meer logbestanden, hoe sneller de index groeit en hoe meer geheugen deze in beslag neemt.

De Loki-aanpak vereist dat alleen de noodzakelijke gegevens uit een string worden gehaald, waarvan het aantal waarden klein is. Op deze manier krijgen we een kleine index en kunnen we de gegevens doorzoeken door deze te filteren op tijd en op geïndexeerde velden, en vervolgens de rest te scannen met reguliere expressies of zoeken naar subtekenreeksen. Het proces lijkt niet het snelste, maar Loki splitst het verzoek in verschillende delen en voert deze parallel uit, waarbij in korte tijd een grote hoeveelheid gegevens wordt verwerkt. Het aantal shards en parallelle verzoeken daarin is configureerbaar; De hoeveelheid gegevens die per tijdseenheid kan worden verwerkt, hangt dus lineair af van de hoeveelheid beschikbare bronnen.

Door deze afweging tussen een grote, snelle index en een kleine, parallelle brute-force-index kan Loki de kosten van het systeem beheersen. Het kan flexibel worden geconfigureerd en uitgebreid naar behoefte.

De Loki-stack bestaat uit drie componenten: Promtail, Loki, Grafana. Promtail verzamelt logs, verwerkt deze en stuurt deze naar Loki. Loki bewaart ze. En Grafana kan gegevens bij Loki opvragen en weergeven. Over het algemeen kan Loki niet alleen worden gebruikt voor het opslaan van logboeken en het doorzoeken ervan. De hele stapel biedt geweldige mogelijkheden voor het verwerken en analyseren van binnenkomende gegevens op de Prometheus-manier.
Een beschrijving van het installatieproces kunt u vinden hier.

Zoeken op logboeken

U kunt de logs doorzoeken in een speciale Grafana-interface - Explorer. De query's gebruiken de LogQL-taal, die sterk lijkt op de PromQL die in Prometheus wordt gebruikt. In principe kan het worden gezien als een gedistribueerde grep.

De zoekinterface ziet er als volgt uit:

Het verzoek zelf bestaat uit twee delen: selector en filter. Selector is een zoekopdracht met behulp van geïndexeerde metagegevens (labels) die aan logboeken zijn toegewezen, en filter is een zoekreeks of regexp die records filtert die door de selector zijn gedefinieerd. In het gegeven voorbeeld: Tussen accolades is er een selector, alles daarna is een filter.

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

Vanwege de manier waarop Loki werkt, kun je geen zoekopdrachten maken zonder een selector, maar labels kunnen zo algemeen worden gemaakt als je wilt.

Een selector is een sleutelwaardewaarde tussen accolades. U kunt selectors combineren en verschillende zoekvoorwaarden opgeven met behulp van de operatoren =, != of ​​reguliere expressies:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

Een filter is tekst of regexp die alle gegevens filtert die door de selector worden ontvangen.

Het is mogelijk om ad-hocgrafieken te verkrijgen op basis van de ontvangen gegevens in de metrische modus. U kunt bijvoorbeeld achterhalen hoe vaak een item met de stringindex in de nginx-logboeken verschijnt:

Een volledige beschrijving van de mogelijkheden vindt u in de documentatie LogQL.

Log parseren

Er zijn verschillende manieren om logboeken te verzamelen:

• Met behulp van Promtail, een standaardcomponent van de stapel voor het verzamelen van logs.
• Rechtstreeks vanuit de docker-container met behulp van Loki Docker logboekregistratie-stuurprogramma.
• Gebruik Fluentd of Fluent Bit, die gegevens naar Loki kunnen sturen. In tegenstelling tot Promtail hebben ze kant-en-klare parsers voor vrijwel elk type log en kunnen ze ook logs met meerdere regels verwerken.

Meestal wordt Promtail gebruikt voor het parseren. Het doet drie dingen:

• Vindt gegevensbronnen.
• Plakt er labels aan.
• Verzendt gegevens naar Loki.

Momenteel kan Promtail logboeken lezen van lokale bestanden en van systemd journal. Het moet worden geïnstalleerd op elke machine waarvan logboeken worden verzameld.

Er is integratie met Kubernetes: Promtail herkent automatisch, via de Kubernetes REST API, de status van het cluster en verzamelt logs van een node, service of pod, waarbij hij direct labels plaatst op basis van metadata uit Kubernetes (podnaam, bestandsnaam, etc.) .

Met Pipeline kunt u ook labels ophangen op basis van gegevens uit het logboek. Pipeline Promtail kan uit vier soorten fasen bestaan. Meer details binnen officiële documentatie, ik zal meteen enkele nuances opmerken.

1. Fasen ontleden. Dit is de RegEx- en JSON-fase. In dit stadium extraheren we gegevens uit de logs in de zogenaamde geëxtraheerde kaart. We kunnen uit JSON extraheren door simpelweg de velden die we nodig hebben naar de geëxtraheerde kaart te kopiëren, of via reguliere expressies (RegEx), waarbij benoemde groepen in de geëxtraheerde kaart worden "in kaart gebracht". De geëxtraheerde kaart is een sleutel/waarde-archief, waarbij sleutel de naam van het veld is, en waarde de waarde uit de logboeken.
2. Transformeer fasen. Deze fase heeft twee opties: transformeren, waar we de transformatieregels instellen, en bron - de gegevensbron voor transformatie uit de geëxtraheerde kaart. Als een dergelijk veld niet op de geëxtraheerde kaart staat, wordt het aangemaakt. Op deze manier is het mogelijk om labels te maken die niet gebaseerd zijn op de geëxtraheerde kaart. In dit stadium kunnen we de gegevens in de geëxtraheerde kaart manipuleren met behulp van een redelijk krachtige Golang-sjabloon. Bovendien moeten we niet vergeten dat de geëxtraheerde kaart volledig wordt geladen tijdens het parseren, wat het bijvoorbeeld mogelijk maakt om de waarde daarin te controleren: “{{if .tag}tagwaarde bestaat{end}}”. Sjabloon ondersteunt voorwaarden, lussen en enkele tekenreeksfuncties zoals Vervangen en Trimmen.
3. Actiefasen. Op dit punt kunt u iets doen met de geëxtraheerde inhoud:
   • Maak een label van de geëxtraheerde gegevens, die door Loki worden geïndexeerd.
   • Wijzig of stel de gebeurtenistijd in via het logboek.
   • Wijzig de gegevens (logtekst) die naar Loki gaan.
   • Maak statistieken.
4. Fasen filteren. De matchfase, waar we inzendingen die we niet nodig hebben naar /dev/null kunnen sturen of doorsturen voor verdere verwerking.

Aan de hand van een voorbeeld van het verwerken van reguliere nginx-logboeken, zal ik laten zien hoe u logboeken kunt parseren met Promtail.

Laten we voor de test als nginx-proxy een gewijzigde nginx-afbeelding jwilder/nginx-proxy:alpine nemen en een kleine daemon die zichzelf via HTTP kan opvragen. De daemon heeft verschillende eindpunten waarop hij antwoorden van verschillende groottes kan leveren, met verschillende HTTP-statussen en met verschillende vertragingen.

We verzamelen logboeken van docker-containers, die te vinden zijn langs het pad /var/lib/docker/containers/ / -json.log

In docker-compose.yml configureren we Promtail en specificeren we het pad naar de configuratie:

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'
 // ...

Voeg het pad naar de logs toe naar promtail.yml (er is een “docker” optie in de configuratie, die hetzelfde doet op één regel, maar het zou niet zo duidelijk zijn):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Wanneer deze configuratie is ingeschakeld, worden logboeken van alle containers naar Loki verzonden. Om dit te voorkomen, wijzigen we de instellingen van de test-nginx in docker-compose.yml - voeg een veld voor een logtag toe:

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

Promtail.yml bewerken en Pipeline instellen. De invoer bevat logboeken van het volgende type:

{"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"}

Pijplijnfase:

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

We extraheren de velden stream, attrs, attrs.tag (als ze bestaan) uit de binnenkomende JSON en plaatsen ze in de geëxtraheerde kaart.

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

Als het ons is gelukt om het tagveld in de geëxtraheerde kaart te plaatsen, extraheren we met behulp van regexp de namen van de afbeelding en de container.

 - labels:
     image_name:
     container_name:

Wij wijzen labels toe. Als de sleutels image_name en container_name in de geëxtraheerde gegevens worden gevonden, worden hun waarden toegewezen aan de overeenkomstige labels.

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

We verwijderen alle logboeken waarin de labels image_name en container_name niet zijn geïnstalleerd.

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

Voor alle logboeken waarvan de afbeeldingsnaam nginx.promtail.test is, extraheert u het logboekveld uit het bronlogboek en plaatst u dit in de uitgepakte kaart met de rijsleutel.

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

We maken de invoerregel leeg met reguliere expressies en halen de virtuele nginx-host en de nginx-logregel eruit.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Parseer het nginx-logboek met behulp van reguliere expressies.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|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<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Laten we request_url analyseren. Met behulp van regexp bepalen we het doel van het verzoek: naar statische gegevens, naar foto's, naar API en stellen we de bijbehorende sleutel in de geëxtraheerde kaart in.

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

Met behulp van voorwaardelijke operatoren in Sjabloon controleren we de geïnstalleerde velden in de geëxtraheerde kaart en stellen we de vereiste waarden in voor het veld request_type: foto, statisch, API. Wijs een ander toe als het mislukt. request_type bevat nu het verzoektype.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

We hebben de labels api_request, virtual_host, request_type en status (HTTP-status) ingesteld op basis van wat we in de geëxtraheerde kaart hebben kunnen plaatsen.

       - output:
           source: nginx_log_row

Wijzig de uitvoer. Nu gaat het opgeschoonde nginx-logboek van de uitgepakte kaart naar Loki.

Nadat u de bovenstaande configuratie hebt uitgevoerd, kunt u zien dat aan elk item labels zijn toegewezen op basis van gegevens uit het logboek.

Eén ding om in gedachten te houden is dat het ophalen van labels met een groot aantal waarden (kardinaliteit) Loki aanzienlijk kan vertragen. Dat wil zeggen dat u bijvoorbeeld user_id niet in de index moet plaatsen. Lees hierover meer in het artikel “Hoe labels in Loki logquery's sneller en eenvoudiger kunnen maken" Maar dit betekent niet dat u zonder indexen niet op user_id kunt zoeken. U moet filters gebruiken bij het zoeken (‘de gegevens pakken’), en de index fungeert hier als stream-ID.

Visualisatie van logboeken

Loki kan fungeren als gegevensbron voor Grafana-grafieken met behulp van LogQL. De volgende functies worden ondersteund:

• snelheid — aantal records per seconde;
• tellen in de loop van de tijd — het aantal records in het opgegeven bereik.

Er zijn ook aggregatiefuncties Sum, Avg en andere. Je kunt behoorlijk complexe grafieken maken, bijvoorbeeld een grafiek van het aantal HTTP-fouten:

De standaard databron Loki is qua functionaliteit wat verminderd ten opzichte van de Prometheus databron (je kunt bijvoorbeeld de legenda niet wijzigen), maar Loki kan als bron gekoppeld worden met het Prometheus type. Ik weet niet zeker of dit gedocumenteerd gedrag is, maar afgaande op de reactie van de ontwikkelaars “Hoe Loki configureren als Prometheus-gegevensbron? · Uitgave #1222 · grafana/loki”, is bijvoorbeeld volledig legaal en Loki is volledig compatibel met PromQL.

Voeg Loki toe als gegevensbron met het type Prometheus en voeg URL /loki toe:

En we kunnen grafieken maken, alsof we met statistieken van Prometheus werken:

Ik denk dat de discrepantie in functionaliteit tijdelijk is en dat de ontwikkelaars dit in de toekomst zullen corrigeren.

statistieken

Loki biedt de mogelijkheid om numerieke gegevens uit logboeken te halen en deze naar Prometheus te sturen. Het nginx-logboek bevat bijvoorbeeld het aantal bytes per antwoord, evenals, met een bepaalde aanpassing van het standaard logformaat, de tijd in seconden die nodig was om te reageren. Deze gegevens kunnen worden geëxtraheerd en naar Prometheus worden verzonden.

Voeg nog een sectie toe aan promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time 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: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Met deze optie kunt u statistieken definiëren en bijwerken op basis van gegevens uit de geëxtraheerde kaart. Deze statistieken worden niet naar Loki verzonden, maar verschijnen in het Promtail /metrics-eindpunt. Prometheus moet worden geconfigureerd om de in dit stadium ontvangen gegevens te ontvangen. In het bovenstaande voorbeeld verzamelen we voor request_type=“api” een histogramstatistiek. Met dit soort metrieken is het handig om percentielen te verkrijgen. Voor statische gegevens en foto's verzamelen we de som van de bytes en het aantal rijen waarin we bytes hebben ontvangen om het gemiddelde te berekenen.

Lees meer over statistieken hier.

Open de poort op Promtail:

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

Zorg ervoor dat statistieken met het voorvoegsel promtail_custom verschijnen:

Prometheus opzetten. Vacaturepromptail toevoegen:

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

En we tekenen een grafiek:

Zo kun je bijvoorbeeld de vier langzaamste queries achterhalen. U kunt ook monitoring voor deze statistieken instellen.

scaling

Loki kan zich in de enkele binaire modus bevinden of in de shardmodus (horizontaal schaalbare modus). In het tweede geval kan het gegevens in de cloud opslaan en worden de chunks en de index afzonderlijk opgeslagen. Versie 1.5 introduceert de mogelijkheid om op één plek op te slaan, maar het wordt nog niet aanbevolen om deze in productie te gebruiken.

Chunks kunnen worden opgeslagen in S3-compatibele opslag, en horizontaal schaalbare databases kunnen worden gebruikt om indexen op te slaan: Cassandra, BigTable of DynamoDB. Andere delen van Loki – Distributors (voor schrijven) en Querier (voor queries) – zijn staatloos en schalen ook horizontaal.

Op de DevOpsDays Vancouver 2019-conferentie kondigde een van de deelnemers Callum Styan aan dat zijn project met Loki petabytes aan logs heeft met een index van minder dan 1% van de totale grootte: “Hoe Loki statistieken en logboeken correleert - en u geld bespaart'.

Vergelijking van Loki en ELK

Indexgrootte

Om de resulterende indexgrootte te testen, heb ik logboeken overgenomen van de nginx-container waarvoor de bovenstaande pijplijn was geconfigureerd. Het logbestand bevatte 406 regels met een totaalvolume van 624 MB. Logboeken werden binnen een uur gegenereerd, ongeveer 109 vermeldingen per seconde.

Voorbeeld van twee regels uit het log:

Wanneer geïndexeerd door ELK leverde dit een indexgrootte op van 30,3 MB:

In het geval van Loki resulteerde dit in ongeveer 128 KB aan index en ongeveer 3,8 MB aan gegevens in stukjes. Het is vermeldenswaard dat het logboek kunstmatig is gegenereerd en niet over een grote verscheidenheid aan gegevens beschikt. Een simpele gzip op het originele Docker JSON-logboek met gegevens gaf een compressie van 95,4%, en rekening houdend met het feit dat alleen het opgeschoonde nginx-logboek naar Loki zelf werd gestuurd, is een compressie van maximaal 4 MB begrijpelijk. Het totale aantal unieke waarden voor Loki-labels was 35, wat de kleine omvang van de index verklaart. Voor ELK werd het logboek ook gewist. Loki comprimeerde dus de originele gegevens met 96% en ELK met 70%.

Geheugenverbruik

Als we de hele stapel Prometheus en ELK vergelijken, 'eet' Loki meerdere keren minder. Het is duidelijk dat een Go-service minder verbruikt dan een Java-service, en het vergelijken van de grootte van de JVM Heap Elasticsearch en het toegewezen geheugen voor Loki is onjuist, maar toch is het vermeldenswaard dat Loki veel minder geheugen gebruikt. Het CPU-voordeel is niet zo voor de hand liggend, maar het is ook aanwezig.

snelheid

Loki “verslindt” logs sneller. De snelheid hangt van veel factoren af ​​- wat voor soort logs zijn, hoe geavanceerd we zijn in het parseren ervan, netwerk, schijf, enz. - maar is zeker hoger dan ELK (in mijn test - ongeveer twee keer zoveel). Dit wordt verklaard door het feit dat Loki veel minder gegevens in de index stopt en daardoor minder tijd aan indexering besteedt. Bij de zoeksnelheid is de situatie precies andersom: Loki vertraagt ​​merkbaar bij gegevens groter dan enkele gigabytes, terwijl de zoeksnelheid van ELK niet afhankelijk is van de grootte van de gegevens.

Zoeken op logboeken

Loki is aanzienlijk inferieur aan ELK wat betreft logzoekmogelijkheden. Grep met reguliere expressies is krachtig, maar inferieur aan een volwassen database. Het gebrek aan bereikzoekopdrachten, aggregatie alleen op basis van labels, het onvermogen om te zoeken zonder labels - dit alles beperkt ons bij het zoeken naar informatie die interessant is voor Loki. Dit betekent niet dat er niets kan worden gevonden met behulp van Loki, maar het definieert de stroom van het werken met logboeken wanneer u voor het eerst een probleem in de Prometheus-diagrammen aantreft, en vervolgens deze labels gebruikt om te zoeken naar wat er in de logboeken is gebeurd.

interface

Allereerst is het prachtig (sorry, ik kon het niet laten). Grafana heeft een mooie interface, maar Kibana is veel rijker aan functies.

Voor- en nadelen van Loki

Een van de voordelen is dat Loki integreert met Prometheus, zodat we kant-en-klare statistieken en waarschuwingen krijgen. Het is handig om logboeken te verzamelen en op te slaan vanuit Kubernetes Pods, omdat servicedetectie is overgenomen van Prometheus en er automatisch labels aan worden toegevoegd.

Het nadeel is zwakke documentatie. Sommige dingen, bijvoorbeeld de functies en mogelijkheden van Promtail, ontdekte ik pas tijdens het bestuderen van de code, gelukkig is deze open source. Een ander nadeel zijn de zwakke parseermogelijkheden. Loki kan bijvoorbeeld geen logboeken met meerdere regels parseren. Een ander nadeel is dat Loki een relatief jonge technologie is (release 1.0 was in november 2019).

Conclusie

Loki is een 100% interessante technologie die geschikt is voor kleine en middelgrote projecten, waardoor u veel problemen met logaggregatie, logzoeken, monitoring en loganalyse kunt oplossen.

We gebruiken Loki niet in Badoo omdat we een ELK-stack hebben die bij ons past en die door de jaren heen is overwoekerd met verschillende maatwerkoplossingen. Voor ons is het struikelblok het zoeken in logs. Met bijna 100 GB aan logs per dag is het voor ons belangrijk om alles en nog wat meer snel te kunnen vinden. Voor het in kaart brengen en monitoren maken wij gebruik van andere oplossingen die op onze wensen zijn afgestemd en met elkaar zijn geïntegreerd. De Loki-stack heeft tastbare voordelen, maar zal ons niet meer opleveren dan we al hebben, en de voordelen ervan zullen zeker niet opwegen tegen de kosten van migratie.

En hoewel na onderzoek duidelijk werd dat we Loki niet kunnen gebruiken, hopen we dat dit bericht je helpt bij je keuze.

De repository met de code die in het artikel wordt gebruikt, bevindt zich hier.

Bron: www.habr.com