Виправити pvestatd.service у Proxmox: швидко відновити графіки та статистику

Що насправді робить pvestatd (і чого він не робить)

pvestatd — демон статистики ноди у Proxmox. Його завдання періодично збирати метрики (нода, ВМ/CT, сховище, деякі деталі кластера) і зберігати тимчасові ряди, щоб GUI міг будувати графіки й показувати тренди. Це не сам GUI і не «система моніторингу» в розумінні Prometheus. Це канал, що забезпечує роботу вбудованих графіків.

На більшості інсталяцій графіки зберігаються в RRD (Round Robin Database) файлах під /var/lib/rrdcached/db, а оновлення проходять через rrdcached, щоб уникнути постійних дискових операцій. Коли pvestatd не може записувати оновлення — або не може зв’язатися з rrdcached, або не може коректно прочитати системні статистики — він падає або застрягає. GUI тоді показує застарілі або порожні графіки, часто без корисного пояснення.

Практичний висновок: коли графіки зникають, не дивіться в браузер. Діагностуйте pvestatd, rrdcached, стан сховища, права доступу й синхронізацію часу. В такому порядку.

Одна суха правда: якщо ви працюєте без надійних тимчасових рядів, ви експлуатуєте продакшн як пілот, який вважає альтиметри «опційними аксесуарами».

Швидкий план діагностики (перший/другий/третій)

Перший: підтвердьте режим відмови (це справді pvestatd?)

• Перевірте стан сервісу та останні журнали. Ви шукаєте явну помилку: відмовлено у доступі, диск заповнений, сокет відсутній, пошкоджений RRD, стрибок часу.
• Перевірте, чи запущений rrdcached і чи існує його сокет.
• Перевірте вільне місце й тиск інодів на файловій системі, де розташовані RRD дані.

Другий: ізолюйте, чи проблема в шляху запису чи читання

• Шлях запису: чи можемо ми оновлювати RRD? Сокет? Права? Диск? Пошкодження?
• Шлях читання: чи падає pvestatd під час збору статистик із бекендів сховища (ZFS, Ceph, NFS, iSCSI)? Чи один несправний ресурс сховища блокує все?

Третій: підтвердіть вплив на кластер

• У кластері перевірте, чи одна нода хвора, чи всі ноди.
• Перевірте синхронізацію часу й кластерну комунікацію. Дивні стрибки часу можуть зробити RRD графіки «плоскими» або відсутніми, навіть коли оновлення відбуваються.
• Якщо ви використовуєте спільне сховище для RRD (незвично, але трапляється), перевірте стан монтованого шару й затримки.

Не починайте з перевстановлення. Не починайте з випадкових видалень. І, будь ласка, не «виправляйте» вимкненням збору статистики. Це як лікувати жар, зламавши термометр.

Цікаві факти та контекст (чому це ламається саме так)

1. RRD розробляли в кінці 1990-х для компактного зберігання тимчасових рядів з фіксованим розміром — він віддає деталі заради передбачуваності. Добре для вбудованих графіків; не дуже для судових розслідувань.
2. rrdcached існує, щоб зменшити записову ампліфікацію: без нього часті оновлення RRD викликали б багато дрібних синхронних записів і даремний знос SSD.
3. Proxmox історично покладався на RRD для вбудованих графіків, оскільки це просто, локально та не вимагає стека моніторингу. Ця простота робить його повсюдним — і тому збої здаються несподіваними.
4. RRD файли бінарні й вибагливі. Частковий запис, заповнений диск або помилка файлової системи можуть зробити їх непрочитуваними, а інструменти часто повідомляють «invalid header», замість «диск збрехав вам».
5. Стрибки часу можуть порушити ілюзію безперервності: RRD консолідує дані в відра; якщо системний час раптово зміститься назад/вперед, графіки можуть мати пропуски або плоскі ділянки без очевидної помилки.
6. Служби ноди Proxmox — це systemd юніти. Одна відсутня директорія, неправильна власність або зламаний dependency можуть штовхнути pvestatd у цикли перезапусків, що виглядає як «він працює» на перший погляд.
7. Візуалізацію графіків не робить pvestatd. Демон тільки оновлює дані; GUI їх споживає. Люди часто полюють на не той компонент (зазвичай веб-UI).
8. Бекенди сховища можуть отруїти конвеєр статистики: завислий NFS, деградований Ceph або повільна команда ZFS можуть блокувати збір, викликаючи тайм-аути і збої pvestatd.

Практичні завдання: команди, виводи та рішення (12+)

Це реальні дії, які я б виконував на ноді з відсутніми графіками і що впавшим pvestatd. Кожна включає, що означає вивід і яке рішення з нього випливає. Виконуйте від root або з відповідними привілеями.

Завдання 1: Підтвердити стан сервісу й причину останньої помилки

