Jinsi ya kufuatilia afya ya diski kwenye VPS

Kile ambacho ufuatiliaji wa afya ya diski kwenye VPS kinaweza kuona kwa hakika

Ufuatiliaji wa afya ya diski kwenye VPS huanza na ukweli ambao miongozo mingi huuepuka: diski si yako. Mfumo wako wa wageni (guest) huona kifaa cha block cha mtandaoni. Hifadhi halisi, na kila kaunta iliyohifadhiwa ndani yake, ni mali ya mwenyeji (host). smartctl /dev/vda haishindwi kwa sababu uliandika amri vibaya. Inashindwa kwa sababu hakuna kitu nyuma ya kifaa hicho kinachoweza kujibu swali hilo.

SMART (teknolojia ya kujifuatilia, kuchanganua na kuripoti) ni jedwali la kaunta zinazohifadhiwa kwenye diski yenyewe: sekta zilizotengwa upya (reallocated sectors), sekta zinazosubiri (pending sectors), saa za kufanya kazi, na makosa ya midia. Kusoma jedwali hilo kunahitaji njia kwa ajili ya amri za ATA au NVMe (non-volatile memory express) ili kufikia maunzi halisi. Diski ya paravirtual haitoi njia hiyo, kwa hivyo mfumo wa wageni hupata hifadhi ambayo telemetry yake imeondolewa.

Mpangaji hufuatilia athari, si maunzi. Ishara nne zinaonekana kutoka ndani ya mfumo wa wageni: makosa ya I/O (input/output) katika logi ya kernel, mfumo wa faili unaojipachika upya kama read-only, latency inayoongezeka, na nafasi inayoisha. Zote nne zinaweza kuwekewa tahadhari leo, na zote nne huonekana kabla mtumiaji hajalamika. Zisanidi hizo kwanza. Mgawanyo wa majukumu huja mwishoni, kwa sababu hubadilisha mahali ambapo unapaswa kutumia nguvu zako.

Thibitisha kile seva yako inachokifichua

Usikisie hali uliyopo. Angalia, kisha soma sehemu inayolingana na hali hiyo.

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

virtio-blk, diski ya kawaida ya KVM (kernel-based virtual machine). Kifaa ni /dev/vda na smartctl husimama kabla ya kutuma chochote:

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

virtio-blk ni usafirishaji wa paravirtual ambao hauna seti ya amri za ATA au SCSI nyuma yake, kwa hivyo hakuna njia ya kubeba ombi la SMART. -d sat na -d scsi hushindwa kwa njia ile ile, kwa sababu usafirishaji ndio tatizo na si flag.

Diski ya SATA au SCSI iliyoigwa (emulated). Kifaa ni /dev/sda na smartctl hufika mbali vya kutosha kukitambua. Mstari wa model unasomeka QEMU HARDDISK. Mfuatano huo wa herufi unajibu swali lenyewe: unasoma kifaa kilichobuniwa na emulator, na hakiripoti uwezo wowote wa SMART unaoweza kutumika.

Namespace ya NVMe. sudo nvme smart-log /dev/nvme0n1 hurejesha log kamili, ambayo ndiyo watu hudanganyika kwayo. Kwanza kagua utambulisho wa controller kwa sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Nambari ya model inayotaja bidhaa ya hifadhi ya mtandao inamaanisha kuwa controller ni programu, kwa hivyo percentage_used na media_errors hufafanua uigaji huo badala ya flash iliyo chini ya data yako. Ikiwa unataka kujua hifadhi yako ni nini hasa, thibitisha diski ya NVMe kwenye Linux badala ya kuamini maelezo ya mpango.

Container, kama vile LXC (Linux containers) au OpenVZ. Huna block device yako mwenyewe. lsblk huonyesha vifaa vya host au haionyeshi chochote, na smartctl hukataliwa kwa sababu container haishikilii CAP_SYS_RAWIO:

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

Onyo moja kuhusu hali ambapo inafanya kazi. Ikiwa smartctl kwenye VPS inarejesha jedwali kamili la attribute, soma nambari ya serial kabla ya kuchukua hatua yoyote. Baadhi ya host hufichua node ya kifaa cha passthrough, na kaunta hizo ni za maunzi yanayoshirikiwa na kila mpangaji kwenye mashine hiyo. Reallocated_Sector_Ct inayopanda hapo ni tiketi ya msaada. Sio taarifa kuhusu data yako.

