[Feature] Add Node-specific 'Connection Status' and 'Last Seen' Metrics #1169

Closed
opened 2025-12-29 02:28:41 +01:00 by adam · 2 comments
Owner

Originally created by @Draxter on GitHub (Dec 7, 2025).

Use case

As a Platform Engineer, I need metrics that expose the current connection status and the 'last seen' timestamp of registered nodes, labeled by hostname and user. This allows me to build alerts when critical nodes lose contact with the control plane.

Description

Proposed example metrics:

headscale_machine_online{hostname="my-server-01", user="admin"} 1 (Gauge: 1 for online, 0 for offline)

headscale_machine_last_seen_timestamp_seconds{hostname="my-server-01"} 1234567890

Workaround?

I can also see that the individual nodes/clients, which in my case run the tailscale client, have a tailscale metrics command, which shows a lot of useful metrics once upon running that command. However I do not see an easy way to run the tailscale client with permanently enabled metrics endpoint.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

No response

Originally created by @Draxter on GitHub (Dec 7, 2025). ### Use case As a Platform Engineer, I need metrics that expose the current connection status and the 'last seen' timestamp of registered nodes, labeled by hostname and user. This allows me to build alerts when critical nodes lose contact with the control plane. ### Description ### Proposed example metrics: headscale_machine_online{hostname="my-server-01", user="admin"} 1 (Gauge: 1 for online, 0 for offline) headscale_machine_last_seen_timestamp_seconds{hostname="my-server-01"} 1234567890 ### Workaround? I can also see that the individual nodes/clients, which in my case run the tailscale client, have a `tailscale metrics` command, which shows a lot of useful metrics once upon running that command. However I do not see an easy way to run the tailscale client with permanently enabled metrics endpoint. ### Contribution - [x] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancement label 2025-12-29 02:28:41 +01:00
adam closed this issue 2025-12-29 02:28:41 +01:00
Author
Owner

@kradalby commented on GitHub (Dec 9, 2025):

As per Prometheus docs, this would be high cardinality data and it would not be very suitable for metrics, so we will not be adding that.

If you want to monitor Nodes in this way, I would recommend the API.

@kradalby commented on GitHub (Dec 9, 2025): As per [Prometheus docs](https://prometheus.io/docs/practices/naming/), this would be high cardinality data and it would not be very suitable for metrics, so we will not be adding that. If you want to monitor Nodes in this way, I would recommend the API.
Author
Owner

@BeryJu commented on GitHub (Dec 21, 2025):

Accepting that this might have a very high cardinality, what are the feelings of adding a separate option to include a metric like this and acknowledge the risks it may bring?

@BeryJu commented on GitHub (Dec 21, 2025): Accepting that this might have a very high cardinality, what are the feelings of adding a separate option to include a metric like this and acknowledge the risks it may bring?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1169