Monitor CDN edges where one domain has multiple IP's

chelbos commented 2 years ago

⚠️ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

For my SAAS service, I've built my own CDN and I have 9 servers around the world. This allows me to serve my content fast.

I would love to use Uptime Kuma to monitor my network, but the domain monitor is missing the IP

This could be implemented very easy if the request on the server side is done via curl

Please add this feature, that's all I need and will help a lot of people

Thank you!

✔️ Solution

curl -v --resolve mydomain.com:443:xxx.xxx.xxx.xxx

❓ Alternatives

Currently I have a script that does that and notify's me about any issues, but having a nice UI would improve the beauty in my life :)

📝 Additional Context

No response

chelbos commented 2 years ago

No one needs to monitor a domain that is on multiple servers? am I alone?

Computroniks commented 2 years ago

Personally, for me, if the domain is on multiple servers and one server goes down, I would not consider the domain its self to be down as the other servers can still respond to the clients reqests. This is where you could monitor the domain as a whole as well as your seperate servers. I.e have one monitor for example.com and then another for 1.cnd.example.com, 2.cnd.example.com ... n.cnd.example.com.

chelbos commented 2 years ago

yes ... but I have lots of SSL certificates on each server, I would like to know if my admin forgot to renew a SSL on one of the edges. Your solution 1.cnd 2.cnd won't work for that scenario.

suominen commented 2 years ago

It would be nice if it was possible specify the domain for SSL / SNI separately from the hostname or IP address to connect to.

CommanderStorm commented 9 months ago

specify the domain for SSL / SNI separately from the hostname or IP address to connect to

You can do that with the tools currently at your disposal:

you enter the ip into the url field
you enter the Host header as described in https://github.com/louislam/uptime-kuma/issues/2991

mateuszdrab commented 4 months ago

In my case I am TCP port monitoring my ingress DNS record which has two IP addresses and when one of those goes down, Kuma will repeatedly flip between up/down state. I'd much prefer the monitor to have an option to monitor multiple IPs separately from that DNS record and report down if all or any are down (with this being a configurable option).

CommanderStorm commented 4 months ago

About your comments

monitor multiple IPs separately from that DNS record

IP and HOST header can be monitored separately as stated in https://github.com/louislam/uptime-kuma/issues/1689#issuecomment-1843944315

report down if all [...] are down

We track this in

If somebody wants to improve the group monitor them via a PR our contribution guide is here

report down if [...] any are down

This is the current behaviour of groups.

CommanderStorm commented 4 months ago

I think what this issue is really lacking is "How should this work" without exponentially increasing the complexity. There are already probably too many settings, I don't want this to turn into a parameter dump by adding resolution and SNI settings when they essentially already exist via the IP+HOST settings. Do people have any ideas on this?

mateuszdrab commented 4 months ago

An implementation that adds no extra settings could be something like this https://serverfault.com/questions/327708/how-browsers-handle-multiple-ips

Essentially, resolve DNS name, if multiple IPs present, check first one, if success - check is ok. If it fails, try next IP. If a failed over IP works, could either mark it as healthy or degraded - well, that could be a setting ;).

This is what browsers do under the hood, albeit slowly and sometimes the page takes forever to load but it eventually fails over.

CommanderStorm commented 4 months ago

We use axios/Node.js to do the heavy lifting in this department. According to https://github.com/axios/axios/issues/4534#issuecomment-1246088657 we already do Happy Eyeballs. Said issue is a bit contradictory/outdated with https://github.com/nodejs/node/issues/48145 and https://github.com/nodejs/node/issues/708#issuecomment-256405916

There also has been a fair bit of traffic on happy eyeballs in node. See https://github.com/nodejs/node/issues?q=is%3Aissue+happy+eyeballs+is%3Aclosed

=> This might be resolved when we upgrade the docker image to node v18 -> v22

mateuszdrab commented 4 months ago

Interesting; however, Happy Eyeballs isn't quite the same what the old fashioned failover behavior is like. Though, if it works, it will essentially solve my issue if it tries to establish multiple connections to multiple IPs within the same stack (IPv4) - it looks like main purpose of the above is to handle dual stack environments.

Are there any node v22 dev builds available?

CommanderStorm commented 4 months ago

As far as I read section-5.4 of RFC6555, the logic you are talking about SHOULD work as far as I read this part. (not a specs-expert)

CommanderStorm commented 4 months ago

Are there any node v22 dev builds available?

See #4500 what bugs remain before we can publish the first beta of v2.0

louislam / uptime-kuma