Grafana полезна не только в офисе: домашняя лаборатория из пары серверов, NAS и роутера даёт достаточно метрик, чтобы заметить перегрев диска, заполнение раздела или отвалившийся аплинк раньше, чем это станет проблемой. В статье — практический подход к дашбордам для дома: какие метрики собирать, как оформить панели, как вынести конфигурацию в файлы и не утонуть в графиках.

Что измерять дома

Начните с вопросов, на которые дашборд должен отвечать: работает ли сервис, хватает ли места, не перегревается ли железо, не растёт ли latency до интернета. Под каждый вопрос нужен один-два графика, а не двадцать. Базовый набор для Linux-хоста: загрузка CPU, доступная память, свободное место, температура, сетевой трафик и состояние дисков. Для роутера добавьте доступность WAN и потери пакетов, для NAS — состояние массива и SMART.

Источники обычно такие: node_exporter на серверах, blackbox_exporter для проверки HTTP и ICMP, smartctl_exporter для дисков, snmp_exporter для роутера или ИБП. Prometheus собирает метрики, Grafana только отображает. Это разделение важно: дашборд не должен быть единственным местом, где хранится история.

Источник данных и провижининг

Ручное добавление datasource через веб-интерфейс удобно один раз, но при переустановке всё приходится повторять. Grafana умеет читать описание источника из YAML при старте. Положите файл в каталог provisioning/datasources и подключите его в контейнере или пакетной установке.

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    jsonData:
      timeInterval: 30s
      httpMethod: POST

timeInterval должен соответствовать шагу сбора. Если Prometheus опрашивает цели раз в 30 секунд, а Grafana строит графики с шагом 10 секунд, вы получите ступеньки и лишние точки. Для домашней лаборатории разумны 15–30 секунд: чаще — больше нагрузка и объём, реже — можно пропустить короткий всплеск.

Панели, которые действительно читаются

Верхняя строка дашборда — обзор: состояние целей, загрузка CPU, память, место. Ниже — детали по разделам. Используйте понятные единицы (проценты, байты, градусы), фиксируйте минимальное и максимальное значение у процентных шкал и включайте пороги. Красная линия на 90% свободного места полезнее, чем ещё один график.

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

Формула памяти должна учитывать кэш: используйте MemAvailable, а не MemFree. Для диска берите отношение доступного места к размеру и фильтруйте служебные файловые системы, иначе tmpfs и loop-устройства испортят картину.

100 * node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes
100 * node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{mountpoint="/",fstype!~"tmpfs|overlay"}
100 * rate(node_network_receive_bytes_total{device="eth0"}[5m]) * 8 / 1e6

Для температуры имя метрики зависит от драйвера: node_hwmon_temp_celsius есть не на всех системах, иногда доступна node_thermal_zone_temp. Проверьте фактические ряды через Explore, а не копируйте запрос из чужой статьи. Для дисков полезны rate(node_disk_io_time_seconds_total[5m]) и прогноз заполнения через predict_linear.

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 7*24*3600) < 0
max by(instance) (node_hwmon_temp_celsius)
probe_success{job="blackbox_http"}

Переменные вместо копий дашборда

Если серверов несколько, не создавайте отдельный дашборд на каждый. Переменная instance с запросом label_values позволяет переключать хост в одном селекторе, а повторение панелей через Multi-value и All даёт сравнение. Для аккуратной фильтрации используйте label_values(node_uname_info, instance) — эта метрика стабильно содержит нужные метки.

label_values(node_uname_info, instance)
label_values(node_filesystem_avail_bytes, mountpoint)
label_values(up{job="node"}, instance)

Не делайте переменную по job, если целей десятки: список станет нечитаемым. Лучше одна переменная по instance и отдельная по job, а в запросах используйте $instance и $job. Для повторяющихся панелей включите Repeat by и не забудьте ограничить число значений.

Пороги, аннотации и время

Порог — это не только красная линия, но и подсказка. В настройках панели задайте Thresholds: зелёный до 70%, жёлтый до 85%, красный выше. Для температуры домашнего сервера разумны 60 и 75 градусов, но ориентируйтесь на спецификацию железа. Не ставьте порог на 100% свободного места: такой график всегда будет тревожным.

Аннотации отмечают события: перезагрузку, обновление, замену диска. Проще всего отправлять их через HTTP API Grafana из скрипта или CI. Тогда на графике видно, что рост нагрузки совпал с миграцией, и не приходится сверять время вручную. Ещё одна полезная настройка — относительный диапазон времени по умолчанию, например последние 6 часов, чтобы дашборд открывался с осмысленным контекстом.

Дашборды как код

Готовый дашборд экспортируйте в JSON и храните в git. Grafana умеет автоматически подхватывать файлы из каталога provisioning/dashboards: при старте она создаёт или обновляет дашборды в указанной папке. Это защищает от потери настроек и позволяет review изменений.

apiVersion: 1
providers:
  - name: home
    folder: Home
    type: file
    disableDeletion: false
    updateIntervalSeconds: 30
    options:
      path: /var/lib/grafana/dashboards

В JSON не храните секреты и не привязывайтесь к конкретному uid источника данных: используйте переменную datasource. Если дашборд импортирован вручную, при следующем обновлении из файла изменения могут перезаписаться. Договоритесь, что источник истины — репозиторий, а веб-интерфейс только для экспериментов.

Оповещения и разумная нагрузка

Оповещения лучше держать в Prometheus или Grafana Alerting, но не дублировать одно правило в двух местах. Для дома достаточно трёх-пяти правил: хост недоступен, диск заполнен, температура выше порога, SMART показывает ошибку, истёк срок резервной копии. Остальное — информационные графики.

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

Чек-лист хорошего домашнего дашборда:

  • на первом экране видно, всё ли работает;
  • у каждой панели есть единицы и понятное имя;
  • пороги соответствуют реальному железу;
  • есть фильтр по хосту, но нет дублирующих дашбордов;
  • конфигурация и JSON лежат в git;
  • алерты не срабатывают на каждый перезапуск;
  • объём метрик контролируется.

Итог

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

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте