uptime-kuma
uptime-kuma copied to clipboard
louislam
IPv6 + IPv4 switch to see if both are healty
ā ļø Please verify that this feature request has NOT been suggested before.
- [X] I checked and didn't find similar feature request
š·ļø Feature Request Type
API, New Monitor, UI Feature
š Feature description
- currently it depends on whatever the environment is configured to prefer ( e.g. /etc/gai.conf )
- there is no proof if IPv4 + IPv6 Host return the same result
āļø Solution
a little button "resolve ipv6+ipv6" or "dual-stack-check" and the respecting part in the monitoring stack
ā Alternatives
No response
š Additional Context
No response
Seems to be a duplicate of #1025 Also, it doesn't seem to depend on whatever the environment is configured to prefer. On default IPv6 is preferred, but uptime kuma still checks on IPv4 and not on IPv6. Properly, I could just disable IPv4 on my uptime kuma host, but that way I need to activate it again if I want to update uptime kuma as GitHub only supports IPv4... The best solution would be to add the option of which IP to use, but at least uptime kuma should follow the standard and use IPv6 as default.
The problem for OP and me is that we cannot check that IPv4 and IPv6 works. #1025 isn't strictly the same because that is about switching between IPv4 and IPv6 instead of testing both.
Same issue with me. On a location a NAS is only on IPv6. Uptime kuma sees this server as down while it is up and running with a valid DNS and FQDN.
see how https://updown.io/ handle ipv4 + ipv6, not even need to switch, it would be a really nice feature.
Am interested into implementing this as I am running into a lot of false positives due to IPv4/IPv6 thing.
Even a tick box for ipv4 or ipv6 only and then easy enough to create two monitors if needs be - probably easier.
Even a tick box for ipv4 or ipv6 only and then easy enough to create two monitors if needs be - probably easier.
Im hoping for this
Generally speaking, a single URL with hostname can resolve to both IPv4 and IPv6 address(es), but also MULTIPLE addresses. An uptime monitor should really be checking all resolutions of the domain name, not just the default or first one it happens to get.
An uptime monitor should really be checking all resolutions of the domain name, not just the default or first one it happens to get.
not sure if there is any monitoring solution which checks both A/AAAA and possibly even multiple records of them. seems out of scope for uptime kuma since you could simply add more checks for everything you need (v4 and v6).
if you have multiple A/AAAA-Records for http you normally would check on IP and use specific hostname to get correct site, this could be done via setting "URL" to "https://1.2.3.4/my-monitoring-uri" and send host header using "JSON-Headers":
{
"Host": "www.MY.HOST.TLD"
}
most basic is the feature to choose address family for all protocols when using DNS.
if you have multiple A/AAAA-Records for http you normally would check on IP and use specific hostname to get correct site, this could be done via
Please not this likely bug in ipv6 handling of axios: https://github.com/louislam/uptime-kuma/issues/3564 Fixing said bug would possibly require an upgrade of axios which is blocked by there not being a documentation on how to upgrade from 0.x to 1.x and what changes were made or more debugging.
not sure if there is any monitoring solution which checks both A/AAAA and possibly even multiple records of them. seems out of scope for uptime kuma since you could simply add more checks for everything you need (v4 and v6).
You could. I still think the current model can be dangerous for the naive user. You get a green label, even if your connectivity is partially broken. I'm not complaining here, just suggesting that an implicit check of all domain name resolutions would what the user really needs, and often didn't realise that they wanted.
if you have multiple A/AAAA-Records for http you normally would check on IP and use specific hostname to get correct site, this could be done via setting "URL" to "https://1.2.3.4/my-monitoring-uri" and send host header using "JSON-Headers":
{ "Host": "www.MY.HOST.TLD" }
You would also need to be able to specify SNI for this work.
I've been working on a PR to resolve this. It would add an option to specify IPv4 or IPv6. If you leave it on "auto detect" (the default) it will use the current logic. It works with the following monitors so far: Ping, TCP, DNS. I'm working on the HTTP monitor then I'll submit it.
Here are some screenshots of the option:
Thank you!
Iām not sure if "IP Family" is the correct term here, as to my knowledge, it refers to a broader set of IP protocols as TCP, DNS, SMTP etc. ā all being part of the IP family. Thus I would suggest going with "IP version".
I'm not particularly set on the name. It's called IP Address Family in normally, e.g. in the nodejs doco it calls it address family: https://nodejs.org/api/net.html#socketaddressfamily
IP address family should be fine to use, as per IANA the family version 4 and 6 have assigned number 1 and 2.
That being said, I appreciate the work to be able to determine the ip protocol being used for a monitor.
Thank you for your work on this! It would be great if there was a fourth option to check both IPv4 and IPv6, avoiding the need to create 2 ping jobs. Not sure if that's possible in the current uptime-kuma framework.
Thank you for your work on this! It would be great if there was a fourth option to check both IPv4 and IPv6, avoiding the need to create 2 ping jobs. Not sure if that's possible in the current uptime-kuma framework.
I don't see how you would implement a dual check. If IPv4 was down, but IPv6 was up - how would the logic of the monitor be set - should it show as down or up. How would it display which IP version wasn't working? I think it best that this is set up as two monitors for clarity.
Two would make the most sense to me, that way the ping graphs would represent an accurate ping time for each (unless one went down the road to have two ping graphs.... but that seems like a lot of extra development effort). If one wanted they could make a group I suppose to contain the two variants (host - host v4, host v6)
If a service is supposed to be dual-stacked, but suddenly becomes single-stacked (regardless of it's IPv4-only or IPv6-only), the service is for all intents and purposes "down" the way I see it. If Kuma monitors both IPv4 and IPv6 simultaneously, it's no problem to alert/identify what address-family that becomes unresponsive (and alert accordingly, like "IPv4 down for service XYZ" or similar).
If the "down" vs. "partially-down" is a controversal topic, it could probably be made as an option (i.e. if it should just alert, but keep the service status "up", or actually mark the whole service as down). Or, maybe even better, introduce "Degraded" status (in addition to "Up" and "Down"). The latter could probably also be tied in with other feature requests (like #2313) to facilitate a way to show bad performance or other kinds of service degradations.
@joachimtingvold you cant assume clients are dual-stacked and perform some kind downgrade to v4. v6 only (or v4 only) cant reach your services therefore its down for them (not a service "degradation" which would imply reachable but slower).
That's essentially what I said; personally I consider a dual-stacked service to be down if it for some reason becomes single-stacked (regardless if IPv4 or IPv6 is broken). However, I merely suggested that it could be a configuration choice, as I can see people look at this differently. There are scenarios where "Degraded" makes sense, and others where "Down" makes sense. As an example, I assume some use Kuma for internal services, and if you have control of the environment (where you can say 100% of the service consumers are dual-stacked), there might be scenarios where you would like to consider the scenario of "dual-stacked service that becomes single-stacked" to be "Degraded", rather than "Down" (as it in many cases would work, just that it needs time to fall back to the working address family -- like Happy Eyeballs and similar mechanics).
if the service is not reachable its down, if the host (or the route) is broken its a false alarm in regard to this alarm. if you dont want a service to be reachable over v6 (or v4) dont publish AAAA/A-records. essentially you ask for preference order (v6 first, v4 first) or in case of DNS and "ignore downgrade" which is not a behaviour i would recommend for monitoring (sure, its better than "fail silently if downgrade works" but IMHO not much better).
I still think it would be beneficial to have options, and let users decice how they want to monitor things. As I mentioned, I see usecases for both variants in controlled environments. If this is implemented as a IPv4/IPv6-dualstacked-specific feature, or combined with the "service grouping"-feature that has been implemented (or at least partially, see #2487 + #2474 + #2693 + #1236, and probably others), I have no strong opinion on. There are many similar problems that dual-stacked monitoring and service grouping have in common. Some of the top of my head;
- Mark the entire service as down if IPv4 or IPv6 is down
- Mark service as degraded if IPv4 or IPv6 is down
- Alert if one part of the service is down (I would like to know specifically if IPv4 or IPv6 failed)
- Don't alert for both IPv4 and IPv6 if the entire service goes down (just alert once that the service is down)
- ... and probably more
most tools i know have explicit -4 or -6 switches, or (by default) do downgrades (for which you might want to set the order if v6 > v4 is not desired). not a fan of introducing another status (aside up or down) which would need extra settings in notifications.
There's already extensive support for this clearly, adding my voice to that.
I'd also like to share my thinking on the handling of a v4 and/or v6 outage.
IPv4 and IPv6 are entirely different networks, with different routing and, different network-level issues that could impact performance.
Yes, they are typically handled by the same server, often the same service - but that's not a requirement.
There are IPv4-only networks, dual-stack and IPv6 only networks.
In my opinion, the ability to select the IP family needs to be thought of simply as a time saver for creating two entries - and that's it.
An outage of IPv4 or IPv6 while the other remains up is not a degradation of service - it's an outage - the server is offline for some (or maybe all) of your eyeballs.
Where we can, we already create separate monitors for each IP family:
The failure of both IPv4 and IPv6 may be treated differently by some - perhaps it means some more significant outage of the service or backend rather than a network layer issue - but that really depends on the service, the environment and those who manage it.
IPv6 is a replacement for IPv4 (eventually... maybe... someday?) - we must not make the mistake of thinking that dual stack for life is the solution, and our monitoring tools need to embrace that thinking also.
