Hogyan lehet kijavítani egy teli systemd naplót

A systemd napló tárolja a szerver által generált összes naplóüzenetet, és egy kis root partícióval rendelkező VPS-en ez észrevétlenül elfogyaszthatja a rendelkezésre álló lemezterületet. Amikor ez megtörténik, a szolgáltatások nem indulnak el, az írási műveletek leállnak, és elveszíted azokat a diagnosztikai adatokat, amelyekre szükséged van a hiba okának kiderítéséhez. Ez az útmutató bemutatja, hogyan lehet diagnosztizálni a problémát, azonnal helyet szabadítani, és úgy konfigurálni a journald-ot, hogy ez ne fordulhasson elő újra.

A probléma diagnosztizálása

Először ellenőrizze, hogy a napló mennyi helyet foglal:

journalctl --disk-usage

Ez az összes aktív és archivált naplófájl együttes méretét jelzi. Hasonlítsa össze ezt a rendelkezésre álló lemezterülettel a df -h. Egy 20 GB-os root partíción még 2 GB-nyi napló is a teljes lemezterület több mint 10%-át teszi ki, ami elegendő ahhoz, hogy problémákat okozzon.

Ezután derítse ki, mely szolgáltatások generálják a legtöbb zajt. Ez az egy soros parancs rangsorolja az elmúlt 24 órában a 10 legaktívabb naplófájl-forrást:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Szűrjünk kifejezetten a hibákra a journalctl -p err -b parancsot, hogy megnézze, nincs-e egy szolgáltatás, amely összeomlási ciklusba került, és elárasztja a naplót. Ellenőrizheti azt is, hogy a journald korlátozza-e valamelyik szolgáltatás sebességét:

journalctl -u systemd-journald | grep -i "suppressed"

Az elnyomott üzenetek azt jelentik, hogy egy szolgáltatás túllépte az alapértelmezett 10 000 bejegyzéses küszöbértéket 30 másodpercen belül. Ez a tettes.

Néhány dolog különösen gyakori a VPS-instanciákon. Ha Storage=auto be van állítva és /var/log/journal/ létezik, a journald állandó tárolót használ, amelynek alapértelmezett korlátja körülbelül 4 GB. Egy kis root partíción ez gyorsan megtelik. A nem megfelelő leállítások is sérült naplófájlokat hagyhatnak hátra .journal~ kiterjesztéssel. Ezek a fájlok nem cserélődnek le normál módon, és folyamatosan foglalják a helyet.

A naplófájlok biztonságos törlése

Mielőtt bármit is eltávolítana, forgassa át az aktív naplófájlt, hogy a jelenlegi naplófájlok megmaradjanak:

journalctl --rotate

Ezután törölje az archivált naplófájlokat. A törléskor a fájlok életkorát, méretét vagy számát veheti alapul:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

Az első parancs a 24 óránál régebbi naplófájlokat törli. A második a napló teljes méretét 100 MB-ra csökkenti. A harmadik csak az öt legfrissebb archivált fájlt tartja meg. Válassza ki a helyzetének leginkább megfelelőt.

Ha a lemez teljesen megtelt, és a journalctl parancsok nem reagálnak, előfordulhat, hogy manuálisan kell törölnie a naplófájlokat:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Ez a végső megoldás. Ez törli az összes tárolt naplót, és újra létrehozza a könyvtárat a megfelelő jogosultságokkal. Bármely tisztítás után indítsa újra a démont, és ellenőrizze:

sudo systemctl restart systemd-journald
journalctl --disk-usage

A Journald méretkorlátozásainak konfigurálása

A journald alapértelmezett beállításai nagyvonalúak. VPS-en túl nagyvonalúak. Szerkessze a konfigurációt, hogy szigorú korlátokat állítson be a napló tárolására. Hozzon létre egy felülírási fájlt ahelyett, hogy közvetlenül a fő konfigurációt szerkesztené, így a változtatásai a csomagfrissítések után is megmaradnak:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

A legfontosabb utasítások:

