Погодин Евгений — ИТ Заметки
🐧Linux Обновлено 04.11.2026

Linux для админа Windows 16. Мониторинг: Prometheus, node_exporter и Grafana

Note

Материал сверен с официальной документацией (Ubuntu Server, man-страницы и документация проектов; ссылки — в конце статьи). Примеры вывода — иллюстрации: на вашем сервере значения и формат могут отличаться. Перед работой на боевом сервере проверьте команды на тестовой машине.

В Windows за состоянием сервера следят Диспетчер задач и Монитор производительности (PerfMon), а в организациях ещё и система мониторинга вроде Zabbix. На Linux популярен другой набор: Prometheus собирает числовые показатели и хранит их историю, node_exporter отдаёт показатели самого сервера, Grafana рисует графики. В этой статье вы:

  • разберётесь, как устроена модель pull и что такое метрика, временной ряд и метка;
  • поставите node_exporter на два сервера и Prometheus на lnx1;
  • напишете первые запросы на языке PromQL и правило оповещения up == 0, проверите его;
  • подключите Grafana и закроете порты 9090, 9100 и 3000 от посторонних.
Что смотрим Windows (PerfMon) Prometheus и node_exporter
Загрузка процессора объект Processor node_cpu_seconds_total с функцией rate()
Память объект Memory node_memory_MemAvailable_bytes, node_memory_MemTotal_bytes
Место на диске объект LogicalDisk node_filesystem_avail_bytes, node_filesystem_size_bytes
Сеть объект Network Interface node_network_receive_bytes_total
История и оповещения наборы сборщиков данных, внешняя система мониторинга Prometheus хранит историю, правила и Alertmanager оповещают

Что нужно знать заранее

Примеры рассчитаны на Ubuntu Server 24.04 LTS. Раздел Observability документации Ubuntu Server рекомендует Canonical Observability Stack (COS): он построен на Juju и Kubernetes, и это отдельная большая тема. Классический стек LMA (Logging, Monitoring, Alerting) там назван более не рекомендуемым, его описание будет объявлено устаревшим для 26.04 LTS и новее. Для небольшого стенда мы выбираем компоненты проектов напрямую. В репозитории Ubuntu 24.04 есть пакеты prometheus и prometheus-node-exporter: они ставятся одной командой apt, но версии старше проектных, а пути и параметры задаёт упаковщик (в 26.04 LTS пакеты новее — проверьте apt policy <пакет> и документацию выпуска). Мы берём Prometheus и node_exporter из архивов проекта, чтобы пути, параметры и версии совпадали с его документацией. Обновлять их придётся самим: проект стремится выпускать исправления безопасности в течение 7 дней. Пакета grafana в репозитории Ubuntu нет (проверьте apt policy grafana): Grafana ставят из репозитория проекта.

Warning

Адреса в примерах учебные: lnx1 — 192.168.10.20 (сервер мониторинга), lnx2 — 192.168.10.21 (наблюдаемый). Подставьте свои. Правила ufw из статьи нужны, только если он включён: на lnx1 он включён (статья про ufw), состояние lnx2 описано во врезке «Состояние стенда» в статье про Ansible. Включайте ufw по порядку: сначала правило для SSH, потом ufw enable, консоль виртуальной машины держите открытой. Порты Prometheus, node_exporter и Grafana не открывают в интернет ни в каком виде.

Как это устроено

Метрика — числовое измерение: загрузка процессора, свободные байты на диске. Временной ряд (time series) — значения метрики во времени. К значениям прикреплены метки (labels, пары «ключ — значение»): диск, режим процессора и другие. Среди них всегда видны job (имя группы целей из конфигурации) и instance (адрес хост:порт цели).

