Add uptime stats of the portal itself to the Dashboard

[SebastianOpriel]

As Uptime Kuma is used as a separate service, the dashboard shall show its own historic uptime. It shall also be added to the CSV Report.

[kamilczaja]

Not trivial. We need to check whether Uptime Kuma already monitors the AP. If not, we need to figure out which component to perform health checks on - backend? frontend? both combined?

[kamilczaja]

Feasibility analysis

Currently, there is no feasible way to display the Portal uptime consistently and correctly in the portal itself.
The components are monitored by an Uptime Kuma instance which reports only the current online status. The portal gathers and saves the data to calculate the components' uptime.

Problem

The portal cannot fetch the online status from Uptime Kuma when the portal itself is offline. Thus, it cannot save the data and it cannot calculate the uptime. Uptime Kuma unfortunately does not provide any historical data to its external API, so this is not an option either.

Possible solution 1 (not recommended)

Create a completely new service that is deployed independently. This service would take over the portal's current uptime calculation methods and provide historical data via an API. The portal could just fetch the ready-to-display data and display it on the Dashboard.
Needless to say, this approach would be silly due to increased complexity, dependencies and hosting costs.

Possible solution 2

Instead of Uptime Kuma, a better service like Prometheus could be used for uptime monitoring, that would provide historical data to the portal. This would enable the portal to just display the data instead of needing to calculate component uptime by itself. This solves the issue with the portal needing to monitor its own uptime.

Possible solution 3 (recommended)

Disregard this idea as it requires too much work for close to zero benefit.

Summary

Regardless of the approach chosen, completion of this task is dependent on the operator providing us with solid historical uptime data. A component cannot monitor itself.

@AbdullahMuk @jkbquabeck

[AbdullahMuk]

Planned for implementation for milestone "AP White Label - Product Iteration 2".

[SebastianOpriel]

Uptime Kuma unfortunately does not provide any historical data to its external API, so this is not an option either.

Might this help? https://github.com/MedAziz11/Uptime-Kuma-Web-API

[kamilczaja]

Uptime Kuma unfortunately does not provide any historical data to its external API, so this is not an option either.

Might this help? https://github.com/MedAziz11/Uptime-Kuma-Web-API

Unfortunately we do not control the external Uptime Kuma instance that is hosted by Orbiter. I also don't think we intend to use this service in the future on our sides and will most probably adjust the AP to be compatible with more widespread and potent Uptime monitoring services

[SebastianOpriel]

Okay, let's follow best practice approaches. What do you think about:

• Implement a ENV-Var switch to toggle between the current and an optimized version.
• Optimized version will simply deactivate the Dashboard and add a "Status" link to the footer. Like here:
  
  This allows to implement a proper Status page with desired tooling.

[AbdullahMuk]

@kamilczaja aligned with @SebastianOpriel , @yylian that we will not tackle it in Q4/2024.