Hur skiljer sig aggregering av mätvärden från loggaggregering? Kan loggar inte innehålla mätvärden? Kan inte loggaggregationssystem göra samma saker som metriksaggregationssystem?

Detta är frågor som jag ofta får höra. Jag har också sett försäljare som presenterar sitt loggaggregationssystem som lösningen på alla observerbarhetsproblem. Loggaggregation är ett värdefullt verktyg, men det är normalt sett inte ett bra verktyg för tidsseriedata.

Ett par värdefulla funktioner i ett system för aggregering av tidsseriemått är det regelbundna intervallet och lagringssystemet som är anpassat specifikt för tidsseriedata. Det regelbundna intervallet gör det möjligt för en användare att konsekvent härleda verkliga matematiska resultat. Om ett loggaggregationssystem samlar in mätvärden i ett regelbundet intervall kan det potentiellt fungera på samma sätt. Lagringssystemet är dock inte optimerat för de typer av förfrågningar som är typiska för ett system för aggregering av mätvärden. Dessa frågor kommer att ta mer resurser och tid att bearbeta med hjälp av lagringssystem som finns i loggaggregationsverktyg.

Så, vi vet att ett loggaggregationssystem troligen inte är lämpligt för tidsseriedata, men vad är det bra för? Ett loggaggregationssystem är en utmärkt plats för att samla in händelsedata. Detta är oregelbundna aktiviteter som är betydande. Ett exempel kan vara åtkomstloggar för en webbtjänst. Dessa är betydelsefulla eftersom vi vill veta vad som får tillgång till våra system och när. Ett annat exempel är ett programfeltillstånd – eftersom det inte är ett normalt drifttillstånd kan det vara värdefullt vid felsökning.

En handfull regler för loggning:

• DO inkludera en tidsstämpel
• DO formatera i JSON
• DON’T logga obetydliga händelser
• DO logga alla programfel
• MAYBE logga varningar
• DO aktivera loggning
• DO skriva meddelanden på ett mänskligt-läsbar form
• Logga inte informationsdata i produktionen
• Logga inte något som en människa inte kan läsa eller reagera på

Molnkostnader

När du undersöker loggaggregationsverktyg, kan molnet verka som ett attraktivt alternativ. Det kan dock vara förenat med betydande kostnader. Loggar utgör en stor mängd data när de aggregeras över hundratals eller tusentals värdar och program. Inmatning, lagring och hämtning av dessa data är dyrt i molnbaserade system.

Som referenspunkt från ett verkligt system resulterar en samling av cirka 500 noder med några hundra appar i 200 GB loggdata per dag. Det finns förmodligen utrymme för förbättringar i det systemet, men även en halvering kostar nästan 10 000 dollar per månad i många SaaS-erbjudanden. Detta inkluderar ofta lagring i endast 30 dagar, vilket inte är särskilt länge om man vill titta på trenddata år över år.

Detta är inte för att avråda från användningen av dessa system, eftersom de kan vara mycket värdefulla – särskilt för mindre organisationer. Syftet är att påpeka att det kan uppstå betydande kostnader, och det kan vara nedslående när de förverkligas. Resten av den här artikeln kommer att fokusera på lösningar med öppen källkod och kommersiella lösningar som är självhostade.

Verktygsalternativ

ELK

ELK, som är en förkortning av Elasticsearch, Logstash och Kibana, är det populäraste loggaggregationsverktyget med öppen källkod på marknaden. Det används av Netflix, Facebook, Microsoft, LinkedIn och Cisco. De tre komponenterna utvecklas och underhålls alla av Elastic. Elasticsearch är i huvudsak en NoSQL, Lucene-sökmotorimplementation. Logstash är ett loggpipelinesystem som kan ta emot data, omvandla dem och ladda in dem i ett lager som Elasticsearch. Kibana är ett visualiseringslager ovanpå Elasticsearch.

För några år sedan introducerades Beats. Beats är datainsamlare. De förenklar processen att skicka data till Logstash. Istället för att behöva förstå den korrekta syntaxen för varje typ av logg kan en användare installera en Beat som exporterar NGINX-loggar eller Envoy-proxyloggar på rätt sätt så att de kan användas effektivt i Elasticsearch.

När man installerar en ELK-stack på produktionsnivå kan det hända att några andra delar inkluderas, som Kafka, Redis och NGINX. Dessutom är det vanligt att ersätta Logstash med Fluentd, vilket vi kommer att diskutera senare. Detta system kan vara komplext att använda, vilket i början ledde till många problem och klagomål. Dessa har till stor del åtgärdats, men det är fortfarande ett komplext system, så du kanske inte vill prova det om du är en mindre verksamhet.

Detta sagt finns det tjänster tillgängliga så att du inte behöver oroa dig för det. Logz.io kommer att köra det åt dig, men dess listpris är lite dyrt om du har mycket data. Naturligtvis är du förmodligen mindre och kanske inte har så mycket data. Om du inte har råd med Logz.io kan du titta på något som AWS Elasticsearch Service (ES). ES är en tjänst som Amazon Web Services (AWS) erbjuder och som gör det mycket enkelt att snabbt få Elasticsearch att fungera. Det finns också verktyg för att få in alla AWS-loggar i ES med hjälp av Lambda och S3. Detta är ett mycket billigare alternativ, men det krävs viss hantering och det finns några begränsningar.

