Kierrätä VPN-vahtikoiran loki rikkomatta kirjoittajaa

VPN:n terveystarkistus, joka lisää yhden rivin minuutissa, luo hiljaa toisen velvollisuuden: päättää, miten ne rivit lähtevät levyltä. Tunnelin korjaaminen ei tee mitään sille velvollisuudelle, eikä tiedoston uudelleennimeäminen ohjaa uudelleen prosessia, joka pitää yhä vanhaa kuvaajaa. Vastaa ensin kohdekysymykseen ja sovita sitten kierrätys tapaan, jolla kirjoittaja sen avaa.

Valitse kohde ennen kierrätyskäytäntöä

systemd-yksikkö, joka lähettää tulosteensa jo lokiin, pitää säilytyksen yhdessä paikassa. journald pakottaa rajoja, kuten SystemMaxUse ja MaxRetentionSec , joten siellä lokittava vahti perii rajan ilman lisätyötä. Toisen rajoittamattoman tiedoston lisääminen sen viereen kaksinkertaistaa ylläpidon ilman hyötyä.

Oma tiedosto ansaitsee paikkansa, kun jokin muu lukee sitä: jäsentäjä, auditointivienti tai sivu, joka odottaa vakaata polkua. Kun päätös on tehty, tiedosto tarvitsee omistajan, tilan ja kierrätyskäytännön yhdessä kirjoitettuina, koska kolme on oikein vain joukkona. Polku, jonka kuka tahansa voi luoda, on myös polku, jonka kuka tahansa voi korvata, joten hakemiston oikeudet kuuluvat samaan muistiin. Kirjoita kaikki se tarkistuksen viereen, niin seuraava muokkaus alkaa samoista tosiasioista.

Kirjoita lohko kirjoittajan mukaiseksi

Aloita kirjoittajasta, joka avaa polun joka kutsulla, lisää rivin ja poistuu. Tämä malli selviää kierrätyksestä ilman prosessin yhteistyötä, koska seuraava ajo avaa tiedoston, joka sillä hetkellä on polulla. Alla oleva lohko pitää viikon versioita ja luo tiedoston uudelleen omistajalla ja tilalla, jotka kirjoittaja tarvitsee:

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

logrotaten käsikirja määrittelee luvun säilytettyjen kierrätettyjen versioiden lukumääräksi, ei taatuksi seitsemän päivän historiaksi, ja avainsana daily arvioidaan työn suorituksen yhteydessä sen sijaan, että se toimisi omana ajoituksenaan. Useimmissa jakeluissa systemd-ajastin tai cron-merkintä omistaa jo kyseisen kutsun, joten tarkista, kumpi on olemassa, ennen kuin lisäät toisen. Omistajuuden täsmääminen on tärkeämpää kuin säilytysmäärä. Vain rootille tarkoitetun tilan kopioiminen tiedostoon, jota palvelutili kirjoittaa, pysäyttää lokituksen seuraavassa kierrätyksessä, ja vika näkyy tunteja myöhemmin vanhentuneena aikaleimana eikä virheenä. Vahvista kirjoittajan käyttäjä ennen kuin kopioit lohkon muualta.

Kirjoittaja, joka ei avaa koskaan uudelleen, tarvitsee toisenlaisen korjauksen

Pitkään käynnissä oleva prosessi, joka pitää avointa kuvaajaa, kirjoittaa edelleen uudelleennimettyyn inodeen. Tilaa ei vapaudu ja näkyvä tiedosto lakkaa kasvamasta, mikä näyttää rikkinäiseltä kierrätykseltä, kunnes tarkistat inoden. Joko opeta prosessi avaamaan uudelleen tai tee kierrätyksestä kopioiva ja katkaiseva uudelleennimeämisen sijaan.

Uudelleenavaamisen polku on siistimpi siellä, missä ohjelmisto tukee sitä: lähetä dokumentoitu signaali tai suorita dokumentoitu komento ja anna prosessin avata uusi tiedosto itse. Vaihtoehto on copytruncate , joka kopioi sisällön kierrätettyyn nimeen ja katkaisee sitten alkuperäisen paikallaan, joten kuvaaja pysyy kelvollisena, mutta kopioinnin ja katkaisun väliin osuvat kirjoitukset menetetään.

systemd:n käynnistämille yksiköille osoita StandardOutput lokiin tai tiedostoon ja anna yksikön omistaa elinkaari. Shell-silmukka, joka lisää tee -a kautta ilman kokorajaa, on järjestely, joka täyttää osion katkoksen aikana, koska epäonnistuva tarkistus lokittaa usein paljon enemmän kuin terve.

Testaa kierrätys odottamatta ajastinta

Virheenjäljitystila kertoo, mitä tapahtuisi, eikä kosketa mitään, mikä tekee siitä turvallisen ensimmäisen ajon muokkauksen jälkeen. Pakota todellinen kierrätys, kun olet tyytyväinen, ja vahvista sitten, että seuraava lokirivi laskeutuu uuteen tiedostoon eikä uudelleennimettyyn:

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

Lue tuloste siinä järjestyksessä. Virheenjäljityskierroksen pitäisi nimetä tiedosto ja aikomansa toimet; pakotetun ajon pitäisi tuottaa odotettu kierrätetty nimi; tailin pitäisi näyttää tuore merkintä, kun kirjoittaja toimii taas. Kasvava df-arvo ja kutistuva näkyvä tiedosto tarkoittavat yllä kuvattua kuvaajaongelmaa.

Toista pakotettu ajo kahdesti nähdäksesi, miten säilytys käyttäytyy, kun versioita on jo olemassa. Vanhimman tiedoston poistaminen on odotettu tulos, ja puuttuva poisto tarkoittaa yleensä, että kierrätetyn nimen lukumäärä tai jokerimerkki ei vastaa sitä, minkä logrotate loi.

Säilytä palautusmahdollisuus ja kirjallinen merkintä

Tallenna edellinen lohko ennen muokkausta ja merkitse, mikä ajoitin sitä ajaa, koska palautus, joka palauttaa tiedoston mutta ei ajastinta, toistaa puolet alkuperäisestä ongelmasta. Kierrätä kerran käsin palautuksen jälkeen ja vahvista sitten, että kirjoittajan tili voi kirjoittaa lokipolkuun. Jos palvelu toimii systemd:n alla, lataa yksikkö uudelleen jokaisen sen tulosteen uudelleenohjauksen muutoksen jälkeen, koska käynnissä oleva prosessi kirjoittaa edelleen vanhaan kohteeseen. Lue seuraavat lokirivit itse sen sijaan, että luottaisit yksikön palanneen puhtaasti.

Kirjaa tila, omistaja, säilytysmäärä ja odotettu levytalousarvio tarkistuksen viereen. Kun tarkistus myöhemmin muuttuu kertaluontoisesta skriptistä daemoniksi, kierrätyskäytännön on muututtava sen mukana, ja se muistiinpano kertoo seuraavalle henkilölle, mikä oletus rikkoutui.

Pidä lopuksi lokipäätös erillään palautuspäätöksestä. Epäonnistuneen tarkistuksen pitäisi noudattaa yhteyden omaa palautuskäytäntöä, ei logrotaten sisään piilotettua sääntöä, eikä minkään lokijärjestelyn pitäisi olla syy käynnistää toimiva tunneli uudelleen.