Как настроить мониторинг диска на VPS

Что на самом деле показывает мониторинг состояния диска на VPS

Мониторинг состояния диска на VPS начинается с факта, который опускают большинство руководств: диск вам не принадлежит. Ваша гостевая система видит виртуальное блочное устройство. Физический накопитель и все хранящиеся на нем счетчики принадлежат хосту. smartctl /dev/vda не завершается с ошибкой из-за того, что вы неправильно ввели команду. Она завершается, потому что за этим устройством нет ничего, что могло бы ответить на запрос.

SMART (Self-Monitoring, Analysis and Reporting Technology) — это таблица счетчиков, которая ведется на самом накопителе: переназначенные сектора, ожидающие сектора, время наработки в часах, ошибки носителя. Для чтения этой таблицы нужен путь, по которому команды ATA или NVMe (Non-Volatile Memory Express) дойдут до реального оборудования. Паравиртуальный диск такого пути не предоставляет, поэтому гостевая система получает хранилище без телеметрии.

Арендатор отслеживает последствия, а не оборудование. Изнутри гостевой системы видны четыре сигнала: ошибки I/O (ввода-вывода) в журнале ядра, файловая система, перешедшая в режим read-only, растущая задержка и нехватка места. На все четыре можно настроить оповещения уже сегодня, и все они проявляются до того, как на них пожалуется пользователь. Настройте их в первую очередь. Разделение ответственности происходит в конце, так как именно оно определяет, на что стоит тратить усилия.

Проверка того, что именно предоставляет ваш сервер

Не делайте предположений о своей ситуации. Сначала выполните проверку, а затем прочитайте соответствующий раздел.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, стандартный диск KVM (kernel-based virtual machine). Устройство имеет вид /dev/vda, и smartctl завершает работу до отправки каких-либо данных:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk — это паравиртуальный транспорт, за которым не стоит набор команд ATA или SCSI, поэтому нет канала для передачи запроса SMART. -d sat и -d scsi завершаются с той же ошибкой, так как проблема заключается в транспорте, а не в флаге.

Эмулируемый диск SATA или SCSI. Устройство имеет вид /dev/sda, и smartctl успевает дойти до этапа идентификации. Строка модели содержит QEMU HARDDISK. Эта строка сама отвечает на вопрос: вы читаете устройство, созданное эмулятором, и оно не сообщает о наличии полезных функций SMART.

Пространство имен NVMe. sudo nvme smart-log /dev/nvme0n1 возвращает полный лог, что часто вводит пользователей в заблуждение. Сначала проверьте идентификатор контроллера с помощью sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Если номер модели указывает на продукт сетевого хранилища, значит, контроллер является программным, поэтому percentage_used и media_errors описывают эту эмуляцию, а не флеш-память, на которой хранятся ваши данные. Если вы хотите узнать, что представляет собой ваше хранилище на самом деле, проверьте NVMe-диск в Linux, вместо того чтобы доверять описанию плана.

Контейнер, например LXC (Linux containers) или OpenVZ. У вас нет собственного блочного устройства. lsblk показывает устройства хоста или не показывает ничего, а smartctl выдает отказ, так как контейнер не владеет CAP_SYS_RAWIO:

Smartctl open device: /dev/sda failed: Permission denied

Одно предостережение на случай, если команда всё же работает. Если smartctl на VPS возвращает полную таблицу атрибутов, проверьте серийный номер, прежде чем предпринимать какие-либо действия. Некоторые хосты предоставляют проброшенный узел устройства, и эти счетчики относятся к оборудованию, которое совместно используется всеми арендаторами на этой машине. Рост значения Reallocated_Sector_Ct в таком случае — повод для создания тикета в поддержку. Это не имеет отношения к состоянию ваших данных.

Сигнал 1: ошибки ввода-вывода в журнале ядра

Это наиболее ценный сигнал, доступный арендатору, и для его получения не требуется установка агента.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

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

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

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

В ext4 наиболее важна следующая пара сообщений:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

