Rotace logu VPN hlídače bez rozbití zapisovatele

Kontrola stavu VPN, která každou minutu přidá jeden řádek, tiše vytváří druhý úkol: rozhodnout, jak ty řádky opustí disk. Oprava tunelu pro tento úkol nic neudělá a přejmenování souboru nepřesměruje proces, který stále drží starý deskriptor. Nejprve odpovězte na otázku cíle, potom slaďte rotaci se způsobem, jakým soubor otevírá zapisovatel.

Zvolte cíl dřív než politiku rotace

Jednotka systemd, která už posílá svůj výstup do žurnálu, drží retenci na jednom místě. journald vynucuje limity jako SystemMaxUse a MaxRetentionSec , takže hlídač, který tam loguje, zdědí omezení bez jakékoli práce navíc. Přidání druhého neomezeného souboru vedle něj zdvojnásobí údržbu bez zisku.

Vyhrazený soubor si své místo zaslouží, když ho čte něco jiného: parser, export pro audit nebo stránka, která očekává stabilní cestu. Jakmile je toto rozhodnutí učiněno, soubor potřebuje vlastníka, režim a politiku rotace zapsané společně, protože všechny tři jsou správné jen jako celek. Cesta, kterou může vytvořit kdokoli, je také cesta, kterou může kdokoli nahradit, takže oprávnění adresáře patří do stejné poznámky. Zapište to všechno vedle kontroly a příští úprava začne ze stejných faktů.

Napište blok tak, aby odpovídal zapisovateli

Začněte zapisovatelem, který cestu otevírá při každém volání, přidá řádek a skončí. Tento vzor přežije rotaci bez jakékoli spolupráce procesu, protože příští běh otevře soubor, který na této cestě právě leží. Blok níže uchovává týden verzí a znovu vytváří soubor s vlastníkem a režimem, které zapisovatel potřebuje:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

Příručka logrotate definuje počet jako počet uchovaných rotovaných verzí, nikoli jako zaručených sedm dní historie, a klíčové slovo daily se vyhodnocuje při běhu úlohy, místo aby působilo jako vlastní plánovač. Na většině distribucí už tento příkaz vlastní časovač systemd nebo záznam cron, takže před přidáním druhého zkontrolujte, který existuje. Shoda vlastnictví je důležitější než počet retence. Zkopírování režimu jen pro root na soubor, který zapisuje servisní účet, zastaví logování při příští rotaci a selhání se objeví o hodiny později jako zastaralé časové razítko, ne jako chyba. Před kopírováním bloku odjinud potvrďte uživatele zapisovatele.

Zapisovatel, který nikdy neotevře znovu, potřebuje jinou opravu

Dlouho běžící proces, který drží otevřený deskriptor, dál zapisuje do přejmenovaného inodu. Místo se neuvolní a viditelný soubor přestane růst, což vypadá jako rozbitá rotace, dokud inod nezkontrolujete. Buď proces naučte znovu otevírat, nebo nechte rotaci kopírovat a zkracovat místo přejmenování.

Cesta znovuotevření je čistší tam, kde ji software podporuje: pošlete dokumentovaný signál nebo spusťte dokumentovaný příkaz a nechte proces otevřít nový soubor sám. Alternativou je copytruncate , která zkopíruje obsah do rotovaného názvu a pak zkrátí originál na místě, takže deskriptor zůstane platný, ale zápisy mezi kopií a zkrácením se ztratí.

U jednotek spouštěných systemd nasměrujte StandardOutput do žurnálu nebo do souboru a nechte jednotku vlastnit životní cyklus. Smyčka shellu, která přidává přes tee -a bez omezení velikosti, je uspořádání, které při výpadku zaplní oddíl, protože neúspěšná kontrola často zaloguje mnohem víc než zdravá.

Otestujte rotaci, aniž byste čekali na časovač

Ladicí režim hlásí, co by se stalo, a ničeho se nedotýká, což z něj dělá bezpečný první běh po úpravě. Až budete spokojeni, vynuťte skutečnou rotaci a poté potvrďte, že další řádek logu přistane v novém souboru, ne v přejmenovaném:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Čtěte výstup v tomto pořadí. Ladicí průchod by měl pojmenovat soubor a akce, které zamýšlí; vynucený běh by měl vytvořit očekávaný rotovaný název; tail by měl po dalším běhu zapisovatele ukázat nový záznam. Rostoucí hodnota df se zmenšujícím se viditelným souborem znamená výše popsaný problém s deskriptorem.

Zopakujte vynucený běh dvakrát, abyste viděli, jak se retence chová, když verze už existují. Smazání nejstaršího souboru je očekávaný výsledek a chybějící smazání obvykle znamená, že počet nebo zástupný znak v rotovaném názvu neodpovídá tomu, co logrotate vytvořil.

Uchovejte možnost vrácení a písemný záznam

Před úpravou uložte předchozí blok a poznamenejte, který plánovač ho spouští, protože vrácení, které obnoví soubor, ale ne časovač, reprodukuje polovinu původního problému. Po obnovení jednou ručně zrotujte a potvrďte, že účet zapisovatele může na cestu logu zapisovat. Pokud služba běží pod systemd, po každé změně přesměrování výstupu jednotku znovu načtěte, protože běžící proces dál zapisuje do starého cíle. Přečtěte si sami několik dalších řádků logu, místo abyste věřili, že se jednotka vrátila čistě.

Zaznamenejte režim, vlastníka, počet retence a očekávaný rozpočet disku vedle samotné kontroly. Když se kontrola později změní z jednorázového skriptu na démona, politika rotace se musí změnit s ní, a ta poznámka říká dalšímu člověku, který předpoklad se rozbil.

Nakonec držte rozhodnutí o logu oddělené od rozhodnutí o obnově. Neúspěšná kontrola by měla následovat vlastní politiku obnovy spojení, ne pravidlo skryté v logrotate, a žádné uspořádání logování by nemělo být důvodem restartovat fungující tunel.