Как настроить мониторинг сайта: полное руководство

3 апреля 2026 · Время чтения: 13 мин

За 10 лет работы с веб-проектами я видел сотни ситуаций, когда сайт падал в самый неподходящий момент — в пятницу вечером, в выходные, во время рекламной кампании. И каждый раз владельцы бизнеса узнавали об этом от клиентов, а не от систем мониторинга.

Зачем нужен мониторинг сайта

Честно говоря, мониторинг — это не просто модная фишка для IT-отделов. Это базовая потребность любого бизнеса, который зависит от сайта. Я обычно объясняю клиентам простым примером: представьте, что ваш магазин закрыт, а вы об этом не знаете. Покупатели приходят, видят закрытую дверь и уходят к конкурентам.

На практике у меня был клиент с интернет-магазином, который приносил 500 тысяч рублей в месяц. Сайт упал в пятницу в 18:00 из-за переполнения диска на сервере, а владелец узнал об этом только в понедельник утром. За выходные он потерял примерно 50 тысяч рублей выручки. После этого случая мы настроили полноценный мониторинг.

Основные причины, почему мониторинг критически важен:

Время простоя = потерянные деньги. Каждая минута недоступности сайта стоит денег
Репутационные потери. Клиенты не любят нерабочие сайты и запоминают негативный опыт
SEO-последствия. Поисковики понижают в выдаче сайты с частыми проблемами доступности
Превентивное решение проблем. Многие проблемы можно предотвратить, если заметить их на раннем этапе

ℹ️

Статистика: По данным исследований, даже 1% простоя в год может обойтись в сотни тысяч рублей для среднего интернет-магазина. А для крупных проектов счёт идёт на миллионы.

Виды мониторинга сайта

За годы работы я выделил несколько ключевых типов мониторинга, которые нужно настраивать в комплексе. Нельзя ограничиваться только одним видом — это как смотреть на слона через замочную скважину.

Мониторинг доступности (Uptime)

Самый базовый, но критически важный тип. Проверяет, отвечает ли сайт на HTTP-запросы. Я настраиваю проверки каждые 1-5 минут в зависимости от критичности проекта. Для интернет-магазинов — каждую минуту, для корпоративных сайтов можно и каждые 5 минут.

Важные нюансы при настройке:

Проверяйте не только главную страницу, но и ключевые разделы (каталог, корзину, личный кабинет)
Используйте мониторинг с разных географических точек
Настройте проверку не только HTTP 200, но и содержимого страницы

Мониторинг производительности

Здесь отслеживаем время загрузки страниц, время ответа сервера, скорость работы базы данных. У меня есть клиент, сайт которого формально работал, но загружался по 15 секунд. Пользователи просто уходили, не дождавшись загрузки. Это тоже простой, только незаметный.

Ключевые метрики для отслеживания:

TTFB (Time To First Byte) — должно быть менее 200ms для хорошей производительности
Page Load Time — полное время загрузки страницы, оптимально до 3 секунд
Core Web Vitals — метрики от Google, влияющие на SEO

Мониторинг ресурсов сервера

Отслеживаем загрузку процессора, использование оперативной памяти, свободное место на диске, нагрузку на базу данных. Это превентивный мониторинг — он помогает предотвратить проблемы до их возникновения.

На практике я видел множество ситуаций, когда сайт падал из-за переполнения диска логами или из-за утечки памяти в PHP-скриптах. Если отслеживать эти метрики, проблемы можно решить заранее.

Мониторинг безопасности

Проверка SSL-сертификатов, мониторинг подозрительной активности, отслеживание изменений в критических файлах. Особенно актуально для сайтов на WordPress, где часто происходят взломы.

⚠️

Внимание: SSL-сертификаты имеют срок действия. Я видел случаи, когда сайты становились недоступными из-за истёкшего сертификата. Обязательно настройте уведомления за 30 дней до истечения.

Выбор сервиса мониторинга

Честно говоря, выбор сервиса мониторинга — это как выбор автомобиля. Можно купить простую машину, которая довезёт из точки А в точку Б, а можно взять премиальный вариант со всеми удобствами. Всё зависит от ваших потребностей и бюджета.

Бесплатные решения

UptimeRobot — мой любимый бесплатный сервис. Даёт 50 мониторов бесплатно с проверкой каждые 5 минут. Этого хватает для небольших проектов. Простой в настройке, надёжный, с понятным интерфейсом.

