Allowing ping/dns/http calls via RIPE ATLAS for distributed network monitoring

[ilogus]

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

• I checked and didn't find similar feature request

🏷️ 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]

Is this not already possible via the json-query monitor?
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: https://github.com/louislam/uptime-kuma/blob/014231ef86e13adb62bc78002d40202b5cbe2b5b/CONTRIBUTING.md

[ilogus]

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]

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.