Системы мониторинга производительности 2026: от CLI-утилит до Prometheus и Grafana

Когда сервер "тормозит" или приложение не отвечает, время на диагностику ограничено. В 2026 году подход к мониторингу остается двухуровневым: быстрые CLI-утилиты для немедленной оценки ситуации и полноценный стек Prometheus/Grafana для постоянного наблюдения, анализа трендов и проактивного алертинга. Это практическое руководство проведет вас по всем этапам — от первой команды top до развертывания отказоустойчивой системы мониторинга с информативными дашбордами и автоматическими уведомлениями. Вы получите готовые конфигурации, примеры алерт-правил и советы по оптимизации, проверенные в рабочих средах.

С чего начать: быстрая диагностика состояния сервера CLI-утилитами

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

top и htop: первичный анализ нагрузки на CPU и память

Утилита top — это первое, что запускает системный администратор при подозрении на проблему. Она показывает общую картину нагрузки. Более продвинутая альтернатива — htop (часто требует установки), которая предоставляет цветовую подсветку и удобную навигацию.

Ключевые метрики в выводе top:

• load average: средняя нагрузка за 1, 5 и 15 минут. Критическое значение — когда нагрузка превышает количество ядер CPU. Например, load average 8.0 на 4-ядерном процессоре сигнализирует о постоянной очереди задач.
• %CPU: загрузка каждого процесса. Сортировка по этому полю (клавиша P) сразу выявляет "пожирателей" процессорного времени.
• %MEM: доля оперативной памяти, занимаемая процессом. Сортировка по памяти (клавиша M) помогает найти утечки.

Практические команды для быстрого анализа:

# Запуск top с сортировкой по CPU с самого начала
top -o %CPU
# Запуск top в режиме одного снимка (полезно для скриптов)
top -b -n 1 | head -20
# Если установлен htop, он дает более наглядную картину
htop

vmstat и iostat: глубокая диагностика памяти и дискового ввода-вывода

Проблемы со свопом (подкачкой) или дисковым IO часто неочевидны в top. Здесь на помощь приходят vmstat (virtual memory statistics) и iostat (I/O statistics).

Анализ памяти и свопа с vmstat:

# Запуск с интервалом 2 секунды, 5 отчетов
vmstat 2 5

Важные колонки в выводе:

• swpd: объем использованной виртуальной памяти (свопа). Если значение постоянно растет — физической памяти не хватает.
• si (swap in), so (swap out): количество данных, считываемых с диска в память и выгружаемых на диск. Высокие значения (сотни в секунду) — явный признак нехватки RAM, что катастрофически замедляет систему.
• bi, bo: блоки, считанные с диска и записанные на диск. Помогают оценить общую активность IO.

Диагностика дискового подсистемы с iostat:

# Показать статистику по всем устройствам с интервалом 2 секунды
iostat -x 2

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

• %util: процент загрузки устройства. Значения, стабильно превышающие 80-90%, указывают на то, что диск стал узким местом.
• await: среднее время (в мс) выполнения запросов ввода-вывода. Высокий await при высоком %util подтверждает проблему с производительностью диска.
• r/s, w/s: количество операций чтения и записи в секунду.

Сочетание этих утилит позволяет за минуты отличить проблему с нехваткой памяти (высокие si/so в vmstat) от проблемы с диском (высокие %util и await в iostat).

Переход к постоянному мониторингу: зачем нужен стек Prometheus и Grafana

CLI-утилиты незаменимы для оперативной диагностики, но у них есть фундаментальные ограничения: нет истории данных, нельзя настроить автоматические уведомления, сложно отслеживать десятки серверов одновременно. Когда вам нужно не просто "потушить пожар", а предотвратить его, понять тренды (например, как растет использование диска) и централизованно наблюдать за всей инфраструктурой, необходим переход на систему постоянного мониторинга.