Ishara ya 1: Hitilafu za I/O kwenye logi ya kernel

Hii ndiyo ishara yenye thamani zaidi ambayo mpangaji (tenant) anayo, na haihitaji wakala (agent) yeyote.

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'

Ombi lililoshindwa kutoka kwenye diski ya mtandaoni linaonekana hivi:

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

Tabaka la block liliomba uandishi (write) kutoka kwa mwenyeji (host) na mwenyeji akarudisha hitilafu. Kwenye VPS, hii mara chache huwa ni seli ya flash inayokufa. Kwa kawaida ni tabaka la hifadhi la mwenyeji au njia ya mtandao kuelekea hifadhi iliyounganishwa kwenye mtandao (network attached storage), kwa hivyo ni tukio la upande wa mtoa huduma. Nakili muhuri wa muda (timestamp), jina la kifaa, na sekta (sector) kwenye tiketi yako, kwa sababu hayo ndiyo mambo ambayo timu ya hifadhi inaweza kulinganisha na logi zao wenyewe.

Mfuatano wa ext4 ambao ni muhimu zaidi ni jozi hii:

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

Mstari wa pili ndio unaoumiza, kwa sababu mashine inabaki ikiwa imewaka. Inajibu ping, inajibu SSH, na kila uandishi unashindwa. Ukaguzi wa kawaida wa HTTP unaendelea kufaulu wakati programu yako ikitoa hitilafu kwenye kila ombi.

XFS inazima mfumo wa faili (filesystem) badala yake:

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 inasoma boot ya sasa pekee isipokuwa kama logi (journal) imehifadhiwa kwenye diski, na picha (images) nyingi husambazwa na logi tete inayokaa kwenye RAM. Washa uendelevu (persistence), la sivyo ushahidi utatoweka wakati hasa wa reboot utakayofanya wakati wa kutatua matatizo.

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

Baada ya reboot yako inayofuata, journalctl --list-boots inapaswa kuorodhesha zaidi ya boot moja. Hata uendelevu ukiwa umewashwa, mfumo wa faili uliogeuka kuwa wa kusoma pekee (read-only) hauwezi kurekodi kilichotokea baadaye, jambo ambalo ni hoja ya kweli ya kusafirisha logi nje ya mashine hiyo.

Ishara ya 2: kunasa remount ya read-only

Fanya hitilafu iwe dhahiri kabla ya kujaribu kuigundua.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Tafuta errors=remount-ro katika chaguzi za mount. Picha za cloud za Ubuntu na Debian huiweka katika /etc/fstab, kwa hivyo hitilafu ya metadata hufanya mfumo wa faili kuwa read-only badala ya kuendelea juu ya uharibifu. Ikiwa haipo, iongeze kwenye ingizo la root katika /etc/fstab, au iweke kwenye superblock kwa kutumia sudo tune2fs -e remount-ro /dev/vda1. Kusimama kwa kelele ni bora kuliko ufisadi wa kimya.

Bendera ya mount si uthibitisho. Jaribu kwa kuandika:

touch /var/tmp/.disk-probe

Kwenye root ya read-only, hii huchapisha hasa:

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

Tumia /var/tmp, si /tmp. Kwenye picha nyingi /tmp ni tmpfs inayoshikiliwa kwenye kumbukumbu, kwa hivyo uandishi uliofanikiwa hapo hauthibitishi chochote kuhusu diski yako.

Funga jaribio la uandishi pamoja na ukaguzi wa nafasi, na utume heartbeat pale tu kila ukaguzi unapofaulu:

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 kwenye mstari huo wa mwisho inamaanisha mnyororo mzima unafanya kazi. set -eu hufanya ukaguzi wowote ulioshindwa utoke kwa exit code isiyo ya sifuri kabla ya mstari wa curl kuendeshwa, kwa hivyo hakuna heartbeat inayotumwa. Ugeuzi huo ndio lengo: kifuatiliaji hugeuka kuwa chekundu kwa sababu hakuna kilichowasili, na seva isiyoweza kuandika haiwezi kuaminiwa kuelezea tatizo lake yenyewe. Usomaji bado hufanya kazi kwenye mfumo wa faili wa read-only, kwa hivyo hati yenyewe bado huanza.