Pingdom — в бесплатном тарифе даёт 1 монитор, но с очень детальной статистикой. Хорош для тестирования и понимания, что такое мониторинг вообще.

StatusCake — до 10 мониторов бесплатно. Неплохой интерфейс, но иногда бывают ложные срабатывания.

Платные решения

Для серьёзных проектов я рекомендую платные решения. Они дают больше возможностей, лучшую поддержку и меньше ложных срабатываний.

Pingdom Professional — от $10/месяц. Отличная детализация, множество локаций для проверки, хорошие возможности оповещений. Использую для большинства коммерческих проектов.

New Relic — серьёзное решение для крупных проектов. Кроме мониторинга доступности даёт глубокую аналитику производительности приложений. От $99/месяц, но возможности впечатляющие.

DataDog — ещё более продвинутое решение. Мониторинг всей инфраструктуры, логов, метрик. Для enterprise-проектов это практически стандарт.

Собственные решения

Иногда имеет смысл настроить собственный мониторинг. Особенно если у вас специфические требования или вы хотите полный контроль над данными.

Zabbix — мощная открытая система мониторинга. Сложная в настройке, но очень гибкая. Подойдёт, если есть системный администратор в штате.

Nagios — классика жанра. Надёжный, проверенный временем, но требует серьёзных знаний для настройки.

Prometheus + Grafana — современный стек для мониторинга. Популярен в DevOps-команды. Красивые дашборды, гибкие настройки, но нужна экспертиза для внедрения.

Настройка базового мониторинга

Начну с самого простого варианта — настройки мониторинга через UptimeRobot. Это решение, которое я рекомендую всем своим клиентам как стартовую точку. Даже если потом переходите на что-то более сложное, базовый мониторинг должен работать всегда.

Регистрация и первая настройка

Заходим на uptimerobot.com, регистрируемся. В бесплатном аккаунте получаем 50 мониторов с проверкой каждые 5 минут. Для начала этого более чем достаточно.

Создаём первый монитор:

Нажимаем "Add New Monitor"
Выбираем тип "HTTP(s)"
Вводим URL сайта
Задаём имя монитора (например, "Главная страница example.com")
Выбираем интервал проверки (5 минут для бесплатного аккаунта)

Но простая проверка доступности — это только начало. Я всегда настраиваю дополнительные проверки:

Настройка проверки содержимого

В расширенных настройках монитора включаем "Keyword Monitoring". Указываем ключевое слово, которое должно присутствовать на странице. Например, для интернет-магазина можно проверять наличие слова "Каталог" или "Корзина".

Это защищает от ситуаций, когда сервер отдаёт HTTP 200, но вместо сайта показывает страницу ошибки или заглушку хостинг-провайдера.

Множественные точки проверки

В настройках монитора выбираем несколько локаций для проверки. Это помогает избежать ложных срабатываний из-за проблем на стороне сервиса мониторинга. Обычно выбираю 3-4 точки: США, Европа, Азия.

💡

Совет: Не ограничивайтесь проверкой только главной страницы. Обязательно добавьте мониторинг ключевых разделов: страницы товаров, формы заказа, личного кабинета. У меня был случай, когда главная работала, а весь каталог был недоступен из-за проблем с базой данных.

Мониторинг производительности

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

Ключевые метрики производительности

За годы работы я выделил метрики, которые реально влияют на бизнес-результат:

Time To First Byte (TTFB) — время до получения первого байта от сервера. Это показатель того, как быстро сервер обрабатывает запрос. Для хорошего UX должно быть менее 200ms, приемлемо до 500ms.

First Contentful Paint (FCP) — когда пользователь видит первый контент. Хорошо — до 1.8 секунд, плохо — больше 3 секунд.

Largest Contentful Paint (LCP) — когда загружается самый крупный элемент на странице. Это одна из Core Web Vitals, которая напрямую влияет на SEO.

Cumulative Layout Shift (CLS) — насколько элементы страницы сдвигаются во время загрузки. Пользователи ненавидят, когда кнопки "прыгают" во время клика.

Инструменты для мониторинга производительности

Google PageSpeed Insights — бесплатный инструмент от Google. Даёт оценку производительности и конкретные рекомендации по улучшению. Проблема в том, что это разовая проверка, а не постоянный мониторинг.

GTmetrix — более детальный анализ производительности. В бесплатном тарифе даёт 3 проверки в день, в платном — постоянный мониторинг. Показывает водопад загрузки, что очень помогает в оптимизации.