cr0x@server:~$ systemctl status pvestatd --no-pager
● pvestatd.service - PVE status daemon
     Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
     Active: failed (Result: exit-code) since Tue 2025-12-23 09:11:31 UTC; 2min 10s ago
    Process: 1442 ExecStart=/usr/bin/pvestatd (code=exited, status=1/FAILURE)
Dec 23 09:11:31 server pvestatd[1442]: unable to write rrd: Permission denied
Dec 23 09:11:31 server systemd[1]: pvestatd.service: Failed with result 'exit-code'.

Значення: Маєте конкретну помилку. Не гадати. «Permission denied» сильно вказує на власність/режим директорій RRD або сокета rrdcached.

Рішення: Перейдіть до перевірки прав (Тиск на сховище, права доступу) і перевірки сокета rrdcached.

Завдання 2: Прочитати журнал для контексту (часто показує першу реальну помилку)

cr0x@server:~$ journalctl -u pvestatd -b --no-pager -n 200
Dec 23 09:11:30 server pvestatd[1442]: starting server
Dec 23 09:11:31 server pvestatd[1442]: rrdcached: connect to /var/run/rrdcached.sock: No such file or directory
Dec 23 09:11:31 server pvestatd[1442]: can't initialize rrd: No such file or directory

Значення: Це не проблема прав; сокет відсутній. Це або rrdcached не запущений, або він сконфігурований з іншим шляхом сокета, або директорія відсутня.

Рішення: Перевірте сервіс rrdcached і шлях сокета.

Завдання 3: Перевірити стан rrdcached і наявність сокета

cr0x@server:~$ systemctl status rrdcached --no-pager
● rrdcached.service - data caching daemon for rrdtool
     Loaded: loaded (/lib/systemd/system/rrdcached.service; enabled)
     Active: active (running) since Tue 2025-12-23 08:55:02 UTC; 18min ago
   Main PID: 612 (rrdcached)
     Tasks: 1
     Memory: 2.3M
Dec 23 08:55:02 server rrdcached[612]: starting up

cr0x@server:~$ ls -l /var/run/rrdcached.sock
ls: cannot access '/var/run/rrdcached.sock': No such file or directory

Значення: Сервіс запущений, але сокета немає за цим шляхом. Демон може використовувати інше місце для сокета (часто залежить від пакету) або не створив його.

Рішення: Знайдіть реальний шлях сокета й узгодьте очікування Proxmox або налаштування сервісу.

Завдання 4: Знайти реальний сокет rrdcached і підтвердити, що це справжній сокет

cr0x@server:~$ ss -xlpn | grep rrdcached
u_str LISTEN 0      4096   /run/rrdcached/rrdcached.sock  12345              * 0    users:(("rrdcached",pid=612,fd=4))

Значення: Сокет насправді /run/rrdcached/rrdcached.sock. Якщо pvestatd очікує /var/run/rrdcached.sock, маємо невідповідність.

Рішення: Підтвердіть, як Proxmox налаштований на підключення; виправте конфіг або акуратно створіть символічне посилання.

Завдання 5: Перевірити очікуваний симлінк (поширений фікс)

cr0x@server:~$ ls -ld /var/run
lrwxrwxrwx 1 root root 4 Dec 23 08:40 /var/run -> /run

cr0x@server:~$ ls -l /run/rrdcached/rrdcached.sock
srwxrwxrwx 1 root root 0 Dec 23 08:55 /run/rrdcached/rrdcached.sock

Значення: /var/run вказує на /run. Але ім’я сокета відрізняється. Іноді Proxmox шукає /run/rrdcached.sock, а rrdcached створює піддиректорію.

Рішення: Або переконфігуруйте rrdcached, щоб створював сокет там, де очікує Proxmox, або створіть симлінк (краще змінити конфіг, але симлінк працює, якщо ви розумієте наслідки).

Завдання 6: Подивитись дефолти rrdcached (сокет і базова директорія)

cr0x@server:~$ grep -E 'SOCK|BASE|OPTS' /etc/default/rrdcached
SOCKGROUP=www-data
BASE_PATH=/var/lib/rrdcached
DAEMON_OPTS="-l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/"

Значення: Сокет явно вказано. Proxmox має можливість зв’язуватися з тим сокетом; якщо не може — відбувається збій.

Рішення: Налаштуйте Proxmox використовувати вказаний сокет або змініть конфігурацію rrdcached.

Завдання 7: Перевірити вільне місце й іноди там, де живуть RRD (графіки вмирають при «повному»)

cr0x@server:~$ df -h /var/lib/rrdcached /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G   30G     0 100% /

cr0x@server:~$ df -i /var/lib/rrdcached
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2      196608 196608     0  100% /