Стек Prometheus и Grafana в 2026 году остается де-факто стандартом для этого. Prometheus отвечает за сбор, хранение временных рядов и обработку правил алертинга. Grafana — мощный инструмент для визуализации собранных метрик в виде дашбордов. Переходить на такой стек стоит, когда количество серверов превышает 3-5, а требования к надежности и проактивному реагированию становятся критичными.

Развертывание и базовая настройка Prometheus для сбора метрик

Развертывание Prometheus — straightforward-процесс. Приведем два проверенных способа, подходящих для разных сред.

Установка Prometheus: два проверенных способа

Способ 1: Установка из официального архива (рекомендуется для полного контроля).

# Скачивание актуальной версии (актуально на апрель 2026)
wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz
# Распаковка
tar xvf prometheus-2.47.0.linux-amd64.tar.gz
cd prometheus-2.47.0.linux-amd64/
# Создание системного пользователя
sudo useradd --no-create-home --shell /bin/false prometheus
# Копирование бинарников и конфигов
sudo cp prometheus promtool /usr/local/bin/
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool
sudo mkdir /etc/prometheus /var/lib/prometheus
sudo cp -r consoles/ console_libraries/ prometheus.yml /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus

Создаем systemd-юнит для автозапуска (/etc/systemd/system/prometheus.service):

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
    --config.file /etc/prometheus/prometheus.yml \
    --storage.tsdb.path /var/lib/prometheus/ \
    --web.console.templates=/etc/prometheus/consoles \
    --web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

Запускаем: sudo systemctl daemon-reload && sudo systemctl start prometheus && sudo systemctl enable prometheus.

Способ 2: Установка через пакетный менеджер (быстрее, но версия может быть чуть старше).

# Для Ubuntu/Debian
sudo apt update
sudo apt install prometheus
# Для CentOS/RHEL 8+
sudo dnf install prometheus

Проверяем работоспособность: systemctl status prometheus и открываем в браузере http://your-server-ip:9090. Должен появиться веб-интерфейс Prometheus.

Конфигурация prometheus.yml: понимание scrape_configs

Сердце Prometheus — файл конфигурации /etc/prometheus/prometheus.yml. Его ключевая часть — секция scrape_configs, где описывается, какие метрики и откуда собирать.

global:
  scrape_interval: 15s      # Как часто собирать метрики с таргетов
  evaluation_interval: 15s  # Как часто оценивать правила алертов

# Конфигурации для сбора метрик
scrape_configs:
  # Job для мониторинга самого Prometheus
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Job для мониторинга Linux-серверов (будет добавлен позже)
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']  # Адрес node_exporter

Важно соблюдать отступы в YAML. Параметр targets содержит список хостов и портов, с которых Prometheus будет считывать метрики в формате OpenMetrics.

Сбор данных с серверов и сервисов: работа с экспортерами

Prometheus сам по себе не умеет собирать метрики с приложений или ОС. Для этого используются экспортеры — небольшие программы, которые "переводят" внутренние метрики сервиса в понятный Prometheus формат и отдают их по HTTP на специальном порту.

Node Exporter: сбор метрик операционной системы

Node Exporter — главный экспортер для сбора метрик с Linux-сервера (CPU, память, диск, сеть, нагрузка). Установка аналогична Prometheus:

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar xvf node_exporter-*.tar.gz
sudo cp node_exporter-*/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

Создаем systemd-юнит и запускаем службу. По умолчанию node_exporter слушает порт 9100. Проверьте доступность метрик: curl http://localhost:9100/metrics.

Теперь нужно добавить этот таргет в Prometheus. В секцию scrape_configs файла prometheus.yml добавляем или редактируем job 'node':

  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100', 'server2-ip:9100', 'server3-ip:9100']
        labels:
          datacenter: 'msk1'

После изменения конфига перезагрузите Prometheus: sudo systemctl reload prometheus.

Мониторинг веб-сервисов и баз данных: специализированные экспортеры

Для мониторинга прикладного уровня существуют десятки экспортеров. Принцип настройки един:

1. Установите и запустите экспортер рядом с мониторируемым сервисом.
2. Настройте его (часто через переменные окружения или флаги командной строки) для подключения к сервису.
3. Добавьте новый job в prometheus.yml.

