Полное руководство по резервному копированию и восстановлению стека мониторинга: Prometheus и Grafana

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

Инструкция основана на проверенной практике работы с Prometheus 2.45+ и Grafana 10.0+ в продакшн-средах. Все шаги протестированы на реальных инсталляциях.

Что нужно резервировать в стеке мониторинга и почему это критично

Стек мониторинга состоит из компонентов, которые теряют ценность по отдельности. Бэкап только дашбордов Grafana бесполезен без данных Prometheus. Резервная копия метрик бессмысленна без правил алертинга. Нужно копировать всё, что не является временным или легко воссоздаваемым.

Последствия потери компонентов:

Конфигурации Prometheus - невозможность сбора новых метрик
Правила алертинга - пропуск критических инцидентов
Временные ряды - разрыв в исторических данных
Дашборды Grafana - потеря визуализаций и панелей управления
Настройки Grafana - сброс источников данных и пользователей

Ключевые данные Prometheus: конфигурация, правила и временные ряды

Prometheus хранит данные в трёх основных категориях, каждая требует отдельного подхода к резервированию.

Конфигурационные файлы обычно находятся в /etc/prometheus/. Основной файл prometheus.yml содержит глобальные настройки, scrape-конфигурации для сбора метрик и настройки remote_write/read. Файлы правил алертинга (*.rules) хранятся в поддиректориях типа /etc/prometheus/rules/ или /etc/prometheus/alerts/.

Директория данных указывается параметром --storage.tsdb.path (по умолчанию data/). Внутри находятся:

WAL (Write-Ahead Log) - журнал предзаписи в директории wal/, содержит последние 2 часа данных
Блоки данных - сжатые сегменты временных рядов в директориях вида 01HX5V5ZJQ6W...
Файл метаданных meta.json в каждом блоке

Snapshot'ы создаются через API Prometheus командой POST /api/v1/admin/tsdb/snapshot. Они представляют собой консистентную копию всех блоков данных на момент создания, включая WAL. Snapshot - единственный безопасный способ копирования работающей базы данных метрик.

Артефакты Grafana: дашборды, настройки и база данных

Grafana имеет более сложную структуру данных, чем Prometheus. Простое копирование JSON дашбордов недостаточно.

База данных Grafana может быть:

SQLite - файл grafana.db в директории данных (обычно /var/lib/grafana/)
PostgreSQL/MySQL - внешняя база данных, указанная в grafana.ini

В базе данных хранятся пользователи, организации, предпочтения, playlist'ы, аннотации, ключи API и некоторые настройки источников данных.

Конфигурационные файлы:

grafana.ini - основной конфигурационный файл
custom.ini - пользовательские переопределения
Файлы провайдеров аутентификации (LDAP, OAuth)

Дашборды можно экспортировать через UI (Share → Export) или API (/api/dashboards/uid/). Для массового экспорта нужны скрипты.

Источники данных (Data Sources) настраиваются через UI или API (/api/datasources/). Без них дашборды не смогут получать данные.

Плагины устанавливаются в /var/lib/grafana/plugins/. Их конфигурации могут храниться в базе данных или JSON-файлах.

Практическое пошаговое руководство по созданию полного бэкапа

Эта инструкция создаёт структурированный архив со всеми компонентами стека. Выполняйте шаги от root или с sudo-правами.

Создание снапшота данных Prometheus и копирование конфигураций

Сначала создайте snapshot данных Prometheus. Если Prometheus работает в Docker, используйте IP контейнера или host network.

# Создание snapshot через API Prometheus
curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot

# Ответ содержит имя созданной директории
{"status":"success","data":{"name":"20230505T120000Z-0123456789abc"}}

# Альтернативно: оффлайн-снапшот через promtool
promtool tsdb create-snapshot /prometheus/data /backup/prometheus-snapshots

Скопируйте конфигурации и правила:

# Копирование конфигураций Prometheus
cp -r /etc/prometheus/ /backup/prometheus-config/

# Проверка прав доступа
chmod -R 755 /backup/prometheus-config/
chown -R prometheus:prometheus /backup/prometheus-config/