WebPageTest — профессиональный инструмент тестирования. Можно выбрать браузер, устройство, локацию. Даёт очень подробную информацию о процессе загрузки.

Настройка автоматического мониторинга производительности

Для постоянного мониторинга я использую комбинацию инструментов. Вот скрипт, который запускаю через cron каждый час для проверки времени загрузки:

#!/bin/bash

URL="https://example.com"
LOG_FILE="/var/log/performance_monitor.log"
THRESHOLD=3000  # миллисекунды

# Измеряем время загрузки
LOAD_TIME=$(curl -o /dev/null -s -w '%{time_total}\n' $URL)
LOAD_TIME_MS=$(echo "$LOAD_TIME * 1000" | bc | cut -d. -f1)

# Записываем в лог
echo "$(date): $URL загрузился за ${LOAD_TIME_MS}ms" >> $LOG_FILE

# Проверяем превышение порога
if [ $LOAD_TIME_MS -gt $THRESHOLD ]; then
    echo "ВНИМАНИЕ: Медленная загрузка сайта $URL - ${LOAD_TIME_MS}ms" | mail -s "Проблема производительности" admin@example.com
fi

Этот скрипт проверяет время загрузки и отправляет уведомление, если оно превышает установленный порог. Простое, но эффективное решение.

Мониторинг сервера и ресурсов

Мониторинг сервера — это как регулярный медосмотр. Можно чувствовать себя нормально, но анализы покажут скрытые проблемы. У меня был случай, когда клиент жаловался на периодические зависания сайта. Оказалось, что раз в день запускался скрипт резервного копирования, который загружал процессор на 100%.

Ключевые метрики сервера

Загрузка процессора (CPU Usage) — должна быть в среднем не выше 70-80%. Краткосрочные пики до 90-95% допустимы, но постоянная высокая загрузка — признак проблем.

Использование памяти (RAM Usage) — критично для PHP-приложений. Если память заканчивается, процессы начинают убиваться, сайт падает. Держу планку не выше 85% использования.

Место на диске (Disk Usage) — казалось бы, очевидно, но я регулярно вижу сайты, которые падают из-за переполненного диска. Логи, кеш, временные файлы — всё это накапливается.

Сетевая активность — помогает выявить DDoS-атаки или аномальную нагрузку.

Состояние базы данных — количество соединений, медленные запросы, размер таблиц.

Простой мониторинг через bash-скрипты

Не всегда нужны сложные системы мониторинга. Иногда простой bash-скрипт решает 80% задач. Вот мой универсальный скрипт для мониторинга основных метрик:

#!/bin/bash

# Настройки
EMAIL="admin@example.com"
CPU_THRESHOLD=80
MEMORY_THRESHOLD=85
DISK_THRESHOLD=90

# Проверяем загрузку CPU
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | awk -F'%' '{print $1}')
if (( $(echo "$CPU_USAGE > $CPU_THRESHOLD" | bc -l) )); then
    echo "Высокая загрузка CPU: ${CPU_USAGE}%" | mail -s "CPU Alert" $EMAIL
fi

# Проверяем использование памяти
MEMORY_USAGE=$(free | grep Mem | awk '{printf("%.1f", ($3/$2) * 100.0)}')
if (( $(echo "$MEMORY_USAGE > $MEMORY_THRESHOLD" | bc -l) )); then
    echo "Высокое использование памяти: ${MEMORY_USAGE}%" | mail -s "Memory Alert" $EMAIL
fi

# Проверяем место на диске
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | cut -d'%' -f1)
if [ $DISK_USAGE -gt $DISK_THRESHOLD ]; then
    echo "Мало места на диске: ${DISK_USAGE}%" | mail -s "Disk Alert" $EMAIL
fi

# Проверяем состояние MySQL
MYSQL_CONNECTIONS=$(mysql -u root -p'password' -e "SHOW STATUS LIKE 'Threads_connected';" | grep Threads_connected | awk '{print $2}')
if [ $MYSQL_CONNECTIONS -gt 100 ]; then
    echo "Много подключений к MySQL: ${MYSQL_CONNECTIONS}" | mail -s "MySQL Alert" $EMAIL
fi

Добавляем этот скрипт в crontab для запуска каждые 5 минут:

*/5 * * * * /path/to/server_monitor.sh

Мониторинг логов

Логи — это чёрный ящик сервера. Они содержат массу полезной информации, но нужно уметь её извлекать. Я всегда настраиваю мониторинг критических событий в логах.