Значення: Немає ні місця, ні інодів. Це не «зламався моніторинг», це «система задихається». Oновлення RRD не проходять; демони падають; інші сервіси незабаром теж постраждають.

Рішення: Звільніть місце/іноди негайно, потім відремонтуйте RRD при потребі. Не перезапускайте сервіси на повній файловій системі — ви лише накрутіть журнали й проблеми.

Завдання 8: Визначити, що «з’їло» диск (швидко, без драм)

cr0x@server:~$ du -xhd1 /var | sort -h
120M    /var/cache
380M    /var/lib
1.2G    /var/log
28G     /var

Значення: Використання диску концентрується в /var. Занурьтеся в /var/log і /var/lib.

Рішення: Ротація/усікання нестримних логів, очищення кешів, виправлення причини лог-шторму. Потім перезапустіть сервіси статистики.

Завдання 9: Шукати лог-шторм, що також викликає виснаження інодів

cr0x@server:~$ ls -lh /var/log | tail -n 10
-rw-r----- 1 root adm  12G Dec 23 09:10 syslog
-rw-r----- 1 root adm 8.1G Dec 23 09:09 kern.log
-rw-r----- 1 root adm  55M Dec 23 08:50 pveproxy/access.log

Значення: syslog і kern.log величезні. Щось спамується. Виправити pvestatd без зупинки спаму — як нівечити човен, залишаючи дірку відкритою.

Рішення: Зупинити джерело спаму; безпечно прокрутити або обнулити логи; повернути простір. Потім підтвердити, що pvestatd і rrdcached можуть писати.

Завдання 10: Перевірити власність і права директорій RRD

cr0x@server:~$ ls -ld /var/lib/rrdcached /var/lib/rrdcached/db
drwxr-xr-x 5 root root 4096 Dec 23 08:55 /var/lib/rrdcached
drwxr-xr-x 6 root root 4096 Dec 23 08:55 /var/lib/rrdcached/db

Значення: Власник root, що часто неправильно для моделі оновлень rrdcached. Залежно від налаштувань, rrdcached очікує власника користувача/групи rrdcached або конкретних групових дозволів на сокет.

Рішення: Перевірте користувача виконання rrdcached і виправте власність. Уникайте recursive chmod 777 «вирішень» — потім пошкодуєте.

Завдання 11: Підтвердити користувача rrdcached і ефективні права

cr0x@server:~$ ps -o user,group,pid,cmd -p $(pidof rrdcached)
USER     GROUP    PID CMD
rrdcached rrdcached 612 rrdcached -l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/

Значення: Демон працює як rrdcached. Йому потрібен доступ на запис до своїх journal і DB директорій.

Рішення: Встановіть правильну власність rrdcached:rrdcached для /var/lib/rrdcached (якщо така ваша конфігурація) і переконайтесь, що групові дозволи відповідають доступу до сокета.

Завдання 12: Безпечно виправити власність директорій (лише після перевірки конфігурації)

cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl restart rrdcached
cr0x@server:~$ systemctl restart pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Значення: Сервіси повернулись. Це необхідно, але не достатньо.

Рішення: Підтвердіть, що графіки оновлюються, перевіривши час модифікації RRD файлів і журнали pvestatd.

Завдання 13: Перевірити оновлення RRD (часи модифікації мають рухатися)

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | tail -n 5
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/mem.rrd

Значення: RRD файли торкаються. Це сильний знак, що оновлення відновились.

Рішення: Якщо часи не змінюються, повертайтесь до налагодження сокета/шляху запису.

Завдання 14: Виявити корупцію (RRD «invalid header» — ваш підказник)

cr0x@server:~$ rrdtool info /var/lib/rrdcached/db/pve2-node/server/cpu.rrd | head
ERROR: /var/lib/rrdcached/db/pve2-node/server/cpu.rrd: invalid header (bad magic)

Значення: Файл пошкоджено. Він не буде графуватись. pvestatd може падати при спробі його оновити (залежно від обробки помилок).

Рішення: Замініть пошкоджений RRD на новий (втратите історію для цього ряду) або відновіть зі резервної копії, якщо вона є.

Завдання 15: Визначити, наскільки пошкодження поширене

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -print0 | xargs -0 -n1 sh -c 'rrdtool info "$0" >/dev/null 2>&1 || echo "BAD $0"' | head
BAD /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
BAD /var/lib/rrdcached/db/pve2-node/server/loadavg.rrd

Значення: Ви можете оцінити радіус ураження. Якщо це кілька файлів — замініть їх. Якщо сотні — розгляньте скидання всього дерева RRD після виправлення дискових проблем.

Рішення: Цілеспрямована заміна для невеликого пошкодження; повний скидання для масштабної руйнації (після переконання в цілісності ФС).

