Wat is het verschil tussen aggregatie van metriek en logaggregatie? Kunnen logboeken geen metriek bevatten? Kunnen systemen voor logboekaggregatie niet hetzelfde doen als systemen voor metriekaggregatie?

Dit zijn vragen die ik vaak hoor. Ik heb ook gezien dat verkopers hun log aggregatie systeem aanprijzen als de oplossing voor alle observeerbaarheidsproblemen. Log aggregatie is een waardevol hulpmiddel, maar het is normaal gesproken geen goed hulpmiddel voor tijdreeksgegevens.

Een paar waardevolle kenmerken in een tijdreeks metrics aggregation systeem zijn het reguliere interval en het opslagsysteem dat speciaal is aangepast voor tijdreeksgegevens. Het regelmatige interval stelt een gebruiker in staat om consistent echte wiskundige resultaten af te leiden. Als een log aggregatie systeem metrieken verzamelt in een regelmatig interval, kan het potentieel op dezelfde manier werken. Het opslagsysteem is echter niet geoptimaliseerd voor het soort query’s dat typisch is voor een metrics aggregation systeem. Deze queries zullen meer middelen en tijd vergen om te verwerken met behulp van opslagsystemen die te vinden zijn in logaggregatietools.

Dus, we weten dat een logaggregatiesysteem waarschijnlijk niet geschikt is voor tijdreeksgegevens, maar waar is het dan wel goed voor? Een log aggregatie systeem is een prima plek voor het verzamelen van event data. Dit zijn onregelmatige activiteiten die significant zijn. Een voorbeeld zouden de toegangslogs voor een webdienst kunnen zijn. Deze zijn belangrijk omdat we willen weten wat onze systemen bezoekt en wanneer. Een ander voorbeeld is een toepassingsfout – omdat dit geen normale bedrijfsomstandigheid is, kan dit waardevol zijn bij het oplossen van problemen.

Een handvol regels voor logboekregistratie:

• Zorg voor een tijdstempel
• Opmaak in JSON
• Geen onbelangrijke gebeurtenissen loggen
• Geef een log van alle toepassingsfouten
• Geef een log van waarschuwingen
• Geef log
• Geef berichten in een door mensen leesbare vorm
• Geef berichten in een door mensen leesbare vorm
• Geef een log van waarschuwingen
• Geef een log in
• leesbare vorm
• Geen informatieve gegevens in productie loggen
• Geen gegevens loggen die een mens niet kan lezen of waarop hij niet kan reageren

Cloud kosten

Bij het onderzoeken van log aggregatie tools, lijkt de cloud een aantrekkelijke optie. Er kunnen echter aanzienlijke kosten aan verbonden zijn. Logs vertegenwoordigen een hoop gegevens wanneer ze worden samengevoegd over honderden of duizenden hosts en toepassingen. De invoer, opslag en het ophalen van die gegevens zijn duur in cloud-gebaseerde systemen.

Als referentiepunt van een echt systeem, een verzameling van ongeveer 500 nodes met een paar honderd apps resulteert in 200 GB aan loggegevens per dag. Er is waarschijnlijk ruimte voor verbetering in dat systeem, maar zelfs het verminderen van het met de helft zal bijna $ 10.000 per maand kosten in veel SaaS-aanbiedingen. Dit omvat vaak een retentie van slechts 30 dagen, wat niet erg lang is als je wilt kijken naar trending data year-over-year.

Dit is niet om het gebruik van deze systemen te ontmoedigen, want ze kunnen zeer waardevol zijn-vooral voor kleinere organisaties. Het doel is erop te wijzen dat er aanzienlijke kosten kunnen zijn, en het kan ontmoedigend zijn wanneer deze worden gerealiseerd. De rest van dit artikel zal zich richten op open source en commerciële oplossingen die zelf gehost worden.

Tool opties

ELK

ELK, kort voor Elasticsearch, Logstash, en Kibana, is de meest populaire open source log aggregatie tool op de markt. Het wordt gebruikt door Netflix, Facebook, Microsoft, LinkedIn en Cisco. De drie componenten worden allemaal ontwikkeld en onderhouden door Elastic. Elasticsearch is in wezen een NoSQL, Lucene zoekmachine implementatie. Logstash is een log pipeline systeem dat gegevens kan opnemen, transformeren en laden in een store zoals Elasticsearch. Kibana is een visualisatielaag bovenop Elasticsearch.

Een paar jaar geleden werden de Beats geïntroduceerd. Beats zijn dataverzamelaars. Ze vereenvoudigen het proces van het verzenden van gegevens naar Logstash. In plaats van de juiste syntaxis van elk type log te moeten begrijpen, kan een gebruiker een Beat installeren die NGINX-logboeken of Envoy-proxy-logboeken op de juiste manier exporteert, zodat ze effectief kunnen worden gebruikt binnen Elasticsearch.

Bij het installeren van een ELK-stack op productieniveau, kunnen een paar andere onderdelen worden opgenomen, zoals Kafka, Redis en NGINX. Ook is het gebruikelijk om Logstash te vervangen door Fluentd, waar we het later over zullen hebben. Dit systeem kan complex zijn om te bedienen, wat in zijn begindagen tot veel problemen en klachten leidde. Deze zijn grotendeels verholpen, maar het is nog steeds een complex systeem, dus je wilt het misschien niet proberen als je een kleinere operatie bent.

