Мониторинг сервера в Grafana: готовые дашборды, визуализация метрик и настройка алертов

Быстрый старт: импорт готового дашборда Node Exporter Full

Получить полноценную визуализацию метрик сервера в Grafana можно за 5 минут. Не нужно создавать панели с нуля. Достаточно импортировать готовый community-дашборд Node Exporter Full. Он покрывает все ключевые показатели: загрузку CPU, использование оперативной памяти, дисковое пространство, сетевой трафик и десятки других метрик. Инструкция проверена на Grafana 10.x и Prometheus 2.45+ в июле 2026 года.

Для тех, кто только разворачивает стек мониторинга, у нас есть полное руководство по настройке Prometheus, Grafana и оповещений с нуля. Если вам нужен мониторинг веб-сервера, посмотрите статью про дашборд мониторинга Nginx в Grafana.

Предварительные требования: Prometheus и Node Exporter

Импортированный дашборд не покажет данные, если Prometheus не собирает метрики с целевого сервера. Убедитесь, что:

• Node Exporter установлен и запущен на сервере, который нужно мониторить. По умолчанию он отдает метрики на порту 9100.
• Prometheus настроен на сбор метрик с этого Node Exporter. В файле prometheus.yml должен быть прописан target с адресом сервера и портом 9100.
• Prometheus успешно видит target. Проверьте в веб-интерфейсе Prometheus на вкладке Status → Targets: статус должен быть UP.

Детальную инструкцию по установке Node Exporter, разбору ключевых метрик и настройке сбора данных читайте в руководстве Мониторинг Linux-сервера с Prometheus Node Exporter. Там же описаны нюансы мониторинга ZFS-пулов.

Добавление Prometheus как источника данных в Grafana

Grafana должна знать, откуда брать метрики. Добавьте Prometheus как data source:

1. В боковом меню Grafana перейдите: Connections → Data Sources (или Configuration → Data Sources в старых версиях).
2. Нажмите Add data source и выберите Prometheus.
3. В поле Prometheus server URL укажите адрес вашего Prometheus. Если он запущен на том же хосте, что и Grafana, используйте http://localhost:9090.
4. Нажмите Save & Test. Появится зеленая галочка с сообщением об успешном подключении.

Если проверка не проходит, убедитесь, что Prometheus доступен по сети с хоста Grafana и не блокируется файрволом.

Импорт дашборда Node Exporter Full по ID

Самый быстрый способ получить рабочий дашборд - импортировать его по идентификатору с grafana.com. Дашборд Node Exporter Full имеет ID 1860. Это проверенный сообществом шаблон с более чем 20 панелями.

1. Наведите курсор на иконку «+» в боковом меню и выберите Import dashboard.
2. В поле Import via grafana.com введите 1860 и нажмите Load.
3. В выпадающем списке Prometheus выберите добавленный ранее источник данных.
4. Нажмите Import.

Сразу после импорта откроется дашборд с панелями: CPU Usage, Memory Usage, Disk Space Used, Network Traffic, System Load, Uptime и другими. Если данные не отображаются, проверьте временной диапазон в правом верхнем углу - по умолчанию может стоять «Last 6 hours», а сервер только что запущен.

Адаптация дашборда под свои задачи

Готовый дашборд - это основа. Рабочие нагрузки и пороговые значения у каждой инфраструктуры свои. То, что для одного сервера критично, для другого - норма. Адаптируйте панели под реальные условия эксплуатации.

Изменение порогов и цветовых схем

Цвета на панелях Grafana - не украшение, а инструмент быстрой диагностики. Правильно настроенные пороги позволяют мгновенно оценить состояние сервера. По умолчанию многие панели используют стандартные значения, которые редко подходят для продакшена.

Пример настройки порогов для панели CPU Usage:

1. Наведите курсор на панель CPU Usage и нажмите на заголовок, затем выберите Edit.
2. В правой панели редактора найдите секцию Thresholds.
3. Измените значения: установите красный цвет для значений выше 90% (вместо стандартных 80%). Добавьте оранжевый для диапазона 70-90% как предупреждение.
4. Нажмите Apply в правом верхнем углу.

Аналогично настройте пороги для памяти (красный при использовании >85% доступной памяти, а не всей, включая кэш) и дискового пространства (красный при свободном месте <10% на корневом разделе).

Добавление панели для HTTP 5xx ошибок

Метрики сервера показывают состояние железа и ОС. Но проблемы часто возникают на уровне приложения. Ошибки HTTP 5xx - прямой индикатор сбоев в работе веб-сервера или бэкенда. Добавьте отдельную панель для их отслеживания.

Создание панели для мониторинга 5xx ошибок Nginx или другого веб-сервера, метрики которого собирает Prometheus:

1. Нажмите Add panel в верхней части дашборда.
2. В поле запроса PromQL введите: rate(nginx_http_requests_total{status=~"5.."}[5m]). Этот запрос считает количество 5xx-ответов в секунду за последние 5 минут.
3. Выберите тип визуализации Stat или Time series. Для Stat крупная цифра с цветовым индикатором удобна для быстрой оценки. Для Time series - график, показывающий динамику ошибок.
4. Настройте пороги: значение > 0.1 ошибок в секунду - оранжевый, > 1 - красный.
5. Сохраните панель.

Если вы используете Nginx, рекомендуем полное руководство по созданию дашборда Nginx в Grafana с готовыми PromQL-запросами для RPS, времени ответа и кодов ошибок.

Настройка алертов в Grafana для критических событий