Для nginx отслеживаю ошибки 5xx, медленные запросы, аномальную активность:

#!/bin/bash

LOG_FILE="/var/log/nginx/error.log"
ACCESS_LOG="/var/log/nginx/access.log"
EMAIL="admin@example.com"

# Проверяем ошибки 5xx за последний час
ERRORS_5XX=$(tail -n 10000 $ACCESS_LOG | grep "$(date '+%d/%b/%Y:%H' -d '1 hour ago')" | grep -c " 5[0-9][0-9] ")

if [ $ERRORS_5XX -gt 10 ]; then
    echo "Много ошибок 5xx за последний час: $ERRORS_5XX" | mail -s "5xx Errors Alert" $EMAIL
fi

# Проверяем медленные запросы (больше 5 секунд)
SLOW_REQUESTS=$(tail -n 10000 $ACCESS_LOG | awk '$NF > 5 {print}' | wc -l)

if [ $SLOW_REQUESTS -gt 5 ]; then
    echo "Обнаружено $SLOW_REQUESTS медленных запросов" | mail -s "Slow Requests Alert" $EMAIL
fi

⚠️

Важно: Не забывайте про ротацию логов. Я видел сервера, которые падали из-за того, что логи заполняли весь диск. Настройте logrotate для автоматической ротации логов.

Настройка оповещений

Мониторинг без оповещений — это как пожарная сигнализация без звука. Бессмысленно. Но тут важно найти баланс: слишком мало уведомлений — пропустите проблему, слишком много — начнёте их игнорировать.

Каналы оповещений

За годы работы я протестировал множество способов получения уведомлений. У каждого есть свои плюсы и минусы:

Email — классика, но не всегда оперативно. Хорошо для некритичных уведомлений или детальных отчётов.

SMS — самый надёжный способ для критичных уведомлений. Работает даже без интернета. Но дорого, если много уведомлений.

Telegram/WhatsApp — быстро, удобно, бесплатно. Можно создать отдельный чат для уведомлений. Я обычно использую Telegram для большинства проектов.

Slack/Discord — хорошо для команды. Все видят уведомления, можно быстро обсудить проблему.

Звонки — для критичных ситуаций. Некоторые сервисы мониторинга могут автоматически звонить при серьёзных проблемах.

Настройка эскалации

Эскалация — это система постепенного увеличения "громкости" уведомлений. Схема, которую я использую для критичных проектов:

1-я попытка: Telegram-сообщение ответственному разработчику
Через 5 минут: SMS + email
Через 15 минут: Звонок + уведомление руководителю проекта
Через 30 минут: Уведомление владельцу бизнеса

Это гарантирует, что критичные проблемы не останутся незамеченными, даже если основной ответственный недоступен.

Создание Telegram-бота для уведомлений

Telegram — мой любимый способ получения уведомлений. Быстро, бесплатно, работает на всех устройствах. Вот как создать простого бота для уведомлений:

botToken = $botToken;
        $this->chatId = $chatId;
    }
    
    public function sendAlert($message) {
        $url = "https://api.telegram.org/bot{$this->botToken}/sendMessage";
        
        $data = [
            'chat_id' => $this->chatId,
            'text' => $message,
            'parse_mode' => 'HTML'
        ];
        
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_POST, true);
        curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
        curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        
        $response = curl_exec($ch);
        curl_close($ch);
        
        return json_decode($response, true);
    }
    
    public function sendSiteDownAlert($siteName, $url) {
        $message = "🚨 САЙТ НЕДОСТУПЕН\n\n";
        $message .= "Сайт: {$siteName}\n";
        $message .= "URL: {$url}\n";
        $message .= "Время: " . date('d.m.Y H:i:s');
        
        return $this->sendAlert($message);
    }
    
    public function sendPerformanceAlert($siteName, $loadTime) {
        $message = "⚠️ МЕДЛЕННАЯ ЗАГРУЗКА\n\n";
        $message .= "Сайт: {$siteName}\n";
        $message .= "Время загрузки: {$loadTime}s\n";
        $message .= "Время: " . date('d.m.Y H:i:s');
        
        return $this->sendAlert($message);
    }
}

// Использование
$notifier = new TelegramNotifier('YOUR_BOT_TOKEN', 'YOUR_CHAT_ID');
$notifier->sendSiteDownAlert('Мой сайт', 'https://example.com');
?>

Умная фильтрация уведомлений

Одна из главных проблем мониторинга — ложные срабатывания. Я разработал систему фильтрации, которая значительно снижает количество ложных уведомлений:

