SysteemarchitectuurDevOps engineer

Hoe organiseer je monitoring en logging in een gedistribueerde applicatie-architectuur?

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord.

Het organiseren van monitoring en logging in gedistribueerde IT-architecturen is essentieel voor het waarborgen van veerkracht, het identificeren en analyseren van fouten, en het evalueren van de prestaties van diensten. Het is belangrijk om gecentraliseerde logging en een systeem voor metrics voor alle diensten te implementeren, zodat een volledig overzicht van wat er in het systeem gebeurt, verkregen kan worden.

Algemene stappen:

  1. Gecentraliseerde logging — alle diensten schrijven logs naar een enkel systeem (bijvoorbeeld ELK-stack: Elasticsearch, Logstash, Kibana, of Grafana Loki).
  2. Verzoek tracing — het gebruik van systemen voor gedistribueerde tracing (bijvoorbeeld Jaeger, Zipkin) om de “route” van een verzoek tussen diensten te volgen.
  3. Monitoring en alerting — het gebruik van Prometheus, Grafana voor het verzamelen en visualiseren van metrics en het instellen van alerts.

Voorbeeld van logging configuratie in Python:

import logging from pythonjsonlogger import jsonlogger logger = logging.getLogger() logHandler = logging.StreamHandler() formatter = jsonlogger.JsonFormatter() logHandler.setFormatter(formatter) logger.addHandler(logHandler) logger.setLevel(logging.INFO) logger.info('Service gestart', extra={'service': 'orders', 'env': 'prod'})

Belangrijkste kenmerken:

  • Biedt een enkel transparant overzicht van de hele infrastructuur.
  • Verbetert het zoeken en analyseren van incidenten in meerdere omgevingen.
  • Maakt snelle reacties op degradaties of storingen van componenten mogelijk.

Vragen met een valstrik.

Moet je altijd alle acties van de dienst op INFO-niveau loggen?

Antwoord: Nee, omdat dit snel kan leiden tot een toename van het logvolume, de prestaties kan verlagen en het moeilijker maakt om echte fouten te zoeken. Het is beter om de semantiek van logniveaus aan te houden (DEBUG voor debugging, ERROR voor kritieke problemen, INFO voor belangrijke gebeurtenissen).


Is het mogelijk om metrics alleen op infrastructuurniveau (CPU, RAM) te verzamelen en applicatieniveau metrics te negeren?

Antwoord: Nee. Applicatieniveau metrics (bijvoorbeeld responstijd, aantal fouten) zijn cruciaal voor bedrijfsanalyse en operationele respons. Ze helpen om de “knelpunten” in de logica van de diensten te zien, en niet alleen in de “hardware”.


Is standaard HTTP-verzoekstracing met behulp van de webserver altijd voldoende in een gedistribueerd systeem?

Antwoord: Onjuist. Voor complexe scenario's die ketens van diensten bestrijken, is volledige gedistribueerde tracing met een unieke Trace-Id nodig om de route en de verwerkingstijd van een verzoek in alle fasen te zien.