Mindkét beállítás SystemMaxUse és SystemKeepFree beállítása kettős biztonságot nyújt: a naplófájlok mérete rögzített, és a rendszernek mindig van mozgástere, függetlenül attól, hogy mi más található még a lemezen.

Tartós és ideiglenes tárolás

A Storage= utasítás szabályozza, hová kerülnek a naplófájlok. Ha Storage=persistent értékre, hogy a naplók a /var/log/journal/ a lemezre. Ez a kívánt beállítás a termelési szerverek esetében, mert így a naplófájlok túlélik az újraindítást, és utólag is kivizsgálhatja az összeomlásokat. Ha a könyvtár nem létezik, hozza létre:

sudo mkdir -p /var/log/journal

Az alternatíva, Storage=volatilea naplók a RAM-ban maradnak /run/log/journal/. A naplóbejegyzések újraindításkor eltűnnek. Ez ideális ideiglenes konténerek vagy olyan szerverek esetében, amelyek az összes naplót továbbítják egy külső rendszerbe.

A tömörítés letiltása nagy forgalmú szervereken

A Journald alapértelmezés szerint tömöríti az 512 bájtnál nagyobb adatelemeket. A nagy naplóátviteli forgalmat kezelő szervereken ez megnöveli a CPU terhelését. Állítsa be Compress=no , ha a naplókat külső rendszerbe továbbítja, és nincs szüksége a helyi tárhely minimalizálására. Állítsa be ForwardToConsole=no értéket a termelési környezetben. A konzol továbbítása szinkron módon történik, és egy leállt virtuális soros konzol teljesen blokkolhatja a journald démont.

Bármely konfigurációs változtatás után indítsa újra a szolgáltatást:

sudo systemctl restart systemd-journald

A naplókarbantartás automatizálása

A kézi tisztítás nem skálázható. Hozzon létre egy systemd időzítőt a naplófájlok ütemezett törléséhez. Állítson be egy szolgáltatási egységet a /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Ezután hozzon létre egy megfelelő időzítőt a /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Engedélyezze a sudo systemctl enable --now journal-vacuum.timer. Az időzítő minden vasárnap hajnali 2 órakor fut, és egy lépésben alkalmazza mind az időalapú, mind a méretalapú megőrzést.

Egy dolog, amit az időzítő nem fog elkapni: a sérült naplófájlok. Nem megfelelő leállítás után a journald karanténba helyezi a sérült fájlokat úgy, hogy a ~ a fájlnévhez. Ezek a .journal~ fájlok továbbra is beleszámítanak a lemezhasználatba, de nem kerülnek automatikusan törlésre. Rendszeresen ellenőrizze és távolítsa el a régieket:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Naplók külső továbbítása

Azoknál a szervereknél, ahol hosszú távú megőrzésre van szükség a helyi tárhely növelése nélkül, továbbítsa a naplókat egy központi rendszerbe. A legegyszerűbb megközelítés a syslog-továbbítás engedélyezése a journald.conf:

ForwardToSyslog=yes

Teljes metaadatokkal (PID, UID, egységnevek) rendelkező strukturált naplók esetén használja a systemd-journal-remote parancsot a JSON formátumú bejegyzések továbbításához egy naplókezelő platformra. A külső napló tárolás védi az ellenőrzési nyomvonalat is, ha a helyi lemez meghibásodik vagy a szerver biztonsága veszélybe kerül.

Következtetés

A teljes systemd-napló javítása egyszerű, és könnyen megelőzhető. A legfontosabb lépések:

• Ellenőrizze a használatot a journalctl --disk-usage parancs segítségével, és azonosítsa a zajos szolgáltatásokat.
• Azonnal szabadítson fel helyet a journalctl --rotate parancsokkal, majd --vacuum-size vagy --vacuum-time.
• Állítson be kifejezett méretkorlátokat egy journald.conf felülírási fájlban.
• Automatizálja a tisztítást egy systemd időzítővel.
• A naplókat továbbítsa külső helyre hosszú távú megőrzés céljából.

Az FDC VPS- és dedikált szervercsomagjai biztosítják a termelési naplóterhelésekhez szükséges lemez-I/O-t és tárhelyet.