Минимальное время простоя: Не отправляю уведомление, если сайт недоступен меньше 2 минут
Множественные проверки: Подтверждаю проблему с нескольких серверов
Временные окна: Не отправляю повторные уведомления чаще раза в 15 минут
Статус-страницы: Проверяю статус хостинг-провайдера перед отправкой уведомления

Мониторинг SSL и безопасности

Безопасность — это не то, о чём думаешь, пока проблема не случится. Но когда случается, исправлять последствия гораздо дороже, чем предотвращать. За годы работы я видел десятки взломанных сайтов, и в большинстве случаев проблему можно было предотвратить правильным мониторингом.

Мониторинг SSL-сертификатов

SSL-сертификаты имеют срок действия, и если его пропустить, сайт станет недоступным для пользователей. Современные браузеры агрессивно блокируют сайты с просроченными сертификатами.

У меня был клиент, который потерял 20% трафика за один день из-за истёкшего SSL-сертификата. Пользователи видели страшное предупреждение браузера и просто уходили. А ведь можно было настроить уведомление за месяц до истечения.

Скрипт для проверки срока действия SSL:

#!/bin/bash

DOMAIN="example.com"
DAYS_THRESHOLD=30
EMAIL="admin@example.com"

# Получаем дату истечения сертификата
EXPIRY_DATE=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -dates | grep notAfter | cut -d= -f2)

# Конвертируем в timestamp
EXPIRY_TIMESTAMP=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_TIMESTAMP=$(date +%s)

# Вычисляем оставшиеся дни
DAYS_LEFT=$(( ($EXPIRY_TIMESTAMP - $CURRENT_TIMESTAMP) / 86400 ))

echo "SSL-сертификат для $DOMAIN истекает через $DAYS_LEFT дней"

if [ $DAYS_LEFT -lt $DAYS_THRESHOLD ]; then
    echo "SSL-сертификат для $DOMAIN истекает через $DAYS_LEFT дней!" | mail -s "SSL Certificate Expiry Warning" $EMAIL
fi

Мониторинг изменений в файлах

Один из признаков взлома — изменения в системных файлах сайта. Я всегда настраиваю мониторинг ключевых файлов и папок. Особенно актуально для WordPress, где хакеры часто модифицируют .htaccess, index.php, wp-config.php.

Простой скрипт мониторинга файлов:

#!/bin/bash

SITE_PATH="/var/www/html"
HASH_FILE="/var/log/file_hashes.txt"
EMAIL="admin@example.com"

# Создаём новый файл с хешами
find $SITE_PATH -name "*.php" -o -name ".htaccess" -o -name "*.js" | xargs md5sum > /tmp/current_hashes.txt

# Сравниваем с предыдущим состоянием
if [ -f $HASH_FILE ]; then
    CHANGED_FILES=$(diff $HASH_FILE /tmp/current_hashes.txt | grep "^>" | wc -l)
    
    if [ $CHANGED_FILES -gt 0 ]; then
        echo "Обнаружены изменения в $CHANGED_FILES файлах:" > /tmp/changes.txt
        diff $HASH_FILE /tmp/current_hashes.txt >> /tmp/changes.txt
        
        cat /tmp/changes.txt | mail -s "File Changes Detected" $EMAIL
    fi
fi

# Сохраняем текущее состояние
cp /tmp/current_hashes.txt $HASH_FILE

Мониторинг подозрительной активности

Важно отслеживать аномальную активность в логах. Множественные попытки входа, запросы к несуществующим файлам, подозрительные User-Agent'ы — всё это может указывать на попытки взлома.

Я настраиваю алерты на следующие события:

Более 10 неудачных попыток входа в админку за час
Запросы к файлам .php в папке uploads (признак backdoor'а)
Необычно высокий трафик с одного IP
Запросы к известным уязвимостям (/wp-admin/install.php, /config.php и т.д.)

ℹ️

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

Анализ логов и метрик

Собирать данные мониторинга — это только половина дела. Важно уметь их анализировать и делать правильные выводы. Я видел множество проектов, где настроен отличный мониторинг, но никто не анализирует данные. Это как покупать дорогие весы и не смотреть на показания.

Паттерны в данных мониторинга

За годы работы я научился видеть характерные паттерны в данных мониторинга. Они многое говорят о состоянии проекта:

Пиковые нагрузки в определённое время — обычно связаны с рассылками, рекламными кампаниями или обновлениями контента. Если пики регулярные, можно предсказать нагрузку и подготовиться.

Постепенное ухудшение производительности — часто указывает на накопление "мусора": логов, кеша, временных файлов. Или на рост объёма данных без оптимизации запросов.

Периодические кратковременные падения — могут быть связаны с задачами cron, резервным копированием, обновлениями. Нужно сопоставить время падений с расписанием задач.

Аномальная активность в ночное время — часто признак автоматических атак или неправильно настроенных задач.

Построение дашбордов

Данные мониторинга нужно визуализировать. Хорошо построенный дашборд позволяет с одного взгляда понять состояние всей инфраструктуры. Я использую несколько подходов:

Для простых проектов достаточно дашборда в UptimeRobot или Pingdom. Показывает основные метрики доступности и производительности.

Для более сложных проектов создаю кастомные дашборды в Grafana. Можно объединить данные из разных источников: сервер, приложение, база данных, CDN.

Пример простого скрипта для сбора метрик в формате Prometheus:

query('SHOW STATUS LIKE "Threads_connected"');
        $row = $result->fetch();
        return (int)$row[1];
    } catch (Exception $e) {
        return 0;
    }
}

function getErrorRate() {
    // Анализируем логи за последний час
    $logFile = '/var/log/nginx/access.log';
    $oneHourAgo = date('d/M/Y:H', strtotime('-1 hour'));
    
    $totalRequests = 0;
    $errorRequests = 0;
    
    $handle = fopen($logFile, 'r');
    if ($handle) {
        while (($line = fgets($handle)) !== false) {
            if (strpos($line, $oneHourAgo) !== false) {
                $totalRequests++;
                if (preg_match('/" [45]\d\d /', $line)) {
                    $errorRequests++;
                }
            }
        }
        fclose($handle);
    }
    
    return $totalRequests > 0 ? round(($errorRequests / $totalRequests) * 100, 2) : 0;
}
?>

Корреляция событий

Самое интересное начинается, когда вы учитесь сопоставлять разные метрики. Например, рост времени ответа базы данных может коррелировать с увеличением числа одновременных пользователей. Или падение конверсии — с ухудшением производительности.

Я веду журнал всех изменений на проектах: обновления, настройки, рекламные кампании. Это помогает понять, что именно привело к изменению метрик.

Мониторинг мобильной версии

Мобильный трафик составляет больше половины всех посещений для большинства сайтов. Но многие забывают, что мобильная версия может работать по-разному. Адаптивный дизайн не гарантирует одинаковую производительность на всех устройствах.

Особенности мобильного мониторинга

У меня был клиент, сайт которого отлично работал на десктопе, но ужасно тормозил на мобильных устройствах. Проблема была в тяжёлых изображениях, которые не оптимизировались для мобильных экранов.

Ключевые отличия мобильного мониторинга:

Медленная сеть — нужно тестировать на 3G-соединениях, а не только на быстром WiFi
Слабые процессоры — JavaScript, который быстро выполняется на десктопе, может тормозить на мобильных
Ограниченная память — большие страницы могут вызывать перезагрузки вкладок
Различные браузеры — особенности Safari на iOS, Samsung Browser на Android

Инструменты для мобильного мониторинга

Google PageSpeed Insights — показывает отдельные метрики для мобильных и десктопных устройств. Очень часто мобильная оценка значительно ниже.

WebPageTest — можно выбрать конкретные мобильные устройства для тестирования. Полезно тестировать на разных скоростях соединения.

Chrome DevTools — режим эмуляции мобильных устройств. Можно ограничить скорость сети и мощность процессора.

Скрипт для автоматической проверки мобильной производительности через Google PageSpeed API:

 $url,
        'key' => $apiKey,
        'strategy' => 'mobile',
        'category' => 'performance'
    ];
    
    $requestUrl = $apiUrl . '?' . http_build_query($params);
    
    $ch = curl_init($requestUrl);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $response = curl_exec($ch);
    curl_close($ch);
    
    $data = json_decode($response, true);
    
    if (isset($data['lighthouseResult']['categories']['performance']['score'])) {
        $score = $data['lighthouseResult']['categories']['performance']['score'] * 100;
        
        return [
            'score' => $score,
            'fcp' => $data['lighthouseResult']['audits']['first-contentful-paint']['displayValue'] ?? 'N/A',
            'lcp' => $data['lighthouseResult']['audits']['largest-contentful-paint']['displayValue'] ?? 'N/A',
            'cls' => $data['lighthouseResult']['audits']['cumulative-layout-shift']['displayValue'] ?? 'N/A'
        ];
    }
    
    return false;
}