Для Docker-инсталляций конфиги могут находиться в volumes. Проверьте монтирования:

docker inspect prometheus_container | grep -A5 Mounts

Экспорт конфигурации Grafana: от дашбордов до настроек

Экспортируйте дашборды через API Grafana. Вам понадобится API key с правами Admin.

# Создание API key (если нет)
curl -XPOST -H "Content-Type: application/json" \
  -d '{"name":"backup-key", "role":"Admin"}' \
  http://admin:admin@localhost:3000/api/auth/keys

# Экспорт всех дашбордов
API_KEY="eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE..."
curl -s -H "Authorization: Bearer $API_KEY" \
  http://localhost:3000/api/search?type=dash-db \
  | jq -r '.[].uid' \
  | while read uid; do
    curl -s -H "Authorization: Bearer $API_KEY" \
      "http://localhost:3000/api/dashboards/uid/$uid" \
      | jq '.dashboard' > "/backup/grafana-dashboards/$uid.json"
done

Экспортируйте источники данных:

# Список источников данных
curl -s -H "Authorization: Bearer $API_KEY" \
  http://localhost:3000/api/datasources \
  > /backup/grafana-datasources.json

Для SQLite просто скопируйте файл базы данных:

cp /var/lib/grafana/grafana.db /backup/grafana/

Для PostgreSQL или MySQL создайте дамп:

# PostgreSQL
pg_dump -U grafana grafana_db > /backup/grafana/grafana_db.sql

# MySQL
mysqldump -u grafana -p grafana > /backup/grafana/grafana_db.sql

Скопируйте конфигурационные файлы и плагины:

cp /etc/grafana/grafana.ini /backup/grafana/
cp -r /var/lib/grafana/plugins/ /backup/grafana/

Организация хранения: локальный диск, NFS и S3-совместимые хранилища

Локальное хранение бэкапов на том же сервере не обеспечивает отказоустойчивость. Используйте минимум два уровня хранения.

Локальная директория - временное хранение для архивации. Риск: потеря при отказе диска.

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

Объектные хранилища S3 - оптимальный выбор для долгосрочного хранения. Примеры: AWS S3, MinIO, Яндекс Облако, Ceph.

# Упаковка всего в архив
tar -czf /backup/monitoring-backup-$(date +%Y%m%d-%H%M).tar.gz \
  /backup/prometheus-* \
  /backup/grafana-*

# Загрузка в S3 через AWS CLI
aws s3 cp /backup/monitoring-backup-*.tar.gz \
  s3://my-backup-bucket/monitoring/

# Загрузка в S3 через MinIO клиент
mc cp /backup/monitoring-backup-*.tar.gz \
  myminio/backup-bucket/monitoring/

Настройте политики жизненного цикла в S3 для автоматического удаления старых бэкапов:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Filter": {"Prefix": "monitoring/"},
      "Expiration": {"Days": 30},
      "ID": "DeleteOldBackups"
    }
  ]
}

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

# Шифрование с помощью GPG
gpg --symmetric --cipher-algo AES256 \
  -o /backup/monitoring-backup-encrypted.tar.gz.gpg \
  /backup/monitoring-backup-*.tar.gz

Полный bash-скрипт для автоматического бэкапа:

#!/bin/bash
set -euo pipefail
BACKUP_DIR="/backup/$(date +%Y%m%d-%H%M)"
mkdir -p "$BACKUP_DIR"

# Бэкап Prometheus
curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot
cp -r /etc/prometheus/ "$BACKUP_DIR/prometheus-config/"

# Бэкап Grafana
API_KEY="your-api-key"
curl -s -H "Authorization: Bearer $API_KEY" \
  http://localhost:3000/api/search?type=dash-db \
  | jq -r '.[].uid' \
  | while read uid; do
    curl -s -H "Authorization: Bearer $API_KEY" \
      "http://localhost:3000/api/dashboards/uid/$uid" \
      | jq '.dashboard' > "$BACKUP_DIR/grafana-dashboards/$uid.json"
done

