Skip to content

Health-Endpoint

Die Health-Checks dienen dazu festzustellen, ob der Service ordnungsgemäss funktioniert oder nicht. Es können mehrere Health-Checks vorhanden sein. Der Service gilt dabei als Healthy, wenn alle Health-Checks als Healthy eingestuft werden. Falls einer der Health-Checks den Status Degraded oder Unhealthy zurückgibt, übernimmt der Service diesen Status.

Die Health-Checks wurden so konzipiert, dass sie sekündlich abgerufen werden können.

Erreichbarkeit / URL

Die Health-Checks sind unter /healthz, /healthz/startup, /healthz/ready und /healthz/live erreichbar ( Bsp.: https://service.cmiag.ch/healthz) Es ist dabei entscheidend, dass die Health-Checks mandantenunabhängig sind.

Die Health-Checks werden wie folgt ausgeführt:

  • /healthz => Führt alle vorhandenen Health-Checks aus
  • /healthz/startup => Führt die Startup Health-Checks aus. Ein "Not OK" signalisiert, dass der Prozess sich noch im Startvorgang befindet.
  • /healthz/ready => Führt die Ready Health-Checks aus. Ein "Not OK" gibt an, dass der Prozess noch keine Anfragen verarbeiten sollte.
  • /healthz/live => Führt die Live Health-Checks aus. Ein "Not OK" bedeutet, dass der Prozess sich in einem undefinierten Zustand befindet.

Status Code

Abhängig vom Status der Health-Checks werden die folgenden Status-Codes zurückgegeben:

  • Healthy => 200 (OK)
  • Degraded => 200 (OK)
  • Unhealthy => 503 (Service Unavailable)

JSON Antwort

Wenn der Health-Check-Endpunkt aufgerufen wird, wird die folgende JSON-Struktur zurückgegeben:

{
  "Status": "Healthy | Unhealthy | Degraded",
  "HealthChecks": [
    {
      "Status": "Healthy | Unhealthy | Degraded",
      "Component": "Health check name",
      "Description": "Response description",
      "Tags": [
        "STARTUP | READY | LIVE"
      ],
      "Exception": "Possible exception"
    },
    {
      "Status": "Healthy | Unhealthy | Degraded",
      "Component": "Health check name",
      "Description": "Response description",
      "Tags": [
        "STARTUP | READY | LIVE"
      ],
      "Exception": "Possible exception"
    }
  ],
  "HealthCheckDuration": "Duration"
}

Jeder einzelne Health-Check wird unter "HealthChecks" als eigenes JSON-Element aufgelistet.

Konfiguration

{
  "HealthCheck": {
    "RequireHost": [
      "localhost"
    ],
    "ApiKey": "<API Key>"
  }
}

RequireHost

Durch die Verwendung von RequireHost kann ein Array definiert werden, das steuert, auf welchen Hosts die Health-Check-Endpunkte hören. Wird bspw. health.demo.local eingetragen, so antworten die Health-Checks nur auf Anfragen an diesen Host. Wenn das Array leer ist, hören die Health-Checks auf alle Anfragen. Standardmässig ist localhost eingetragen. Mögliche Werte: Domains, IP-Adressen, Ports usw. Hier einige Beispiele:

  • localhost
  • health.demo.local
  • *:5000 (für alle Anfragen auf Port 5000)
  • 192.168.1.100.

ApiKey

Mit ApiKey kann ein API-Key festgelegt werden, der für die Health-Endpunkte im Header X-HEALTH-KEY mitgegeben werden muss. Falls kein API-Key festgelegt ist, ist keiner erforderlich. Standardmässig ist kein API-Key gesetzt.