// Использование
$result = checkMobilePerformance('https://example.com', 'YOUR_API_KEY');

if ($result && $result['score'] < 70) {
    $message = "Низкая мобильная производительность: {$result['score']}/100\n";
    $message .= "FCP: {$result['fcp']}\n";
    $message .= "LCP: {$result['lcp']}\n";
    $message .= "CLS: {$result['cls']}";
    
    // Отправляем уведомление
    mail('admin@example.com', 'Mobile Performance Alert', $message);
}
?>

Создание статус-страницы

Статус-страница — это публичная страница, где пользователи могут посмотреть текущее состояние сервисов. Это показывает прозрачность и профессионализм. Когда у пользователей проблемы с доступом, они сначала идут проверить статус-страницу.

Я создавал статус-страницы для нескольких крупных проектов. Пользователи это очень ценят — вместо паники и звонков в поддержку они видят, что проблема известна и решается.

Что должно быть на статус-странице

Текущий статус основных сервисов — сайт, API, база данных, CDN
История инцидентов — что было, как решили, сколько длилось
Плановые работы — когда планируется техническое обслуживание
Подписка на уведомления — email или RSS для получения обновлений
Контакты поддержки — как связаться, если проблема не отражена на странице

Простой пример статус-страницы на PHP:

 'Основной сайт',
        'api' => 'API сервис',
        'database' => 'База данных',
        'cdn' => 'CDN'
    ];
    
    public function checkServiceStatus($service) {
        switch($service) {
            case 'website':
                return $this->checkWebsite('https://example.com');
            case 'api':
                return $this->checkAPI('https://api.example.com/status');
            case 'database':
                return $this->checkDatabase();
            case 'cdn':
                return $this->checkCDN('https://cdn.example.com/test.png');
            default:
                return ['status' => 'unknown', 'response_time' => 0];
        }
    }
    
    private function checkWebsite($url) {
        $start = microtime(true);
        
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_TIMEOUT, 10);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        
        $response = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        curl_close($ch);
        
        $responseTime = round((microtime(true) - $start) * 1000);
        
        $status = ($httpCode == 200 && $response !== false) ? 'operational' : 'down';
        
        return [
            'status' => $status,
            'response_time' => $responseTime,
            'http_code' => $httpCode
        ];
    }
    
    private function checkDatabase() {
        try {
            $start = microtime(true);
            $pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'password');
            $pdo->query('SELECT 1');
            $responseTime = round((microtime(true) - $start) * 1000);
            
            return ['status' => 'operational', 'response_time' => $responseTime];
        } catch (Exception $e) {
            return ['status' => 'down', 'response_time' => 0];
        }
    }
    
    public function generateStatusPage() {
        $overall_status = 'operational';
        $services_status = [];
        
        foreach ($this->services as $key => $name) {
            $status = $this->checkServiceStatus($key);
            $services_status[$key] = $status;
            
            if ($status['status'] !== 'operational') {
                $overall_status = 'degraded';
            }
        }
        
        // Генерируем HTML
        ob_start();
        ?>
        
        
        
            Статус сервисов
            
            
            

        
            <h1>Статус сервисов</h1>
            
                Общий статус: 
            
            
            
                services as $key => $name): ?>
                    
                        
                        
                            
                        
                         0): ?>
                            (ms)
                        
                    
                
            
            
            Последнее обновление: 
        
        
        generateStatusPage();
?>

Автоматизация и интеграции

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

Автоматическое восстановление

Многие проблемы можно решать автоматически, без участия человека. Я настраиваю скрипты, которые пытаются восстановить работу сервисов при обнаружении проблем:

Перезапуск сервисов — если nginx или MySQL упали, пытаемся перезапустить
Очистка кеша — если время ответа резко выросло, очищаем кеш
Освобождение места — автоматически удаляем старые логи при нехватке места
Перезагрузка PHP-FPM — при утечках памяти

Пример скрипта автоматического восстановления:

#!/bin/bash

LOG_FILE="/var/log/auto_recovery.log"

log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> $LOG_FILE
}