Prometheus работает по модели pull: сам обходит заданные цели (targets) по HTTP и забирает у каждой страницу /metrics с текущими значениями. Цель, которая отдаёт такие данные, называется экспортёром (exporter). Для Linux-сервера это node_exporter: он читает показатели ядра и отдаёт их как node_.... Для Windows существует отдельный windows_exporter: node_exporter рассчитан на Unix-подобные системы.

 lnx1 (192.168.10.20)                          lnx2 (192.168.10.21)
 +--------------------------------+            +---------------------+
 | Grafana :3000                  |            |                     |
 |    | запросы PromQL            |   опрос    |  node_exporter      |
 |    v                           |   (pull)   |  :9100  /metrics    |
 | Prometheus :9090 --------------+----------->|                     |
 |    ^  опрос                    |            +---------------------+
 |    +-- node_exporter :9100     |
 +--------------------------------+

Метрики бывают разных типов. Счётчик (counter) только растёт или обнуляется при перезапуске: node_cpu_seconds_total, сколько секунд процессор провёл в каждом режиме. Датчик (gauge) может расти и падать: node_memory_MemAvailable_bytes. Скорость изменения счётчика даёт функция rate(). Когда вы видите на графике загрузку в процентах, это результат запроса на PromQL (Prometheus Query Language), а не сырое значение.

Оповещения делятся на две части. Правила в самом Prometheus решают, что сломалось, и отправляют сигнал в Alertmanager. Он объединяет оповещения, ограничивает частоту уведомлений, позволяет «заглушать» оповещения и рассылает уведомления получателям. Графики рисует Grafana: у самого Prometheus есть лишь простая страница запросов.

Порты и стенд

Порт Что слушает Кто должен подключаться
9100 node_exporter (по умолчанию на всех интерфейсах) только Prometheus на lnx1
9090 сервер Prometheus (по умолчанию на всех интерфейсах) только сам lnx1 и Grafana на нём
3000 Grafana (по умолчанию на всех интерфейсах) администраторы через туннель SSH или nginx
9093 Alertmanager только Prometheus

Порты 9090, 9100 и 3000 — значения по умолчанию. Alertmanager в статье дан обзорно: порт 9093 указан в примере prometheus.yml из архива Prometheus.

node_exporter

Ставим на lnx2 и на lnx1 (так мы увидим и сервер мониторинга). Номер версии подставьте актуальный со страницы Releases проекта на GitHub. Рядом с архивом лежит файл с контрольными суммами: проверьте архив до установки. Это защита от повреждённой загрузки, а не от подмены на стороне сайта: источник и номер версии проверяйте сами.

VER=1.12.1   # на 04.11.2026: проверьте последний выпуск на странице Releases
BASE=https://github.com/prometheus/node_exporter/releases/download/v$VER
mkdir -p ~/ne-dl && cd ~/ne-dl
wget $BASE/node_exporter-$VER.linux-amd64.tar.gz $BASE/sha256sums.txt
sha256sum --check --ignore-missing sha256sums.txt

Должна появиться строка node_exporter-1.12.1.linux-amd64.tar.gz: OK. Если контрольная сумма не сходится, дальше не идите. Архив в примере для процессоров amd64, для других архитектур выберите свой. Установите бинарный файл и заведите системного пользователя без входа (статья про systemd разбирает этот приём; при повторе useradd сообщит, что пользователь уже есть, и эту команду можно пропустить):

tar xzf node_exporter-$VER.linux-amd64.tar.gz
sudo install -m 755 node_exporter-$VER.linux-amd64/node_exporter \
  /usr/local/bin/
sudo useradd --system --no-create-home --shell /usr/sbin/nologin \
  node_exporter

Юнит /etc/systemd/system/node_exporter.service (создайте через sudo nano). Опция --web.listen-address задаёт адрес и порт, на которых слушает экспортёр. На lnx1 Prometheus опрашивает его через localhost, поэтому вместо <АДРЕС> впишите 127.0.0.1. На lnx2 его опрашивает другой сервер, поэтому впишите адрес lnx2, 192.168.10.21. Юнит ждёт сеть через network-online.target: без этого после перезагрузки служба могла бы стартовать раньше, чем появится адрес, и не запуститься.

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

[Service]
Type=exec
User=node_exporter
ExecStart=/usr/local/bin/node_exporter --web.listen-address=<АДРЕС>:9100
Restart=on-failure
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
curl -s http://127.0.0.1:9100/metrics | grep -m 3 '^node_load'
sudo ss -tlnp | grep 9100

