Sinds mijn blog over het zelf hosten van server-side Google Tag Manager (sGTM) is er een hoop veranderd in mijn setup. De afgelopen tijd heb ik enkele essentiële aanpassingen doorgevoerd die de 'self-hosted' setup een stuk robuuster maken. Met verbeterde logging en enkele slimme aanpassingen, is sGTM nu echt 'bulletproof'. Ik neem je mee in de (meest essentiële) aanpassingen!
Afbeelding van een (futuristische) server, gemaakt met Midjourney
Dit blog bouwt voort op de kennis van ‘Host server-side GTM voor een paar euro per maand’. Ik sta daarom niet zo nadrukkelijk stil bij de Docker commands, maar wel bij de configuratie van de Caddy proxy en Docker.Mijn sGTM-setup is met name wat robuuster geworden, doordat ik logging heb toegevoegd. Een ander punt waarmee ik worstelde was het weergeven van het remote IP-adres van de cliënt. Dit is een specifiek Caddy + Docker Swarm probleem. Het remote IP-adres heb je nodig om bijvoorbeeld een geolocatie vast te stellen.Een korte leeswijzer:
Client-side IP-adres doorgeven aan sGTM
Integreren van logging met Datadog
Het eindresultaat
Indruk van het Datadog portaal, het eindresultaat van deze 'how-to'
Remote IP-adres (van de client) doorgeven aan sGTM
Bij het implementeren van een server-side oplossing zoals sGTM is het essentieel dat het remote IP-adres van je bezoeker (de cliënt) correct wordt doorgegeven. Dit is van cruciaal belang voor functionaliteiten als:
geolocatie
gepersonaliseerde content
beveiligingstoepassingen
Het gebruik van Docker in combinatie met een proxy zoals Caddy kan een probleem opleveren. De standaardinstellingen kunnen ervoor zorgen dat het lokale IP-adres van de proxy (bijvoorbeeld 10.0.0.1) zelf wordt doorgegeven in plaats van dat van de daadwerkelijke cliënt. Het is noodzakelijk om gebruik te maken van de configuratie ‘mode: host’ binnen de poortconfiguraties. Door deze modus te gebruiken, kan de Caddy-proxy direct toegang krijgen tot het netwerk van de host, waardoor het in staat is om de werkelijke client IP-adressen vast te leggen en correct door te geven aan de services die achter de proxy draaien.Dit ziet er dan als volgt uit voor wat betreft de configuratie in je yaml-bestand:
In een moderne tech-stack is het monitoren van je applicaties en services geen luxe, maar een noodzaak. Datadog is een populair platform dat uitgebreide inzichten biedt in de prestaties, beschikbaarheid en gezondheid van je services. Het integreren van Datadog is vrij eenvoudig. Het spreekt bijna voor zich, maar je een Datadog accountEen account maak je aan op de website van Datadog door te klikken op 'get started for free'! Kies vervolgens voor hosting in Europa. nodig. Dit kost je om het uit te to proberen verder niks met een ‘free plan’.
(1) Configureren van Datadog als docker stack
Datadog draait binnen het Docker cluster als een apart stack. Het stack bestaat enkel uit één service: de Datadog agent. Deze agent fungeert als een tussenlaag tussen je Docker services in sGTM stack en het Datadog-platform. De agent verzamelt en verzendt metrieken, events en logs vanuit je containers. Het docker stack yml bestand ziet er als volgt uit:
version: '3.9'
services:
agent:
image: datadog/agent:latest
deploy:
replicas: 2 # amount is identical to the number of nodes in the cluster.
placement:
max_replicas_per_node: 1
restart_policy:
condition: on-failure
environment:
- DD_API_KEY=$DD_API_KEY
- DD_LOGS_ENABLED=true
- DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true
- DD_CONTAINER_EXCLUDE=image:datadog/agent:*
- DD_SITE=datadoghq.eu
volumes:
- '/var/run/docker.sock:/var/run/docker.sock:ro'
- '/proc/:/host/proc/:ro'
- datadog:/opt/datadog-agent/run:rw
- '/sys/fs/cgroup/:/host/sys/fs/cgroup:ro'
volumes:
datadog:
Enkele kernpunten in de configuratie:
Image: We gebruiken datadog/agent:latest om ervoor te zorgen dat we de nieuwste versie van de Datadog-agent hebben.
Environment variabelen:
DD_API_KEY: Je unieke Datadog API-sleutel, nodig voor authenticatie. De sleutel kan je hier aanmaken.
DD_LOGS_ENABLED en DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL: Deze zorgen ervoor dat logs van alle containers worden verzameld en naar Datadog worden verzonden.
DD_CONTAINER_EXCLUDE: Met deze variabele zorgen we ervoor dat logs van de Datadog-agent zelf worden uitgesloten, om ruis in je logs te voorkomen.
DD_SITE: Dit verwijst naar de specifieke Datadog-instantie waarmee je wilt integreren. In het geval van Europese opslag is datadoghq.eu de juiste waarde.
Volumes: Hier binden we een aantal cruciale paden van de host naar de agent-container:
/var/run/docker.sock: Geeft de agent toegang tot de Docker API, wat essentieel is voor het verzamelen van containermetrieken en logs.
/proc/ en /sys/fs/cgroup/: Deze geven inzicht in systeem- en processtatistieken van de host.
Met deze eenvoudige configuratie van Datadog integreer je naadloos logging en monitoring in je sGTM-setup. Dit biedt niet alleen zichtbaarheid in je server-side tag-beheer, maar verhoogt ook de algehele veerkracht en betrouwbaarheid van je systeem.
(2) Toevoegen van Datadog labels aan sGTM services
De sGTM services zijn niet automatisch zichtbaar voor de Datadog agent. De agent kan de service ontdekken middels specifieke labels in het docker-yml bestand. Deze labels spelen een sleutelrol in hoe Datadog informatie interpreteert en visualiseert:
com.datadoghq.ad.check_names: Dit label definieert de naam van de service zoals deze zal verschijnen in Datadog. Bijvoorbeeld, voor de tag-server-service is het ingesteld op '["tag-server"]'.
com.datadoghq.ad.init_configs: Dit label is meestal ingesteld op een lege array '[{}]', wat betekent dat er geen initiële configuratie is vereist voordat Datadog metrieken en logs begint te verzamelen.
com.datadoghq.ad.instances: Met dit label kunnen we de host en poort dynamisch instellen waar Datadog naar informatie moet zoeken. Door gebruik te maken van '%%host%%' en '%%port%%', vraagt het de actuele host en poort van de service op.
com.datadoghq.ad.logs: Hiermee geven we aan hoe de logs moeten worden ingedeeld in Datadog. De 'source' is de naam van de service, en 'service' helpt bij het groeperen van logs onder een gemeenschappelijke noemer, in dit geval 'sgtm'.
Om een beter idee te geven, het sGTM stack docker-compose.yml bestand ziet er met deze labels als volgt uit:
Met deze labels heb je op een eenvoudige manier zeer gedetailleerde monitoring en logging zonder de noodzaak van ingewikkelde configuraties. Dit zorgt niet alleen voor betere inzichten maar verhoogt ook de stabiliteit en betrouwbaarheid van onze sGTM-setup.
Eindresultaat: configureer je eigen server
Tot slot nog een kort stappenplan om deze setup te implementeren. Ik ga ervan uit dat je al een docker swam hebt draaien (lees anders mijn eerdere blog).
cd sgtm-manual-server
cp .env.template .env
vim .env
Vervang vervolgens de placeholders met de relevante waarden voor jouw setup. Herhaal deze stap voor de map data-docker-stack. Note: dat DNS mapping naar je server al goed moet staan (zie wederom mijn eerdere blog).
Samenvatting: Van ‘basic’ self-hosted sGTM-setup naar één met monitoring met Datadog
Het mag duidelijk zijn: een robuuste, server-side Google Tag Manager (sGTM) setup is essentieel voor het effectief beheren en optimaliseren van je online activiteiten.De integratie van Datadog brengt de voordelen van geavanceerde logging en monitoring eenvoudig binnen handbereik. Dit stelt je in staat om proactief problemen te identificeren, te reageren op prestatie-uitdagingen en continue verbeteringen door te voeren. De toevoeging van gedetailleerde logging biedt de zekerheid die je nodig hebt en zorgt ervoor dat je altijd op de hoogte bent van wat er in je sGTM omgeving gebeurt.Heb je vragen, opmerkingen of wil je je eigen ervaringen delen? Laat dan zeker een reactie achter of neem contact met me op. Dank voor het lezen en veel succes!