Elastic, moderbolaget till stacken, erbjuder en mer robust produkt som använder den öppna kärnmodellen, vilket ger ytterligare alternativ kring analysverktyg och rapportering. Den kan också vara värd på Google Cloud Platform eller AWS. Detta kan vara det bästa alternativet, eftersom denna kombination av verktyg och värdplattformar erbjuder en billigare lösning än de flesta SaaS-alternativ och ändå ger mycket värde. Det här systemet kan effektivt ersätta eller ge dig kapaciteten hos ett SIEM-system (Security Information and Event Management).

Elk-stacken erbjuder också bra visualiseringsverktyg genom Kibana, men den saknar en varningsfunktion. Elastic tillhandahåller varningsfunktionalitet i det betalda tillägget X-Pack, men det finns inget inbyggt i systemet med öppen källkod. Yelp har skapat en lösning på det här problemet, kallad ElastAlert, och det finns förmodligen andra. Denna extra programvara är ganska robust, men den ökar komplexiteten i ett redan komplext system.

Graylog

Graylog har nyligen ökat i popularitet, men det fick sin början när Lennart Koopmann skapade det redan 2010. Ett företag med samma namn föddes två år senare. Trots den ökande användningen ligger den fortfarande långt efter ELK-stacken. Detta innebär också att den har färre gemenskapsutvecklade funktioner, men den kan använda samma Beats som ELK-stacken använder. Graylog har fått beröm i Go-communityn i och med introduktionen av Graylog Collector Sidecar skriven i Go.

Graylog använder Elasticsearch, MongoDB och Graylog Server under huven. Detta gör den lika komplex att köra som ELK-stacken och kanske lite mer. Graylog kommer dock med alerting inbyggd i open source-versionen, samt flera andra anmärkningsvärda funktioner som streaming, omskrivning av meddelanden och geolokalisering.

Strömningsfunktionen gör att data kan dirigeras till specifika strömmar i realtid medan de behandlas. Med den här funktionen kan en användare se alla databasfel i en enda Stream och webbserverfel i en annan Stream. Varningar kan även baseras på dessa strömmar när nya objekt läggs till eller när ett tröskelvärde överskrids. Latency är förmodligen ett av de största problemen med loggaggregationssystem, och Streams eliminerar detta problem i Graylog. Så snart loggen kommer in kan den dirigeras till andra system genom en Stream utan att behandlas fullt ut.

Funktionen för omskrivning av meddelanden använder sig av den öppna källkodsmotorn Drools. Detta gör det möjligt att utvärdera alla inkommande meddelanden mot en användardefinierad regelfil som gör det möjligt att ta bort ett meddelande (så kallad Blacklisting), lägga till eller ta bort ett fält eller ändra meddelandet.

Den coolaste funktionen kan vara Graylogs geolokaliseringsfunktion, som har stöd för att plotta IP-adresser på en karta. Detta är en ganska vanlig funktion och finns även i Kibana, men den tillför mycket värde – särskilt om du vill använda detta som ditt SIEM-system. Geolokaliseringsfunktionaliteten finns i den öppna källkodsversionen av systemet.

Företaget Graylog tar betalt för support på den öppna källkodsversionen om du vill ha det. Det erbjuder också en öppen kärnmodell för sin Enterprise-version som erbjuder arkivering, granskningsloggning och ytterligare stöd. Det finns inte många andra alternativ för support eller hosting, så du får troligen klara dig själv om du inte använder Graylog (företaget).

Fluentd

Fluentd utvecklades på Treasure Data, och CNCF har antagit det som ett inkubationsprojekt. Det skrevs i C och Ruby och rekommenderas av AWS och Google Cloud. Fluentd har blivit en vanlig ersättning för Logstash i många installationer. Den fungerar som en lokal aggregator för att samla in alla nodloggar och skicka dem till centrala lagringssystem. Det är inte ett loggaggregationssystem.

Det använder ett robust plugin-system för att ge snabba och enkla integrationer med olika datakällor och datautgångar. Eftersom det finns över 500 plugins tillgängliga bör de flesta av dina användningsfall vara täckta. Om de inte är det, låter detta som en möjlighet att bidra tillbaka till open source-communityt.

Fluentd är ett vanligt val i Kubernetes-miljöer på grund av dess låga minneskrav (bara tiotals megabyte) och dess höga genomströmning. I en miljö som Kubernetes, där varje pod har en Fluentd-sidecar, kommer minnesförbrukningen att öka linjärt med varje ny pod som skapas. Om du använder Fluentd kommer ditt systemutnyttjande att minska drastiskt. Detta börjar bli ett vanligt problem med verktyg utvecklade i Java som är avsedda att köras en per nod där minnesöverskottet inte har varit ett stort problem.