123 أسطر
5.1 KiB
Markdown
123 أسطر
5.1 KiB
Markdown
# Uptime Kuma POC — Monitoring & Alerting on Ghaymah Cloud
|
|
|
|
## Goal
|
|
|
|
Deploy Uptime Kuma as a containerized app on Ghaymah Cloud, prove out
|
|
HTTP monitoring + Telegram alerting, and expose a public status page —
|
|
without building a monitoring system from scratch.
|
|
|
|
## Architecture
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
Internet((🌍 Internet))
|
|
|
|
subgraph GhaymahCloud ["☁️ Ghaymah Cloud Environment"]
|
|
direction LR
|
|
UK["🚀 Uptime Kuma<br/>(Port: 3001)"]
|
|
DemoWeb["🌐 demo-web-server<br/>(NGINX :80)"]
|
|
end
|
|
|
|
Internet --> UK
|
|
Internet --> DemoWeb
|
|
|
|
UK -- "HTTP Check<br/>(Every 60s)" --> DemoWeb
|
|
UK -. "Alert on Down/Up" .-> Telegram{"📱 Telegram Channel"}
|
|
UK -. "Exposes" .-> PublicPage(["📊 Public Status Page"])
|
|
|
|
style Internet fill:#f9f9f9,stroke:#333,stroke-width:2px;
|
|
style Telegram fill:#2CA5E0,stroke:#fff,stroke-width:2px,color:#fff;
|
|
style PublicPage fill:#4CAF50,stroke:#fff,stroke-width:2px,color:#fff;
|
|
classDef cloud fill:#f0f8ff,stroke:#4a90e2,stroke-width:2px,stroke-dasharray: 5 5;
|
|
classDef container fill:#ffffff,stroke:#333333,stroke-width:1px,shadow:true;
|
|
class GhaymahCloud cloud;
|
|
class UK,DemoWeb container;
|
|
```
|
|
|
|
## What was deployed
|
|
|
|
| App | Image | Port | Instances | Volume |
|
|
|--------------------|----------------------------|------|-----------|--------------|
|
|
| `uptime-kuma` | `louislam/uptime-kuma:2` | 3001 | 1 | `/app/data` |
|
|
| `demo-web-server` | `nginx` | 80 | 1 | none |
|
|
|
|
Both run as single-instance Ghaymah Apps. Uptime Kuma is intentionally
|
|
kept at **1 instance** — it stores its data in a local SQLite database,
|
|
so scaling it out would split monitor history across separate,
|
|
inconsistent instances.
|
|
|
|
`demo-web-server` (plain nginx) was added as a self-owned target to
|
|
monitor, so the POC watches infrastructure we actually control rather
|
|
than a third-party test endpoint.
|
|
|
|
## Monitoring setup
|
|
|
|
- **Monitor:** `test app`
|
|
- **Type:** HTTP(s)
|
|
- **Target:** `https://demo-web-server-web-9b9b121d.hosted.cumin.dev/`
|
|
- **Check interval:** every 60 seconds
|
|
- **Retries:** 0 (flags Down immediately — good for fast POC testing)
|
|
- **Timeout:** 48 seconds
|
|
|
|
During setup the monitor was pointed first at `httpstat.us/200` (found
|
|
unstable, frequent 502s) and then `httpbin.org/status/200` for
|
|
stability testing, before finally being switched to the team's own
|
|
nginx instance.
|
|
|
|
## Alerting
|
|
|
|
- **Channel:** Telegram
|
|
- Created via `@BotFather`, bot token and chat ID configured as an
|
|
Uptime Kuma notification, linked to the `test app` monitor.
|
|
- **Tested:** forced a Down state (pointed the monitor at an endpoint
|
|
returning HTTP 502) and confirmed a Telegram alert arrived; then
|
|
restored a healthy endpoint and confirmed the recovery (Up) alert
|
|
arrived as well.
|
|
|
|
## Public Status Page
|
|
|
|
- **URL:** https://uptime-kuma-web-3aa83c30.hosted.cumin.dev/status/ghaymah-status
|
|
- **Access:** public, no login required
|
|
- Shows overall status ("All Systems Operational"), the `test app`
|
|
monitor grouped under **Services**, its uptime percentage, and a
|
|
recent heartbeat history bar.
|
|
|
|
## Data persistence
|
|
|
|
Uptime Kuma stores its SQLite database and configuration under
|
|
`/app/data` inside the container, which is mounted to a persistent
|
|
Ghaymah volume. Restarting or redeploying the container does not lose
|
|
monitors, notification settings, or status page configuration.
|
|
|
|
## Export / configuration snapshot
|
|
|
|
This Uptime Kuma version (2.5.4) does not currently expose a
|
|
Settings > Backup/Export screen, so `uptime-kuma-config-export.json`
|
|
in this folder was assembled by hand from the live dashboard to
|
|
document every setting used in this POC (monitor config, notification
|
|
setup, status page config, deployment parameters). Secrets (bot
|
|
token, chat ID) are intentionally redacted from that file.
|
|
|
|
## How to verify it yourself
|
|
|
|
1. Open the [status page](https://uptime-kuma-web-3aa83c30.hosted.cumin.dev/status/ghaymah-status) — no login needed.
|
|
2. To test alerting: edit the `test app` monitor's URL to point at any
|
|
endpoint that returns a non-2xx status, save, and wait up to 60
|
|
seconds for the next heartbeat. A Down alert should arrive on
|
|
Telegram. Point it back at a healthy URL to see the Up recovery
|
|
alert.
|
|
|
|
## Security & Data Resilience
|
|
|
|
- **Independent Health Tracking:** The Uptime Kuma stack functions as an independent observer. The persistence layer retains the complete outage and metrics history inside an isolated volume.
|
|
- **Failover Alerts Validation:** Explicitly validated notification webhooks logic to verify immediate alerting upon HTTP failures and automatic recovery resolution (Up events).
|
|
- **Persistent Storage Configuration:** Critical settings (like SQLite DB, configurations) are safely coupled to `/app/data` volume mount to circumvent ephemeral container cycles.
|
|
|
|
## Next steps (not yet done)
|
|
|
|
- Put Uptime Kuma behind a custom domain / HTTPS via reverse proxy
|
|
(Ghaymah already terminates HTTPS on its own subdomains, so this is
|
|
optional for the POC).
|
|
- Consider Telegram bot token rotation before handing this off, since
|
|
the token was shared in a chat during setup.
|