Hvordan er metrikaggregering anderledes end logaggregering? Kan logs ikke indeholde metrikker? Kan log-aggregationssystemer ikke gøre de samme ting som metrik-aggregationssystemer?

Dette er spørgsmål, jeg ofte hører. Jeg har også set leverandører, der har lanceret deres logaggregationssystem som løsningen på alle observabilitetsproblemer. Logaggregation er et værdifuldt værktøj, men det er normalt ikke et godt værktøj til tidsseriedata.

Et par værdifulde funktioner i et system til aggregering af tidsseriemetrikker er det regelmæssige interval og lagringssystemet, der er tilpasset specifikt til tidsseriedata. Det regelmæssige interval gør det muligt for en bruger at udlede reelle matematiske resultater på en konsekvent måde. Hvis et logaggregationssystem indsamler metrikker i et regelmæssigt interval, kan det potentielt fungere på samme måde. Lagringssystemet er imidlertid ikke optimeret til de typer forespørgsler, der typisk er i et system til aggregering af metrikker. Disse forespørgsler vil tage flere ressourcer og mere tid at behandle ved hjælp af de lagringssystemer, der findes i logaggregationsværktøjer.

Så vi ved, at et logaggregationssystem sandsynligvis ikke er egnet til tidsseriedata, men hvad er det så godt til? Et logaggregationssystem er et godt sted til indsamling af hændelsesdata. Det er uregelmæssige aktiviteter, der er betydningsfulde. Et eksempel kunne være adgangslogfiler for en webtjeneste. Disse er vigtige, fordi vi ønsker at vide, hvad der har adgang til vores systemer og hvornår. Et andet eksempel kunne være en programfejltilstand – fordi det ikke er en normal driftstilstand, kan det være værdifuldt i forbindelse med fejlfinding.

En håndfuld regler for logning:

• DO inkludere et tidsstempel
• DO formatere i JSON
• Log ikke ubetydelige hændelser
• DO logge alle programfejl
• MÅSKE logge advarsler
• DO slå logning til
• DO skrive meddelelser i en menneskelig-læsbar form
• Log ikke informationsdata i produktion
• Log ikke noget, som et menneske ikke kan læse eller reagere på

Cloud-omkostninger

Når du undersøger logaggregeringsværktøjer, kan skyen virke som en attraktiv mulighed. Det kan dog være forbundet med betydelige omkostninger. Logfiler repræsenterer en masse data, når de aggregeres på tværs af hundredvis eller tusindvis af værter og programmer. Indlæsning, lagring og hentning af disse data er dyre i cloud-baserede systemer.

Som et referencepunkt fra et reelt system resulterer en samling på omkring 500 knudepunkter med et par hundrede apps i 200 GB logdata om dagen. Der er sikkert plads til forbedringer i det system, men selv en halvering af det vil koste næsten 10.000 dollars om måneden i mange SaaS-tilbud. Dette omfatter ofte en opbevaring på kun 30 dage, hvilket ikke er særlig længe, hvis man ønsker at se på trending data år for år.

Dette er ikke for at fraråde brugen af disse systemer, da de kan være meget værdifulde – især for mindre organisationer. Formålet er at påpege, at der kan være betydelige omkostninger, og det kan være afskrækkende, når de bliver realiseret. Resten af denne artikel vil fokusere på open source- og kommercielle løsninger, der er selvhostede.

Værktøjsmuligheder

ELK

ELK, forkortelse for Elasticsearch, Logstash og Kibana, er det mest populære open source-værktøj til logaggregering på markedet. Det bruges af Netflix, Facebook, Microsoft, Microsoft, LinkedIn og Cisco. De tre komponenter er alle udviklet og vedligeholdt af Elastic. Elasticsearch er i bund og grund en NoSQL, Lucene-søgemaskineimplementering. Logstash er et log-pipelinesystem, der kan indtage data, transformere dem og indlæse dem i et lager som Elasticsearch. Kibana er et visualiseringslag på toppen af Elasticsearch.

For et par år siden blev Beats introduceret. Beats er dataindsamlere. De forenkler processen med at sende data til Logstash. I stedet for at skulle forstå den korrekte syntaks for hver type log, kan en bruger installere en Beat, der eksporterer NGINX-logs eller Envoy-proxy-logs korrekt, så de kan bruges effektivt i Elasticsearch.

Når man installerer en ELK-stack på produktionsniveau, kan der være et par andre dele inkluderet, som Kafka, Redis og NGINX. Det er også almindeligt at erstatte Logstash med Fluentd, som vi vil diskutere senere. Dette system kan være komplekst at betjene, hvilket i dets tidlige dage førte til en masse problemer og klager. Disse er stort set blevet rettet, men det er stadig et komplekst system, så du vil måske ikke prøve det, hvis du er en mindre virksomhed.

Det sagt, er der tjenester til rådighed, så du behøver ikke at bekymre dig om det. Logz.io vil køre det for dig, men deres listepris er en smule stejl, hvis du har mange data. Selvfølgelig er du sandsynligvis mindre og har måske ikke en masse data. Hvis du ikke har råd til Logz.io, kan du kigge på noget som AWS Elasticsearch Service (ES). ES er en tjeneste, som Amazon Web Services (AWS) tilbyder, og som gør det meget nemt at få Elasticsearch til at fungere hurtigt. Den har også værktøj til at få alle AWS-logs ind i ES ved hjælp af Lambda og S3. Dette er en meget billigere løsning, men der kræves en vis administration, og der er nogle få begrænsninger.