Завдання 16: Перевірити синхронізацію часу (графіки можуть «зупинитись» через неправильний час)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-23 09:16:02 UTC
           Universal time: Tue 2025-12-23 09:16:02 UTC
                 RTC time: Tue 2025-12-23 06:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Значення: NTP «active», але годинник не синхронізовано і RTC дрейфує. Якщо час стрибатиме, поведінка RRD стане незрозумілою і графіки можуть мати пропуски.

Рішення: Виправте синхронізацію часу перед тим, як робити висновки про «зламані» статистики. Час — це залежність, а не пропозиція.

Завдання 17: Виявити тайм-аути бекендів сховища, що гальмують збір статистики

cr0x@server:~$ journalctl -u pvestatd -b --no-pager | tail -n 20
Dec 23 09:05:11 server pvestatd[1320]: storage 'nfs-archive' status error: timeout waiting for response
Dec 23 09:05:11 server pvestatd[1320]: unable to update storage statistics

Значення: Один проблемний storage може зламати або затримати цикл статистики. Класичний випадок: графіки помирають, бо NFS змонтований не відповідає, а не через проблеми з RRD.

Рішення: Виправте або тимчасово відключіть проблемний storage у конфігурації; переконайтесь, що pvestatd стабілізується.

Завдання 18: Перевірити статус сховищ Proxmox з CLI (без здогадок через UI)

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active        29454016        10240000        17600000   34.77%
nfs-archive   nfs     inactive              0               0               0    0.00%

Значення: Сховище неактивне; pvestatd про нього скаржився. Маємо чітку причину.

Рішення: Якщо воно потрібне — виправте монтру/мережу. Якщо застаріле — видаліть з конфігурації. Зомбі-сховища вбивають статистику.

RRD і rrdcached: ремонт, скидання і коли приймати втрату даних

Зрозуміти складові

Конвеєр зазвичай виглядає так:

• pvestatd періодично збирає значення.
• Він передає оновлення в rrdcached через UNIX сокет.
• rrdcached кешує оновлення і записує їх у RRD файли.
• Веб-UI Proxmox читає дані RRD і рендерить графіки.

Збої концентруються навколо:

• Проблем із сокетом: неправильний шлях, права, демон впав, застарілий файл сокета.
• Права директорій/файлів: rrdcached не може писати журнал/DB, або pvestatd не може підключитись.
• Диск/іноди заповнені: записи не проходять; журнали не можуть очиститись; демони падають.
• Пошкодження RRD: невірні заголовки, обрізані файли, випадкові помилки читання через проблеми зі сховищем.
• Неперервність часу: оновлення не відображаються через неправильний системний час.

Рішення: рятувати чи скидати?

RRD — не транзакційна база. Якщо є корупція, варіантів небагато:

• Невелика кількість пошкоджених файлів: видаліть/замістьіть ті файли і дозвольте Proxmox створити їх наново.
• Широкомасштабна корупція: скиньте все дерево RRD після виправлення дискової/ФС проблеми. Прийміть втрату історії; відновіть коректність.
• Є резервні копії/snapshots /var/lib/rrdcached: відновіть директорію (найкращий варіант).

Моє тверде правило: якщо хост пережив інцидент з переповненням диска або помилки ФС, і ви бачите багато пошкоджених RRD, припиніть намагатись їх зберегти. Вам не потрібні «історичні» графіки на основі купи тиші.

Цілеспрямований ремонт: замінити лише пошкоджені серії

Після зупинки сервісів ви можете перемістити пошкоджені RRD в карантин і дозволити відновлення. Proxmox відтворить відсутні RRD при отриманні нових даних.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mkdir -p /root/rrd-quarantine
cr0x@server:~$ mv /var/lib/rrdcached/db/pve2-node/server/cpu.rrd /root/rrd-quarantine/
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Що це означає: Ви пожертвували одним тимчасовим рядом, щоб відновити оновлення. Новий файл створиться; історичний CPU графік скинеться. Це прийнятно — вам потрібен моніторинг, а не ностальгія.

Повний скидання: коли все прогнило

Якщо більшість RRD пошкоджено або DB дерево в жахливому стані — скиньте його. Але тільки після того, як ви виправите місце на диску, цілісність ФС і синхронізацію часу — інакше ви зіпсуєте нові файли.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mv /var/lib/rrdcached/db /var/lib/rrdcached/db.broken.$(date +%s)
cr0x@server:~$ mkdir -p /var/lib/rrdcached/db
cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd

Що це означає: Ви починаєте з чистого аркуша. За кілька хвилин графіки повинні почати заповнюватись. Якщо не починають — проблема не в старих RRD файлах, а в каналі або залежностях.

Перевірка на швидкість: чи можемо ми поговорити з rrdcached?

