Мониторинг WordPress: Uptime Kuma, Grafana и Алерты в Telegram (2026)

Знаете это чувство? Звонит клиент. Говорит: «Сайт не открывается». Вы проверяете — действительно, 502 ошибка. Пока разбирались, пока чинили, прошло 40 минут. Клиент уже написал в соцсети, что ваш сайт «вечно лежит». Репутация — в минус.

А ведь можно было узнать о проблеме через 30 секунд после её возникновения. Получить алерт в Telegram. Открыть ноутбук. Починить. Клиент даже не успел бы заметить.

Разница между этими двумя сценариями — одна: мониторинг. Не «какой-нибудь плагин для аптайма», а полноценная система observability, которая видит всё: доступность сайта, скорость ответа, нагрузку на сервер, состояние базы данных, срок действия SSL-сертификата.

Сегодня построим такую систему с нуля. Бесплатно. На своём сервере. Без зависимости от сторонних сервисов, которые могут закрыться или поднять цены.

Что вообще нужно мониторить

Прежде чем ставить инструменты, давайте определимся, что именно мы хотим видеть. Мониторинг WordPress — это не одна метрика. Это четыре слоя.

Слой 1: Доступность (Uptime)

Самое базовое. Отвечает ли сайт? Какой код возвращает? Сколько времени отвечает? Если сайт лежит — вы должны узнать об этом первыми, а не от клиентов.

Слой 2: Производительность (Performance)

Сайт может быть доступен, но тормозить. TTFB выше 800 мс, LCP больше 2.5 секунд, CLS скачет. Google это видит. Пользователи тоже. Но без мониторинга вы об этом не узнаете, пока не проверите PageSpeed вручную.

Слой 3: Ресурсы сервера (Infrastructure)

CPU, RAM, диск, сеть. Если PHP-FPM съедает всю память — сайт начнёт падать с 502 ошибкой (мы разбирали это в статье про 502). Если диск забьётся логами — перестанут писаться новые данные. Если MySQL упрётся в лимит подключений — база встанет.

Слой 4: Бизнес-метрики (Application)

Для WooCommerce это количество заказов в час, брошенные корзины, время оформления заказа. Для блога — количество комментариев, время генерации страницы. Эти метрики говорят о здоровье бизнеса, а не только о здоровье сервера.

Сегодня настроим все четыре слоя. Начнём с самого простого — проверки доступности.

Uptime Kuma: ваш личный сторожевой пёс

Помните, как мы упоминали Uptime Kuma в статье про бэкапы? Тогда это был просто способ проверить, работает ли сайт. Теперь поговорим о нём серьёзно.

Uptime Kuma — это self-hosted инструмент мониторинга. Красивый интерфейс, поддержка HTTP(S), TCP, DNS, push-мониторинга, SSL-сертификатов. И главное — он бесплатный, с открытым кодом, и работает на вашем сервере.

Установка через Docker (рекомендуется)

Самый чистый способ — через Docker. Создаём папку и запускаем:

mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma

# Создаём docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.8'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
EOF

# Запускаем
docker-compose up -d

Через минуту Uptime Kuma доступен по адресу http://your-server:3001. Открываем, создаём администратора, и можно добавлять мониторы.

Установка без Docker (для shared-хостинга)

Если Docker недоступен, ставим напрямую:

# Установка Node.js 18+
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs

# Клонируем Uptime Kuma
git clone https://github.com/louislam/uptime-kuma.git
cd uptime-kuma
npm run setup

# Запускаем
node server/server.js

Для автозапуска через systemd создаём сервис:

sudo nano /etc/systemd/system/uptime-kuma.service

Содержимое:

[Unit]
Description=Uptime Kuma
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/uptime-kuma
ExecStart=/usr/bin/node server/server.js
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Активируем:

sudo systemctl daemon-reload
sudo systemctl enable uptime-kuma
sudo systemctl start uptime-kuma

Настройка мониторов для WordPress

Теперь добавим мониторы. В Uptime Kuma жмём «Add New Monitor» и создаём несколько проверок.

Монитор 1: Главная страница (HTTP)

Тип: HTTP(s)
URL: https://custom-code.ru/
Интервал: 60 секунд
Expected HTTP Status: 200
Heartbeat Interval: 60
Retries: 3