Elastic, moderselskabet bag stakken, tilbyder et mere robust produkt, der bruger den åbne kernemodel, som giver yderligere muligheder omkring analyseværktøjer og rapportering. Det kan også hostes på Google Cloud Platform eller AWS. Dette er måske den bedste løsning, da denne kombination af værktøjer og hostingplatforme giver en billigere løsning end de fleste SaaS-muligheder og stadig giver en masse værdi. Dette system kan effektivt erstatte eller give dig muligheden for et SIEM-system (Security Information and Event Management).

ELK-stakken tilbyder også gode visualiseringsværktøjer via Kibana, men den mangler en alarmfunktion. Elastic tilbyder alarmfunktionalitet i det betalte X-Pack add-on, men der er intet indbygget i open source-systemet. Yelp har skabt en løsning på dette problem, kaldet ElastAlert, og der er sikkert andre. Dette ekstra stykke software er ret robust, men det øger kompleksiteten af et i forvejen komplekst system.

Graylog

Graylog er for nylig steget i popularitet, men det fik sin start, da Lennart Koopmann skabte det tilbage i 2010. Et firma blev født med samme navn to år senere. På trods af den stigende brug halter den stadig langt bagefter ELK-stakken. Det betyder også, at den har færre fællesskabsudviklede funktioner, men den kan bruge de samme Beats, som ELK-stakken bruger. Graylog har fået ros i Go-fællesskabet med introduktionen af Graylog Collector Sidecar skrevet i Go.

Graylog bruger Elasticsearch, MongoDB og Graylog Server under motorhjelmen. Det gør den lige så kompleks at køre som ELK-stakken og måske lidt mere. Graylog kommer dog med alerting indbygget i open source-versionen, samt flere andre bemærkelsesværdige funktioner som streaming, message rewriting og geolokalisering.

Streaming-funktionen gør det muligt at videresende data til specifikke Streams i realtid, mens de behandles. Med denne funktion kan en bruger se alle databasefejl i en enkelt Stream og webserverfejl i en anden Stream. Advarsler kan endda baseres på disse Streams, når der tilføjes nye elementer, eller når en tærskelværdi overskrides. Latency er nok et af de største problemer med logaggregationssystemer, og Streams eliminerer dette problem i Graylog. Så snart loggen kommer ind, kan den videresendes til andre systemer gennem en Stream uden at blive behandlet fuldt ud.

Mediefunktionerne til omskrivning af meddelelser bruger open source-regelsystemet Drools. Dette gør det muligt at evaluere alle indkommende meddelelser i forhold til en brugerdefineret regelfil, der gør det muligt at droppe en meddelelse (kaldet Blacklisting), at tilføje eller fjerne et felt eller at ændre meddelelsen.

Den fedeste funktion er måske Graylogs geolokaliseringsfunktion, som understøtter plottning af IP-adresser på et kort. Dette er en ret almindelig funktion, og den er også tilgængelig i Kibana, men den tilføjer en masse værdi – især hvis du ønsker at bruge dette som dit SIEM-system. Geolokaliseringsfunktionaliteten findes i open source-versionen af systemet.

Graylog, virksomheden, opkræver gebyr for support på open source-versionen, hvis du ønsker det. Det tilbyder også en åben kernemodel for sin Enterprise-version, der tilbyder arkivering, auditlogning og yderligere support. Der er ikke mange andre muligheder for support eller hosting, så du vil sandsynligvis være på egen hånd, hvis du ikke bruger Graylog (virksomheden).

Fluentd

Fluentd blev udviklet hos Treasure Data, og CNCF har vedtaget det som et Incubating-projekt. Det blev skrevet i C og Ruby og anbefales af AWS og Google Cloud. Fluentd er blevet en almindelig erstatning for Logstash i mange installationer. Den fungerer som en lokal aggregator til at indsamle alle node-logs og sende dem afsted til centrale lagringssystemer. Det er ikke et logaggregationssystem.

Det bruger et robust plugin-system til at give hurtige og nemme integrationer med forskellige datakilder og dataudgange. Da der er over 500 plugins til rådighed, burde de fleste af dine anvendelsestilfælde være dækket. Hvis de ikke er det, lyder dette som en mulighed for at bidrage tilbage til open source-fællesskabet.

Fluentd er et almindeligt valg i Kubernetes-miljøer på grund af dets lave hukommelseskrav (kun tiendedele af megabyte) og dets høje gennemløb. I et miljø som Kubernetes, hvor hver pod har en Fluentd-sidecar, vil hukommelsesforbruget stige lineært med hver ny pod, der oprettes. Brug af Fluentd vil drastisk reducere din systemudnyttelse. Dette er ved at blive et almindeligt problem med værktøjer udviklet i Java, der er beregnet til at køre én pr. node, hvor hukommelsesoverheadet ikke har været et stort problem.