Dat gezegd hebbende, er zijn diensten beschikbaar, zodat je je daar geen zorgen over hoeft te maken. Logz.io zal het voor u uitvoeren, maar de catalogusprijs is een beetje hoog als je veel gegevens hebt. Natuurlijk, je bent waarschijnlijk kleiner en hebt misschien niet veel gegevens. Als je je Logz.io niet kunt veroorloven, zou je kunnen kijken naar iets als AWS Elasticsearch Service (ES). ES is een dienst die Amazon Web Services (AWS) aanbiedt en die het heel gemakkelijk maakt om Elasticsearch snel aan de praat te krijgen. Het heeft ook tooling om alle AWS logs in ES te krijgen met behulp van Lambda en S3. Dit is een veel goedkopere optie, maar er is enig beheer vereist en er zijn een paar beperkingen.

Elastic, het moederbedrijf van de stack, biedt een robuuster product dat het open core-model gebruikt, dat extra opties biedt rond analysetools, en rapportage. Het kan ook worden gehost op Google Cloud Platform of AWS. Dit is misschien wel de beste optie, omdat deze combinatie van tools en hostingplatforms een goedkopere oplossing biedt dan de meeste SaaS-opties en toch veel waarde biedt. Dit systeem zou effectief de mogelijkheden van een SIEM-systeem (Security Information and Event Management) kunnen vervangen of geven.

De ELK-stack biedt ook geweldige visualisatietools via Kibana, maar het mist een alerting-functie. Elastic biedt waarschuwingsfunctionaliteit binnen de betaalde X-Pack add-on, maar er is niets ingebouwd voor het open source-systeem. Yelp heeft een oplossing voor dit probleem gemaakt, genaamd ElastAlert, en er zijn waarschijnlijk anderen. Dit extra stukje software is redelijk robuust, maar het verhoogt de complexiteit van een toch al complex systeem.

Graylog

Graylog is onlangs in populariteit gestegen, maar het kreeg zijn start toen Lennart Koopmann het in 2010 creëerde. Twee jaar later werd een bedrijf met dezelfde naam geboren. Ondanks het toenemende gebruik ervan, ligt het nog steeds ver achter op de ELK stack. Dit betekent ook dat het minder community-ontwikkelde features heeft, maar het kan dezelfde Beats gebruiken die de ELK stack gebruikt. Graylog heeft lof geoogst in de Go-gemeenschap met de introductie van de Graylog Collector Sidecar geschreven in Go.

Graylog gebruikt Elasticsearch, MongoDB, en de Graylog Server onder de motorkap. Dit maakt het net zo complex om te draaien als de ELK stack en misschien een beetje meer. Graylog wordt echter geleverd met waarschuwingen ingebouwd in de open source versie, evenals verschillende andere opmerkelijke functies zoals streaming, message rewriting, en geolocatie.

De streaming functie maakt het mogelijk om gegevens te routeren naar specifieke Streams in real time, terwijl ze worden verwerkt. Met deze functie kan een gebruiker alle database fouten in een enkele Stream zien en web server fouten in een andere Stream. Alerts kunnen zelfs worden gebaseerd op deze Streams wanneer nieuwe items worden toegevoegd of wanneer een drempel wordt overschreden. Latency is waarschijnlijk één van de grootste problemen met log aggregatie systemen, en Streams elimineren dat probleem in Graylog. Zodra het logboek binnenkomt, kan het via een Stream naar andere systemen worden gerouteerd zonder volledig te worden verwerkt.

De functie voor het herschrijven van berichten maakt gebruik van de open source rules engine Drools. Dit maakt het mogelijk om alle inkomende berichten te evalueren aan de hand van een door de gebruiker gedefinieerd bestand met regels, waardoor een bericht kan worden verwijderd (genaamd Blacklisting), een veld kan worden toegevoegd of verwijderd, of het bericht kan worden gewijzigd.

De coolste functie is misschien wel Graylog’s geolocatie mogelijkheid, die het plotten van IP-adressen op een kaart ondersteunt. Dit is een vrij gebruikelijke functie en is ook beschikbaar in Kibana, maar het voegt veel waarde toe – vooral als u dit wilt gebruiken als uw SIEM-systeem. De geolocatie-functionaliteit wordt geleverd in de open source-versie van het systeem.

Graylog, het bedrijf, rekent voor ondersteuning op de open source-versie als je dat wilt. Het biedt ook een open core-model voor zijn Enterprise-versie die archivering, auditlogging en extra ondersteuning biedt. Er zijn niet veel andere opties voor ondersteuning of hosting, dus je zult waarschijnlijk op jezelf aangewezen zijn als je Graylog (het bedrijf) niet gebruikt.

Fluentd

Fluentd is ontwikkeld bij Treasure Data, en de CNCF heeft het geadopteerd als een Incubating project. Het is geschreven in C en Ruby en wordt aanbevolen door AWS en Google Cloud. Fluentd is in veel installaties een veelgebruikte vervanging voor Logstash geworden. Het fungeert als een lokale aggregator om alle node logs te verzamelen en ze naar centrale opslagsystemen te sturen. Het is geen log aggregatie systeem.

Het maakt gebruik van een robuust plugin systeem om snelle en eenvoudige integraties met verschillende gegevensbronnen en gegevens outputs te bieden. Aangezien er meer dan 500 plugins beschikbaar zijn, zouden de meeste van uw gebruikssituaties gedekt moeten zijn. Als dat niet het geval is, klinkt dit als een kans om bij te dragen aan de open source-gemeenschap.

Fluentd is een veel voorkomende keuze in Kubernetes-omgevingen vanwege de lage geheugenvereisten (slechts tientallen megabytes) en de hoge verwerkingscapaciteit. In een omgeving als Kubernetes, waar elke pod een Fluentd sidecar heeft, zal het geheugengebruik lineair toenemen met elke nieuwe pod die wordt gemaakt. Het gebruik van Fluentd zal het gebruik van je systeem drastisch verminderen. Dit is een veelvoorkomend probleem aan het worden met tools ontwikkeld in Java die bedoeld zijn om één per node te draaien, waar de geheugenoverhead geen groot probleem is geweest.