Це репозиторій з вихідним кодом Uptime Monitor monitoring server. Готовий продукт деплоїться в: https://github.com/ajjs1ajjs/Uptime-Monitor Офіційний сайт: https://ajjs1ajjs.github.io/Uptime-Monitor/
Enterprise uptime & SSL monitoring — перевірка доступності сайтів, сервісів і SSL-сертифікатів з багатоканальними сповіщеннями, SLA-звітами та публічною сторінкою статусу.
| 🔍 5 типів перевірок | HTTP/HTTPS, TCP/Port, Ping, DNS та SSL — з інтервалами від 5 с | |
| 🔐 SSL-моніторинг | Контроль строку дії сертифікатів, пороги 30/14/7/5/3/1 день | |
| 📢 10+ каналів сповіщень | Telegram, Discord, Slack, MS Teams, Email/SMTP, SMS/Twilio, Webhook, Pushover, Gotify, ntfy | |
| 📊 Публічна сторінка статусу | /status без автентифікації, PWA — встановлюється на телефон |
|
| 📈 Інциденти та uptime % | Історія перевірок і відсоток аптайму за будь-який період | |
| 📄 SLA-звіти | Експорт у JSON, CSV та HTML-PDF | |
| 🔒 Безпека | Ролі admin/viewer, API-ключі, CSRF, rate-limit, SSRF-guard | |
| 🗂️ Обслуговування | Maintenance windows, бекапи та відновлення БД |
| Дашборд | Публічна сторінка статусу |
|---|---|
![]() |
![]() |
| Вхід | |
|---|---|
![]() |
Дашборд зображено з демо-даними;
/status— з робочої інсталяції.
Ubuntu / Debian (одна команда і встановлює, і оновлює):
curl -sSL https://raw.githubusercontent.com/ajjs1ajjs/Uptime-Monitor/main/install.sh | sudo bashОдна команда і встановлює, і оновлює. При оновленні зберігаються конфіг, БД, користувачі та паролі; замінюється лише бінарник (попередній лишається як
.old). Бінарники доступні для Linux (amd64/arm64).
go build -o uptime-monitor ./cmd/uptime-monitor
./uptime-monitor server --port 8080При першому встановленні скрипт друкує логін/пароль прямо у висновку:
====================================
Логін: admin
Пароль: <згенерований>
====================================
- Пароль також зберігається одноразово у
/var/lib/uptime-monitor/admin_password.txt - При вході система попросить змінити пароль перед використанням
Втратили пароль:
sudo UPTIME_MONITOR_ADMIN_PASSWORD='YourStrongPass123' /opt/uptime-monitor/uptime-monitor reset-admin --config /etc/uptime-monitor/config.json
sudo systemctl restart uptime-monitor| Тип | Що перевіряє | Приклад |
|---|---|---|
http / https |
Відповідь сервера, статус-код, ключове слово | https://example.com |
port / tcp |
Доступність TCP-порту | example.com:443 |
ping |
ICMP-відповідь | 1.1.1.1 |
dns |
Резолвінг DNS | google.com |
ssl |
Строк дії сертифіката | https://example.com |
Telegram · Discord · Slack · MS Teams · Email/SMTP · SMS/Twilio · Webhook · Pushover · Gotify · ntfy
Кожен канал налаштовується через дашборд; секрети каналів шифруються (AES-GCM).
sudo systemctl start|stop|restart|status uptime-monitor
# Оновлення = та сама команда встановлення
curl -sSL https://raw.githubusercontent.com/ajjs1ajjs/Uptime-Monitor/main/install.sh | sudo bash
# Службові
uptime-monitor server [--port 8080] [--config PATH]
uptime-monitor reset-admin [--config PATH]
uptime-monitor has-admin [--config PATH]
uptime-monitor restore --backup FILENAME
uptime-monitor drill [flood|chaos|failover|all] # локальні навантажувальні/відмовні прогониДві копії сервісу можуть працювати над однією базою: лідер обирається через
рядок leader_lock з heartbeat (TTL 45 с, heartbeat 15 с). Лідер виконує
перевірки та фонові задачі; standby віддає лише читання, а на зміни відповідає
409 з підказкою X-Leader. Поточний стан видно в /health та /health/ready.
Лідерство — це lease, а не прапорець: нода вважає себе лідером лише поки перебуває в TTL-вікні, яке вона реально продовжила в базі. Якщо база тимчасово не відповідає, lease не продовжується — нода доживає поточне вікно і знімає з себе лідерство.
⚠️ Обмеження. «Спільна база» означає базу, яку обидві ноди справді можуть блокувати. Із вбудованим SQLite це один хост (два процеси на одній файловій системі), а не файл на NFS/CIFS: мережеві ФС не дають надійного POSIX-блокування, а саме на ньому тримається рядок лідера. Fencing поки операторський (STONITH); вікно split-brain обмежене розбіжністю годинників між нодами плюс TTL.Ліміти запитів (окрім логіну та відновлення пароля, які рахуються в базі) рахуються в пам'яті кожного процесу окремо, тому для дешевих ендпойнтів фактичний ліміт у парі —
ноди × max.
Конфіг — у config.json (Linux: /etc/uptime-monitor/config.json):
{
"server": { "port": 8080, "host": "0.0.0.0" },
"data_dir": "/var/lib/uptime-monitor",
"log_dir": "/var/log/uptime-monitor",
"check_interval": 60,
"alert_policy": {
"request_timeout_seconds": 15,
"grace_period_seconds": 0,
"up_success_threshold": 3,
"still_down_repeat_seconds": 600,
"treat_4xx_as_down": true,
"verify_ssl": true,
"ssl_notification_days": [30, 14, 7, 5, 3, 1],
"ssl_check_interval_hours": 6,
"retry_delays": [10, 10, 10, 10, 10],
"max_retries": 5
}
}- Пароль адміна генерується при першій інсталяції і показується лише раз; зберігається bcrypt-хеш
- Ролі: viewer — тільки читання; admin — керування
- CSRF: same-origin перевірка для cookie-авторизованих змін API; API-ключі звільнені
- Rate-limit: логін 5/15хв, публічна сторінка 30/60с
- SSRF-guard при створенні сайтів (заборона loopback/link-local/metadata)
- Секрети каналів сповіщень шифруються (AES-GCM, ключ
master.keyпоруч із конфігом)
Бекенд: Go 1.26.6 · net/http · SQLite (WAL, modernc.org/sqlite) · gorilla/websocket · pongo2 (Jinja2-шаблони) · golang.org/x/crypto
Фронтенд: Vanilla JS · Tailwind · PWA · WebSocket (embedded через go:embed)
cmd/uptime-monitor # CLI: server, reset-admin, has-admin, restore
internal/api # HTTP API, middleware, WebSocket, UI-шаблони
internal/auth # bcrypt, сесії, API-ключі, rate-limit
internal/config # конфігурація сервера
internal/monitor # воркер перевірок (http/tcp/ping/dns/ssl)
internal/netguard # захист від SSRF/DNS-rebinding
internal/notify # канали сповіщень (10+)
internal/storage # SQLite: сайти, історія, сесії, аудит
MIT © ajjs1ajjs