Пример вывода на lnx1 (значения вымышленные):

node_load1 0.15
node_load15 0.19
node_load5 0.22
LISTEN 0 4096 127.0.0.1:9100 0.0.0.0:* users:(("node_exporter",pid=2410,fd=3))

На lnx2 curl обращайтесь к 192.168.10.21:9100, и ss покажет этот адрес. Без опции --web.listen-address порт был бы открыт на всех адресах (*:9100). Если на lnx2 включён ufw, добавьте и правило: порт разрешён одному адресу сервера мониторинга.

sudo ufw allow proto tcp from 192.168.10.20 to any port 9100

Проверка: curl -s http://192.168.10.21:9100/metrics | head -3 с lnx1 должна отвечать, с любого другого узла нет. Откат: уберите опцию из юнита, выполните sudo systemctl daemon-reload и sudo systemctl restart node_exporter; правило ufw удалите по номеру (sudo ufw status numbered, затем sudo ufw delete <НОМЕР>). По умолчанию включены коллекторы процессора, памяти, дисков, файловых систем, сети и другие. Коллектор systemd (состояние служб) выключен: документация советует включать дополнительные коллекторы по одному и проверять на тестовой системе.

Prometheus

Загрузите и проверьте архив на lnx1 так же, как для node_exporter (архив содержит prometheus, promtool и пример prometheus.yml). Заведение пользователя при повторе можно пропустить:

VER=3.15.1   # на 04.11.2026: проверьте последний выпуск на странице Releases
BASE=https://github.com/prometheus/prometheus/releases/download/v$VER
mkdir -p ~/prom-dl && cd ~/prom-dl
wget $BASE/prometheus-$VER.linux-amd64.tar.gz $BASE/sha256sums.txt
sha256sum --check --ignore-missing sha256sums.txt
tar xzf prometheus-$VER.linux-amd64.tar.gz
cd prometheus-$VER.linux-amd64
sudo install -m 755 prometheus promtool /usr/local/bin/
sudo useradd --system --no-create-home --shell /usr/sbin/nologin prometheus
sudo install -d /etc/prometheus
sudo install -d -o prometheus -g prometheus /var/lib/prometheus

Конфигурация /etc/prometheus/prometheus.yml:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']

  - job_name: node
    static_configs:
      - targets: ['localhost:9100', '192.168.10.21:9100']

scrape_interval задаёт, как часто опрашивать цели, evaluation_interval — как часто вычислять правила. В scrape_configs каждая работа (job_name) получает список целей static_configs: мы опрашиваем сам Prometheus и два node_exporter. Проверьте файл до запуска:

promtool check config /etc/prometheus/prometheus.yml

Ответ должен содержать слово SUCCESS (формат зависит от версии). Теперь юнит /etc/systemd/system/prometheus.service. Опция --web.listen-address=127.0.0.1:9090 решает важную задачу безопасности: по умолчанию Prometheus слушает все интерфейсы (0.0.0.0:9090), а мы оставляем только локальный адрес.

[Unit]
Description=Prometheus server

[Service]
Type=exec
User=prometheus
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=127.0.0.1:9090
Restart=on-failure
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now prometheus
promtool check healthy
sudo ss -tlnp | grep 9090

Если срок хранения не задан, данные хранятся 15 дней. Веб-интерфейс слушает только 127.0.0.1, поэтому с PC1 откройте его через туннель SSH, а затем http://localhost:9090:

ssh -N -L 9090:127.0.0.1:9090 lnx1

Алиас lnx1 взят из файла config из статьи про SSH; без него команда такая: ssh -N -L 9090:127.0.0.1:9090 admin-lab@192.168.10.20. Откройте раздел Status, Target health (адрес /targets): все три цели должны быть в состоянии UP. Если цель DOWN, проверьте, что node_exporter работает и порт не закрыт брандмауэром.

Первые запросы PromQL

Откройте страницу запросов (адрес /query, в более старых выпусках /graph) и по очереди введите запросы из таблицы. Они собраны из имён метрик node_exporter.