Iendeshe kutoka kwa 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 inapaswa kuonyesha unit ikiwa na muda wa NEXT chini ya dakika tano. Uendeshaji ulioshindwa huonekana katika journalctl -u disk-probe.service pamoja na maandishi ya hitilafu ya shell yenyewe, kwa hivyo unaweza kutofautisha mfumo wa faili wa read-only na ule uliojaa bila kuingia kwenye seva.

URL hiyo ya push ni ya Uptime Kuma push monitor. Unda monitor ya aina ya Push, nakili token yake kwenye hati, na uweke muda wa heartbeat wa monitor kuwa mrefu kidogo kuliko muda wa timer ili uendeshaji mmoja wa polepole usikuamue saa 03:00. Ikiwa huna ukurasa wa hali bado, instance ya Uptime Kuma unayojiendeshea ndiyo mahali nafuu zaidi pa kuweka ukaguzi huu.

Vikwazo viwili vya kweli. Uchunguzi unathibitisha kuwa uandishi ulikubaliwa, si kwamba baiti zilifika kwenye hifadhi ya kudumu, kwa sababu usomaji unaweza kutolewa kutoka kwa page cache. Na inaendeshwa kwenye mashine inayofuatiliwa, kwa hivyo seva iliyokwama kabisa itakaa kimya badala ya kuripoti utambuzi.

Ishara 3: mienendo ya latency na throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Soma r_await na w_await kwanza. Hizi ni wastani wa milisekunde ambazo operesheni ya kusoma (read) au kuandika (write) ilichukua, ikijumuisha muda uliotumika kusubiri kwenye foleni. Soma aqu-sz inayofuata, ambayo ni wastani wa idadi ya maombi yanayoshughulikiwa kwa wakati mmoja. Puuza %util kwenye diski ya mtandaoni (virtual disk): inamaanisha tu kwamba foleni haikuwa tupu, na kifaa kinachohudumia maombi mengi kwa sambamba kinaweza kuwa karibu na asilimia 100 wakati bado hakijafikia kikomo chake. await ndiyo namba inayofuatilia kile ambacho watumiaji wanahisi.

Thamani kamili si muhimu kama msingi wako wa awali (baseline), kwa hivyo rekodi saa tulivu na uihifadhi. /proc/diskstats ndiyo chanzo cha data ghafi ikiwa ungependa kukusanya vihesabio mwenyewe.

Kwa kipimo cha makusudi:

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

Soma kizuizi cha clat percentiles, hasa asilimia 99 (99th percentile). --direct=1 inaruka page cache yako. Hairuki cache ya mwenyeji (host), kwa hivyo matokeo yanaelezea njia nzima kuanzia mchakato wako hadi kwenye hifadhi ya jukwaa (platform storage). Iendeshe wakati seva haina shughuli nyingi, kwa sababu inashindana na mzigo wako wa kazi.

Kuongezeka kwa await bila makosa yoyote kwenye logi ya kernel kwa kawaida si ishara ya diski inayofeli. Ni mgongano wa rasilimali kwenye mwenyeji, toleo la hifadhi la CPU steal time kutoka kwa jirani mwenye kelele. Ikiwa hali hii inajirudia kila siku kwa saa ileile na tiketi yako ya msaada inarudi bila tatizo, jibu ni mpango ambao I/O yake haishirikiwi kwa njia ileile, jambo ambalo ni kweli kwa a storage VPS over a regular VPS wakati mzigo wa kazi unategemea sana diski.

Ishara ya 4: ukaguzi wa mfumo wa faili unaoweza kufanywa ukiwa umepachikwa (mounted)

ext4 huhifadhi kaunta ya hitilafu kwenye superblock, na hii hubaki hata baada ya kuwasha upya seva (reboot) hata kama logi zako zimefutika.

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

Mfumo wa faili ulio mzima huchapisha Filesystem state: clean na FS Error count: 0. clean with errors na namba isiyo sifuri inamaanisha kernel ilikumbana na hitilafu ya metadata wakati fulani, hata kama hakuna aliyeona na logi imeshapita. Amri hiyo inapaswa kuwemo kwenye ukaguzi wa kila wiki.

