[FEAT]: Healthcheck for container

[SchoolGuy]

Currently, the containerized deployment works very easily but the container engine has no knowledge about the health of the instance.

For Docker the following concept applies: https://docs.docker.com/reference/dockerfile/#healthcheck

This can be reused for k8s of course: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

For this simple purpose, I would recommend having a simple /health endpoint that returns only 200 if the exporter runs successfully.

[SchoolGuy]

Optionally if we want to support the concept of startup/readiness probes we could split this into three routes that return 200 on success and something else for the appropriate scenarios:

• /health/startup - 200 as soon as the application is started
• /health/ready - 200 as soon the config is loaded
• /health/alive - 200 once the exporter is started

I do believe that returning a non-200 reply in case a router is not available is not appropriate.

[holmesb]

Yes /health endpoint/s would be great. Currently the helm chart probes the root path "/", which invokes collection. Ie triggers mktxp hitting the ROS API. And since these probes are hard-coded to occur more frequently than the mktxp minimal_collect_interval default of five seconds, mktxp fails to collect mktxp_* metrics from ROS. Adding /health endpoint will allow k8s http probes without invoking collection. PR #314 should return cached mktxp_* metrics, but Kubernetes probes should not trigger RouterOS collection, so this is the better fix.