Что показывает Запрос
Жива ли цель: 1 — да, 0 — нет up
Загрузка процессора, % 100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
Занятая память, % 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100)
Свободное место на ext4, % node_filesystem_avail_bytes{fstype="ext4"} / node_filesystem_size_bytes{fstype="ext4"} * 100
Принято по сети, байт/с rate(node_network_receive_bytes_total[1m])

Как читать второй запрос. node_cpu_seconds_total{mode="idle"} — счётчик секунд простоя, фигурные скобки фильтруют по метке. [5m] берёт значения за пять минут, rate() превращает их в «секунд простоя в секунду», то есть долю простоя каждого ядра. avg by (instance) усредняет по ядрам, а 100 * (1 - ...) переводит остаток в проценты занятости. rate() применяют только к счётчикам. Результат запроса up выглядит примерно так:

up{instance="192.168.10.21:9100", job="node"}   1
up{instance="localhost:9090", job="prometheus"} 1
up{instance="localhost:9100", job="node"}       1

Правило оповещения

Правила лежат в отдельном файле. Создайте /etc/prometheus/alerts.yml:

groups:
  - name: servers
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Цель {{ $labels.instance }} недоступна"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{fstype="ext4"}
            / node_filesystem_size_bytes{fstype="ext4"} * 100 < 10
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Мало места на {{ $labels.mountpoint }}"

Выражение в expr описывает условие: оповещение активно для каждого ряда, где оно истинно. for: 5m заставляет Prometheus подождать пять минут подряд, прежде чем объявить оповещение сработавшим; до этого оно в состоянии pending. labels и annotations добавляют к оповещению метки и описание, в них работают шаблоны с $labels. Второе правило срабатывает, когда на файловой системе ext4 осталось меньше 10 % свободного места: порог — пример, выберите свой, а для другой файловой системы замените значение метки fstype. Подключите файл: добавьте в prometheus.yml на верхний уровень (рядом с global) блок rule_files, затем проверьте файлы и перечитайте конфигурацию без перезапуска:

rule_files:
  - /etc/prometheus/alerts.yml
promtool check rules /etc/prometheus/alerts.yml
promtool check config /etc/prometheus/prometheus.yml
sudo systemctl kill --signal=SIGHUP --kill-whom=main prometheus

Сигнал SIGHUP — просьба перечитать настройки, Prometheus перечитывает конфигурацию вместе с файлами правил; ошибки смотрите командой sudo journalctl -u prometheus -n 20 --no-pager. Теперь проверим правило на живой аварии. Остановите node_exporter на lnx2, подождите минуту и откройте страницу запросов: up для 192.168.10.21:9100 станет 0. Во вкладке Alerts оповещение InstanceDown сначала будет pending, а через пять минут firing. Затем верните службу (откат) и убедитесь, что оповещение исчезло:

sudo systemctl stop node_exporter
# подождите 6 минут, наблюдайте вкладку Alerts, затем:
sudo systemctl start node_exporter

Само оповещение пока видно только в интерфейсе. Чтобы получать уведомления, нужен Alertmanager: Prometheus отправляет ему оповещения (блок alerting в prometheus.yml), а получателей и правила доставки описывают в конфигурации самого Alertmanager (отдельная тема, см. документацию проекта). Письмо с сервера уйдёт только при настроенной почтовой службе (тоже отдельная тема); без неё читайте оповещения на вкладке Alerts или подключите внешнюю систему мониторинга, например Zabbix. Главное с точки зрения безопасности: любой, кто может обратиться к HTTP-интерфейсу Alertmanager, способен создавать и гасить оповещения и менять «заглушки», поэтому держите его на 127.0.0.1.

Grafana

Grafana ставят из репозитория проекта (пакет grafana — редакция с открытым кодом). Устройство источников и ключей разбирает статья про apt, там же — как сверить отпечаток ключа. Источник мы пишем в формате deb822: это та же строка deb [signed-by=...] https://apt.grafana.com stable main, которую даёт Grafana.