Huwezi kufanya fsck kwenye mfumo wa faili wa root uliopachikwa, na e2fsck -n kwenye mfumo wa faili unaofanya kazi huripoti matatizo ambayo ni mabadiliko ya data yanayoendelea tu. Ili kulazimisha ukaguzi wa kweli, ongeza fsck.mode=force fsck.repair=yes kwenye mstari wa amri wa kernel kwa boot moja kupitia console ya mtoa huduma wako. systemd-fsck kisha huendesha ukaguzi kabla ya root kupachikwa kwa hali ya kusoma na kuandika (read-write).

XFS haina ukaguzi wa mtandaoni. xfs_repair -n /dev/vda1 hukataa kufanya kazi kwenye mfumo wa faili uliopachikwa, kwa hivyo inapaswa kufanywa katika hali ya rescue mode. XFS hulipa fidia hiyo kwa kuwa na sauti: huzima mfumo wa faili pindi hitilafu ya metadata inapotokea badala ya kuendelea.

Kwenye Btrfs kaunta zimejengwa ndani na ni za kudumu.

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

write_io_errs au corruption_errs ikiwa juu ya sifuri ni tukio la kweli, na kaunta huhifadhi thamani zake baada ya reboot hadi utakapozirejesha (reset). scrub husoma upya kila block na kuhakiki checksum yake, ambayo ndiyo kitu cha karibu zaidi na jaribio la media linalopatikana kwenye diski ya mtandaoni. Inatumia I/O nyingi, kwa hivyo ipange kwa saa tulivu.

Ishara ya 5: nafasi iliyo wazi, ikijumuisha sehemu ambazo df huficha

Kuishiwa na nafasi ya diski huivuruga seva kama vile diski mbovu, na jambo hili hutokea mara nyingi zaidi.

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

No space left on device wakati df -h inapoonyesha nafasi iliyo wazi inamaanisha kuwa umeishiwa na inodes badala ya bytes, na df -i inaonyesha IUse% ikiwa katika asilimia 100. Mamilioni ya faili ndogo katika saraka ya cache au mail spool husababisha hili, na kufuta faili kubwa hakusaidii.

Nafasi isiyorejea baada ya kufuta faili kwa kawaida ni faili iliyofutwa ambayo bado imeshikiliwa na mchakato unaoendelea (running process). sudo lsof +L1 huorodhesha faili ambazo idadi ya viungo (link count) imefika sifuri. Kuanzisha upya mchakato unaoshikilia faili hiyo kutafungua nafasi hiyo.

Journal ni mtumiaji wa kawaida wa nafasi ambaye hufanya kazi kimya kimya. journalctl --disk-usage huripoti kile inachokihifadhi. Iwekee kikomo kwa kutumia SystemMaxUse=200M katika /etc/systemd/journald.conf ikifuatiwa na sudo systemctl restart systemd-journald, na urejeshe nafasi hiyo sasa kwa kutumia sudo journalctl --vacuum-size=200M.

Kisa kimoja kinaonekana kama hitilafu (bug) lakini siyo. Kwenye hifadhi ya seva (host storage) iliyosanidiwa kwa mfumo wa thin provisioning, pool ya seva inaweza kujaa wakati df yako bado inaonyesha gigabytes zilizo wazi. Uandikaji wako kisha utafeli kwa hitilafu za I/O katika log ya kernel bila onyo lolote la nafasi ndani ya guest. Hitilafu bila mfumo wa faili kujaa ni mchanganyiko unaostahili kupelekewa tiketi ya msaada (ticket) ndani ya saa hiyo hiyo.

Kuunganisha mawimbi kwenye wakala wa metriki

Push probe hujibu ndiyo au hapana. Mitindo inahitaji wakala wa metriki, na Prometheus node_exporter tayari husafirisha kila kitu kilicho hapo juu bila usanidi wa ziada. Majina ya metriki ya kujengea ni:

• node_filesystem_readonly hupanda hadi 1 wakati mount ikiwa read-only, ambayo ndiyo kengele yako ya remount.
• node_filesystem_avail_bytes na node_filesystem_files_free hushughulikia baiti na inode kando.
• node_disk_io_time_seconds_total na node_disk_read_time_seconds_total hukupa muda wa shughuli na latency kama kaunta unazoweza kuchora kwenye grafu.

