Need more ingress annotations

[Ngoguey42]

Hey, thanks for the great work. I miss a few things for be able to properly use kuma-ingress-watcher

It is already possible to customize the port through uptime-kuma.autodiscovery.probe.port, I would like to also be able to customize more aspects of the url.

This is the url I use in kuma-uptime: http://backend-service.my-namespace.svc.cluster.local:8001/health

In practice I would need 2 more ingress configurations such as these:

uptime-kuma.autodiscovery.probe.route: "/health"
uptime-kuma.autodiscovery.probe.host: "backend-service.my-namespace.svc.cluster.local"

[SQuent]

Thanks for your interest and contribution to this project! I just added support for the two annotations you requested, along with documentation. I plan to merge this within the week, so feel free to take a look beforehand to ensure it meets your needs.

I’m also curious—what's the reason behind wanting to use the in-cluster service URL as the host? I wonder if there might be a risk of not capturing the complete monitoring chain with this setup, which could mean missing out on the full benefits of Uptime Kuma’s black box monitoring. Plus, it could get a bit confusing if the probe URL isn’t the same as the Ingress URL.

Let me know what you think!

[Ngoguey42]

Thank you for implementing this!

To give a bit more context, I actually have two distinct use cases:

• Public URL Monitoring: In this case, I’m interested in tracking the public accessibility of a URL, so the host configured for Traefik is correct.
• In-Cluster Service Monitoring: Here, I’m more focused on tracking the liveness of services that are private to my cluster and not exposed via Traefik. I haven’t tested this yet, but I’m hoping that kuma-ingress-watcher will still successfully register these ingress annotations with Uptime Kuma. Do you think this approach is too much of a workaround?

[SQuent]

New version of helm chart is available. ( 1.5.0 ) I see your point more clearly now, but it would require creating a phantom Ingress with annotations for your internal service. This could add unnecessary complexity. One interesting idea would be to have dedicated Kubernetes kuma-probe objects, which would be managedby this controller and used to create probes in Uptime Kuma. This way, kuma-probe objects could be created for other services without needing to set up phantom Ingresses.

Let me think more about this idea. In the meantime, I’ll keep this feature available for those who may find it useful.