API-monitoringtool: uptime, responstijd en validatie vanaf 300+ locaties

REST-API-monitoring lijkt oppervlakkig op uptime-monitoring, maar is een andere taak. Een API wordt door code gebruikt, niet door mensen, en code is onvergevingsgezind op manieren waarop een browser dat niet is. Een menselijke bezoeker tolereert een pagina die net iets verkeerd wordt weergegeven; een integratie die een veld van het verkeerde type ontvangt, gaat gewoon stuk. API-monitoring moet daarom meer lagen controleren dan alleen "heeft de server geantwoord", en HostTracker controleert ze in volgorde, en faalt bij de eerste laag die niet standhoudt.

Lagen één tot en met drie zijn wat een gewone uptime-check je geeft. Vier en vijf zijn wat er API-monitoring van maakt - en dat zijn de lagen waar de meeste echte API-incidenten zich daadwerkelijk afspelen.

Voordat er iets gevalideerd kan worden, moet de monitor de request doen die je API verwacht. Het volledige requestoppervlak is beschikbaar op een API-monitor:

De meest expressieve manier om een respons te valideren, is er regels voor te schrijven. Elke regel is één regel code, regels worden met AND gecombineerd, en een monitor kan er tot twintig dragen. Dit is de geverifieerde startbundel voor een JSON-API:

status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5s

Vier regels, en samen dekken ze de vier lagen die ertoe doen: het endpoint antwoordde met een 2xx, het antwoordde met JSON in plaats van een foutpagina, de payload bevat een echt resultaat in plaats van een leeg resultaat, en dat gebeurde allemaal binnen het tijdsbudget. Los ook nuttige regels uit dezelfde catalogus zijn onder andere body.json.path("$.status") eq "ok" voor het eigen gezondheidsoordeel van een API, body.json.path("$.error") absent voor een foutveld dat verschijnt in een verder succesvolle respons, body.json.path("$.version") eq "2.4.1" om een onbedoelde terugdraaiing op te vangen, redirects.count eq 0 voor een endpoint dat rechtstreeks moet antwoorden, en cert.days.left gt 14 voor het certificaat op dezelfde verbinding.

Waar een regel over kan gaan

Regels lezen onderwerpen uit de respons en vergelijken ze. De onderwerpen omvatten de statuscode; de totale reactietijd en de onderdelen daarvan voor verbinding, TLS, DNS, headers en body; de ruwe body samen met de grootte en een hash ervan; gestructureerde queries in de payload als JSON, XML, HTML of YAML; individuele responseheaders; de uiteindelijke en oorspronkelijke URL en hun onderdelen; de doorverwijzingsketen, stap voor stap; het aantal resterende dagen, de uitgever en de namen van het certificaat; het afgesproken TLS-protocol en de cipher; de adressen die DNS teruggaf; en Set-Cookie. Vergelijkingen lopen van de voor de hand liggende - gelijk aan, kleiner dan, groter dan - tot contains, startsWith, endsWith, matches voor een reguliere expressie, containsAny en containsAll voor een verzameling, in voor een lijst met toegestane waarden, en exists, isNumber en unique.

Er is ook een as voor wijzigingsdetectie: een regel kan de waarde van deze run vergelijken met die van de vorige run, zodat je kunt toetsen dat een teller nooit terugloopt of dat een body-hash niet is veranderd - het type regel dat een stille terugdraaiing of een ongeautoriseerde inhoudswijziging opvangt in plaats van een storing.

Naast de regeltaal is er een eenvoudiger pad voor één waarde, dat al lang deel uitmaakt van de API-monitoring hier en vaak alles is wat een check nodig heeft. Je vertelt de monitor hoe de body geparsed moet worden, hoe daaruit één waarde geselecteerd wordt, en wat die waarde moet zijn:

• Parsen als JSON, en de selector is een JSONPath-expressie.
• Parsen als XML, en de selector is een XPath-expressie - wat SOAP en andere XML-diensten eenvoudig controleerbaar maakt.
• Behandelen als platte tekst, en de selector is een meerregelige, niet-hoofdlettergevoelige reguliere expressie.

Het predicaat dat op de geselecteerde waarde wordt toegepast, omvat gelijk aan en ongelijk aan, kleiner dan en groter dan in zowel strikte als inclusieve vorm, lidmaatschap van een lijst met toegestane waarden of uitsluiting daarvan, binnen of buiten een numeriek bereik, en een test of de waarde null is of volledig ontbreekt.

Elke storing in deze tabel geeft HTTP 200 terug. Dat is precies het probleem met een API alleen op zijn statuscode monitoren: het transport is geslaagd, dus rapporteert het transport succes.

Die laatste rij is het bewust doen waard. Een tweede monitor die geen inloggegevens meestuurt en toetst op een 401 is de goedkoopste manier om erachter te komen dat een autorisatielaag per ongeluk is uitgeschakeld - een storing die geen enkele hoeveelheid positieve tests ooit aan het licht zal brengen.

API-monitors draaien vanaf de publieke checkpointvloot van HostTracker - 300+ checkpoints in 158 steden - en je kiest welke locaties een bepaalde monitor gebruikt. Geografie doet er bij een API meer toe dan bij een website: een endpoint achter een CDN of een geo-gerouteerde load balancer kan gezond zijn in Frankfurt en falen in São Paulo, en een check vanaf één locatie kan dat onmogelijk zien. Hetzelfde geldt voor DNS - een verouderd of verkeerd geconfigureerd record verspreidt zich vaak ongelijkmatig, wat er van binnenuit uitziet als een sporadische storing en van buitenaf als een regionale.

Vanaf veel plekken draaien brengt een voor de hand liggend risico met zich mee: meer checkpoints, meer kansen dat één instabiel netwerkpad vals alarm slaat. HostTracker regelt dat met een bevestigingsquorum. Wanneer een checkpoint een storing meldt, wordt de check herhaald vanaf extra onafhankelijke checkpoints, en de statusverandering wordt pas bevestigd zodra ze het eens zijn - standaard een meerderheidsoordeel over maximaal zeven agents, met een minimum van drie. Je kunt dit strenger maken, door een vast aantal agents te vereisen dat de storing meldt, of volledige overeenstemming tussen hen, voor een endpoint waar een vals alarm erger is dan een trage melding.

Na bevestiging volgt de melding de vertraging die elk contact heeft gekozen - direct, of na 3, 5, 15, 30 of 60 minuten, of na 3, 6, 12 of 24 uur ononderbroken storing - via de negen notificatiekanalen: e-mail, sms, spraakoproep, webhook, Slack, webpush en de berichten-apps Telegram, Discord en Viber. Het webhookkanaal is hoe meldingen een incidentmanager of een teamchattool bereiken.

De check is een configureerbaar HTTP-verzoek plus responsanalyse, dus wat erbij past volgt daar direct uit.

• REST- en JSON-API's zijn het alledaagse geval, en REST-API-monitoring is wat de meeste accounts als eerste inrichten: een GET of POST, headers voor het inloggegeven, en JSONPath- of assertion-regels over de payload.
• GraphQL werkt als een POST met de query in de body, gevolgd door JSONPath in data - en het is de moeite waard om te toetsen dat het errors-veld afwezig is, aangezien GraphQL berucht is om het antwoorden met 200 terwijl er fouten in zitten.
• SOAP- en XML-diensten zijn een POST met de envelope als body en XPath als selector, wat precies zo in de respons grijpt als de specificatie bedoelt.
• Webhookontvangers en callback-endpoints kunnen worden gecontroleerd op bereikbaarheid en op de respons die ze geven op een correct gevormd verzoek - waardevol, omdat een ontvanger die stilletjes is gestopt met het accepteren van leveringen nergens in je eigen systeem een fout veroorzaakt.
• Health- en readiness-endpoints zijn, als je ze hebt, het waardevolste doelwit van allemaal: je applicatie weet al of haar afhankelijkheden gezond zijn, en een assertion op dat oordeel maakt van die eigen kennis een melding.