Вторая строка — самая критичная, так как машина продолжает работать. Она отвечает на ping, отвечает по SSH, но любая операция записи завершается ошибкой. Обычная HTTP-проверка продолжает проходить успешно, в то время как ваше приложение выдает ошибку на каждом запросе.

XFS в такой ситуации переводит файловую систему в режим остановки:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k считывает только текущую загрузку, если журнал не хранится на диске, а многие образы поставляются с энергозависимым журналом, который находится в оперативной памяти. Включите постоянное хранение логов, иначе доказательства исчезнут ровно в тот момент перезагрузки, которую вы выполните при поиске неисправности.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

После следующей перезагрузки journalctl --list-boots должен отобразить более одной загрузки. Даже при включенном постоянном хранении файловая система, перешедшая в режим «только чтение», не сможет записать последующие события, что является веским аргументом в пользу отправки логов за пределы сервера.

Сигнал 2: отслеживание перемонтирования в режим read-only

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

findmnt -no SOURCE,FSTYPE,OPTIONS /

Ищите errors=remount-ro в параметрах монтирования. Облачные образы Ubuntu и Debian устанавливают его в /etc/fstab, поэтому при ошибке метаданных файловая система переходит в режим read-only, вместо того чтобы продолжать работу с повреждениями. Если этот параметр отсутствует, добавьте его для корневого раздела в /etc/fstab или установите в суперблоке с помощью sudo tune2fs -e remount-ro /dev/vda1. Громкая остановка лучше, чем скрытое повреждение данных.

Флаг монтирования — это не доказательство. Проверьте возможность записи:

touch /var/tmp/.disk-probe

На корневой файловой системе в режиме read-only будет выведено именно это:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

Используйте /var/tmp, а не /tmp. В большинстве образов /tmp — это tmpfs, находящаяся в оперативной памяти, поэтому успешная запись туда ничего не говорит о состоянии вашего диска.

Объедините тест записи с проверкой свободного места и отправляйте heartbeat только в том случае, если все проверки пройдены успешно:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

probe-ok в последней строке означает, что вся цепочка работает. set -eu заставляет любую неудачную проверку завершить выполнение с ненулевым кодом до того, как сработает строка curl, поэтому heartbeat не будет отправлен. В этом и заключается смысл инверсии: монитор окрашивается в красный цвет, так как данные не поступили, а сервер, который не может писать на диск, не может считаться надежным источником информации о собственных проблемах. Чтение на файловой системе в режиме read-only продолжает работать, поэтому сам скрипт запускается без ошибок.

Запускайте его через systemd timer.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers должен показать юнит со временем NEXT менее пяти минут. Неудачный запуск отобразится в journalctl -u disk-probe.service с текстом ошибки оболочки, поэтому вы сможете отличить файловую систему в режиме read-only от переполненной, не заходя на сервер по SSH.

Указанный URL для push — это push-монитор Uptime Kuma. Создайте монитор типа Push, скопируйте его токен в скрипт и установите интервал heartbeat монитора чуть больше, чем интервал таймера, чтобы один медленный запуск не приводил к ложным оповещениям в 03:00. Если у вас еще нет страницы статуса, самостоятельно развернутый экземпляр Uptime Kuma — самый доступный способ настроить эту проверку.

Два честных ограничения. Проверка подтверждает, что запись была принята, но не гарантирует, что байты достигли энергонезависимого хранилища, так как чтение может быть выполнено из page cache. Кроме того, проверка выполняется на самой машине, поэтому полностью зависший сервер просто замолчит, вместо того чтобы сообщить о диагнозе.

Сигнал 3: тренды задержки и пропускной способности

sudo apt install -y sysstat
iostat -xdz 5 3

Сначала изучите r_await и w_await. Это среднее время в миллисекундах, затраченное на операцию чтения или записи, включая время ожидания в очереди. Затем посмотрите aqu-sz — среднее количество запросов в обработке. Не обращайте внимания на %util для виртуального диска: этот показатель лишь означает, что очередь не была пуста, а устройство, обрабатывающее множество запросов параллельно, может показывать почти 100 процентов, даже не приближаясь к пределу производительности. await — это показатель, который отражает реальный пользовательский опыт.

