Feature: Healthcheck for the application itself

[freefd]

The frigate-notify docker image is Scratch-based, which means any additional utils are missing (even shell and ps tools).

In this situation, to add the ability to perform healthcheck there is an approach like the traefik did. Compose notation:

servicename:
...
    healthcheck:
      test: traefik healthcheck --ping
...

Thus, probably, the following could also be enough:

./frigate-notify healthcheck

The list of possible unhealthy criteria:

1. Configuration malformed: https://github.com/0x2142/frigate-notify/blob/main/config/config.go#L199-L214
2. Frigate (over Web API): https://github.com/0x2142/frigate-notify/blob/main/config/config.go#L252-L281
   1. Endpoint is unreachable (monitor feature)
   2. Authentication has failed (Feature Request)
   3. HTTP response codes >= 400
3. MQTT: https://github.com/0x2142/frigate-notify/blob/main/events/mqtt.go#L20-L51
   1. Endpoint is unreachable
   2. Authentication has failed
   3. Topic does not exist
4. Notifier X is configured
   1. Endpoint is unreachable
   2. Authentication has failed

[freefd]

Dear @0x2142, since you started implementing the REST API from #125, it seems that here we can move on to a more common way of implementing healthcheck endpoints - the well-known z-pages approach:

• https://vimeo.com/173610242
• https://github.com/kelseyhightower/app-healthz

Thus, regardless of having the /status informational endpoint, for the m2m communications the app requires endpoints for Liveness and Readiness probes:

• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

The direct mapping is

• Readiness => /api/vX/readyz
• Liveness => /api/vX/healthz

From the response perspective, liveness endpoint can just return {"status":"ok"} with HTTP 200 OK, while the readiness endpoint returns an entire message like {"status":"probename is not yet ready"}.

[0x2142]

Sounds good, I can include that 👍