sudo apt-get install -y apt-transport-https wget gnupg
sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/grafana.asc \
  https://apt.grafana.com/gpg-full.key
sudo chmod 644 /etc/apt/keyrings/grafana.asc
sudo tee /etc/apt/sources.list.d/grafana.sources <<'EOF'
Types: deb
URIs: https://apt.grafana.com
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/grafana.asc
EOF
sudo apt-get update
sudo apt-get install grafana

После установки служба называется grafana-server. По умолчанию Grafana слушает порт 3000 (параметр http_port) на всех интерфейсах: пустой http_addr означает 0.0.0.0. Ограничим её локальным адресом. Откройте /etc/grafana/grafana.ini (sudo nano), найдите раздел [server] и задайте параметр; строки, начинающиеся с ;, закомментированы, поэтому уберите точку с запятой:

[server]
http_addr = 127.0.0.1
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl restart grafana-server
sudo ss -tlnp | grep 3000

Откройте туннель на PC1 (ssh -N -L 3000:127.0.0.1:3000 lnx1) и зайдите на http://localhost:3000. Начальный логин и пароль — admin и admin. Grafana предложит сменить пароль при первом входе: сделайте это сразу и сохраните новый пароль в менеджере паролей, ведь admin из документации знает любой. Позже пароль меняют в профиле пользователя. Правка параметра admin_password в grafana.ini после первого запуска пароль не меняет.

Подключите Prometheus: Connections, Add new connection, найдите Prometheus, Add new data source. В поле адреса укажите http://localhost:9090: localhost здесь — сервер, на котором работает Grafana, то есть lnx1. Нажмите Save & test, должно появиться сообщение Successfully queried the Prometheus API. Теперь запросы из таблицы выше можно вводить при создании панели на дашборде (странице с набором графиков). Готовые дашборды для node_exporter (например, «Node Exporter Full») публикуют на grafana.com, и их можно импортировать в Grafana. Чужой дашборд состоит из чужих запросов: проверьте автора и просмотрите запросы до импорта.