Популярные экспортеры:

• mysqld_exporter / postgres_exporter: метрики баз данных (количество соединений, медленные запросы, размеры таблиц).
• nginx-exporter / apache-exporter: метрики веб-серверов (запросы в секунду, статус-коды, время ответа).
• cadvisor: детальные метрики по Docker-контейнерам (CPU, память, сеть, диск на уровне контейнера). Для комплексного мониторинга Docker-инфраструктуры также полезно ознакомиться с полной шпаргалкой по управлению и мониторингу Docker-контейнеров.
• blackbox_exporter: мониторинг доступности сервисов "снаружи" (HTTP, TCP, ICMP пробы).

Пример добавления job для mysqld_exporter (предполагается, что он запущен на порту 9104):

  - job_name: 'mysql'
    static_configs:
      - targets: ['dbserver-ip:9104']

Визуализация данных: создание информативных дашбордов в Grafana

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

Подключение Grafana к Prometheus и основы PromQL

Установите Grafana согласно официальной инструкции для вашего дистрибутива. После запуска (обычно порт 3000) выполните первоначальную настройку и добавьте источник данных (Data Source):

1. В меню выберите Connections > Data sources.
2. Нажмите "Add data source" и выберите "Prometheus".
3. В поле URL укажите адрес вашего Prometheus, например, http://localhost:9090.
4. Сохраните и протестируйте подключение.

Для построения графиков используется язык запросов Prometheus (PromQL). Базовые примеры:

• Текущая нагрузка: node_load1
• Использование CPU (процент): 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)
• Свободная оперативная память в ГБ: node_memory_MemFree_bytes / 1024 / 1024 / 1024

Функция rate() вычисляет скорость изменения метрики за указанный интервал (например, [1m]), что необходимо для счетчиков (counters), которые только растут.

Создание и настройка дашборда для системного администратора

Создайте новый дашборд и добавьте панели для ключевых метрик. Структура полезного дашборда "Общее состояние сервера":

1. Load Average (график): node_load1, node_load5, node_load15.
2. Использование CPU по ядрам (график): 100 - (avg by (cpu) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)
3. Оперативная и swap-память (гаджеты или график):
   Использовано RAM: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / 1024 / 1024 / 1024
   Использовано Swap: node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes
4. Дисковое пространство (таблица или гаджеты): node_filesystem_avail_bytes{mountpoint="/"} / 1024 / 1024 / 1024
5. Сетевой трафик (график):
   Входящий: rate(node_network_receive_bytes_total{device="eth0"}[1m]) * 8 (в битах)
   Исходящий: rate(node_network_transmit_bytes_total{device="eth0"}[1m]) * 8

Для экономии времени можно импортировать готовые дашборды из официальной библиотеки Grafana. Например, дашборд Node Exporter Full (ID: 1860) предоставляет исчерпывающий обзор метрик ОС.

Предупреждение о проблемах: настройка алерт-правил в Prometheus

Мониторинг без алертов — это просто архив данных. Prometheus позволяет определять условия, при превышении которых генерируется алерт. Эти алерты затем отправляются в Alertmanager для рассылки уведомлений.

Примеры критических алерт-правил для сервера

Создайте файл с правилами, например, /etc/prometheus/rules/server_rules.yml:

groups:
  - name: server_alerts
    rules:
      # Высокая нагрузка (больше 80% от числа ядер за 5 минут)
      - alert: HighLoadAverage
        expr: node_load1 / count(node_cpu_seconds_total{mode="idle"}) > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокая нагрузка на {{ $labels.instance }}"
          description: "Load average 1m = {{ $value }}. Превышает 80% от числа ядер."

      # Мало свободной памяти (менее 10%)
      - alert: LowMemoryAvailable
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Мало свободной памяти на {{ $labels.instance }}"
          description: "Доступно {{ $value | humanizePercentage }} памяти."

      # Диск заполняется (свободно менее 15%)
      - alert: DiskSpaceFilling
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Мало свободного места на диске {{ $labels.instance }}"
          description: "На mountpoint {{ $labels.mountpoint }} свободно {{ $value | humanizePercentage }}."

      # Сервис (экспортер) недоступен
      - alert: NodeExporterDown
        expr: up{job="node"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: node_exporter недоступен"
          description: "Проверьте состояние службы node_exporter на сервере."

Подключите файл правил в prometheus.yml, добавив секцию:

rule_files:
  - "rules/server_rules.yml"

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

Alertmanager получает алерты от Prometheus и занимается их группировкой, подавлением дубликатов и рассылкой. Установите Alertmanager аналогично Prometheus. Ключевой файл — alertmanager.yml.

Пример конфигурации для отправки в Telegram (предполагается, что бот уже создан):

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'telegram-notifications'

receivers:
- name: 'telegram-notifications'
  telegram_configs:
  - bot_token: 'YOUR_BOT_TOKEN'
    chat_id: YOUR_CHAT_ID
    parse_mode: 'HTML'
    message: '{{ range .Alerts }}[{{ .Status | toUpper }}] {{ .Labels.severity | toUpper }}
{{ .Annotations.summary }}
{{ .Annotations.description }}
{{ end }}'

В prometheus.yml укажите адрес Alertmanager:

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - 'localhost:9093'  # Порт Alertmanager по умолчанию

После перезагрузки Prometheus и Alertmanager система начнет генерировать и отправлять уведомления. Для отладки сложных инцидентов, особенно в распределенных системах, полезны навыки глубокой диагностики, например, описанные в руководстве по полной диагностике Custom Resources в Kubernetes.

Поддержка и оптимизация инфраструктуры мониторинга

Развернутый стек мониторинга сам требует наблюдения и оптимизации, особенно при масштабировании.

Оценка нагрузки и поиск узких мест в стеке

Prometheus предоставляет богатые метрики о своей собственной работе. Ключевые из них для мониторинга:

• prometheus_tsdb_head_samples_appended_total: скорость добавления новых образцов (samples). Резкий рост может указывать на добавление новых таргетов или экспортеров с высоким cardinality метрик.
• prometheus_target_scrape_duration_seconds: длительность сбора метрик с каждого таргета. Высокие значения могут говорить о проблемах с сетью или производительностью экспортера.
• process_resident_memory_bytes: потребление оперативной памяти самим Prometheus. Рост сверх ожидаемого может быть связан с большим количеством активных временных рядов.

Настройте политику хранения данных (--storage.tsdb.retention.time). По умолчанию Prometheus хранит данные 15 дней. Для долгосрочного хранения (месяцы, годы) рассмотрите использование remote storage (Thanos, Cortex).

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

Проблема 1: Рост времени выполнения запросов в Grafana.
Решение: Включите кэширование запросов в Grafana. Разделяйте дашборды: общие дашборды высокого уровня и детальные — для глубокого анализа конкретных сервисов. Используйте запросы с разумными временными диапазонами.

Проблема 2: Огромный объем данных и медленная работа Prometheus.
Решение: Настройте retention в соответствии с реальными потребностями. Для горизонтального масштабирования используйте архитектуру с remote write/read, где несколько Prometheus-серверов пишут данные в централизованное хранилище (например, Thanos Receiver).

Проблема 3: Управление сотнями конфигураций таргетов.
Решение: Откажитесь от статических конфигов в пользу service discovery. Prometheus поддерживает автоматическое обнаружение таргетов в Kubernetes, AWS EC2, Consul, Azure и через файлы. Например, файловое SD позволяет динамически обновлять список таргетов, что упрощает управление в гибридных средах.

Не забывайте регулярно делать бэкапы конфигурационных файлов Prometheus, правил алертов и дашбордов Grafana (их можно экспортировать в JSON). Внедрение мониторинга — это итеративный процесс. Начните с ключевых метрик, убедитесь в стабильности работы стека, а затем постепенно расширяйте его функциональность, добавляя новые экспортеры и дашборды.