Абсолютные значения менее важны, чем ваш собственный базовый уровень, поэтому зафиксируйте показатели в часы низкой нагрузки и сохраните их. /proc/diskstats — это исходный источник данных, если вы предпочитаете собирать счетчики самостоятельно.

Для проведения целенаправленного измерения:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

Изучите блок clat percentiles, в частности 99-й перцентиль. --direct=1 пропускает ваш page cache. Он не пропускает кэш хоста, поэтому результат описывает весь путь от вашего процесса до хранилища платформы. Запускайте тест, когда сервер простаивает, так как он конкурирует с вашей собственной рабочей нагрузкой.

Рост await при отсутствии ошибок в журнале ядра обычно не указывает на неисправность диска. Это конфликт ресурсов на хосте, аналог CPU steal time от «шумного соседа» для дисковой подсистемы. Если проблема повторяется в одно и то же время каждый день, а тикет в поддержку не выявляет проблем, решением будет переход на тарифный план, где ввод-вывод не является общим, что характерно для storage VPS в сравнении с обычным VPS, если ваша нагрузка ограничена скоростью диска.

Сигнал 4: проверка файловой системы на смонтированном разделе

ext4 хранит счетчик ошибок в суперблоке, который сохраняется после перезагрузок, даже если логи уже очищены.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

Исправная файловая система выводит Filesystem state: clean и FS Error count: 0. Значения clean with errors и ненулевой счетчик означают, что ядро столкнулось с ошибкой метаданных, даже если никто этого не заметил, а запись в логе была удалена. Эту команду стоит включить в еженедельную проверку.

Вы не можете запустить fsck на смонтированной корневой файловой системе, а e2fsck -n на работающей системе сообщает о проблемах, вызванных лишь изменением данных в процессе работы. Чтобы принудительно выполнить полноценную проверку, добавьте fsck.mode=force fsck.repair=yes в параметры командной строки ядра при одной из загрузок через консоль вашего провайдера. Тогда systemd-fsck выполнит проверку до того, как корень будет смонтирован в режиме чтения-записи.

У XFS нет инструментов для проверки «на лету». xfs_repair -n /dev/vda1 отказывается работать с примонтированной файловой системой, поэтому ее нужно запускать в режиме восстановления (rescue mode). XFS компенсирует это тем, что работает «громко»: при ошибке метаданных она переводит файловую систему в состояние shutdown, вместо того чтобы продолжать работу.

В Btrfs счетчики встроены и являются постоянными.

sudo btrfs device stats /
sudo btrfs scrub start -B /

Значения write_io_errs или corruption_errs выше нуля указывают на реальное событие, а счетчики сохраняют свои значения после перезагрузок, пока вы их не сбросите. scrub повторно считывает каждый блок и проверяет его контрольную сумму — это максимально близкий аналог теста носителя, доступный для виртуального диска. Эта операция создает высокую нагрузку на I/O, поэтому планируйте ее на время низкой активности.

Сигнал 5: свободное место, включая скрытые разделы

Нехватка места выводит сервер из строя так же, как и неисправный диск, при этом случается это гораздо чаще.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device, в то время как df -h показывает наличие свободного места, означает, что у вас закончились inodes, а не байты, при этом df -i показывает IUse% на 100 процентов. Миллионы мелких файлов в директории кэша или почтовой очереди вызывают эту проблему, и удаление крупных файлов здесь не поможет.

Место, которое не освобождается после удаления файлов, обычно занято удаленным файлом, который все еще удерживается запущенным процессом. sudo lsof +L1 выводит список файлов, количество ссылок на которые достигло нуля. Перезапуск процесса, удерживающего такой файл, освобождает место.