Если Grafana нужна всей команде, поставьте перед ней nginx с HTTPS (статья про nginx, сертификат — по статье про Let's Encrypt) и оставьте http_addr = 127.0.0.1: наружу тогда смотрит только nginx. За прокси в разделе [server] задают адрес сайта (параметры domain и root_url, см. описание параметров Grafana).

Безопасность

  • Порты. Мониторинг показывает устройство вашей сети: версии, диски, адреса. Порты 9090, 9100, 3000 и 9093 не открывают в интернет. В таблице выше показано, кому они нужны. Если сервер имеет публичный адрес, убедитесь командой sudo ss -tlnp, что Prometheus и Grafana слушают 127.0.0.1, а ufw включён (статья про ufw). Если вы запускаете эти программы в контейнерах, помните: опубликованный порт Docker обходит правила ufw (статья про Docker).
  • У Prometheus нет входа по умолчанию. Проект исходит из того, что недоверенные пользователи могут обратиться к HTTP-интерфейсу, и тогда они увидят все собранные данные. Административный API (--web.enable-admin-api) и управление по HTTP (--web.enable-lifecycle) по умолчанию выключены: не включайте их без нужды. Базовая аутентификация и TLS (шифрование соединения) поддерживаются через опцию --web.config.file (помечена экспериментальной); node_exporter тоже принимает её.
  • Пароль Grafana. Смените admin сразу. Заведите отдельные учётные записи администраторов и не работайте под admin постоянно.
  • Обновления. Prometheus и node_exporter из архивов apt не обновляет. Регулярно сверяйте номер с последним выпуском; обновление — это замена бинарного файла и перезапуск службы.
  • Копии. Конфигурацию (prometheus.yml, alerts.yml, grafana.ini, юниты) включите в резервные копии из статьи про restic: история метрик часто не нужна, а вот настройки без труда не восстановить.

Prometheus или Zabbix

Это не война, а два подхода. Zabbix описан в отдельной статье.

Prometheus, node_exporter, Grafana Zabbix
Состав отдельные компоненты: сервер Prometheus, экспортёры, Alertmanager, Grafana единый продукт: сервер, база данных, веб-интерфейс, агенты
Как собираются данные Prometheus сам опрашивает цели по HTTP (pull) сервер опрашивает агента (пассивные проверки) или агент присылает данные (активные)
Настройка файлы YAML, удобные для хранения в системе контроля версий Git веб-интерфейс: узлы, шаблоны, элементы данных, триггеры
Условия и запросы PromQL выражения триггеров
Оповещения правила в Prometheus и отдельный Alertmanager действия, типы оповещений и эскалации внутри Zabbix
Графики Grafana встроенные графики и дашборды
Хранение истории собственная база временных рядов на сервере Prometheus база данных (в статье про Zabbix — PostgreSQL)

Prometheus хорошо подходит для динамичных сред (контейнеры, сервисы), метрик приложений и настройки «как код». Проект называет его пригодным и для «машинного» мониторинга, и для динамичных сервисных архитектур, и не рекомендует там, где нужна стопроцентная точность (например, биллинг по запросам). Zabbix удобнее, когда нужно быстро добавить узел по шаблону, настроить уведомления и права пользователей в веб-интерфейсе, не редактируя файлы. Оба могут работать в одной сети: пока вы осваиваете новый инструмент, не отключайте старый.

Типичные ошибки и недоразумения

  • Цель в состоянии DOWN. node_exporter не запущен, слушает не тот адрес или порт 9100 закрыт на lnx2. Проверьте curl http://192.168.10.21:9100/metrics с lnx1, ss -tlnp и правило ufw.
  • Правило не видно в Alerts. Не добавлен блок rule_files или конфигурация не перечитана после правки. Выполните promtool check config и посмотрите журнал службы.
  • Grafana не находит Prometheus. В адресе источника указан внешний адрес вместо http://localhost:9090 либо Prometheus слушает другой адрес. Для Grafana localhost — тот сервер, где она работает.
  • rate() для датчика. Функция предназначена для счётчиков. Для node_memory_MemAvailable_bytes её не применяют.
  • Оповещения не приходят письмом. Правила в Prometheus не отправляют письма: нужен Alertmanager с получателем и почтовая служба. Без них оповещение видно только в интерфейсе.
  • Порты открыты всем. После установки Prometheus и Grafana слушают все интерфейсы, node_exporter — тоже, если не задана опция --web.listen-address. Привяжите их и проверьте ss.
  • Пароль admin/admin остался. Это публичное значение по умолчанию: смените его сразу.
  • Ожидание вечной истории. При настройках по умолчанию Prometheus хранит данные 15 дней.

Проверьте себя

  1. Чем модель pull отличается от модели, в которой сервер сам присылает данные? Prometheus сам обходит цели по HTTP и забирает /metrics. Цели достаточно отдавать данные, а о недоступности цели говорит метрика up со значением 0.
  2. Что такое экспортёр и какой экспортёр нужен для Linux-сервера? Это программа, которая отдаёт показатели в формате, понятном Prometheus. Для Linux — node_exporter, порт по умолчанию 9100; для Windows — отдельный windows_exporter.
  3. Что делает запрос 100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))? Показывает загрузку процессора в процентах для каждого узла: берёт скорость роста счётчика простоя за 5 минут, усредняет по ядрам и вычитает из единицы.
  4. Зачем в правиле оповещения параметр for: 5m? Prometheus объявляет оповещение сработавшим, только если условие истинно все пять минут подряд; до этого оно в состоянии pending. Так короткие сбои не будят администратора.
  5. Что нужно сделать, чтобы порты Prometheus, node_exporter и Grafana не торчали наружу? Привязать Prometheus (--web.listen-address=127.0.0.1:9090), node_exporter (на lnx1 — 127.0.0.1, на lnx2 — свой адрес плюс правило ufw для сервера мониторинга) и Grafana (http_addr = 127.0.0.1), ходить в интерфейсы через туннель SSH или nginx с HTTPS. Пароль admin в Grafana сменить.

Что дальше

Источники

Ещё по теме «Linux»