search

juanfont / headscale

An open source, self-hosted implementation of the Tailscale control server
BSD 3-Clause "New" or "Revised" License
23.49k stars 1.29k forks source link

[Feature] Expose OIDC server status via monitoring #1940

Open viq opened 6 months ago

viq commented 6 months ago

Use case

This would allow easy checking of what headscale thinks of availability of the OIDC server, and to set up alerting based on such.

Description

Currently if the OIDC server is not available, headscale (if configured to do so) will switch to "standard" mode, and emit a message in logs. But if someone doesn't look at logs constantly, the only warning about this will be when registering a new machine instead of getting redirected to OIDC login, one will get the information about commands to run on server.

Headscale already has support for exposing some of internal information to prometheus. It would be great if this information was available there as well.

Contribution

How can it be implemented?

Possibly metrics like headscale_oidc_configured or headscale_oidc_info with some information about the configured OIDC server, if any, and headscale_oidc_functional with 0 or 1 depending what the internal checks show.

kradalby commented 1 month ago

I wonder if a /health/oidc endpoint might make more sense than a metric. My rational is:

For a metric to be meaningful, we either need to poll oidc on every scrape, which seems a bit "wrong" and might interfere with other metrics. Alternatively we need a routine that checks all the time.

While querying a health endpoint is more "please check if the oidc is available from your perspective", like what we do for the database here https://github.com/juanfont/headscale/blob/main/hscontrol/handlers.go#L128

What do you think?