Wat er niet bij past, is een reeks - een token verkrijgen, het gebruiken, en dan de resource verwijderen. Een API-monitor doet één verzoek per run. Voor een echte meerstaps-reis is de browsergestuurde transactiecheck het juiste middel; voor de laadtijd van een pagina in plaats van een endpoint, zie browsertoegang en paginalaadtijd.

1. Probeer het endpoint eerst met de gratis directe HTTP-check - geen login vereist - zodat je de status, timing en respons ziet waar je zo meteen regels tegen gaat schrijven.
2. Voeg een monitor toe en kies het type API-monitoring. Stel de methode in en voeg de headers of body toe die het endpoint nodig heeft; geef de monitor een eigen inloggegeven in plaats van dat van een persoon te hergebruiken.
3. Schrijf de assertions. Begin met de bundel van vier regels hierboven - status, content type, één betekenisvolle waarde uit de payload, en een reactietijdbudget - wat een oprecht goede standaard is voor bijna elke JSON-API.
4. Kies een interval tussen één minuut en 24 uur. Drie minuten is de standaard en een redelijk startpunt; reserveer één minuut voor de endpoints waarvan een storing een incident is.
5. Kies de locaties. Twee of drie regio's waar je afnemers daadwerkelijk zitten, verslaan één enkele locatie, en dat is wat een regionale storing zichtbaar maakt.
6. Voeg de contacten toe en stel voor elk de meldingsvertraging in. Niet iedereen hoeft het al bij minuut één te horen.
7. Laat het een dag draaien, en bekijk dan de geschiedenis van de reactietijd voordat je de timingregel aanscherpt. Een budget dat op echte data is gebaseerd, houdt stand; een budget dat op een gok is gebaseerd, wordt gedempt.

Deze vullen elkaar aan en worden vaak met elkaar verward. Een observability- of APM-platform instrumenteert je code en vertelt je wat er binnen een verzoek is gebeurd. Externe API-monitoring staat buiten je infrastructuur en vertelt je wat een afnemer daadwerkelijk ontvangt. Beide zijn de moeite waard; geen van beide vervangt de ander.

Het patroon waar de meeste teams op uitkomen, is externe monitoring voor detectie en interne telemetrie voor diagnose: HostTracker vertelt je dat een endpoint kapot is, vanaf waar, en tegen welke regel, en je eigen tracing vertelt je waarom. Daarnaast verklaart een databasequerymonitor vaak een API die traag is geworden, en verklaart servermonitoring de host waarop deze draait.

• Eén verzoek per run. Geen tokenuitwisseling, geen geketende aanroepen. Richt de monitor op een endpoint waarvan de authenticatie niet verloopt, en gebruik een transactiecheck wanneer wat je moet bewijzen een reeks is.
• Twintig assertion-regels per monitor. In de praktijk ruim voldoende - de bundel van vier regels dekt de meeste endpoints - maar goed om te weten voordat je een contracttest met honderd regels plant.
• Assertion-modus vervangt de oudere trefwoord- en statusinstellingen. De twee modellen kunnen niet op één monitor worden gecombineerd; kies de regeltaal of de oude trefwoordmodus, niet allebei.
• Geen OpenAPI- of JSON-schemavalidatie. Je toetst op specifieke waarden en structuren, niet op een heel schemadocument.
• De requestbody heeft een lengtelimiet, dus een zeer grote POST-payload is niet waarvoor deze check is gebouwd.
• Het is monitoring, geen testen. Het juiste doelwit is een alleen-lezen of idempotent endpoint. Een monitor die elke drie minuten vanaf meerdere locaties data wijzigt, wordt uiteindelijk de oorzaak van een incident in plaats van wat het detecteert.