Журнал часто является скрытым потребителем дискового пространства. journalctl --disk-usage показывает объем занимаемых им данных. Ограничьте его размер с помощью SystemMaxUse=200M в файле /etc/systemd/journald.conf, затем выполните sudo systemctl restart systemd-journald, а чтобы немедленно вернуть место, используйте sudo journalctl --vacuum-size=200M.

Один случай выглядит как ошибка, но ею не является. В хранилищах с thin provisioning пул хоста может заполниться, в то время как ваш df все еще показывает свободные гигабайты. Ваши операции записи завершаются с ошибками ввода-вывода в журнале ядра, при этом внутри гостевой системы предупреждение о нехватке места отсутствует. Ошибки при неполной файловой системе — это ситуация, требующая создания тикета в тот же час.

Подключение сигналов к агенту сбора метрик

Активный зонд (push probe) дает ответ «да» или «нет». Для анализа трендов требуется агент сбора метрик, а Prometheus node_exporter уже экспортирует все указанные выше данные без дополнительной настройки. Метрики, на которых стоит строить графики:

• node_filesystem_readonly принимает значение 1, если файловая система смонтирована только для чтения; это ваш сигнал для оповещения о перемонтировании.
• node_filesystem_avail_bytes и node_filesystem_files_free охватывают использование байтов и инодов соответственно.
• node_disk_io_time_seconds_total и node_disk_read_time_seconds_total предоставляют время занятости и задержку в виде счетчиков, которые можно визуализировать.

Два правила позволяют отловить ситуации, требующие немедленного реагирования:

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

Второе правило срабатывает, когда текущий тренд достигает нуля в течение четырех дней. Это позволяет получить предупреждение за несколько дней до инцидента, а не при заполнении на 95 процентов, когда у вас остаются считанные минуты.

Зоны ответственности

Провайдер владеет физическими дисками. Он отслеживает SMART, управляет массивом и заменяет диски с растущим числом переназначенных секторов (reallocated sectors), как правило, не уведомляя вас, поскольку массив компенсирует отказ. Именно для этого используется RAID 10 на вашем VPS: выход диска из строя приводит к пересборке массива, а не к простою. Вы не видите этих процессов, и оплата этой абстракции — основная причина аренды виртуального сервера.

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

Поэтому реальная защита арендатора — это резервная копия, хранящаяся вне сервера, и процедура восстановления, которую вы выполнили самостоятельно. Снимки (snapshots) провайдера удобны, но они находятся на той же платформе, что и защищаемый объект, поэтому снимки и резервные копии — это разные уровни защиты. Запланируйте регулярные учения: раз в квартал восстанавливайте свежую резервную копию на новый VPS, запускайте приложение и фиксируйте затраченное время. Это число и есть ваше реальное время восстановления. Первые учения всегда проходят медленнее, чем кто-либо ожидал.

Когда SMART применим к вам

Руководства, обучающие smartctl, верны и применимы в тот момент, когда оборудование становится действительно вашим:

• Выделенный или bare metal сервер, где sudo smartctl -a /dev/sda возвращает полную таблицу атрибутов, а smartd может отправить вам письмо при изменении любого атрибута.
• Планы хранения данных, которые пробрасывают физический диск в гостевую систему. Провайдеры указывают это явно, так как это является преимуществом.
• Оборудование, которым вы владеете: дома или в арендованной стойке.
• Диск за RAID-контроллером, доступный через sudo smartctl -a -d megaraid,0 /dev/sda, или USB-корпус с поддержкой -d sat.

На реальных NVMe-накопителях sudo smartctl -a -d nvme /dev/nvme0 и sudo nvme smart-log /dev/nvme0n1 сообщают critical_warning и percentage_used непосредственно с самого диска. На реальных SATA-дисках атрибутами, предсказывающими выход из строя, являются Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) и Reported_Uncorrect (187). Если значение любого из них отлично от нуля, планируйте замену. Крупномасштабные исследования дисков постоянно подтверждают этот короткий список, а большинство остальных атрибутов являются информационным шумом.

Запускайте демон, а не проверяйте диски вручную.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