Швидка перевірка — чи існує сокет і чи доступний він для запису групою користувача сервісу. Не завжди просто «написати» тестовий рядок без знання імен RRD, але ви можете підтвердити наявність сокета й права.

cr0x@server:~$ stat /run/rrdcached/rrdcached.sock
  File: /run/rrdcached/rrdcached.sock
  Size: 0         	Blocks: 0          IO Block: 4096   socket
Device: 0,21	Inode: 12345       Links: 1
Access: (0777/srwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-12-23 08:55:02.000000000 +0000
Modify: 2025-12-23 08:55:02.000000000 +0000
Change: 2025-12-23 08:55:02.000000000 +0000

Що це означає: Сокет існує й має широкі дозволи (можливо, занадто широкі). Якщо pvestatd все ще скаржиться на підключення — можливо, він використовує інший шлях або сокет створюється в іншому місці під час завантаження.

Жарт #1: Коли графіки зникають, це не «лише UI». Це система ввічливо каже, що в неї скінчилося терпіння.

Підводні камені кластера та багатонодових систем

На автономній ноді проблеми з pvestatd зазвичай локальні: диск, права, сокет, корупція. У кластері додаються дві додаткові групи проблем:

• Розбиті симптоми: одна нода без графіків, інша в порядку, третя іноді оновлюється.
• Перехресні залежності: зламані визначення сховища або дрейф часу на одній ноді можуть створити плутану поведінку UI при переході між нодами.

Правило для кластера: підтвердьте, чи проблема по-нодно

Запустіть перевірки сервісів на кожній ноді. Не думайте, що якщо UI порожній скрізь, то це «GUI». Може бути кеш браузера, або ж усі ноди отримали одну й ту ж зміну (наприклад, скрипт жорсткого загартування).

cr0x@server:~$ for n in pve1 pve2 pve3; do echo "== $n =="; ssh $n systemctl is-active pvestatd; done
== pve1 ==
active
== pve2 ==
failed
== pve3 ==
active

Значення: Проблема по вузлу. Перестаньте шукати кластерне чарівне виправлення. Порівняйте використання файлової системи pve2, конфіг rrdcached і визначення сховищ з іншими нодами.

Дрейф часу в кластері — особливий вид дурості

RRD не любить, коли час йде назад. Кластерні сервіси теж цього не люблять. Якщо одна нода дрейфує, вона може показувати графіки з пропусками, і ви помилково діагностуєте «зламані» статистики, тоді як насправді — «час зламався».

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0B0C0D (ntp1)
Stratum         : 3
Last offset     : +0.000842 seconds
RMS offset      : 0.001210 seconds
System time     : 0.000311 seconds fast of NTP time
Leap status     : Normal

Значення: Час стабільний. Якщо бачите великі зсуви або «Not synchronised», виправте це перш за все.

Зламані визначення сховища впливають на збір статистики

Збір статистики Proxmox часто опитує бекенди сховища. Відпала NFS сервер, завислий iSCSI шлях або команда Ceph, що зависла, можуть призвести до блокування або тайм-аутів pvestatd.

Ваш найкращий хід: отримати чистий pvesm status. Якщо сховище мертве й не потрібне — видаліть його з конфігурації. Якщо потрібне — виправте монтру/мережу. «Inactive назавжди» — не безпечний стан; це запрошення для тайм-аутів демона.

Тиск на сховище, права доступу і «чому графіки вмирають першими»

Чому графіки зникають на ранній стадії деградації хоста? Бо вони інтенсивно пишуться і не є критично важливими для підтримки роботи ВМ. Ядро із задоволенням тримає ваші робочі навантаження живими, поки фонова служба тихо втрачає можливість зберігати історію.

Інциденти з заповненим диском: ланцюгова реакція

Коли root заповнений:

• rrdcached не може скинути журнали або оновити RRD файли.
• pvestatd не може писати і виходить або агресивно перезапускається.
• Логи можуть ставати голоснішими, що використовує ще більше диска і погіршує ситуацію.
• Зрештою інші компоненти падають (оновлення пакетів, кеші автентифікації, кластерні повідомлення).

Якщо запам’ятати одне: спочатку вирішіть проблему місця/інодів. Всі інші виправлення залежать від можливості записати кілька кілобайт.

Права доступу: тихе саботування

Проблеми з правами часто виникають після:

• Ручного «прибирання», коли хтось виконав chown на /var/lib або відновив із бекапа з неправильною власністю.
• Скриптів жорсткої політики, що звужують права на /run або змінюють умови umask.
• Переміщення директорій на інші ФС і втрати ACL або розширених атрибутів.

Добрий підхід до дебагу — ставитися до /var/lib/rrdcached як до директорії даних програми: вона потребує стабільної власності, стабільних дозволів і вільного місця. Якщо ви тримаєте її на кореневому розділі разом з усім іншим — ви ставите історію моніторингу на волю ротації логів. Це смілива ставка.

Здоров’я файлової системи: якщо бачили корупцію, не ігноруйте диск

Пошкодження RRD часто є симптомом, а не хворобою. Якщо був пропадання живлення, глюк диска або падіння хоста VM, і тепер RRD пошкоджені — перевірте журнал ядра на I/O помилки і SMART статус. Інакше ви «полагодите» графіки і скоро втратите ноду.

cr0x@server:~$ dmesg -T | egrep -i 'ext4|xfs|btrfs|I/O error|nvme|ata' | tail -n 15
[Mon Dec 23 08:41:12 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Mon Dec 23 08:41:12 2025] Buffer I/O error on device sda2, logical block 1234567

Значення: Файлова система мала поганий день. Очікуйте корупції RRD. Не просто видаляйте RRD і рухайтесь далі; заплануйте вікно технічного обслуговування для ремонту ФС і перевірки обладнання.

Ось цитата, переказана від вагомого фахівця з надійності: перефразована думка — «Надія — не стратегія; будувати системи, що припускають відмову» — приписується Gene Kranz (перефразовано).

Три корпоративні історії з практики

1) Інцидент через хибне припущення: «Це просто веб-UI»