Sheria mbili hunasa visa vinavyosababisha ukurasa wa tahadhari:

- 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

Sheria ya pili huwaka wakati mwelekeo wa sasa unapofikia sifuri ndani ya siku nne, kwa hivyo unapata onyo siku kadhaa kabla badala ya kusubiri hadi ifike asilimia 95, ambapo utakuwa na dakika chache tu.

Nani anawajibika kwa nini

Mtoa huduma wako anamiliki diski za kimwili. Wao husoma SMART, huendesha array, na hubadilisha diski yenye sekta zilizotengwa (reallocated sectors) zinazoongezeka, kwa kawaida bila kukuambia, kwa sababu array hufyonza hitilafu hiyo. Hiyo ndiyo kazi ya RAID 10 kwenye VPS yako: diski iliyokufa inakuwa mchakato wa kujenga upya (rebuild) badala ya kukatika kwa huduma. Huwezi kuona lolote kati ya hayo, na kulipia uondoaji huo wa ugumu (abstraction) ndilo lengo kuu la kukodisha seva ya mtandaoni.

Wewe unamiliki data yako, na telemetry ya diski isingeweza kuilinda hata hivyo. Matukio yanayoharibu data ya mpangaji (tenant) kwa kweli ni rm ya kimakosa, deploy mbaya, mvamizi aliye na SSH key yako, na tukio la jukwaa (platform incident) linalochukua array nzima pamoja nayo. Sifa za SMART hazitabiri lolote kati ya hayo.

Kwa hivyo, ulinzi wa kweli wa mpangaji ni backup inayokaa nje ya seva na urejeshaji (restore) ambao umeufanya wewe mwenyewe. Snapshots za mtoa huduma ni rahisi kutumia na hukaa kwenye jukwaa moja na kitu wanachokilinda, ndiyo maana snapshots na backups ni ulinzi tofauti. Weka zoezi kwenye kalenda yako: mara moja kila robo mwaka, rejesha backup mpya zaidi kwenye VPS mpya, anzisha programu, na uandike muda uliotumika. Namba hiyo ndiyo muda wako halisi wa kurejesha huduma (recovery time). Zoezi la kwanza huwa polepole kuliko vile mtu yeyote alivyodhani.

Wakati SMART inapokuhusu

Miongozo inayofundisha smartctl ni sahihi, na inahusu vifaa pindi tu vinapokuwa mali yako:

• Seva iliyojitolea au bare metal, ambapo sudo smartctl -a /dev/sda inarejesha jedwali kamili la sifa na smartd inaweza kukutumia barua pepe sifa inapobadilika.
• Mipango ya hifadhi inayopitisha diski ya kimwili moja kwa moja kwa mgeni (guest). Watoa huduma huandika hili waziwazi, kwa sababu ni hoja ya mauzo.
• Vifaa unavyomiliki, nyumbani au katika nafasi ya rack unayokodisha.
• Diski iliyo nyuma ya RAID controller, inayoweza kufikiwa kwa sudo smartctl -a -d megaraid,0 /dev/sda, au USB enclosure yenye -d sat.

Kwenye NVMe halisi, sudo smartctl -a -d nvme /dev/nvme0 na sudo nvme smart-log /dev/nvme0n1 huripoti critical_warning na percentage_used kutoka kwenye diski yenyewe. Kwenye SATA halisi, sifa zinazotabiri kufeli ni Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) na Reported_Uncorrect (187). Yoyote kati ya hizo ikiondoka kwenye sifuri inamaanisha panga uingizwaji. Tafiti za diski kwa kiwango kikubwa huishia kwenye orodha hiyo hiyo fupi, na sifa nyingine nyingi ni kelele tu.

Endesha daemon badala ya kuangalia kwa mkono.

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

Log ya self-test inapaswa kuonyesha Completed without error kwa ajili ya jaribio uliloanzisha sasa hivi. Ubuntu na Debian husafirisha /etc/smartd.conf ikiwa na mstari wa DEVICESCAN, uliosasishwa kufikia Agosti 2026, kwa hivyo daemon huchukua kila diski inayoiona na kutuma barua pepe kwa root pindi mabadiliko yanapotokea. Hakuna kati ya hayo inayofanya kazi kwenye diski ya mtandaoni (virtual disk), ndiyo maana sehemu iliyobaki ya mwongozo huu ipo.

