Blog ·
Een grootboek dat telt vóór er een prijs is
Monitoring levert een getal op voor elke check, lang voordat er een prijs bestaat. Zo bouwden we eerst het tellen, en waarom die volgorde de veilige is.
Door Provibr
Er staat geen prijs op monitoring. Geen bedrag, geen munt, geen pakket, geen factuurregel. Wat er sinds deze ronde wél is, is een grootboek dat elke check vastlegt die het platform werkelijk verstuurd heeft, dat dertien maanden bewaart, en dat elk uur afsluit in een emmer die daarna nooit meer bewerkt wordt.
Het tellen bouwen vóór het rekenen lijkt de verkeerde volgorde tot je het één keer andersom gedaan hebt. Een meter die naast een factuur ontstaat erft elk gemak dat die factuur wil: een herhaalpoging die stilletjes meetelt omdat het totaal er anders raar uitzag, een correctie die als bewerking op de rij wordt uitgevoerd. Dat zijn beslissingen, en ze zijn eenvoudiger goed te nemen als er geen totaal van afhangt.
Het grootboek bestaat dus, er zit geen geld in, en één kolom erin is met opzet leeg.
Wat telt is wat werkelijk vertrok
Een geroosterde check doorloopt een klein aantal standen, en het grootboek stelt per stand één vraag: is er verkeer de deur uit gegaan. Dat staat als tabel over élke uitkomst en niet als een keuzeblok met een standaardtak, want een standaardtak is precies hoe een zevende uitkomst stil "telt niet" wordt en er een maand ontbreekt.
| Uitkomst | Rij geschreven | Telt mee | Waarom |
|---|---|---|---|
| gepland | nee | nee | het slot is gereserveerd, er is nog niets verstuurd |
| geclaimd | nee | nee | geclaimd maar niet verstuurd; de rij ontstaat bij het dispatchen |
| verstuurd | ja | ja | er is werkelijk een check de deur uit gegaan |
| afgerond | ja | ja | klaar; hij kreeg zijn rij al bij het verzenden |
| overgeslagen | nee | nee | nooit verstuurd: geen agent, geen gezonde probe, onderhoud of een voorbijgegaan slot |
| verlopen | nee | nee | de deadline verstreek zonder dat er iets vertrok |
Twee van die regels verdienen een eigen zin.
Een check die een dode machine bereikt telt gewoon mee. Er is verkeer geweest en er is gemeten; dat het antwoord "down" luidt is de uitkomst en niet de vraag. Een regel die alleen geslaagde checks telde, zou het minst rekenen bij de klanten voor wie we het hardst werken.
En de uitkomst verlopen is subtieler dan het lijkt, want een verzoek kan verlopen nádat het verstuurd is. Er wordt niet dubbel geteld, en niet bij toeval: een tick komt daar alleen via de veegronde die ticks raakt die de verzendstap nooit haalden, en wat wél vertrok telde al als verstuurd en heeft zijn rij dus al.
De bronklasse, onze eigen probe of de agent van de klant, staat in de rij en in de signatuur van de functie die beslist. Beide tellen vandaag hetzelfde, en juist daarom staat de klasse opgeschreven in plaats van aangenomen.
Eén tick, één rij
Failover is het geval dat een gebruiksgetal stil opblaast. Een check draait vanaf de ene bron, die bron is onbereikbaar, een andere neemt over, en nu zijn er twee pogingen voor één meting.
Hier is dat een unieke index op een sleutel van de vorm tick:<tick-id>. Herhaalpogingen en failovers binnen dezelfde tick leveren dezelfde sleutel op, dus de tweede invoeging botst en geeft niets terug. Beide schrijfwegen doen dat; geen van beide kijkt eerst, want tussen een leesopdracht en een invoeging past een tweede gateway.
De sleutel is een tekstkolom en niet de verwijzing naar de tick, en dat is het interessante deel. Ticks blijven zeven dagen bestaan, usage dertien maanden. Als de veegronde de tick weghaalt wordt die verwijzing leeg, en in Postgres is een lege waarde nooit gelijk aan een andere lege waarde, dus een unieke index op die kolom zou een week later stil duplicaten gaan toestaan.
Een handmatige test is óók verkeer
Er is een knop die nu meteen een check uitvoert. Hij telt niet mee, en hij wordt tóch vastgelegd.
Allebei die helften doen ertoe. Hij telt niet mee omdat een mens die op een knop drukt niet de geroosterde dienst is. Hij wordt vastgelegd omdat het nog steeds verkeer naar iemands machine is, en duizend keer drukken per uur is precies wat een gebruikssysteem moet kunnen laten zien. Een tweede tabel waar geen enkel overzicht naar kijkt zou juist het geval verbergen waarin het getal interessant is.
Wat de twee uit elkaar houdt is geen afspraak maar een controle in de database: een rij van de handmatige soort mag niet meetellen en mag geen tick dragen. "Handmatig én meetellend" kan niet bestaan, en dat is belangrijk omdat zo'n rij er in elk overzicht volkomen gewoon uitziet.
Een uur sluit laat, en verandert daarna nooit meer
Emmers gaan per organisatie, per uur, per bronklasse en per checktype. Een uur wordt pas afgesloten als er vijftien minuten van het volgende uur voorbij zijn.
De voor de hand liggende reden, een laat meetresultaat, is niet de echte; resultaten raken het totaal niet. Wat wél laat kan zijn is de rij zelf: een transactie die om 10:59:59 commit wordt om 11:00:00 zichtbaar, meerdere gateways lezen elk hun eigen klok, en eentje die even weg was loopt achteraf zijn achterstand in. Vijftien minuten is een orde ruimer dan alles wat één check mag duren, waar de maximale timeout 120 seconden is en de lease 45.
Zodra een uur dicht is wordt het niet bewerkt. Een late gebeurtenis levert een nieuwe rij op die naar de basisrij wijst met een machineleesbare reden, nooit een bijwerking. Dat wordt door de vorm afgedwongen en niet door discipline: de unieke index over organisatie, uur, bronklasse en checktype is partieel en geldt alleen voor rijen die geen correctie zijn, zodat een tweede correctie op hetzelfde uur niet met de eerste botst en wegvalt. Zouden correcties diezelfde index delen, dan is juist het bewijs dat je bij een geschil wilt hebben wat er verdwijnt. De reden zelf is één woord en geen vrije zin, want het paneel vertaalt hem in negen talen en een export groepeert erop.
Grenzen die geen prijslijst zijn
Elke organisatie heeft een toegestane ruimte, en elk getal daarin is gekozen om een ongeluk tegen te houden, niet om een pakket te beschrijven.
Hoogstens 200 regels, met opzet hetzelfde getal dat de aanmaakactie al afdwong: een lagere standaard zou bestaande accounts op dag één over hun grens duwen en de pauzeerregel hieronder zonder aankondiging laten vuren. Hoogstens 9 bronnen per regel, wat de acht hosted locaties plus één agent is die het schema al toestond. Alle bekende checktypen, afgeleid van die lijst in plaats van uitgeschreven, zodat een zevende type niet standaard voor iedereen verboden is. Een ondergrens van 60 seconden, die een ruimte omhoog mag zetten en nooit omlaag; omlaag is een apart betaald recht dat een naam heeft en niet bestaat.
Het revisienummer in die rij is wat in het grootboek belandt, en nul betekent "er staat geen rij, dit is de standaard". Zonder dat onderscheid is een gebruiksrij van vorig jaar niet terug te voeren op wat er toen mocht, en dat is de hele reden om een revisie te bewaren.
Wat pauzeert als de ruimte kleiner wordt
Wordt een ruimte verlaagd tot onder wat een account gebruikt, dan stoppen er regels. Wélke is een beslissing, en er waren twee kandidaten.
Duurste eerst kan niet, want er is geen prijs. Het zou betekenen dat "duur" wordt afgeleid uit het aantal bronnen of het interval, en dan pauzeert precies de scherpste bewaking die de klant heeft. Wie zijn pakket verkleint verliest liever een randmeting dan de melding die hem 's nachts wakker maakt.
Dus de oudste regels blijven draaien en de nieuwste pauzeren. De oudste dragen de langste incidentgeschiedenis en de meldingen waar mensen op vertrouwen, en "wat je het laatst aanzette gaat het eerst uit" is de enige volgorde die een klant kan voorspellen zonder onze code te lezen. De sortering is aanmaaktijd en dan regel-id, twee sleutels omdat een sjabloontoepassing meerdere regels in dezelfde milliseconde maakt; zonder dat tweede kenmerk komt de voorbeschouwing niet overeen met wat er daarna gebeurt.
Regels die een grens op hun vorm overtreden, een verboden checktype, hosted bronnen die niet meer mogen, te veel bronnen, worden eerst weggenomen en tellen daarna mee in wat er overblijft. Een interval dat nu te snel is pauzeert helemaal niets: een verhoogde ondergrens weigert een nieuwe of gewijzigde regel en laat draaiende regels met rust tot iemand ze aanraakt.
De lege kolom
Emmers hebben een kolom invoice_ref en die is leeg. Het is een benoemde naad en geen vergeetachtigheid, in dezelfde geest als het recht dat een naam heeft en geen implementatie: komt de facturatie er, dan staat de vorm die zij nodig heeft er al, en hoeft er niets aan het tellen te worden herzien onder tijdsdruk.
Twee verwante beslissingen volgen dezelfde redenering. Het grootboek heeft een eigen tabel in plaats van een afleiding uit de ticks, want ticks leven zeven dagen en dit 395. En de rijen per check zijn weggelaten uit de export van persoonsgegevens, met de reden ernaast opgeschreven: honderdduizenden per maand, een export die per sectie op 25.000 rijen wordt afgekapt, en uurbuckets die dezelfde totalen dragen. De emmers en de grenzenrij gaan wél mee.
Wat wij zouden opschrijven
- Schrijf de meter vóór de prijs. Elke vraag is eerlijker te beantwoorden als er geen totaal van afhangt.
- Boek op het moment dat het werk vertrekt, niet als het antwoord komt, en een laat antwoord is geen meetprobleem meer.
- Laat de idempotentiesleutel zijn onderwerp overleven. Een sleutel op een rij die opgeruimd wordt gaat volgens rooster duplicaten toelaten.
- Som élke uitkomst in een tabel op. Een standaardtak maakt van een nieuwe stand een stille nul.
- Correcties zijn rijen, nooit bewerkingen, en de uniciteit die het origineel beschermt mag de correctie niet blokkeren.
- Kies de volgorde die je klant kan voorspellen, en schrijf op welke je verwierp.
Voor de duidelijkheid over wat dit is: monitoring zit achter een uitrolschakelaar die standaard uit staat, er is geen rechtenlaag met geld erin, en niets hiervan is vandaag te koop. Twee dingen zijn onbewezen. De opruimronde heeft nooit tegen een werkelijk oude rij gedraaid, alleen tegen het schema. En de worker die uren afsluit is via zijn functie beproefd en niet via een langdraaiend proces, dus een gateway die een nacht weg is en zijn achterstand inloopt is beredeneerd en niet waargenomen.
Uit het monitoringwerk aan Provibr. Waarom een probe geen rechten draagt die hij niet nodig heeft staat in een probe die zich nergens toe laat overhalen, en waarom een incident niet sluit omdat de metingen stopten staat in een incident dat nooit sluit op stilte.