Centrale PHP Logging Patterns
Iedereen kent het, er gaat iets mis in onze applicatie en we beginnen de vervelende taak van 'grep'ing door duizenden lijnen van logs om erachter te komen wat er aan de hand is. Als je een paar servers of containers hebt, wordt dit een bijna onmogelijke taak en de klassieke SSH en tail zullen je niet meer goed van dienst zijn. In dit gesprek sprak Philipp Krenn, ontwikkelaar bij Elastic, over enkele loggingpatronen met behulp van de Elastic Stack.
Wat is deze Elastic Stack? De Elastic Stack bestaat voornamelijk uit vier diensten. Uiteraard Elastic Search, die zal dienen als een database voor al onze logs. Kibana zal de presentatielaag verzorgen, hier kunnen we een nette weergave van onze logs maken en wat meer gebruikersvriendelijke interfaces creëren. Beats zal onze logs doorsturen naar onze database. Tot slot wordt de logstash gebruikt om de gegevens die we naar onze Elastic Search willen sturen, te ontleden en te verrijken.
Krenn stelde vijf manieren voor om uw logs te centraliseren in uw Elastic Stack, bedrijven moeten die kiezen die het beste bij hun behoeften passen. Ik zal ze kort doornemen, maar zorg ervoor dat je de code voorbeelden op zijn github bekijkt.
- Parsing: Door gebruik te maken van de grok debugger in Kibana, kan je de relevante informatie uit een logfile ontleden tot iets leesbaars en filterbaars door gebruik te maken van reguliere uitdrukkingen. Na verloop van tijd zal je een goede voorbeeldgrootte van herbruikbare expressies hebben om snel de gegevens te krijgen die u nodig heeft voor meerdere projecten. Als alternatief biedt Elastic ook de data visualizer die mogelijke velden kan detecteren en uw werk gemakkelijker kan maken.
Nadelen: Regex is vervelend. Hoe zit het met multiline logs? Hoe zit het met verschillende logformaten? - Send: Natuurlijk ka je ook een appender, zoals GelfHandler of ElasticSearchHandler, gebruiken om events meteen naar Elastic te sturen zonder dat ze eerst in een logbestand moeten worden opgeslagen.
Nadelen: Dit is zeer strak gekoppeld. Je zal geen logs hebben tijdens storingen. - Structured: Je kan evenementen in een gestructureerd formaat als JSON schrijven en ze daarna centraliseren, daarvoor heb je zelfs geen logstash nodig om de bestanden te parsen. De Elastic community biedt het Elastic Common Schema aan om je te helpen JSON-bestanden te normaliseren. De ECS specificeert een gemeenschappelijke set van velden bij het opslaan van gebeurtenisgegevens in Elasticsearch.
Nadelen: Nogmaals, dit is zeer nauw gekoppeld. Serialisatie is erg traag en zal wat overhead geven. - Containerize: Enter Docker containers. Iedereen gebruikt Docker containers tegenwoordig, toch? Natuurlijk kun je alles in je Docker-logs loggen en dit naar Elastic sturen. Je kan je logs eenvoudig verrijken door metadata van Docker zelf toe te voegen. Dit is waarschijnlijk de manier waarop de meeste bedrijven dit doen. Via de Docker-aansluiting kan je alle logbestanden van lopende containers verzamelen en verwerken.
Nadelen: Een beetje ingewikkelder om op te zetten en goed te krijgen. - Orchestrate: Kubernetes is de volgende stap in het runnen van niet georchestreerde Docker containers. Door het opzetten van een daemonset van Fluentd-containers kan deze automatisch alle logs van alle nodes verzamelen. Kubernetes zorgt ervoor dat bij het schalen van het aantal nodes in de cluster alle logging consistent blijft. Door de eenvoudige schaalbaarheid is Kubernetes de ideale keuze om je ELK Stack te hosten, omdat het zich eenvoudig kan aanpassen aan de variabele hoeveelheid logs die u wilt verwerken.
Nadelen: Instelling op expertniveau
Conclusie
Je hoeft niet alles uit te zoeken en je hele infrastructuur op z'n kop te zetten om een mooi log pattern te hebben. Kies de structuur die het beste werkt voor je organisatie en werk toe naar betere oplossingen wanneer die geschikt zijn. Dit gesprek gaf een aantal mooie voorbeelden en hopelijk wat inspiratie om een professionele logging infrastructuur in je bedrijf te hebben.