Это базовая проверка. Если сайт вернёт не 200 — получите алерт.

Монитор 2: Админка WordPress

Тип: HTTP(s)
URL: https://custom-code.ru/wp-login.php
Expected HTTP Status: 200
Интервал: 300 секунд (5 минут)

Если админка недоступна — вы не сможете войти и что-то исправить. Лучше узнать об этом сразу.

Монитор 3: TTFB (время ответа сервера)

Uptime Kuma показывает время ответа, но не даёт алертов по нему напрямую. Поэтому создаём отдельный скрипт-проверку.

Создаём файл /opt/uptime-kuma/check-ttfb.sh:

#!/bin/bash

URL="https://custom-code.ru/"
MAX_TTFB=800  # Максимальный TTFB в мс

# Делаем запрос и получаем время до первого байта
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' "$URL" | awk '{printf "%.0f", $1 * 1000}')

if [ "$TTFB" -gt "$MAX_TTFB" ]; then
    echo "TTFB too high: ${TTFB}ms (max: ${MAX_TTFB}ms)"
    exit 1
else
    echo "TTFB OK: ${TTFB}ms"
    exit 0
fi

Делаем исполняемым:

chmod +x /opt/uptime-kuma/check-ttfb.sh

В Uptime Kuma добавляем монитор типа «Push» и вызываем этот скрипт через cron каждые 5 минут.

Монитор 4: SSL-сертификат

Uptime Kuma умеет проверять срок действия SSL. Добавляем монитор:

Тип: HTTP(s)
URL: https://custom-code.ru/
Включаем: «Ignore TLS/SSL errors» — нет, наоборот, проверяем сертификат
Max Redirects: 0

Uptime Kuma автоматически отправит алерт за 14 дней до истечения сертификата. Больше никаких просроченных SSL.

Монитор 5: База данных (MySQL)

Если база недоступна — сайт падает. Добавляем TCP-монитор:

Тип: TCP Port
Host: localhost
Port: 3306
Интервал: 60 секунд

Если MySQL упадёт — узнаете через минуту.

Монитор 6: Redis

Аналогично для Redis:

Тип: TCP Port
Host: localhost
Port: 6379

Алерты в Telegram: чтобы не пропустить

Мониторинг без алертов — это просто красивые графики, на которые никто не смотрит. Настоящая ценность — в мгновенных уведомлениях.

Создаём Telegram-бота

Открываем в Telegram @BotFather
Отправляем /newbot
Придумываем имя и username
Получаем токен вида 123456789:ABCdefGHIjklMNOpqrsTUVwxyz

Получаем chat_id

Пишем что-нибудь нашему боту, потом открываем:

curl https://api.telegram.org/bot/getUpdates

В ответе ищем "chat":{"id":123456789} — это ваш chat_id.

Настраиваем в Uptime Kuma

Идём в Settings → Notifications → Add New Notification → Telegram. Заполняем:

Bot Token: ваш токен
Chat ID: ваш chat_id

Жмём «Test» — должно прийти тестовое сообщение. Если пришло — сохраняем и применяем ко всем мониторам.

Что приходит в алерте:

🔴 [DOWN] Custom Code - Main Page
Time (UTC): 2026-06-21 14:30:00
Type: HTTP(s)
https://custom-code.ru/
Error: connect ECONNREFUSED 127.0.0.1:443

А когда сайт восстановится:

✅ [UP] Custom Code - Main Page
Time (UTC): 2026-06-21 14:32:00
Type: HTTP(s)
https://custom-code.ru/

Prometheus + Grafana: мониторинг ресурсов сервера

Uptime Kuma отлично проверяет доступность. Но он не показывает, что происходит внутри сервера. Для этого нужен Prometheus (собирает метрики) и Grafana (рисует красивые графики).

Установка через Docker Compose

Создаём папку /opt/monitoring и добавляем в docker-compose.yml:

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|container)($$|/)'
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=your_password_here
    restart: unless-stopped

volumes:
  prometheus-data:
  grafana-data:

Конфигурация Prometheus

Создаём prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  # Метрики сервера
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

  # Метрики Nginx (если установлен nginx-prometheus-exporter)
  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']

  # Метрики MySQL
  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

Устанавливаем экспортеры