Ситуація: середня компанія з кластером Proxmox, що підтримує внутрішні сервіси — CI раннери, кілька баз даних і багато «тимчасових» ВМ, які стали постійними. Одного ранку на найзавантаженішій ноді зникли графіки. Інженер на чергуванні припустив, що це проблема браузера або регресія UI після оновлень. Він перезапустив pveproxy і pvedaemon, бо це сервіси, які всі знають.

Графіки залишились порожніми. Вони підняли тікет вендору і запланували поступовий перезапуск нод, щоб «очистити стан». Тим часом реальна проблема була очевидною: кореневий розділ був 100% заповнений, бо одна ВМ під час бекапу генерувала помилки автентифікації щосекунди, а ротація логів не встигала.

Коли перша нода перезавантажилась, вона повернулась повільніше, ніж зазвичай. Сервіси, які потребували запису диску під час завантаження, спотикались. Декілька ВМ не вдалося автоматично стартувати. Сфера проблем розширилась: вже було не лише графіки, а й доступність.

Коли хтось нарешті виконав df -h, виправлення було очевидним: зупинити джерело лог-спаму, акуратно обрізати логи, звільнити простір, перезапустити rrdcached і pvestatd. Графіки повернулись. Перезавантаження стало єдиним по-справжньому небезпечним кроком, зробленим через припущення, що «графіки — це справа UI».

Урок: графіки — симптом стану шляху запису. Коли вони зникають, перше питання має бути «чи може ця нода писати дані надійно?», а не «чи браузер закешував щось?»

2) Оптимізація, що відвернулась: «Змістимо rrdcached на швидше сховище»

Інша організація, схожа атмосфера: команда дбала про продуктивність, багато SSD, бажання тримати root чистим. Хтось вирішив перенести /var/lib/rrdcached на «швидкий» ZFS dataset з агресивною компресією і трохи екзотичними параметрами монтажу. У тестах все працювало. У проді теж здавалося нормально.

Але потім підступило «назад». Датасет включили в регулярні snapshot/реплікації з частими снапшотами. RRD файли маленькі, але багато і часто оновлюються. Оверхед снапшотів спричинив достатні латентні сплески під час скидання, що змусило rrdcached відставати. З’явились випадкові тайм-аути. Графіки стали періодично застарілими — саме та проблема, що підіб’є довіру до моніторингу.

Команда відрегулювала інтервали запису rrdcached, щоб зменшити частоту скидання. Це зменшило I/O, але збільшило кількість втрат даних при некоректному відключенні і посилило ефект «графіки відстають». Люди перестали перевіряти графіки, бо вони не були своєчасними. Моніторинг став декоративним.

Кінцева нудна, але правильна дія: тримати /var/lib/rrdcached на стабільній локальній ФС з передбачуваною латентністю, виключити його з агресивної політики снапшотів і прийняти, що RRD дані не такі цінні, щоб їх реплікувати з тим же фанатизмом, як диски ВМ.

Урок: бекенд моніторингу має бути стабільним і нудним. Низька латентність допомагає, але передбачуваність важливіша за хитромудрі оптимізації.

3) Нудна, але правильна практика, що врятувала день: «Відділити /var і встановити пороги»

Третя команда вже переживала відмови через заповнення диска. Вони зробили дві нудні речі: виділили /var на окрему файлову систему з запасом вільного місця і налаштували оповіщення на 70% і 85% використання з політикою ескалації. Не гламурно. Не для конференцій. Просто працює.

