Als Developer wil ik Healthchecks

[rubenvdlinde]

zodat ik op afstand kan monitoren of componenten goed draaien of dat er problemen zijn.

Beetje rondkijken leverde twee methodes op een /health endpoint of een health-json. Naar mijn menig is die laatste het mooiste omdat je daarmee healthchecks per endpoint kan bieden (ofwel binnen een api zou het ene endpoint wel en het andere endpoint niet gezond kunnen zijn) en het een Standaard Status heeft. Aan de hand van de OAS documentatie (of beter nog zelf exploring endpoints) zouden we dan weer iets kunnen bouwen wat daar door heenloopt aan de hand van een chronjob en iets met de opgehaald info doet. (denk aan een container die een health dashboard bied en notificatie op falende healtchecks). Mooi onderdeel van de health-json standaard is dat het componenten kent waarmee we automatisch ook een call hebben om te kijken welk component er eigenlijk onder een API zit (wat leuk antwoord geeft op de wat draaid waar vraag, en waardoor we weten welke referentie er gevolgd zou moeten worden in de OAS documentatie en we ook dáár op kunnen testen).

Het zou ook aardig zijn om deze functionaliteit te combineren met authenticatie, en NLX-Ontsluiting (in theorie kunnen we bij NLX alle beschikbare services opvragen, bij de services de enpoints exploren en daar een healthcheck op doen). Daarmee is er dan inzicht in welke services waar in het landschap falen (beheer iemand?).

• Keuze maken over methode voor healtchecks
• Ontwerp van health bericht
• Opnemen van functionaliteit voor keuze
• Opnemen in DESIGN.md

@ThijsBroersen, @ehotting en @matthiasoliveiro kunnen jullie hier eens op mee denken? Ik vind eigenlijk dat healthchecks onderdeel zouden moeten zijn van de definition of done voor een API

[rubenvdlinde]

Dit komt mee met #274

[rubenvdlinde]

Dit is nu op de achtergrond geregeld, dus het zou mijn voorkeur hebben om komende sprint uit te schrijven hoe deze getest kan worden zodat we hem kunnen afronden.

[rubenvdlinde]

Hiervoor hoeft geen weergave te komen denk ik, gewoon postman test uitschrijven.

[rjzondervan]

De postmantest van deze functionaliteit is vrij eenvoudig. We nemen een willekeurig component, geheel toevallig heb ik dit getest met het wrc, op een willekeurig endpoint anders dan de root van het component zonder id (weer geheel toevallig, nemen we als voorbeeld even de templateslijst).

Als we dan de volgende header meegeven, bevragen we de healthcheck van het component in plaats van de entiteit zelf:

Accept: application/healt+json

Door dit op een GET-bevraging als bovenstaande mee te geven, krijgen we een health status van het component, zoals dit:

{
    "status": "pass",
    "version": "1",
    "releaseID": "V.0.1",
    "notes": [],
    "output": ""
}

[CMasselink]

Dit werkt.
@rjzondervan je hebt alleen wel een typefout in de accept header staan "healt" ipv "health" waardoor de voorbeeldinstructie niet werkt.