Журнал самотестирования должен показывать Completed without error для только что запущенной проверки. В Ubuntu и Debian поставляется /etc/smartd.conf со строкой DEVICESCAN, актуальной на август 2026 года, поэтому демон обнаруживает каждый доступный диск и отправляет письмо пользователю root при изменениях. Ничего из этого не работает с виртуальными дисками, поэтому и существует остальная часть этого руководства.

FAQ

Почему smartctl не работает на моем VPS?

Потому что диск является виртуальным. В гостевой системе KVM, использующей virtio-blk, smartctl -a /dev/vda выводит /dev/vda: Unable to detect device type, так как паравиртуальный диск не поддерживает канал команд ATA или SCSI, необходимый для передачи запроса SMART. На эмулируемом диске вы обращаетесь к устройству, модель которого определяется как QEMU HARDDISK, и за ним нет доступных данных SMART. Внутри контейнера в работе smartctl отказывается сразу из-за отсутствия CAP_SYS_RAWIO. Ничто из этого не является ошибкой конфигурации, и никакой флаг -d не решит проблему.

Как узнать, выходит ли из строя диск на моем VPS?

Следите за последствиями, а не за оборудованием. Проверяйте sudo journalctl -k -p err -b на наличие строк blk_update_request: I/O error и Remounting filesystem read-only. Запустите sudo dumpe2fs -h /dev/vda1 | grep -i 'error count', чтобы найти ошибки, которые уже отсутствуют в логах. Отслеживайте r_await с помощью iostat -xdz 5, сравнивая их с базовыми показателями, которые вы зафиксировали, когда система работала исправно. На VPS ошибка ввода-вывода (I/O error) обычно означает проблему с хранилищем на стороне хоста, а не выход из строя физического диска, поэтому такие случаи требуют создания тикета в поддержку с указанием временной метки и сектора.

На что настроить алерты для мониторинга состояния диска VPS?

Достаточно четырех типов оповещений. Перевод файловой системы в режим «только чтение» (read-only), который можно отследить через node_filesystem_readonly == 1 или с помощью проверки записи, завершающейся неудачей. Свободное место и свободные иноды, стремящиеся к нулю. Любые ошибки ядра I/O error за последний интервал времени. «Пульс» (heartbeat) сервера, чтобы вы получили уведомление, если машина перестанет отвечать. Игнорируйте любые показатели, полученные от SMART, так как на виртуальном диске эти значения либо отсутствуют, либо описывают эмуляцию гипервизора.

Почему моя файловая система перешла в режим «только чтение»?

Файловая система ext4, смонтированная с параметром errors=remount-ro, делает это намеренно при обнаружении ошибки метаданных: она прекращает запись, чтобы не усугублять повреждения. Причина находится в логе ядра прямо над строкой о перемонтировании, обычно это EXT4-fs error об отмене журнала после того, как нижележащее устройство вернуло ошибку ввода-вывода. Перемонтирование в режим чтения-записи без проверки файловой системы лишь скрывает симптом, оставляя причину нетронутой. Сохраните лог, затем проверьте файловую систему в режиме rescue с помощью e2fsck -fy /dev/vda1, предварительно отмонтировав её.

Могу ли я когда-нибудь прочитать данные SMART на виртуальном сервере?

В отдельных случаях — да. Выделенные (dedicated) и bare metal серверы предоставляют реальные атрибуты. То же самое касается тарифных планов с пробросом физического диска (passthrough) в гостевую систему, а также любого хоста, которым вы владеете самостоятельно. Некоторые платформы предоставляют гостевой системе NVMe-контроллер, и nvme smart-log возвращает лог, поэтому сначала запустите sudo nvme id-ctrl /dev/nvme0: если номер модели указывает на сетевое хранилище, значит, эти счетчики поступают от программного контроллера. А там, где узел с пробросом диска действительно показывает реальные счетчики на общей машине, они описывают оборудование, разделяемое с другими арендаторами, поэтому единственное полезное действие — это создание тикета в поддержку.