Twee weken lang haperde steeds dezelfde webserver uit een pool van vier. De oorzaak: kernelmodules van een antivirusagent die alleen op die ene server actief waren. Hoe ik dat bewees, welk spoor vals bleek, en waarom een pakketinventaris je kan misleiden.

Eén van vier webservers bleef haperen: de antivirus in de kernel

Vier identieke webservers achter een load balancer. Twee weken lang gaf steeds dezelfde server af en toe fouten en trage antwoorden. Herstarten hielp even. Identieke servers die zich niet identiek gedragen, zijn niet identiek, dus de vraag was: wat is er anders?

Het verschil vinden

Na veel vergelijken bleek het verschil in de kernel te zitten. Op die ene server waren de realtime-scanmodules van de antivirusagent (ESET Server Security) geladen. Op de andere drie niet. Die modules haken in op bestandstoegang, ook op een NFS-mount die de applicatie intensief gebruikt.

Het bewijs kwam uit twee hoeken:

lsmod: de modules stonden alleen op die server.
Een teller voor stale NFS file handles: ~122 per uur vóór de ingreep, ~84 per uur na een verse remount met de antivirus nog actief, en ~10 per uur na het uitschakelen van de modules.

Een vals spoor

In dmesg stonden veel regels Output dropped. Dat leek het rokende pistool, maar het bleek een LOG-regel in de firewall (met een limiet van vijf per minuut) die op alle vier de servers stond. De haperende server had er zelfs de minste. Dat bewijsstuk heb ik ingetrokken. Een RCA wordt sterker door wat je eruit haalt, niet door wat je erin laat staan.

Nameten onder belasting

Na de ingreep een meting onder productiebelasting:

	Vóór	Na
Uitgaande verbindingen per request	1,20	0,99
SYN-retransmissies (zelfde tijdvenster)	126	59
Stale file handles	108.091 op een dag	0
p95-responstijd	hoogste van de vier	laagste van de vier

Meetvalkuil: de lege server

Bij de eerste nameting leek de herstelde server ineens zes keer zo traag. De oorzaak: de load balancer gebruikt least_conn met een korte slow start. Een server die net terug in de pool komt, heeft per definitie de minste verbindingen, en trekt dus acht minuten lang vrijwel al het verkeer. Zodra de verbindingen gelijkliepen, was het verschil weg. Lees de eerste tien minuten van zo'n vergelijking dus nooit als prestatieverschil, maar onthoud wel dat die warmloop bij dagvolume een echt risico is.

Wat de inventaris niet liet zien

Daarna inventariseerde ik alle webservers. Een paar verrassingen:

Het pakket heet niet zoals je denkt. dpkg -l | grep eset vond niets. Het pakket heet efs. Met de verkeerde zoekterm concludeer je "nooit geïnstalleerd".
De beheeragent staat helemaal niet in dpkg. Die is buiten pakketbeheer geïnstalleerd en dus onzichtbaar in elke pakketinventaris.
Handwerk per host. Op één server stond de agent nooit, op een andere stonden de modules nog op schijf. Ze werden zelfs bij elke start van de service opnieuw gecompileerd, zonder blacklist. Dat ze nu nergens geladen zijn, hangt dus af van configuratie, niet van iets dat het afdwingt.
Geen configuratiebeheer. De agent kwam in het configuratiebeheer niet voor, dus niets corrigeerde afwijkingen.

Wat ik meeneem

Identieke servers die zich verschillend gedragen: vergelijk de kernel, de modules en de mounts, niet alleen de applicatie.
Trek bewijs in dat niet klopt, en schrijf op waarom.
Meet na onder echte belasting, en ken de valkuilen van je load balancer.
Een pakketinventaris is geen software-inventaris. Controleer ook wat buiten pakketbeheer is geïnstalleerd.