Для Nginx:

docker run -d --name nginx-exporter \
  -p 9113:9113 \
  nginx/nginx-prometheus-exporter:latest \
  -nginx.scrape-uri=http://localhost:8080/stub_status

Для MySQL:

docker run -d --name mysql-exporter \
  -p 9104:9104 \
  -e DATA_SOURCE_NAME="wordpress_user:password@(localhost:3306)/" \
  prom/mysqld-exporter

Открываем Grafana

Заходим на http://your-server:3000. Логин: admin, пароль: тот, что указали в docker-compose.yml.

Добавляем Prometheus как Data Source:

Configuration → Data Sources → Add data source
Выбираем Prometheus
URL: http://prometheus:9090
Save & Test

Импортируем готовые дашборды

В Grafana тысячи готовых дашбордов. Импортируем самые полезные:

Node Exporter Full: ID 1860 — метрики сервера (CPU, RAM, диск, сеть)
Nginx: ID 12621 — метрики веб-сервера
MySQL Overview: ID 7362 — метрики базы данных

Импорт: Dashboards → Import → вводим ID → выбираем Prometheus → Import.

Мониторинг Core Web Vitals

Доступность и ресурсы — это хорошо. Но что с производительностью с точки зрения пользователя? Здесь на помощь приходит CrUX API от Google.

Скрипт для проверки CWV

Создаём /opt/monitoring/check-cwv.sh:

#!/bin/bash

URL="https://custom-code.ru/"
API_KEY="your_google_api_key"