Одного дня зміни в мережі спричинили повторювані помилки автентифікації для монтованого сховища, що викликало постійний потік логів. Використання диска росло. Спрацювало оповіщення на 70% і його відреагували. Інженер на чергуванні не «вирішив пізніше». Він почав розбиратись негайно, бо так прописано в рукобуку, і тому, що вже бачили наслідки 90%.

Корінь проблеми вирішили (дані доступу й поведінка повторних спроб монтування), ротація логів відбулась. pvestatd ніколи не впав. Графіки не зникли. Ніхто не мав гадати, що трапилось, бо тимчасова історія залишилась цілою й нудною.

Урок: відділяйте критичні write-heavy ділянки, оповіщайте рано й ставтесь до заповнення диска як до інциденту надійності, а не як до прибирання.

Жарт #2: Місце на диску — як офісна політика: ігноруєш довго — воно рано чи пізно організує зустріч з вашим CEO.

Типові помилки: симптом → корінь → виправлення

1) Симптом: GUI не показує графіків; pvestatd «failed»

Корінь: невідповідність шляху сокета rrdcached або відсутній сокет.

Виправлення: Підтвердьте реальний сокет через ss -xlpn, узгодьте конфіг у /etc/default/rrdcached, перезапустіть rrdcached, потім pvestatd.

2) Симптом: в логах pvestatd «Permission denied» при записі RRD

Корінь: Неправильна власність/режим на /var/lib/rrdcached або директорії журналу; іноді через відновлення чи ручні зміни.

Виправлення: Підтвердьте користувача rrdcached через ps, застосуйте правильний chown -R на /var/lib/rrdcached, перезапустіть сервіси.

3) Симптом: графіки зупинилися, хоча сервіси «active»

Корінь: Диск заповнений або виснажені іноди, що викликає тихі відмови оновлень; або rrdcached відстає з великим журналом.

Виправлення: Перевірте df -h і df -i. Звільніть місце/іноди. Потім перевірте, чи рухаються часові мітки RRD.

4) Симптом: помилки типу «invalid header (bad magic)»

Корінь: Пошкоджені RRD файли, часто після переповнення диска або помилок файлової системи.

Виправлення: Карантинні файли RRD або скиньте дерево RRD; розберіться з диском/ФС.

5) Симптом: pvestatd періодично падає; в логах згадки про тайм-аути сховища

Корінь: Один проблемний бекенд сховища (завислий NFS, проблеми iSCSI, повільний Ceph) блокує збір статистики.

Виправлення: pvesm status щоб ідентифікувати неактивні сховища. Виправте мережу/монтування або видаліть мертве сховище.

6) Симптом: графіки мають пропуски або дивні «плоскі» ділянки по нодах

Корінь: Дрейф часу або NTP не синхронізований; іноді після паузи/пробудження VM або проблем з RTC.

Виправлення: Використайте timedatectl та chronyc tracking. Виправте синхронізацію часу; уникайте великих ручних стрибків часу.

7) Симптом: перезапуск pvestatd «виправляє» коротко, потім знову падає

Корінь: Цикл перезапуску ховає постійну upstream проблему (диск, права, тайм-аути сховища). Перезапуски — знеболювальне, а не операція.

Виправлення: Читайте журнал, знайдіть першу помилку і вирішіть залежність. Припиніть флапінг; стабілізуйте систему.

Контрольні списки / покроковий план

Чеклист A: Повернути графіки за 15 хвилин (безпечний шлях)

1. Перевірте systemctl status pvestatd і journalctl -u pvestatd -b на предмет першої реальної помилки.
2. Перевірте systemctl status rrdcached і підтвердьте сокет через ss -xlpn | grep rrdcached.
3. Перевірте вільне місце й іноди: df -h /, df -i /.
4. Якщо диск/іноди заповнені — звільніть простір спочатку. Краще зупинити джерело спаму, потім ротацію/усікання логів.
5. Переконайтесь, що власність /var/lib/rrdcached відповідає користувачу виконання rrdcached.
6. Перезапускайте в порядку: systemctl restart rrdcached, потім systemctl restart pvestatd.
7. Підтвердіть оновлення RRD: перевірте час модифікації файлів у /var/lib/rrdcached/db.
8. Якщо з’являється корупція — карантинуйте окремі пошкоджені файли. Якщо багато файлів пошкоджено — скиньте дерево RRD після перевірки стану сховища.

Чеклист B: Стабілізувати і запобігти повторенню (дорослий шлях)

