Monitoring voordat je opschaalt

Opschalen is spannend. Meer servers, meer regio’s, meer bewegende onderdelen, het voelt allemaal als vooruitgang. Maar opschalen draait vooral om reageren op wat je systeem werkelijk doet. En als je niet kunt zien wat je systeem doet, ben je niet aan het opschalen. Dan ben je aan het gokken met grotere getallen.

Je kunt niet opschalen wat je niet ziet. Voordat je ook maar een laag complexiteit toevoegt, wil je drie vragen kunnen beantwoorden: draait het, is het kapot, en wordt het trager. Dat is monitoring, en voor een vroege startup hoeft het niet duur of uitgebreid te zijn.

Dit artikel kijkt naar de minimaal bruikbare monitoring voor een vroeg product, waarom complexiteit zonder zicht gevaarlijker is dan een simpele stack zonder, en hoe je voorkomt dat je verzuipt in meldingen die niets betekenen.

Complexiteit zonder zicht is het echte risico

Een simpele stack die je niet kunt zien is te overleven. Als er iets stuk gaat, is er één server, één log, één plek om te kijken. Je vindt het wel.

Een complexe stack die je niet kunt zien is een valkuil. Zodra je opsplitst in meerdere services, queues en managed onderdelen, is een probleem niet meer “de server ligt eruit” maar “iets tussen vijf componenten is traag en ik weet niet welke”. Zonder monitoring wordt elk incident archeologie.

Daarom zet ik mijn hakken in het zand als founders infrastructuur willen toevoegen voordat er enige observability is. Extra complexiteit vermenigvuldigt het aantal plekken waar een storing zich kan verstoppen. Monitoring houdt dat aantal kenbaar. Eerst de complexiteit toevoegen is een doolhof bouwen en dan het licht uitdoen.

De minimaal bruikbare monitoring

Je hebt geen observability-platform met een budget van zes cijfers nodig. Voor een vroege startup dekken vijf dingen bijna alles wat ertoe doet.

Uptime-checks. Een simpele externe dienst die je site elke minuut pingt en je waarschuwt zodra hij niet meer reageert. Dit is het waardevolste dat je kunt instellen, en het kost tien minuten. Als je product eruit ligt, wil je het weten voordat je klanten het je vertellen.

Error tracking. Een tool die fouten uit je applicatie opvangt en groepeert, zodat je ziet wat er werkelijk stukgaat in productie en hoe vaak. Dit maakt van “een klant zei dat er iets misging” een stack trace met een aantal ernaast.

Basismetrieken. Responstijden, aantal requests, CPU en geheugen op je server. Je hebt geen mooie dashboards nodig. Je hebt genoeg nodig om “dingen werden vorige dinsdag twee keer zo traag” op te merken voordat het “alles staat in brand” wordt.

Alerting op de paar dingen die ertoe doen. Een manier om een bericht te krijgen als er echt iets je aandacht nodig heeft. Let op het woord paar.

Toegang tot logs. Het vermogen om je logs daadwerkelijk te lezen wanneer je ze nodig hebt, het liefst op één plek in plaats van om 2 uur ‘s nachts een server inloggen. Als een error tracker zegt dat er iets stuk is, vertellen logs je waarom.

Dat is de hele lijst. Vijf mogelijkheden, de meeste gratis of bijna gratis bij vroege volumes.

Begin met goedkope, managed tools

Bouw je monitoringstack niet zelf. Dat is een eigen infrastructuurproject, met eigen onderhoud en een eigen vermogen om kapot te gaan op het slechtste moment.

Managed diensten dekken alle vijf de mogelijkheden goedkoop. Uptime-checks van een simpele externe monitor. Error tracking van een tool met een ruime gratis laag die vroege volumes opvangt zonder rekening. Metrieken en logs van wat je hostingprovider al biedt, of een managed logdienst. Alerts naar een mail of een chatkanaal dat je echt leest.

Het doel is je aandacht aan je product besteden, niet aan het draaiende houden van het ding dat je product bewaakt. Dezelfde logica geldt voor waar je alles überhaupt draait, en die keuze maak je het best bewust. Het welke hosting heb ik nodig framework loopt die keuze door zonder te overbouwen.

Alertmoeheid en waar je niet op moet alerten

De snelste manier om monitoring nutteloos te maken is alerten op te veel. Als alles je pingt, doet niets dat. Binnen een week zet je meldingen op stil, en de ene alert die ertoe deed ligt begraven onder veertig die dat niet deden.

Wees dus bewust over wat je wakker maakt. Alert op dingen die echt, urgent en uitvoerbaar zijn:

• De site ligt eruit of is van buitenaf onbereikbaar.
• De foutratio schiet ver boven normaal uit.
• Een kernactie (aanmelden, afrekenen, inloggen) faalt.
• Een resource raakt bijna op (schijf vol, certificaat verloopt).

En weersta alerten op de rest:

• Een enkele tijdelijke fout die zichzelf oploste.
• CPU die kort 80 procent raakt.
• Elke individuele fout, in plaats van een betekenisvolle ratio.
• Alles waar je op het moment van de melding toch niets mee zou doen.

Als een alert niet verandert wat je het komende uur doet, is het geen alert. Het is een metriek die je kunt bekijken wanneer je dat kiest. Houd die twee gescheiden en je alerts blijven betrouwbaar.

Een simpele beslisregel

Voor founders die monitoring afwegen tegen de volgende stap in opschalen houdt deze regel goed stand:

Zet de vijf basics op voordat je ook maar één stuk infrastructuurcomplexiteit toevoegt. Als je niet kunt zien wat je huidige stack doet, heb je niets te zoeken in het groter maken ervan.

Monitoring is goedkoop, snel, en het betaalt zichzelf terug de eerste keer dat het een probleem vangt voordat een klant dat doet. Opschalen bovenop blindheid is duur, traag, en presenteert de rekening om 2 uur ‘s nachts. Begin met het licht aandoen.

---

Loop je hier tegenaan?

Vertel me waar je mee zit, per mail of in een gratis gesprek. Samen bepalen we de slimste volgende stap.

Vertel me over je situatie → · Mail direct: hello@yourstartup.expert