Uptime-Kuma

Uptime Kuma - небольшая и простая система мониторинга ресурсов, сервисов, игровых серверов. Поддерживает ответы кодов HTTP, ответы JSON, позволяет мониторить Docker-сервисы. Так же есть поддержка мониторинга игровых серверов в Steam. Не требует особых навыков и пердолинга мониторинга как в Zabbix. Если необходимо организовать публичную страницу для пользователей и отправку в Telegram уведомлений о сбое - неплохая штука.

Установка в Docker-Compose

Note

Подразумевается что у нас уже установлен Docker и Docker-Compose, если нет - Читаем это

Создадим произвольную папку, пусть это будет uptime-kuma, далее создаем docker-compose.yaml с содержимым:

version: "3.8"

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"  # Маппим порт 3001 на порт хоста 3001. Если нужно чтобы браузер отзывался на 80 порт, то меняем на "80:3001"
    volumes:
      - ./data:/app/data  # Папка в котором будут храниться логи и конфигурация. Создастся автоматически
    environment:
      - TZ=UTC  # Обозначаем таймзону
      - UMASK=0022  # Права на файлы
    networks:
      - kuma_network  # Обозначаем имя сети (может быть любым)
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001"]
      interval: 30s
      retries: 3
      start_period: 10s
      timeout: 5s
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

networks:
  kuma_network:
    driver: bridge

Запускаем через docker-compose up -d. Если у вас стоит docker-compose v2, то docker compose up -d

Мониторим сервис по JSON

К примеру, есть радиостанция на базе Icecast. Icecast предоставляет возможность выводить json статус вещания, к примеру:

{
  "station": {
    "id": 1,
    "name": "SCUF FM",
    "shortcode": "scuf_fm",
    "description": "Я просто хочу отдохнуть от трудовых будней",
    "frontend": "icecast"
  }
   "is_online": true,
}

Будем мониторить наличие "true" в параметре "is_online". Если слово будет отличаться или изчезнет, то мониторинг вернет ошибку. Таким образом создаем новый монитор, где:

  • Monitor Type: HTTP(s) - Json Query
  • Friendly Name: Любое
  • URL: https://your-service.com/api/station
  • Json query: is_online
  • Expected Value: true
  • Heartbeat Interval: 60 (Или 120. В секундах)
  • Request Timeout: 48 (Достаточно, можно меньше или больше, в секундах)

В разделе HTTP Options:

  • Method: GET
  • Body Encoding: JSON

В разделе Advanced:

  • Accepted Status Codes: 200-299

Опционально - Description и Monitor Groups на свой вкус, если необходимо обьединить сервисы общей сущностью. Сохраняем:

Note

Если healtcheck сервиса производится средствами ping (icmp) то пинг у него меньше чем запрос и обработка JSON/HTML, потому как суммируется время получения и обработки данных. Так же следует обратить внимание, если удаленный сервер блокирует частое обращение к HTML/JSON, то предусмотрите вайтлист IP-сервиса мониторинга или увеличьте частоту опроса healthcheck. В моем случае раз в несколько запросов я получал ошибку timeout of 48000ms exceeded.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9