FAQ

Kwa nini smartctl haifanyi kazi kwenye VPS yangu?

Kwa sababu diski ni ya mtandaoni. Kwenye KVM guest inayotumia virtio-blk, smartctl -a /dev/vda huchapisha /dev/vda: Unable to detect device type, kwa sababu diski ya paravirtual haina njia ya amri ya ATA au SCSI kwa ajili ya ombi la SMART kupita. Kwenye diski iliyoigwa (emulated), unafikia kifaa ambacho modeli yake inasomeka QEMU HARDDISK, bila data yoyote ya SMART inayoweza kutumika nyuma yake. Ndani ya container, smartctl hukataliwa moja kwa moja kwa kukosa CAP_SYS_RAWIO. Hakuna kati ya haya ni usanidi mbaya, na hakuna flag ya -d inayoweza kurekebisha hali hiyo.

Nitajuaje kama diski ya VPS yangu inafeli?

Fuatilia athari badala ya maunzi. Kagua sudo journalctl -k -p err -b kwa ajili ya mistari ya blk_update_request: I/O error na kwa ajili ya Remounting filesystem read-only. Endesha sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' ili kupata makosa ambayo logi zimekwisha yapoteza. Fuatilia r_await kutoka iostat -xdz 5 dhidi ya msingi (baseline) uliorekodi wakati mfumo ulikuwa mzima. Kwenye VPS, kosa la I/O kwa kawaida humaanisha tatizo la hifadhi ya host badala ya diski inayokufa, kwa hivyo hilo ni jambo la kuweka kwenye tiketi ya msaada (support ticket) likiwa na timestamp na sekta husika.

Ni nini ninachopaswa kuwekea tahadhari (alert) kwa ajili ya afya ya diski ya VPS?

Tahadhari nne zinatosha. Mount ya read-only, kutoka node_filesystem_readonly == 1 au jaribio la kuandika (write probe) linalofeli. Nafasi iliyo wazi na inodes zilizo wazi zinazoelekea sifuri. Kosa lolote la kernel I/O error katika muda uliopita. Heartbeat kutoka kwa seva, ili ukimya ukutahadharishe wakati seva inapoacha kujibu. Achana na chochote kinachotokana na SMART, kwa sababu kwenye diski ya mtandaoni thamani hizo ama hazipo au zinaelezea uigaji wa hypervisor.

Kwa nini mfumo wangu wa faili uli-remount kuwa read-only?

ext4 iliyowekwa (mounted) na errors=remount-ro hufanya hivi kwa makusudi inapokutana na kosa la metadata: huacha kuandika badala ya kuendelea juu ya uharibifu. Kichochezi kipo kwenye logi ya kernel juu kidogo ya mstari wa remount, kwa kawaida ni EXT4-fs error kuhusu journal iliyokatishwa baada ya kifaa cha msingi kurudisha kosa la I/O. Ku-remount kuwa read-write bila kukagua mfumo wa faili huficha dalili na kuacha chanzo kikiendelea. Nasa logi, kisha kagua mfumo wa faili ukiwa ume-unmount kutoka rescue mode kwa kutumia e2fsck -fy /dev/vda1.

Je, ninaweza kusoma data ya SMART kwenye seva ya mtandaoni?

Katika hali maalum, ndiyo. Seva zilizojitolea (dedicated) na bare metal hukupa sifa halisi. Hivyo ndivyo ilivyo kwa mipango ya hifadhi inayopitisha diski halisi (passthrough) kwa guest, na host yoyote unayomiliki mwenyewe. Baadhi ya majukwaa huwasilisha NVMe controller kwa guest na nvme smart-log hurudisha logi, kwa hivyo endesha sudo nvme id-ctrl /dev/nvme0 kwanza: namba ya modeli inayotaja huduma ya hifadhi ya mtandao inamaanisha kuwa kaunta hizo zinatoka kwa controller ya programu. Na pale ambapo node ya passthrough inapoonyesha kaunta halisi kwenye mashine inayoshirikiwa, zinaelezea maunzi yanayoshirikiwa na wapangaji wengine, kwa hivyo hatua pekee ya maana ni tiketi ya msaada.