# Проверяем статус nginx
if ! systemctl is-active --quiet nginx; then
    log_message "Nginx не работает, пытаемся перезапустить"
    systemctl restart nginx
    
    if systemctl is-active --quiet nginx; then
        log_message "Nginx успешно перезапущен"
        echo "Nginx был автоматически перезапущен" | mail -s "Auto Recovery: Nginx" admin@example.com
    else
        log_message "Не удалось перезапустить Nginx"
        echo "КРИТИЧНО: Не удалось перезапустить Nginx" | mail -s "CRITICAL: Nginx Failed" admin@example.com
    fi
fi

# Проверяем использование диска
DISK_USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $DISK_USAGE -gt 90 ]; then
    log_message "Диск заполнен на ${DISK_USAGE}%, очищаем логи"
    
    # Очищаем старые логи
    find /var/log -name "*.log" -type f -mtime +30 -delete
    find /var/log -name "*.log.*" -type f -mtime +7 -delete
    
    # Очищаем кеш приложения
    rm -rf /var/www/html/cache/*
    
    NEW_USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
    log_message "После очистки использование диска: ${NEW_USAGE}%"
fi

# Проверяем утечки памяти в PHP-FPM
PHP_MEMORY=$(ps aux | grep php-fpm | awk '{sum+=$4} END {print sum}')
if (( $(echo "$PHP_MEMORY > 50" | bc -l) )); then
    log_message "Высокое использование памяти PHP-FPM: ${PHP_MEMORY}%, перезапускаем"
    systemctl reload php8.1-fpm
    log_message "PHP-FPM перезапущен"
fi

Интеграция с системами уведомлений

Я интегрирую мониторинг с рабочими инструментами команды. Если используете Slack — уведомления приходят в Slack. Если Jira — автоматически создаются тикеты для критичных проблем.

Пример интеграции с Slack:

webhookUrl = $webhookUrl;
    }
    
    public function sendAlert($message, $severity = 'warning') {
        $color = [
            'info' => '#36a64f',
            'warning' => '#ff9900',
            'critical' => '#ff0000'
        ];
        
        $payload = [
            'attachments' => [
                [
                    'color' => $color[$severity] ?? '#ff9900',
                    'fields' => [
                        [
                            'title' => 'Алерт мониторинга',
                            'value' => $message,
                            'short' => false
                        ],
                        [
                            'title' => 'Время',
                            'value' => date('d.m.Y H:i:s'),
                            'short' => true
                        ],
                        [
                            'title' => 'Сервер',
                            'value' => gethostname(),
                            'short' => true
                        ]
                    ]
                ]
            ]
        ];
        
        $ch = curl_init($this->webhookUrl);
        curl_setopt($ch, CURLOPT_POST, true);
        curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($payload));
        curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        
        $response = curl_exec($ch);
        curl_close($ch);
        
        return $response;
    }
}
?>

💡

Совет: Не забывайте тестировать системы автоматического восстановления. У меня был случай, когда скрипт автоматически "чинил" проблему, которая требовала руч

Нужна помощь с настройкой мониторинга?

Наши специалисты настроят комплексный мониторинг вашего сайта и обеспечат его стабильную работу.

Павел

Веб-разработчик · 10+ лет опыта · Bitrix, WordPress, Laravel

Как настроить мониторинг сайта: полное руководство

Зачем нужен мониторинг сайта

Виды мониторинга сайта

Мониторинг доступности (Uptime)

Мониторинг производительности

Мониторинг ресурсов сервера

Мониторинг безопасности

Выбор сервиса мониторинга

Бесплатные решения

Платные решения

Собственные решения

Настройка базового мониторинга

Регистрация и первая настройка

Настройка проверки содержимого

Множественные точки проверки

Мониторинг производительности

Ключевые метрики производительности

Инструменты для мониторинга производительности

Настройка автоматического мониторинга производительности

Мониторинг сервера и ресурсов

Ключевые метрики сервера

Простой мониторинг через bash-скрипты

Мониторинг логов

Настройка оповещений

Каналы оповещений

Настройка эскалации

Создание Telegram-бота для уведомлений

Умная фильтрация уведомлений

Мониторинг SSL и безопасности

Мониторинг SSL-сертификатов

Мониторинг изменений в файлах

Мониторинг подозрительной активности

Анализ логов и метрик

Паттерны в данных мониторинга

Построение дашбордов

Корреляция событий

Мониторинг мобильной версии

Особенности мобильного мониторинга

Инструменты для мобильного мониторинга

Создание статус-страницы

Что должно быть на статус-странице

Общий статус:

Автоматизация и интеграции

Автоматическое восстановление

Интеграция с системами уведомлений

Нужна помощь с настройкой мониторинга?

Читайте также