# Запрос к CrUX API
RESPONSE=$(curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?url=$URL&key=$API_KEY")

# Парсим метрики
LCP=$(echo $RESPONSE | jq -r '.record.metrics.largest_contentful_paint.percentile')
INP=$(echo $RESPONSE | jq -r '.record.metrics.interaction_to_next_paint.percentile')
CLS=$(echo $RESPONSE | jq -r '.record.metrics.cumulative_layout_shift.percentile')

# Конвертируем в нормальные единицы
LCP_SEC=$(echo "scale=2; $LCP / 1000" | bc)
CLS_FIXED=$(echo "scale=3; $CLS / 100" | bc)

echo "LCP: ${LCP_SEC}s | INP: ${INP}ms | CLS: $CLS_FIXED"

# Алерт, если метрики плохие
if [ "$LCP" -gt 2500 ] || [ "$INP" -gt 200 ] || [ "$CLS" -gt 10 ]; then
    curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="⚠️ Core Web Vitals Alert for $URL:
LCP: ${LCP_SEC}s (target: < 2.5s)
INP: ${INP}ms (target: < 200ms)
CLS: $CLS_FIXED (target: < 0.1)"
fi

Получить Google API Key можно в Google Cloud Console. CrUX API бесплатный до 25 000 запросов в день.

Добавляем в cron:

# Каждый день в 12:00
0 12 * * * /opt/monitoring/check-cwv.sh

Мониторинг PHP-FPM

PHP-FPM — это сердце WordPress. Если он тормозит или переполнен — сайт падает. Настроим мониторинг его статуса.

Включаем status page

В конфиге пула PHP-FPM (/etc/php/8.2/fpm/pool.d/www.conf) раскомментируем:

pm.status_path = /status
ping.path = /ping

В конфиге Nginx добавляем:

location ~ ^/(status|ping)$ {
    access_log off;
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

Перезагружаем:

sudo systemctl reload php8.2-fpm
sudo systemctl reload nginx

Скрипт мониторинга PHP-FPM

Создаём /opt/monitoring/check-php-fpm.sh:

#!/bin/bash

STATUS_URL="http://127.0.0.1/status?json"
MAX_ACTIVE=40  # Максимум активных процессов

# Получаем статус
RESPONSE=$(curl -s "$STATUS_URL")

# Парсим метрики
ACTIVE=$(echo $RESPONSE | jq -r '.["active processes"]')
IDLE=$(echo $RESPONSE | jq -r '.["idle processes"]')
TOTAL=$(echo $RESPONSE | jq -r '.["total processes"]')
MAX_CHILDREN=$(echo $RESPONSE | jq -r '.["max children reached"]')
SLOW_REQ=$(echo $RESPONSE | jq -r '.["slow requests"]')

echo "Active: $ACTIVE | Idle: $IDLE | Total: $TOTAL | Max reached: $MAX_CHILDREN | Slow: $SLOW_REQ"

# Алерт, если слишком много активных процессов
if [ "$ACTIVE" -gt "$MAX_ACTIVE" ]; then
    curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="⚠️ PHP-FPM Alert:
Active processes: $ACTIVE (max: $MAX_ACTIVE)
Total processes: $TOTAL
Slow requests: $SLOW_REQ
Max children reached: $MAX_CHILDREN"
fi

# Алерт, если есть медленные запросы
if [ "$SLOW_REQ" -gt 10 ]; then
    curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="⚠️ PHP-FPM: $SLOW_REQ slow requests detected. Check slow.log"

Добавляем в cron (каждые 5 минут):

*/5 * * * * /opt/monitoring/check-php-fpm.sh

Мониторинг дискового пространства

Одна из самых частых причин падений — забитый диск. Логи, кэш, бэкапы — всё это растёт со временем.

Скрипт проверки диска

Создаём /opt/monitoring/check-disk.sh:

#!/bin/bash

THRESHOLD=85 # Порог в процентах

# Проверяем все смонтированные файловые системы
df -h | awk 'NR>1 {print $5 " " $6}' | while read usage mount; do
percent=${usage%\%}
if [ "$percent" -gt "$THRESHOLD" ]; then
curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" \
-d text="⚠️ Disk Alert: $mount is ${usage} full"
fi
done

Добавляем в cron (каждые 15 минут):

*/15 * * * * /opt/monitoring/check-disk.sh

Централизованный скрипт алертов

Чтобы не плодить кучу скриптов, соберём всё в один. Создаём /opt/monitoring/monitor-all.sh:

#!/bin/bash

# Конфигурация
BOT_TOKEN="your_bot_token"
CHAT_ID="your_chat_id"
SITE_URL="https://custom-code.ru"
MAX_TTFB=800

# Функция отправки в Telegram
send_alert() {
curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" \
-d parse_mode="HTML" \
-d text="$1"
}

# 1. Проверка доступности
HTTP_CODE=$(curl -o /dev/null -s -w '%{http_code}' "$SITE_URL")
if [ "$HTTP_CODE" != "200" ]; then
send_alert "🔴 Site DOWN
URL: $SITE_URL
HTTP Code: $HTTP_CODE"
fi

# 2. Проверка TTFB
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' "$SITE_URL" | awk '{printf "%.0f", $1 * 1000}')
if [ "$TTFB" -gt "$MAX_TTFB" ]; then
send_alert "⚠️ Slow Response
URL: $SITE_URL
TTFB: ${TTFB}ms (max: ${MAX_TTFB}ms)"
fi

# 3. Проверка SSL
DAYS_LEFT=$(echo | openssl s_client -connect custom-code.ru:443 -servername custom-code.ru 2>/dev/null | openssl x509 -noout -enddate | awk -F= '{print $2}' | xargs -I {} date -d {} +%s)
NOW=$(date +%s)
DAYS=$(( (DAYS_LEFT - NOW) / 86400 ))
if [ "$DAYS" -lt 14 ]; then
send_alert "⚠️ SSL Expiring
Domain: custom-code.ru
Days left: $DAYS"
fi

# 4. Проверка PHP-FPM
ACTIVE=$(curl -s "http://127.0.0.1/status?json" | jq -r '.["active processes"]')
if [ "$ACTIVE" -gt 40 ]; then
send_alert "⚠️ PHP-FPM Overloaded
Active processes: $ACTIVE"
fi

# 5. Проверка MySQL
if ! mysqladmin -u wordpress -p'password' ping > /dev/null 2>&1; then
send_alert "🔴 MySQL DOWN
Cannot connect to database"
fi

# 6. Проверка Redis
if ! redis-cli ping > /dev/null 2>&1; then
send_alert "🔴 Redis DOWN
Cannot connect to Redis"
fi

# 7. Проверка диска
DISK_USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$DISK_USAGE" -gt 85 ]; then
send_alert "⚠️ Disk Space Low
Usage: ${DISK_USAGE}%"
fi

echo "[$(date)] Monitoring check completed"

Делаем исполняемым и добавляем в cron:

chmod +x /opt/monitoring/monitor-all.sh

# Каждые 5 минут
*/5 * * * * /opt/monitoring/monitor-all.sh >> /var/log/monitoring.log 2>&1

Мониторинг Core Web Vitals через Lighthouse CI

Для регулярной проверки производительности используем Lighthouse CI. Он запускает реальные тесты PageSpeed и сохраняет результаты.

Установка:

npm install -g @lhci/cli@latest

Конфигурация `lighthouserc.json`:

{
"ci": {
"collect": {
"url": [
"https://custom-code.ru/",
"https://custom-code.ru/sample-article/"
],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", {"minScore": 0.9}],
"categories:accessibility": ["error", {"minScore": 0.9}],
"largest-contentful-paint": ["warn", {"maxNumericValue": 2500}],
"cumulative-layout-shift": ["warn", {"maxNumericValue": 0.1}]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}

Запуск:

lhci autorun

Добавляем в cron (раз в день):

0 3 * * * cd /opt/monitoring && lhci autorun >> /var/log/lighthouse.log 2>&1

Дашборд Grafana: всё в одном месте

Теперь собираем всё в красивый дашборд. В Grafana создаём новый Dashboard и добавляем панели:

Панель 1: Uptime за 30 дней

Используем данные из Prometheus:

avg_over_time(up{job="wordpress"}[30d]) * 100

Показывает процент доступности. Цель — 99.9%.

Панель 2: TTFB в реальном времени

probe_duration_seconds{job="blackbox"}

Панель 3: CPU и RAM

# CPU
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# RAM
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

Панель 4: PHP-FPM активные процессы

Для этого нужен PHP-FPM exporter. Устанавливаем:

docker run -d --name php-fpm-exporter \
-p 9253:9253 \
hipages/php-fpm_exporter \
--php-fpm.scrape-uri "http://localhost/status?json"

Панель 5: MySQL connections

mysql_global_status_threads_connected

Алерты в Grafana

Grafana умеет сама отправлять алерты. Настраиваем:

Alerting → Contact points → Add contact point
Тип: Telegram
Вводим Bot Token и Chat ID
Save

Теперь создаём правила:

Правило 1: Высокая нагрузка CPU

100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80

Алерт, если CPU > 80% в течение 5 минут.

Правило 2: Мало места на диске

(1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100 > 85

Правило 3: MySQL down

mysql_up == 0

Правило 4: PHP-FPM перегружен

php_fpm_active_processes > 40

Чек-лист настройки мониторинга

✅ Uptime Kuma установлен и доступен
✅ Добавлены мониторы: главная, админка, SSL, MySQL, Redis
✅ Настроены Telegram-алерты
✅ Prometheus + Node Exporter установлены
✅ Grafana установлена с дашбордами
✅ Импортированы готовые дашборды (Node, Nginx, MySQL)
✅ Настроен мониторинг PHP-FPM
✅ Настроен мониторинг Core Web Vitals
✅ Настроены алерты в Grafana
✅ Централизованный скрипт мониторинга работает через cron
✅ Протестированы алерты (искусственно «уронили» сервис)

Решение частых проблем

Uptime Kuma показывает «DOWN», но сайт работает

Проверьте три вещи:

Firewall: возможно, сервер блокирует запросы от Uptime Kuma
Cloudflare: если сайт за Cloudflare, он может блокировать «подозрительные» запросы
User-Agent: добавьте в Uptime Kuma кастомный заголовок User-Agent: UptimeKuma и разрешите его в Nginx

Telegram-алерты не приходят

Проверьте:

# Тестируем отправку вручную
curl -X POST "https://api.telegram.org/bot/sendMessage" \
-d chat_id= \
-d text="Test message"

# Если не работает — проверьте токен и chat_id
# Если работает — проблема в настройках Uptime Kuma или Grafana

Grafana не показывает данные

Проверьте:

# Prometheus работает?
curl http://localhost:9090/-/healthy

# Node Exporter работает?
curl http://localhost:9100/metrics | head

# Prometheus видит цели?
curl http://localhost:9090/api/v1/targets

Алерты приходят слишком часто (alert fatigue)

Это классическая проблема. Если алертов слишком много — вы перестаёте на них реагировать. Решения:

Увеличьте пороги: вместо CPU > 80% поставьте > 90%
Добавьте задержку: алерт только если проблема длится больше 5 минут
Группируйте алерты: один алерт вместо десяти
Настройте quiet hours: не будить ночью, если не критично

Как мониторить WordPress Multisite?

Для сети сайтов добавьте в Uptime Kuma мониторы для каждого подсайта. Или используйте скрипт:

#!/bin/bash
# Мониторинг всех сайтов сети

SITES=$(wp site list --field=url --path=/var/www/wordpress)

for site in $SITES; do
HTTP_CODE=$(curl -o /dev/null -s -w '%{http_code}' "$site")
if [ "$HTTP_CODE" != "200" ]; then
send_alert "🔴 Site DOWN: $site (HTTP $HTTP_CODE)"
fi
done

Итог

Мониторинг — это не роскошь. Это необходимость. Без него вы слепы. Сайт может лежать часами, а вы будете об этом знать только от злых клиентов. SSL-сертификат может истечь, и браузеры будут пугать посетителей. База данных может медленно умирать, а вы заметите это, только когда она окончательно встанет.

С настройкой мониторинга из этой статьи вы получаете:

Мгновенные алерты в Telegram при любых проблемах
Полную видимость состояния сервера и приложений
Историю метрик для анализа трендов
Проактивное обнаружение проблем до того, как они станут критичными

Настройка занимает 2-3 часа. Но она окупается в первый же раз, когда вы получаете алерт о падении сайта в 3 часа ночи, чините его за 5 минут, и никто из пользователей даже не замечает проблемы.

Начните с простого: установите Uptime Kuma и настройте Telegram-алерты. Этого уже достаточно, чтобы спать спокойно. Потом добавляйте Prometheus и Grafana — когда будете готовы к более глубокой аналитике.

И помните: мониторинг — это не «поставил и забыл». Это живой процесс. Пороги нужно настраивать. Алерты — тюнинговать. Дашборды — обновлять. Но это та работа, которая спасает репутацию, нервы и деньги.

Что вообще нужно мониторить

Слой 1: Доступность (Uptime)

Слой 2: Производительность (Performance)

Слой 3: Ресурсы сервера (Infrastructure)

Слой 4: Бизнес-метрики (Application)

Uptime Kuma: ваш личный сторожевой пёс

Установка через Docker (рекомендуется)

Установка без Docker (для shared-хостинга)

Настройка мониторов для WordPress

Монитор 1: Главная страница (HTTP)

Монитор 2: Админка WordPress

Монитор 3: TTFB (время ответа сервера)

Монитор 4: SSL-сертификат

Монитор 5: База данных (MySQL)

Монитор 6: Redis

Алерты в Telegram: чтобы не пропустить

Создаём Telegram-бота

Получаем chat_id

Настраиваем в Uptime Kuma

Что приходит в алерте:

Prometheus + Grafana: мониторинг ресурсов сервера

Установка через Docker Compose

Конфигурация Prometheus

Устанавливаем экспортеры

Открываем Grafana

Импортируем готовые дашборды

Мониторинг Core Web Vitals

Скрипт для проверки CWV

Мониторинг PHP-FPM

Включаем status page

Скрипт мониторинга PHP-FPM

Мониторинг дискового пространства

Скрипт проверки диска

Централизованный скрипт алертов

Мониторинг Core Web Vitals через Lighthouse CI

Установка:

Конфигурация lighthouserc.json:

Запуск:

Дашборд Grafana: всё в одном месте

Панель 1: Uptime за 30 дней

Панель 2: TTFB в реальном времени

Панель 3: CPU и RAM

Панель 4: PHP-FPM активные процессы

Панель 5: MySQL connections

Алерты в Grafana

Правило 1: Высокая нагрузка CPU

Правило 2: Мало места на диске

Правило 3: MySQL down

Правило 4: PHP-FPM перегружен

Чек-лист настройки мониторинга

Решение частых проблем

Uptime Kuma показывает «DOWN», но сайт работает

Telegram-алерты не приходят

Grafana не показывает данные

Алерты приходят слишком часто (alert fatigue)

Как мониторить WordPress Multisite?

Итог

Конфигурация `lighthouserc.json`: