mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Allowing ping/dns/http calls via distributed network (globalpings,ripe Atlas) #2793
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#2793
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ilogus on GitHub (Nov 14, 2023).
⚠️ Please verify that this feature request has NOT been suggested before.
🏷️ Feature Request Type
New Monitor, Other
🔖 Feature description
The proposed feature is the integration of the RIPE ATLAS API to enable advanced network monitoring capabilities. RIPE ATLAS, is a globally distributed network measurement platform, offers extensive data on network connectivity and performance. By integrating its API, Uptime Kuma users could leverage the robust data provided by RIPE ATLAS, enhancing the monitoring of server performance and network health. This integration would offer detailed metrics and insights, particularly beneficial for users requiring comprehensive and multi-locational network analysis. The ability to utilize the RIPE ATLAS API would not only enrich the dashboard with meaningful metrics but also expand the scope of Uptime Kuma's monitoring capabilities, particularly in tracking global server performance and anycast services.
One of the most significant advantages of integrating the RIPE ATLAS API into Uptime Kuma is the centralization of network monitoring capabilities. By bringing together the diverse and comprehensive data from the RIPE ATLAS network with Uptime Kuma's existing features, users gain the benefit of a unified monitoring dashboard. This centralization simplifies the process of tracking and analyzing network. It eliminates the need to switch between different tools and platforms, thereby streamlining the monitoring process and reducing the potential for oversight or error. Having a single, cohesive monitoring panel enhances the efficiency and effectiveness of network management, making it easier for users to get a complete picture of their network's status and to make informed decisions quickly.
✔️ Solution
In my specific use case, the integration of the RIPE ATLAS API with Uptime Kuma would be immensely beneficial for monitoring servers across multiple locations, including anycast servers. This is crucial for maintaining a high level of service quality and uptime, especially in a distributed network environment. The RIPE ATLAS API would provide external and reliable data enabling a more accurate and comprehensive view of network health and performance. This integration would allow for a more detailed analysis of network metrics, including latency, packet loss, and overall connectivity, from various points around the globe. Additionally, it would enhance our ability to promptly identify and resolve network issues, thus improving the efficiency of our monitoring practices and the reliability of our network services.
It's rather complex, so I'm not sure how to go about adding this functionality, add it as a monitor? create another mechanism that uses the uptime kuma API for management? We can debate it.
For more information, documentation is available here : https://atlas.ripe.net/docs/
❓ Alternatives
No response
📝 Additional Context
While the integration of the RIPE ATLAS API presents numerous benefits, it's important to acknowledge the complexity of this task. The API offers a wide array of functionalities, requiring careful consideration in its implementation. Furthermore, access to the RIPE ATLAS is contingent upon being a member of the RIPE community (for example by hosting a probe). This prerequisite adds another layer of complexity and exclusivity to the integration process. Consider these aspects to effectively evaluate the feasibility and resource allocation for this integration.
@CommanderStorm commented on GitHub (Nov 14, 2023):
Is this not already possible via the
json-querymonitor?https://atlas.ripe.net/docs/apis/rest-api-reference/#keys seems like it produces a json respnse
Note that our contribution guide is avaliable here:
github.com/louislam/uptime-kuma@014231ef86/CONTRIBUTING.md@ilogus commented on GitHub (Nov 15, 2023):
Hello, @CommanderStorm. Yes you're right the json-query can be a solution for some measurement (ping for example), but I find that elements of the site remain unused since it measures the metrics of the connection to the API instead of the data present in the response :
It could be something like this:
@TorsHammare commented on GitHub (Feb 2, 2024):
A big +1 on this, if we can integrate Atlas measurements that would mean we can immediately use +12000 probes worldwide with our UptimeKuma which is a HUGE added value, with very diverse geographical locations, etc.
@CommanderStorm commented on GitHub (Feb 2, 2024):
@TorsHammare Please refrain from posting
+1/ requests for updates things on issues, as this makes issue-management harder.Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.
@jimaek commented on GitHub (Apr 18, 2025):
FYI I'm biased as I'm the founder of a competing project https://globalping.io/ (also open source and community powered) but I believe that any RIPE Atlas functionality, even if built, would not be useful to the majority of Uptime Kuma users. It would require everyone to register and start an Atlas probe, wait for credits to accumulate and only then start using the new features. That's for a simple user, if there would be too many measurements happening the user would have to find where to host many additional probes to compensate for the additional credits use.
In case of Globalping, depending on the implementation, the user would simply need to login to the GP dashboard with their GitHub account and they will automatically get a free limit of 500 tests per hour, every hour.
You can even skip the above and use our 250 tests per hour per IP address limit for instant access to the network.
So the majority could instantly start using this new feature without any extra steps or waiting.
Active users could also start probes to generate passive credits, but could also donate as little as $1 to our GitHub Sponsors account to automatically get bonus credits (at Atlas that would be $5k minimum). With the money going to the further development of the project.
And of course we can offer as much support as needed to help you develop this! (e.g. we helped add GP into doggo)
API Docs https://globalping.io/docs/api.globalping.io
GitHub https://github.com/jsdelivr/globalping
@CommanderStorm commented on GitHub (Apr 18, 2025):
I am biased the other way, working in academia ^^
The base free tier that globalping are offering is actually supprisingly high and the insentive for setting up probes / buying credits seems supprisingly little.
Not unsustainable so, but rather measurements from server networks being a target instead of residential mesurements.
Actually, I don't fully care about pricing/credits or if people end up using it.
What I do think is an important part is anti-abuse for the people running the probes.
I assume that at lease a part of our users would end up running one.
Something where you have made differeent design chocies is that one can HTTP everything (except for malware according to https://github.com/jsdelivr/globalping/issues/2).
RIPE has back then chosen to not allow this anymore after the Ebonia-thing from https://labs.ripe.net/author/kistel/ethics-of-ripe-atlas-measurements/
We would at least have to warn users of the risk..
@ilogus commented on GitHub (Apr 19, 2025):
Hello !
With hindsight and your messages, I realize that a RIPE Atlas or GP implementation in Uptime Kuma would be overkill and I agree that most users would have little or no interest in it.
I don't know about everyone's use cases, but Uptime Kuma remains a self-hosted project, accessible to individuals and companies alike.
I think the best compromise is to be able to install several instances of uptime kuma connected to a main dashboard like the feature request #84
If you want we can close this discussion and wait for the addition of #84
@jimaek commented on GitHub (Apr 19, 2025):
We wanted to make the service as useful as possible for everyone without requiring registration. That includes the web tools and especially the CLI. In the future we might increase the credits rewards, it's something we're discussing.
Anti-abuse and security are very important for us. HTTP was important to support to allow use-cases such as testing downtime, checking redirects and overall performance of HTTP services like websites and CDNs. While HTTP is supported its limited by size and domains that can be used. We could expand that list of blocked domains too.
If the implementation idea changes to generic remote executors please let me know, cause I would still live to build an integration for people that would find Globalping based monitoring interesting!
@CommanderStorm commented on GitHub (Apr 19, 2025):
@ilogus sorry, I don't share that opinion.
Overkill for most - yes, likely.
Low usage? - maybe (we don't collect metrics)
Still a really powerful feature - yes
#84 has not had engineering behind it and I am unsure if it will. At least it is not on my list.
@CommanderStorm commented on GitHub (Apr 19, 2025):
@jimaek I think you misunderstood me.
I would love to have a globalping monitor too. Seems like a more powerful option.
On the implementation side, I am thinking of requiring the gh-login and having a credit explainer like
In terms of globalpings offered checks, I think ping, DNS and http are nice.
Unsure what additional things you would like or how others (globalping.io excluded) are integrating. Could you give a screenshot if you find others as particularly well implemented?
Especially interesting would be how they handle the out of credits case.
I am tentatively thinking down with a message indicicating that credits are insufficient.
Disclaimer:
My new semester starts Tuesday and my course load will be a lot, I might not have the time to implement this the next few weeks at least.
@TorsHammare commented on GitHub (Apr 20, 2025):
As someone involved in the Internet measurement community, I’m admittedly a bit biased — but I wanted to share my perspective and strong support for this proposal.
First off, I wasn’t aware of Globalping before and I must say it’s a very interesting and useful initiative. However, its current limitations to only four types of tests fall short for the kinds of diagnostics and measurements I need to perform. I do hope that more test types will be supported in the future. @jimaek
Now, regarding RIPE Atlas: I’m wholeheartedly in favor of integrating the RIPE Atlas API. I actively use both Uptime Kuma and RIPE Atlas in my work, and this integration would be incredibly valuable — particularly for the Internet measurement community.
From a practical standpoint, we often need to run network measurements from specific geographic regions to monitor censorship practices, detect network disruptions like Internet shutdowns, and study routing anomalies. Many of these measurements require hard-to-reach vantage points that RIPE Atlas already provides. Without Atlas, acquiring such reach would be extremely difficult or prohibitively expensive.
Beyond censorship monitoring, this integration would open doors for broader applications such as anycast verification, CDN performance monitoring, and other advanced diagnostics — all from diverse and globally distributed vantage points.
As for concerns around RIPE Atlas credits: most users who would be interested in using this integration are likely already part of the Atlas ecosystem and have credits (myself included). Additionally, the RIPE Atlas team has a history of supporting academic and open-source projects — so I believe it’s worth reaching out to them to request a credit donation for the Uptime Kuma project. This would help introduce new users to the Atlas platform and hopefully encourage them to contribute by hosting probes.
That said, even if no donation comes through, I’d personally be happy to donate 1,000,000,000 RIPE Atlas credits to the Uptime Kuma community. These can be distributed in small amounts to users who want to try it out. Once they’re familiar with the platform, many may choose to set up their own probe — which is incredibly easy and a great way to give back to the ecosystem.
@jimaek commented on GitHub (Apr 20, 2025):
@CommanderStorm
It really depends on the UI so everyone implements it differently but so far the underlying logic has been the same, on 429 code check the message and display it to the user.
A better flow would be to check the
X-RateLimit-RemainingandX-Credits-RemainingHTTP headers of every API response and pro-actively warn the user about low limits.And an even better one would be to calculate on the Uptime Kuma side the expected usage of monitor and compare to the user's available limit
/v1/limitsto warn that they will hit the limit before even creating the monitor.@TorsHammare
We support the main 5 measurement types, ping, traceroute, http(with TLS baked in), dns, mtr.
If we're missing something important please let me know.
You are correct, Atlas users are very generous and happily donate if someone asks. But this also means that Uptime Kuma users would have to spam the mailing list in mass to ask for credits just to get started. Or Uptime Kuma would have to hardcode an API key for all users to share, which would most likely be abused quite quickly.
To me it just doesn't feel like a good experience for anyone involved.
As a long time Atlas user, I just wanted to point that out, since it was one of the biggest issues that I wanted to fix with Globalping :)
@TorsHammare commented on GitHub (Apr 20, 2025):
Of course, I completely agree — an Atlas API key should never be hardcoded or shared publicly. And I also recognize that manual credit distribution would be chaotic and unscalable. What I had in mind was something more automated and seamless.
Just brainstorming here: perhaps each Uptime Kuma instance could be assigned a unique, fixed identifier within the RIPE Atlas tab. Users could then visit a designated web page where they’d input that ID to redeem a small, pre-allocated amount of RIPE Atlas credits, which would be transferred directly to their own RIPE account. From there, they'd generate their own API key and plug it into Uptime Kuma for measurements.
This approach would serve as an introductory trial — giving users a chance to explore Atlas and see if it fits their needs. If they find it valuable, they can always go the next step and host a probe, which is quite straightforward for anyone even slightly technical.
Also, just wanted to say — I really like the idea of integrating Globalping too. It looks like a promising initiative, @jimaek, and I’ll definitely be following the project closely!
@CommanderStorm commented on GitHub (Apr 20, 2025):
Treceroute and mtr is not something where I see the need for an uptime monitor.
What would we check with that?
Likely a different design would be necessary to check things.
I see the usecases for these in doing analytics or one time measurements.
@TorsHammare commented on GitHub (Apr 20, 2025):
@CommanderStorm Traceroute and MTR could be used in monitoring route changes. Which is important in some scenarios. Just "down" or "up" is not enough if you run a sophisticated infra.
@CommanderStorm commented on GitHub (Apr 20, 2025):
Value changed is not something we can currently monitor for.
@ilogus commented on GitHub (Apr 23, 2025):
Okay, I understand your point of view, let's keep the issue open