# Архивирование
cd /backup
tar -czf "monitoring-backup-$(date +%Y%m%d-%H%M).tar.gz" "$(basename $BACKUP_DIR)"

# Загрузка в S3
aws s3 cp "monitoring-backup-*.tar.gz" s3://my-backup-bucket/

# Очистка локальных файлов
rm -rf "$BACKUP_DIR"
rm -f monitoring-backup-*.tar.gz

Восстановление стека на новом сервере с минимальным временем простоя

Восстановление должно быть быстрым и предсказуемым. Этот план позволяет поднять рабочий стек за 30-60 минут.

Развертывание и настройка чистых инстансов Prometheus и Grafana

Начните с установки того же ПО, что было в бэкапе. Совпадение версий критически важно.

# Установка Prometheus (Ubuntu/Debian)
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64/

# Создание пользователя и директорий
useradd --no-create-home --shell /bin/false prometheus
mkdir -p /etc/prometheus /var/lib/prometheus
chown prometheus:prometheus /var/lib/prometheus

Для Docker используйте конкретные теги образов:

# Prometheus
docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /etc/prometheus:/etc/prometheus \
  -v /prometheus:/prometheus \
  prom/prometheus:v2.45.0 \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/prometheus

# Grafana
docker run -d \
  --name grafana \
  -p 3000:3000 \
  -v /var/lib/grafana:/var/lib/grafana \
  -v /etc/grafana:/etc/grafana \
  grafana/grafana:10.0.0

Проверьте версии в бэкапе:

# Prometheus версия из логов бэкапа
grep "version" /backup/prometheus-config/prometheus.yml

# Grafana версия из конфига
grep "app_mode" /backup/grafana/grafana.ini

Импорт snapshot'а данных и конфигураций Prometheus

Распакуйте архив бэкапа и восстановите данные Prometheus.

# Распаковка архива
tar -xzf monitoring-backup-20230505-1200.tar.gz
cd 20230505-1200/