1. Переконайтесь у стабільності синхронізації часу: увімкніть і перевірте chrony/systemd-timesyncd; виправте хронічний дрейф RTC.
2. Переконайтесь, що /var має достатній запас; розгляньте окрему файлову систему або dataset з порогами моніторингу.
3. Аудитуйте налаштування ротації логів. Переконайтесь, що неможливо генерувати багатогігабайтні логи за кілька годин без оповіщень.
4. Перегляньте визначення сховищ; видаліть мертві сховища з конфігу. «Inactive» має бути виключенням, а не нормою.
5. Якщо бачили помилки ФС — заплануйте обслуговування: fsck де потрібно, SMART тести, заміну сумнівних носіїв.
6. Документуйте шлях сокета rrdcached і права. Уникайте «таємних симлінків», які ніхто не розуміє.

Чеклист C: Коли потрібно скинути дані RRD (без загострення проблеми)

1. Виправте місце на диску і перевірте здоров’я файлової системи перш ніж робити скидання.
2. Зупиніть pvestatd і rrdcached.
3. Перемістіть /var/lib/rrdcached/db в інше місце (не видаляйте одразу).
4. Створіть нову директорію db з правильною власністю.
5. Запустіть rrdcached, потім pvestatd.
6. Підтвердіть, що з’являються нові RRD файли і що часові мітки рухаються.

Питання й відповіді

1) Чи потрібно перезавантажувати Proxmox ноду, щоб виправити pvestatd?

Ні. Якщо перезавантаження «виправляє» — скоріше за все була тимчасова проблема з монтуванням або станом сервісу. Діагностуйте корінь (місце, сокет, права, тайм-аути сховища), щоб проблема не повернулась.

2) Чому мої ВМ в порядку, але графіки відсутні?

Бо конвеєр моніторингу не потрібен для роботи віртуалізації. Це канарка для стану шляху запису й залежностей сервісів. Ставтесь до нього як до раннього попередження, а не декоративної дрібниці.

3) Я перезапустив pveproxy і все одно немає графіків. Чому?

Бо pveproxy рендерить UI, але не генерує тимчасові ряди. Якщо pvestatd не оновлює RRD, у UI немає нових даних для відображення.

4) Чи може зламаний NFS сховати справжні графіки ноди?

Може. Якщо збір статистики намагається опитати статус сховища, і цей запит блокується або тайм-аутиться, цикл може провалитись або відставати. Виправте монтування, мережу або видаліть мертве сховище з конфігурації.

5) Чи безпечно видаляти RRD файли?

В безпечному розумінні — так, ви не зламаєте ВМ. Ви втратите історичні графіки для видалених серій. Якщо файли пошкоджені, їх видалення/карантин часто найшвидший шлях повноцінного моніторингу.

6) Чому синхронізація часу важлива для графіків?

RRD групує дані за часом. Великі стрибки створюють пропуски або дивні артефакти при консолідації. У кластері дрейф часу також викликає ширші операційні аномалії. Тримайте NTP здоровим.

7) Моя ФС не заповнена. Що ще може викликати «Permission denied»?

Неправильна власність від відновлень, переміщення директорій або скрипти загартування, що змінюють umask або runtime директорії. Підтвердіть користувача сервісу і власність директорій. Не вирішуйте проблему світовою записуваністю.

8) Як підтвердити, що графіки оновлюються без GUI?

Перевірте час модифікації *.rrd файлів у /var/lib/rrdcached/db. Якщо часові мітки рухаються кожні кілька хвилин — оновлення йдуть. Також перевірте, що журнали pvestatd «затихли» (не видають помилок).

9) Чому іноді rrdcached запущений, але сокет відсутній?

Якщо директорія для сокета не існувала при запуску, або права заважають створенню сокета, rrdcached може не надати очікуваного endpoint. Підтвердіть шлях сокета у конфігу і що директорія існує й доступна для запису.

10) Чи варто переміщувати RRD дані на спільне сховище?

Зазвичай ні. RRD — маленькі й інтенсивно пишучі; спільне сховище додає латентності й режими відмов. Якщо бажаєте централізувати метрики — використайте повноцінний стек моніторингу, а не намагайтесь «скластеризувати» RRD файли.

Наступні кроки, щоб цього не повторилось

Відновлення графіків — це легка частина. Тримати їх надійними — робота.

• Робіть видимим тиск на диск: оповіщення щодо використання простору та інодів значно раніше ніж 95%.
• Тримайте rrdcached передбачуваним: стабільний шлях сокета, правильна власність, уникайте хитромудрих переміщень, що додають латентність.
• Прибирайте мертві визначення сховища: не дозволяйте поламаним монтуванням висіти місяцями як «inactive».
• Виправте синхронізацію часу назавжди: стабільний NTP, адекватний RTC, жодних ручних стрибків часу в проді.
• Якщо бачили корупцію — перевірте обладнання: не сприймайте помилки RRD як лише софтверну незручність.

Якщо зробите це, pvestatd стане тим, чим має бути: фоновим шумом, про який ви ніколи не думаєте. Це і є найкращий тип моніторингу.