Nga vjen rritja e diskut të një serveri VPN dhe si ta kufizojmë

Tuneli ndalon pranimin e lidhjeve, shërbimi rindizet dy herë dhe më pas nuk shfaqet asgjë në regjistrin e tij. Ai heshtje është indici, sepse regjistri është ai që mbushi diskun dhe demoni nuk ka ku të shkruajë gabimin që ju po prisni. Çdo shërbim me jetëgjatësi mund të arrijë në atë gjendje, dhe fshirja e një drejtorie të quajtur logs rrallë e rregullon. Zgjidhja e qëndrueshme është të dini cila depo u rrit, kush e zotëron politikën e mbajtjes së saj dhe nëse shkruesi e lëshoi vërtet hapësirën.

Gjeni depon që u rrit dhe ritmin me të cilin u rrit

Filloni me dy numra që harrohen lehtë: blloqe të lira dhe inode të lira. Një sistem skedarësh mund të raportojë shumë hapësirë dhe prapë të refuzojë një shkrim sepse nuk i kanë mbetur inode, gjë që ndodh kur një shërbim krijon një skedar për sesion. Kërkoni të dyja leximet në të njëjtin vëllim, sepse përgjigjet mund të ndryshojnë në të njëjtën pasdite. Bëjeni ndërsa hosti është i shëndetshëm, që numrat të përshkruajnë funksionimin normal dhe jo një ndërprerje.

df -h /var
df -i /var

Më pas ia atribuoni rritjen një pronari. Vetë shifra e përdorimit të journal-it mbulon vetëm journal-in dhe nuk do të shohë kurrë një demon që shkruan në një shteg nga skedari i tij i konfigurimit.

journalctl --disk-usage

Rritja me kalimin e kohës thotë më shumë se çdo lexim i vetëm. Një nivel korrigjimi i lënë i ndezur, një cikël ripërpjekjesh që regjistron çdo përpjekje, ose një skedar kapjeje që askush nuk e ndaloi: secili prej tyre mund të duket i zakonshëm në një moment dhe shqetësues një orë më vonë. Merrni një lexim, prisni një periudhë të ngarkuar, merrni një tjetër dhe pjesëtoni me intervalin. Një ritëm që mund ta përmendni e kthen kapacitetin në vendim, jo në zjarr.

Çfarë bën rotacioni me një skedar të hapur

Një skedar regjistri është një emër që tregon një inode, dhe hapësira kthehet vetëm kur mbyllet doreza e fundit e hapur. Riemërtoni skedarin dhe shkruesi vazhdon të mbushë të njëjtin inode; fshijeni dhe shkruesi vazhdon të mbushë një inode pa asnjë emër. Kjo gjendje është arsyeja pse «e fshiva skedarin dhe disku mbeti i mbushur» përshkruan përshkrues skedarësh dhe jo një sistem skedarësh të prishur. Rindezja e shkruesit, ose zgjedhja e një mënyre rotacioni që e rihap skedarin, është ajo që i kthen vërtet blloqet.

lsof +L1 | head

Politika i takon komponentit që shkruan skedarin. Journal-i zbaton kufijtë e vet të ruajtjes nga skedari i konfigurimit, ndërsa një shërbim i bazuar në skedarë zakonisht mbështetet te logrotate, ose me një rregull krijimi dhe një sinjal rihapjeje, ose me një mënyrë prerjeje në vend kur shkruesi nuk mund të rihapë. Fillimisht konfirmoni vendimin pa ndryshuar asgjë:

logrotate -d /etc/logrotate.conf

Ku i takon kufiri dhe sa i madh duhet të jetë

Vendoseni kufirin atje ku është konfiguruar shkruesi, jo në pikën e montimit. Një kuotë mbi të gjithë vëllimin mbron hostin, por nuk thotë cili shërbim dështon i pari, dhe një skript global pastrimi tenton të fshijë provat që i duhen incidentit të ardhshëm. Një kufi journal-i, një numër rrotullimesh me madhësi maksimale dhe mbajtja në nivel aplikacioni kufizojnë secili një prodhues. Së bashku kufizojnë totalin; veçmas, secili është një hamendje.

Përmasojeni atë kufi nga mbajtja që mund të mbroni, jo nga hapësira e lirë. Nëse një rishikim kërkon një javë përpjekje lidhjesh, journal-i duhet të mbajë një javë me ritmin më të ngarkuar të pritur, dhe ai ritëm është numri i matur më parë.

Regjistrimi i korrigjimit është një mënyrë e përkohshme me kohë nisjeje të regjistruar, jo një plan ruajtjeje. Mbajeni çështjen e privatësisë brenda të njëjtit vendim, sepse regjistrat e lidhjeve mbajnë adresa dhe identifikues. Një mbajtje më e gjatë është gjithashtu një zgjedhje e trajtimit të të dhënave dhe duhet të merret nga dikush që njeh të dy kufizimet.

Verifikoni kufirin pas një rindezjeje

Një ndryshim mbajtjeje që zgjat deri në rindezjen tjetër nuk është ndryshim. Rindizni shkruesin, konfirmoni që kufiri i ri zbatohet dhe kontrolloni që rotacioni ende funksionon më pas. Për journal-in, një rindezje dhe një lexim i përdorimit u përgjigjen të dy pyetjeve:

systemctl restart systemd-journald
journalctl --disk-usage

Për një shërbim të bazuar në skedarë, ekzekutoni punën e rotacionit një herë me dorë dhe konfirmoni që skedari u zëvendësua dhe përshkruesi u rihap. Një shkrues që mban dorezën e vjetër kalon një kontroll sipërfaqësor dhe dështon herën tjetër kur vëllimi mbushet. Vëzhgoni hapësirën e lirë gjatë provës, sepse një skedar që u zvogëlua ndërsa hapësira nuk u kthye do të thotë që inode i vjetër mbahet ende.

Krahasoni leximin e ardhshëm me këtë

Kthehuni pas një jave dhe krahasoni ritmin e rritjes me atë të regjistruar. Një ritëm që përputhet do të thotë që kufiri mban dhe ngarkesa është e qëndrueshme; një ritëm i dyfishuar do të thotë që diçka ndryshoi, dhe pyetja e dobishme është çfarë. Lexoni së pari përmbajtjen e regjistrit për dështime të përsëritura, sepse cikli i ripërpjekjeve është njëkohësisht simptomë dhe shkak i vëllimit. Pastaj kontrolloni çdo gjë të aktivizuar së fundmi, duke përfshirë nivelet e korrigjimit të ndezura gjatë një incidenti dhe të mos fikura kurrë.

Mbajini kopjet rezervë jashtë të njëjtit vëllim, ose pranoni që një disk i mbushur e merr kopjen me vete. Një kopje e shkruar në hostin që mbron nuk është plan rikuperimi, dhe mbajtja e saj kërkon përgjigjen e vet.

Shkruani çfarë mbahet, ku, për sa kohë dhe kush e heq. Ai fjali është rezultati, dhe është e vetmja pjesë e këtij punë i cili i mbijeton rindezjes tjetër.