# Восстановление конфигураций
cp -r prometheus-config/* /etc/prometheus/
chown -R prometheus:prometheus /etc/prometheus

# Восстановление snapshot'а данных
# Найдите имя директории snapshot'а
SNAPSHOT_DIR=$(find . -type d -name "*snapshot*" | head -1)
cp -r "$SNAPSHOT_DIR"/* /var/lib/prometheus/
chown -R prometheus:prometheus /var/lib/prometheus

Настройте prometheus.yml для использования восстановленных данных:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

# Укажите правильный путь к данным
# storage:
#   tsdb:
#     path: /var/lib/prometheus

rule_files:
  - "/etc/prometheus/rules/*.rules"

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

Запустите Prometheus и проверьте загрузку данных:

systemctl start prometheus
# Или для Docker
docker start prometheus

# Проверка логов
tail -f /var/log/prometheus/prometheus.log
# Ищите сообщения:
# "Loading series data and head chunks..."
# "TSDB started"
# "Server is ready to receive web requests."

# Проверка через API
curl http://localhost:9090/api/v1/query?query=up

Если метрики не появляются, проверьте:

Права доступа к директории данных
Наличие файлов блоков в /var/lib/prometheus/
Сообщения об ошибках в логах
Доступность порта 9090

Восстановление дашбордов, алертов и работоспособности Grafana

Восстановите Grafana после успешного запуска Prometheus.

Для SQLite просто замените файл базы данных:

# Остановите Grafana
systemctl stop grafana-server
# Или
docker stop grafana

# Замените базу данных
cp /backup/grafana/grafana.db /var/lib/grafana/
chown grafana:grafana /var/lib/grafana/grafana.db

# Восстановите конфиги и плагины
cp /backup/grafana/grafana.ini /etc/grafana/
cp -r /backup/grafana/plugins/* /var/lib/grafana/plugins/

Для PostgreSQL или MySQL восстановите дамп:

# PostgreSQL
psql -U grafana grafana_db < /backup/grafana/grafana_db.sql

# MySQL
mysql -u grafana -p grafana < /backup/grafana/grafana_db.sql

Импортируйте дашборды через API:

API_KEY="new-admin-api-key"
for dashboard_file in /backup/grafana-dashboards/*.json; do
  curl -XPOST -H "Content-Type: application/json" \
    -H "Authorization: Bearer $API_KEY" \
    -d "{\"dashboard\":$(cat "$dashboard_file"),\"overwrite\":true}" \
    http://localhost:3000/api/dashboards/db
done

Восстановите источники данных. Убедитесь, что URL указывает на восстановленный Prometheus:

# Измените URL в файле источников данных
sed -i 's/old-prometheus-server:9090/new-server:9090/g' \
  /backup/grafana-datasources.json

# Импорт источников данных
curl -XPOST -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d @/backup/grafana-datasources.json \
  http://localhost:3000/api/datasources

Запустите Grafana и проверьте работоспособность:

systemctl start grafana-server
# Или
docker start grafana

# Откройте браузер http://new-server:3000
# Проверьте:
# 1. Доступность дашбордов
# 2. Наличие данных на графиках
# 3. Работу алертов

Для нулевого простоя используйте стратегию сине-зелёного развёртывания:

Поднимите новую копию стека параллельно со старой
Настройте балансировщик нагрузки на оба стека
Проверьте работоспособность новой копии
Переключите трафик на новый стек
Отключите старый стек после подтверждения стабильности

Если вам нужно быстро развернуть систему мониторинга с нуля, обратитесь к нашему полному руководству по созданию системы мониторинга. Там вы найдёте готовые конфиги, алерт-правила для CPU, RAM, диска и советы по оптимизации.

Автоматизация и интеграция в DevOps-процессы

Разовые бэкапы ненадёжны. Автоматизируйте процесс создания, проверки и уведомления о бэкапах.

Написание отказоустойчивого скрипта и настройка cron

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

#!/bin/bash
# backup-monitoring.sh
set -euo pipefail

# Настройки
BACKUP_DIR="/backup/$(date +%Y%m%d-%H%M)"
LOG_FILE="/var/log/monitoring-backup.log"
S3_BUCKET="s3://my-backup-bucket/monitoring/"
NOTIFY_URL="https://hooks.slack.com/services/..."

# Функция логирования
log() {
  echo "$(date '+%Y-%m-%d %H:%M:%S') $1" | tee -a "$LOG_FILE"
}

# Функция обработки ошибок
error_exit() {
  log "ERROR: $1"
  # Отправка уведомления в Slack
  curl -XPOST -H 'Content-type: application/json' \
    -d "{\"text\":\"Backup failed: $1\"}" \
    "$NOTIFY_URL"
  exit 1
}

# Проверка зависимостей
command -v curl >/dev/null 2>&1 || error_exit "curl not found"
command -v jq >/dev/null 2>&1 || error_exit "jq not found"
command -v aws >/dev/null 2>&1 || error_exit "aws cli not found"

# Начало бэкапа
log "Starting monitoring backup"

# Создание директории
mkdir -p "$BACKUP_DIR" || error_exit "Cannot create backup directory"

# Бэкап Prometheus
log "Backing up Prometheus"
SNAPSHOT_RESPONSE=$(curl -s -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot)
SNAPSHOT_NAME=$(echo "$SNAPSHOT_RESPONSE" | jq -r '.data.name')

if [ -z "$SNAPSHOT_NAME" ]; then
  error_exit "Failed to create Prometheus snapshot"
fi

cp -r "/prometheus/snapshots/$SNAPSHOT_NAME" "$BACKUP_DIR/prometheus-snapshot/"
cp -r /etc/prometheus/ "$BACKUP_DIR/prometheus-config/"

# Бэкап Grafana
log "Backing up Grafana"
API_KEY="$(cat /etc/grafana/api-key)"

# Экспорт дашбордов
mkdir -p "$BACKUP_DIR/grafana-dashboards"
curl -s -H "Authorization: Bearer $API_KEY" \
  "http://localhost:3000/api/search?type=dash-db" \
  | jq -r '.[].uid' \
  | while read uid; do
    curl -s -H "Authorization: Bearer $API_KEY" \
      "http://localhost:3000/api/dashboards/uid/$uid" \
      | jq '.dashboard' > "$BACKUP_DIR/grafana-dashboards/$uid.json"
  done

# Архивирование
log "Creating archive"
cd /backup
ARCHIVE_NAME="monitoring-backup-$(date +%Y%m%d-%H%M).tar.gz"
tar -czf "$ARCHIVE_NAME" "$(basename $BACKUP_DIR)" \
  || error_exit "Failed to create archive"

# Проверка архива
if [ ! -s "$ARCHIVE_NAME" ]; then
  error_exit "Archive is empty"
fi

# Загрузка в S3
log "Uploading to S3"
aws s3 cp "$ARCHIVE_NAME" "$S3_BUCKET" \
  || error_exit "Failed to upload to S3"

# Очистка
rm -rf "$BACKUP_DIR"
rm -f "$ARCHIVE_NAME"

# Успешное завершение
log "Backup completed successfully"
BACKUP_SIZE=$(aws s3 ls "$S3_BUCKET$ARCHIVE_NAME" | awk '{print $3}')
curl -XPOST -H 'Content-type: application/json' \
  -d "{\"text\":\"Backup successful: $ARCHIVE_NAME ($BACKUP_SIZE bytes)\"}" \
  "$NOTIFY_URL"

exit 0

Настройте cron для ежедневного выполнения:

# crontab -e
# Ежедневно в 2:00
0 2 * * * /usr/local/bin/backup-monitoring.sh

# С логированием в файл
0 2 * * * /usr/local/bin/backup-monitoring.sh >> /var/log/backup-cron.log 2>&1

Для более сложных сценариев автоматизации, включая мониторинг ZFS/Btrfs и интеграцию с системами управления инцидентами, используйте готовые скрипты Python и Bash.

Проверка целостности бэкапов и регулярное тестирование восстановления

Бэкап без проверки восстановления - это иллюзия безопасности. Регулярно тестируйте процесс.

Проверка целостности после создания архива:

# Вычисление хеша
MD5_HASH=$(md5sum monitoring-backup-*.tar.gz | awk '{print $1}')
echo "$MD5_HASH" > monitoring-backup-*.tar.gz.md5

# Проверка при загрузке в S3
aws s3 cp monitoring-backup-*.tar.gz.md5 s3://my-backup-bucket/

# Периодическая проверка
DOWNLOADED_HASH=$(aws s3 cp s3://my-backup-bucket/monitoring-backup-*.tar.gz - | md5sum)
if [ "$DOWNLOADED_HASH" != "$MD5_HASH" ]; then
  echo "Hash mismatch! Backup corrupted"
fi

Тестовое восстановление раз в месяц. Используйте Docker для изоляции:

#!/bin/bash
# test-restore.sh

# Скачивание последнего бэкапа
LATEST_BACKUP=$(aws s3 ls s3://my-backup-bucket/monitoring/ \
  | sort | tail -1 | awk '{print $4}')
aws s3 cp "s3://my-backup-bucket/monitoring/$LATEST_BACKUP" .

# Запуск тестового стенда
docker-compose -f test-monitoring.yml up -d

# Проверка работоспособности
sleep 30
curl -f http://localhost:9090/api/v1/query?query=up \
  || echo "Prometheus not responding"
curl -f http://localhost:3000/api/health \
  || echo "Grafana not responding"

# Очистка
docker-compose -f test-monitoring.yml down
rm -f "$LATEST_BACKUP"

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

{
  "backups": [
    {
      "filename": "monitoring-backup-20230505-1200.tar.gz",
      "date": "2023-05-05T12:00:00Z",
      "size": 1572864000,
      "md5": "a1b2c3d4e5f678901234567890123456",
      "prometheus_version": "2.45.0",
      "grafana_version": "10.0.0",
      "components": ["prometheus", "grafana", "alertmanager"],
      "tested": true,
      "test_date": "2023-05-10T14:30:00Z"
    }
  ]
}

Интегрируйте проверки в CI/CD пайплайн. Например, в GitLab CI:

# .gitlab-ci.yml
backup_test:
  stage: test
  script:
    - aws s3 cp s3://my-backup-bucket/monitoring/latest.tar.gz .
    - tar -tzf latest.tar.gz | grep -q "prometheus-config/prometheus.yml"
    - echo "Backup structure OK"
  only:
    - schedules  # Запускать по расписанию

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

Разные ситуации требуют разных подходов к восстановлению. Выберите подходящий сценарий.

Аварийное восстановление vs плановая миграция: два разных подхода

Аварийное восстановление (сервер упал, нужно срочно):

Приоритет скорости над аккуратностью
Восстановите минимально рабочий стек: Prometheus + базовые дашборды
Используйте самый свежий бэкап, даже если он не полный
Отложите восстановление исторических данных на потом
Цель: вернуть мониторинг в течение 30 минут

Плановая миграция (переезд на новый хост, обновление):

Подготовьте новый сервер параллельно со старым
Восстановите полный стек из бэкапа
Проверьте все компоненты: метрики, алерты, дашборды
Настройте балансировщик нагрузки на оба стека
Переключите трафик постепенно или сразу
Мониторьте новую систему 24-48 часов
Отключите старый стек

Клонирование среды для разработки или тестирования:

Используйте бэкап продакшн-среды
Измените настройки для тестового окружения (URL, порты)
Ограничьте retention период для экономии места
Используйте тестовые данные или сгенерируйте метрики

Диагностика частых ошибок при восстановлении

Вот типовые проблемы и их решения:

"Permission denied" при доступе к данным Prometheus

# Проверьте владельца и права
ls -la /var/lib/prometheus/
# Должно быть prometheus:prometheus
chown -R prometheus:prometheus /var/lib/prometheus/
chmod -R 755 /var/lib/prometheus/

Grafana не видит источник данных

# Проверьте доступность Prometheus
curl http://new-prometheus:9090/-/healthy
# Проверьте настройки сети и firewall
iptables -L -n | grep 9090
# Проверьте URL в настройках источника данных
# Должен быть http://new-prometheus:9090

Пустые графики после восстановления

# Проверьте загрузку snapshot'а
ls -la /var/lib/prometheus/
# Должны быть директории блоков (01HX...)

# Проверьте временной диапазон запроса
# В Grafana выберите Last 6 hours вместо Last 15 minutes

# Проверьте метрики через API Prometheus
curl "http://localhost:9090/api/v1/query?query=up[5m]"

Ошибки в дашбордах после импорта

# Проверьте версии плагинов
# Старые дашборды могут использовать устаревшие плагины

# Проверьте совместимость версий Grafana
# Дашборды экспортированные из Grafana 9.x
# могут не работать в Grafana 10.x

# Проверьте источники данных
# Каждая панель должна иметь корректный Data Source

Alertmanager не работает после восстановления

# Проверьте конфигурацию Alertmanager в prometheus.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

# Проверьте доступность Alertmanager
curl http://alertmanager:9093/-/healthy

# Проверьте правила алертинга
# Они должны быть в /etc/prometheus/rules/*.rules

Несовместимость версий ПО - самая частая проблема. Всегда проверяйте:

Компонент	Где проверить версию	Что делать при несовместимости
Prometheus	`prometheus --version` `/etc/prometheus/prometheus.yml`	Установите ту же версию или обновите/откатите
Grafana	`grafana-server -v` `/etc/grafana/grafana.ini`	Используйте ту же major-версию (9.x, 10.x)
Плагины Grafana	`/var/lib/grafana/plugins/`	Установите совместимые версии плагинов
Экспортеры	Версии в бэкапе конфигов	Установите те же версии экспортеров

Для комплексной автоматизации инфраструктуры, включая мониторинг логов Nginx, резервное копирование PostgreSQL и безопасное обновление серверов, используйте готовые примеры кода на Ansible, Terraform, Bash и Python.

Если вы работаете с нейросетями и API, сервис AiTunnel предоставляет единый интерфейс для доступа к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях и без необходимости использовать VPN.

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