Van wie zijn de OpenVPN-logs: de daemon, rsyslog of logrotate?

Logrotatie breekt op een voorspelbare manier: drie componenten menen elk dat zij het bestand bezitten, en het resultaat is een geroteerd log dat blijft groeien terwijl het nieuwe leeg blijft. De daemon houdt een descriptor, logrotate hernoemt het pad en rsyslog schrijft ergens heel anders. Kies één schrijver en één rotator voordat u nog een regel op de stapel legt. De checklist hieronder volgt die volgorde omdat elke latere stap ervan afhangt.

Bepaal wie het bestand schrijft

Twee ontwerpen zijn legitiem. In het eerste schrijft het VPN-proces zelf een bestand via zijn eigen log- of log-append-optie. In het tweede stuurt het records naar de systeemlogger en bepaalt rsyslog of journald waar ze belanden.

Het zijn alternatieven, geen lagen. Een host die beide aanzet, eindigt met twee bestanden die het oneens zijn, en het bestand dat u leest is vaak het verouderde. Kies het pad bewust en verwijder daarna de andere schrijver.

Lees de effectieve serviceconfiguratie voordat u iets wijzigt, inclusief drop-ins die het unit-bestand kunnen overschrijven. Een richtlijn in het profiel dat u hebt bewerkt is geen bewijs dat het degene is die het draaiende proces heeft geladen. Vergelijk de unit met de argumenten van het proces en daarna met de bestanden die het werkelijk heeft geopend.

Benoem de daemon zodat het filter smal kan zijn

Op het syslog-pad geeft u de daemon een eigen identiteit en filtert u daarop. Een regel die overeenkomt met de programmanaam van deze VPN-instantie houdt de records buiten een gedeeld bestand waarvan het bewaarbeleid bij iets anders hoort.

Smalle regels maken ook de volgende vraag beantwoordbaar: welke service produceerde deze regel? Een filter dat overeenkomt met alles met het woord VPN erin verzamelt graag het verkeer van een tweede tunnel en vervaagt beide. Koppel aan de exacte identificatie die de unit aan de logger geeft.

Sluit de regel na de actie, zodat de records niet ook naar de standaardbestemming doorvallen. Dubbele regels in twee bestanden lijken op een logfout en zijn in werkelijkheid een ontbrekende stop. Die ene weglating verdubbelt ook de schijfkosten van het bewaarbeleid.

Roteer zonder de descriptor te verliezen

Wanneer de daemon het bestand schrijft, hernoemt logrotate het pad, maar het proces houdt zijn open descriptor. Nieuwe records blijven in het hernoemde bestand stromen totdat iets het proces dwingt het oorspronkelijke pad opnieuw te openen; daarom kan een rotatie werken lijken terwijl het nieuwe bestand leeg blijft.

De oplossing is een postrotate-actie die het gedocumenteerde herlaad- of herstartgedrag van de service afvuurt. Een signaal naar de logger sturen is een heel andere actie en doet niets voor een daemon die zijn eigen bestand houdt.

Waar heropenen onmogelijk is, is copytruncate de terugvaloptie: kopieer het bestand en kort het daarna ter plaatse in. Het houdt de descriptor geldig ten koste van alles wat tussen de kopie en het inkorten wordt geschreven, dus het is een ruil en geen oplossing. Onder belasting kan die leemte precies de fout opslokken die u probeert te vangen.

Kies per bestand een van de twee en schrijf de keuze op, want ze op hetzelfde pad mengen levert leemtes op die later zeer moeilijk toe te schrijven zijn. Een lezer die beide patronen in één map vindt, kan niet zeggen welke gezaghebbend is.

Stel de bewaring in vanuit het incidentvenster

Bewaring, compressie en maximale grootte horen voort te komen uit hoe ver terug u werkelijk onderzoekt. Een venster van zeven dagen met compressie en een groottelimiet is een redelijk uitgangspunt voor veel uitrollen; een getal dat uit een handleiding is gekopieerd niet.

Houd het beleid op één plek. Als logrotate het bestand roteert en rsyslog het ook roteert, wint de tweede rotatie en blijft het naamschema van de eerste als rommel achter. Kies de eigenaar, schakel de andere rotatie uit en noteer die beslissing naast het beleid.

De rsyslog-documentatie behandelt het routerings- en actiemodel, terwijl de documentatie van de OpenVPN-service gezaghebbend blijft voor de eigen logopties van de daemon. Geen van beide bepaalt uw bewaarbeleid voor u.

Test één rotatie en één nieuwe gebeurtenis

Forceer een enkele rotatie en genereer daarna een nieuwe gebeurtenis, zoals een mislukte authenticatie. Bevestig dat het nieuwe record in het nieuwe bestand verschijnt en dat het oude bestand is gestopt met groeien.

Controleer ook de rechten op het nieuwe bestand, want een rotatie die het met een andere eigenaar opnieuw aanmaakt, breekt de schrijver bij de volgende schrijfactie en levert een leemte op die op een crash lijkt. Vergelijk eigenaar en modus met het serviceaccount voordat u weggaat. Bevestig daarna dat het gecomprimeerde archief leesbaar is, want een archief dat niemand kan openen is geen bewaring. Een snelle lezing van het nieuwste record in het oude bestand bewijst zowel de compressie als de rechten.

Sluit af met het vastleggen van de eigenaar van elke stap: welke component schrijft, welke roteert en waar het bewaarbeleid woont. Die aantekening maakt het volgende logincident tot een controle van vijf minuten in plaats van een middag gissen welke laag de regel heeft laten vallen.