Визуализация полезна, когда вы смотрите на дашборд. Но администратор не может круглосуточно следить за графиками. Алерты решают эту проблему - они оповещают о проблеме в момент её возникновения. Grafana позволяет создавать правила алертов прямо на панелях дашборда, не трогая конфигурацию Alertmanager в Prometheus.

Разница между алертами в Prometheus и Grafana: Prometheus оценивает правила на своей стороне и отправляет их в Alertmanager. Grafana оценивает правила внутри себя, используя данные из подключенного источника. Для типовых пороговых алертов подход Grafana проще в настройке и не требует правки файлов конфигурации Prometheus.

Алерт на высокую загрузку CPU

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

1. Откройте панель CPU Usage на редактирование и перейдите на вкладку Alert.
2. Нажмите Create alert rule from this panel.
3. В секции Condition задайте правило: когда среднее значение метрики avg(node_cpu_seconds_total{mode!="idle"}) превышает 0.9 (то есть 90%) в течение 5 минут.
4. В секции Evaluation behavior укажите проверку каждые 1 минуту и период ожидания 5 минут - это предотвратит ложные срабатывания при кратковременных всплесках.
5. Добавьте аннотации: Summary - «Высокая загрузка CPU на сервере», Description - «Загрузка CPU превысила 90% на протяжении 5 минут. Текущее значение: {{ $values }}».

Алерт на нехватку оперативной памяти

Нехватка памяти опаснее высокой загрузки CPU. Когда памяти не хватает, система начинает использовать swap, и производительность падает в десятки раз. При полном исчерпании памяти OOM-killer принудительно завершает процессы.

Критически важно мониторить не просто используемую память (куда входит кэш), а доступную. Метрика node_memory_MemAvailable_bytes показывает, сколько памяти реально доступно для новых процессов с учетом кэша и буферов.

1. Создайте новую панель или используйте существующую панель Memory Usage.
2. В правиле алерта используйте выражение: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.15. Это сработает, когда доступно менее 15% памяти.
3. Установите период ожидания 5 минут.

Алерт на заполнение дискового пространства

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

1. Используйте метрику node_filesystem_free_bytes{mountpoint="/"} для корневого раздела.
2. Настройте два уровня: предупреждение при свободном месте < 20% и критический алерт при < 10%.
3. Для прогнозирования можно использовать функцию predict_linear: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 24 * 3600) < 0. Это предскажет заполнение диска за 24 часа на основе тренда за последний час.

Алерт на ошибки HTTP 5xx

Ошибки 5xx означают, что веб-сервер или приложение не могут обработать запросы. В отличие от метрик ресурсов, здесь порог часто ненулевой: даже одна 500-я ошибка в минуту может говорить о серьезной проблеме после деплоя.

1. Создайте правило на основе запроса: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 0.1.
2. Установите минимальный период ожидания 1-2 минуты - ошибки 5xx редко бывают случайными всплесками.
3. В аннотации добавьте контекст: имя сервера, текущий rate ошибок, ссылку на дашборд для быстрой диагностики.

Настройка каналов уведомлений

Алерт без доставки бесполезен. Grafana поддерживает отправку уведомлений в Slack, Telegram, email и десятки других сервисов через интеграцию с Alertmanager или собственные contact points.

1. Перейдите в Alerting → Contact points.
2. Нажмите New contact point и выберите тип, например, Slack.
3. Укажите Webhook URL вашего Slack-канала и настройте формат сообщения.
4. Создайте Notification policy в разделе Alerting → Notification policies, чтобы связать алерты с contact point.

Для продакшен-среды настройте эскалацию: если алерт не закрыт в течение 15 минут, отправляйте повторное уведомление или эскалируйте на резервный канал.

Практические советы и типичные проблемы

За годы работы с Grafana и Prometheus мы собрали типичные проблемы, с которыми сталкиваются администраторы при настройке мониторинга.

Дашборд показывает No Data. Самая частая причина - Prometheus не видит target. Проверьте в веб-интерфейсе Prometheus (обычно порт 9090) вкладку Status → Targets. Если target в состоянии DOWN, проверьте сетевую доступность порта 9100 на целевом сервере и настройки файрвола. Вторая причина - несовпадение временных меток. Убедитесь, что на сервере с Prometheus, сервере с Node Exporter и сервере с Grafana синхронизировано время через NTP.

Метрики есть, но значения не совпадают с реальностью. Node Exporter по умолчанию собирает данные с момента своего запуска. Для счетчиков (например, CPU) Grafana использует функцию rate, которая вычисляет изменение за промежуток времени. Если вы только что запустили Node Exporter, дайте ему поработать хотя бы 5-10 минут для накопления данных.

Обновление дашборда до новой версии. Разработчики дашборда Node Exporter Full периодически выпускают обновления. Чтобы не потерять свои кастомизации при обновлении, сохраните дашборд в JSON (Dashboard settings → JSON Model → скопировать) перед импортом новой версии. После импорта можно перенести свои панели через копирование JSON-блоков.

Версионирование дашбордов. Включите встроенное версионирование в Grafana: Dashboard settings → Versions. Grafana автоматически сохраняет версии при каждом изменении, и вы всегда можете откатиться к предыдущей. Для инфраструктурного кода храните JSON-модель дашборда в Git-репозитории и применяйте изменения через Grafana API или Terraform.

Для мониторинга кластерной инфраструктуры с несколькими серверами посмотрите руководство по развертыванию мониторинга кластеров с Prometheus и Grafana. Там разобраны готовые дашборды для Pacemaker и Ceph.

Если вам нужна облачная инфраструктура для развертывания стека мониторинга, обратите внимание на Timeweb Cloud - облачные серверы с гибким масштабированием ресурсов и поддержкой Kubernetes.