hantera Linux-loggar

en viktig bästa praxis för loggning är att centralisera eller aggregera dina loggar på en enda plats, särskilt om du har flera servrar eller arkitektur nivåer. Moderna applikationer har ofta flera nivåer av infrastruktur som kan innehålla en blandning av på premiss servrar och molntjänster. Att försöka jaga rätt fil för att felsöka ett fel skulle vara oerhört svårt, och att försöka korrelera problem över system skulle vara ännu svårare., Det finns inget mer frustrerande än att ta reda på informationen du ville ha fångades inte i en loggfil, eller att loggfilen som kunde ha hållit svaret förlorades efter en omstart av servern.

det här avsnittet förklarar hur du använder centraliseringstjänster för att samla in och centralisera dina Linux-loggfiler.

fördelar

fördelarna med att centralisera loggar

centralisera dina loggar gör att söka igenom loggdata enklare och snabbare, eftersom alla dina loggar är tillgängliga på en enda plats., Istället för att gissa vilken server som har rätt fil kan du helt enkelt komma åt ditt förråd av loggdata för att söka efter relevanta händelser. Centralisering är en viktig del av stora ledningslösningar, eftersom det tillåter dem att analysera, analysera och indexloggar innan de lagras på en enda plats. Detta gör felsökning och lösa produktionsproblem enklare och snabbare. Centralisering erbjuder också dessa fördelar.

• loggar säkerhetskopieras på en separat plats, skydda dem mot oavsiktlig eller oavsiktlig förlust., Detta håller dem också tillgängliga om dina servrar går ner eller blir svarar inte.
• du behöver inte använda SSH-eller ineffektiva grep-kommandon, som kan använda värdefulla datorresurser för komplexa sökningar.
• Du kan minska mängden diskutrymme som används av loggfiler.
• ingenjörer kan felsöka produktionsproblem utan direkt åtkomst till system.

medan centraliserad logghantering i allmänhet är det bättre alternativet finns det fortfarande vissa risker som dålig nätverksanslutning som leder till dataförlust eller loggar med mycket nätverksbandbredd., Vi diskuterar hur du på ett intelligent sätt tar itu med dessa problem i avsnitten nedan.

populära

populära verktyg för att centralisera loggar

de flesta Linux-system centraliserar redan loggar med en syslog-demon. Som vi förklarade i avsnittet Linux Logging Basics är syslog en tjänst som samlar in loggfiler från tjänster och applikationer som körs på värden. Det kan skriva dessa loggar till fil, eller vidarebefordra dem till en annan server via syslog protokollet., Det finns flera syslog-implementeringar som du kan använda, inklusive:

• Rsyslog– en lättviktsdemon installerad på de vanligaste Linux-distributionerna.
• syslog-ng– den näst mest populära syslog daemon för Linux.
• logstash– en tyngre vikt agent som kan göra mer avancerad bearbetning och tolkning. Det kan läsa syslog meddelanden med hjälp av syslog input plugin och vidarebefordra dem till valfritt antal output destinationer.
• fluentd– en annan agent med avancerade bearbetningsfunktioner. Den stöder också syslog input med in_syslog plugin.,

rsyslog är den mest populära syslog-implementeringen och installeras som standard i många distributioner av Linux. Om du behöver mer avancerad filtrering eller anpassade parsing kapacitet, Logstash är nästa mest populära val. Logstash är också tätt integrerad med den elastiska stacken, vilket ger en komplett logghanteringslösning. För den här guiden kommer vi att fokusera på att använda rsyslog eftersom den används så mycket.

config

konfigurera rsyslog.conf

huvudkonfigurationsfilen för rsyslog finns på /etc/rsyslog.conf., Du kan lagra ytterligare konfigurationsfiler i/etc / rsyslog.d / katalog. Till exempel på Ubuntu innehåller den här katalogen /etc/rsyslog.d/50-default.conf, som instruerar rsyslog att skriva systemloggarna till filen. Du kan läsa mer om konfigurationsfilerna i rsyslog-dokumentationen.

konfigurera rsyslog innebär att ställa in ingångskällor (där rsyslog tar emot loggar), samt destinationsregler för var och hur loggar skrivs. Rsyslog tillhandahåller redan standardvärden för att ta emot syslog-händelser, så du behöver normalt bara lägga till din centraliseringsserver som en utgång., Rsyslog använder RainerScript för sin konfigurationssyntax. I det här exemplet vidarebefordrar vi våra loggar till servern på central.example.com över TCP-port 514.

action(type="omfwd" protocol="tcp" target="central.example.com" port="514")

Alternativt kan vi skicka våra loggar till en logghanteringslösning. Molnbaserade logghanteringsleverantörer som SolarWinds ® Loggly® ger dig ett värdnamn och en port som du kan skicka dina loggar till genom att helt enkelt ändra fälten target och port. Kontrollera med din leverantörs dokumentation när du konfigurerar rsyslog..,

direct

loggning av filer och kataloger

rsyslog tillhandahåller imfile-modulen, vilket gör det möjligt att övervaka loggfiler för nya händelser. Detta gör att du kan ange en fil eller katalog som en loggkälla. Rsyslog kan övervaka enskilda filer samt hela kataloger.

vi vill till exempel övervaka loggfiler som skapats av Apache-servern. Vi kan göra det genom att skapa en ny fil i /etc/rsyslog.d/ som heter apache.conf, ladda imfile-modulen och Lägg till Apaches loggfiler som ingångar.,

filparametern stöder jokertecken för övervakning av flera filer samt kataloger.

protokoll

vilket protokoll: UDP, TCP eller RELP?

det finns tre huvudprotokoll du kan välja mellan när du överför loggdata: UDP, TCP och RELP.

UDP skickar meddelanden utan att garantera leverans eller mottagningsbevis (ACK). Det gör ett enda försök att skicka ett paket, och om leveransen misslyckas, försöker den inte igen. Det är mycket snabbare och använder färre resurser än andra protokoll, men bör endast användas på tillförlitliga nätverk som localhost., UDP stöder inte heller kryptering av loggar.

TCP är det vanligaste protokollet för streaming via Internet, eftersom det kräver en ACK innan du skickar nästa paket. Om leveransen misslyckas fortsätter den att försöka igen tills den framgångsrikt levererar meddelandet. TCP kräver dock ett handslag och aktiv anslutning mellan avsändaren och mottagaren, som använder ytterligare nätverksresurser.

Relp (Reliable Event Logging Protocol) är utformad speciellt för rsyslog och är utan tvekan den mest tillförlitliga av dessa tre protokoll., Det bekräftar mottagandet av data i applikationslagret och skickar om det finns ett fel. Eftersom det är mindre vanligt måste du se till att din destination också stöder detta protokoll.

om rsyslog stöter på ett problem vid lagring av loggar, till exempel en otillgänglig nätverksanslutning, köar den loggarna tills anslutningen återställs. De köade loggarna lagras som standard i minnet. Minnet är dock begränsat och om problemet kvarstår kan loggarna överstiga minneskapaciteten, vilket kan leda till dataförlust. För att förhindra detta, överväg att använda diskköer.,

Varning: Du kan förlora data om du bara lagrar loggar i minnet.

que

skicka tillförlitligt med Diskassisterade köer

rsyslog kan köa dina loggar till disk när minnet är fullt. Diskassisterade köer gör transport av stockar mer tillförlitliga. Här är ett exempel på hur du konfigurerar en log forwarding-regel i rsyslog med en diskassisterad kö.

kryptera

kryptera loggar med TLS

När datasäkerhet och sekretess är ett problem bör du överväga att kryptera dina loggar. Sniffers och mellanhänder kan läsa dina loggdata om du överför den via internet i klartext., Du bör kryptera dina loggar om de innehåller privat information, känsliga identifieringsdata eller myndighetsreglerade data. Den rsyslog Demon kan kryptera dina loggar med TLS-protokollet och hålla dina data säkrare.

processen för att aktivera TLS-kryptering beror på din loggningsinställning. Generellt innebär det följande steg.

1. skapa en certifikatutfärdare (CA). Det finns exempelcertifikat i rsyslogs/contrib/gnutls katalog, som bara är bra för testning, men du måste skapa din egen för produktion., Om du använder en logghanteringstjänst kommer den att ha en redo för dig.
2. skapa ett digitalt certifikat för din server för att aktivera TLS, eller använd ett från din leverantör av logghantering.
3. konfigurera din rsyslog-tjänst för att skicka TLS-krypterade data till din logghanteringstjänst.

här är ett exempel rsyslog konfiguration med TLS-kryptering. Ersätt CERT och DOMAIN_NAME med din egen serverinställning.,

$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt$ActionSendStreamDriver gtls$ActionSendStreamDriverMode 1$ActionSendStreamDriverAuthMode x509/name$ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com

Logghanteringstjänster som SolarWinds Loggly tillhandahåller ofta sina egna CAs och certifikat, som du helt enkelt behöver referera till i din rsyslog-konfiguration. Till exempel kräver aktivering av TLS med Loggly bara att du laddar ner Loggly certifikatet till din /etc/rsyslog.d / katalog, uppdatera din konfiguration och starta om rsyslog-tjänsten.

hämta först certifikatet.

$ mkdir -pv /etc/rsyslog.d/keys/ca.d$ cd /etc/rsyslog.d/keys/ca.d$ curl -O https://logdog.loggly.com/media/logs-01.loggly.com_sha12.crt

Öppna sedan konfigurationsfilen/etc/rsyslog.d/22-loggly.conf och Lägg till följande:

Starta om rsyslog.,

$ sudo service rsyslog restart

öva

bästa praxis för Programloggning

förutom de loggar som Linux skapar som standard är det också en bra idé att centralisera loggar från viktiga applikationer. Nästan alla Linux – baserade serverprogram skriver sin statusinformation i separata, dedikerade loggfiler. Detta inkluderar databasprodukter som PostgreSQL eller MySQL, webbservrar som nginx eller Apache, brandväggar, print och fildelningstjänster, katalog och DNS-servrar, och så vidare.

det första administratörer gör efter att ha installerat ett program är att konfigurera det., Linux applikationer har normalt .conf-fil någonstans i / etc-katalogen. Det kan vara någon annanstans också, men det är det första stället där folk letar efter konfigurationsfiler. Beroende på hur komplex eller stor applikationen är kan antalet inställbara parametrar vara få eller i hundratals. Se programmets dokumentation för att lära dig mer, eller använd kommandot lokalisera för att försöka hitta filen själv.

# locate postgresql.conf/usr/pgsql-9.4/share/postgresql.conf.sample/var/lib/pgsql/9.4/data/postgresql.conf

Ställ in en standardplats för loggfiler

Linux-system sparar vanligtvis sina loggfiler under/var/log katalog., Detta fungerar bra, men kontrollera om programmet sparar under en viss katalog under /var/log. Om det gör det, bra. Om inte, kanske du vill skapa en dedikerad katalog för appen under /var/log. Varför? Det beror på att andra program sparar sina loggfiler under /var/log också och om din app sparar mer än en loggfil—kanske en gång varje dag eller efter varje omstart av Tjänsten—kan det vara lite svårt att krypa igenom en stor katalog för att hitta den fil du vill ha.,

om du har mer än en instans av programmet som körs i ditt nätverk, är detta tillvägagångssätt också praktiskt. Tänk på en situation där du kan ha ett dussin webbservrar som körs i ditt nätverk. Om dina loggar lagras på en central syslog-server, hur vet du vilken loggfil som innehåller vilken serverns loggar? Genom att logga varje server i en separat katalog vet du exakt var du ska leta när du felsöker någon server.

använd ett statiskt filnamn

många program lägger till dynamiska data i loggfilens namn, till exempel aktuellt datum eller tidsstämpel., Detta är användbart för att automatiskt dela loggar efter datum, men det gör det svårare för tjänster som rsyslog att hitta den senaste filen. Ett bättre tillvägagångssätt är att använda ett namn som inte ändras för loggfilen och sedan använda logrotate för att tillämpa en tidsstämpel eller nummer till äldre loggfiler.

Lägg till och rotera loggfiler

program bör läggas till befintliga loggfiler istället för att skriva över dem. Detta hjälper till att säkerställa att alla logglinjer fångas och inga data går förlorade, även om programmet startas om. Loggfiler kan dock växa till mycket stora över tiden., Om du försöker hitta orsaken till ett problem, kan du sluta söka igenom tiotusentals linjer.

Vi rekommenderar att du lägger dina loggar till en enda fil, men vi rekommenderar också att du konfigurerar programmet för att rotera loggfilerna så ofta. Verktyg som logrotate kan göra detta automatiskt genom att kopiera den aktuella loggfilen till en ny plats, vilket ger den ett unikt namn och sedan trunkera den aktuella loggfilen., Detta har ett antal fördelar, inklusive:

1. loggar delas över filer efter datum och tid, vilket gör det enkelt att hitta loggar för ett visst datum
2. varje loggfil är mycket mindre, vilket gör dem lättare att söka igenom och lättare att skicka över ett nätverk
3. säkerhetskopiera loggfiler är mycket lättare, och ta bort eller arkivera äldre loggar kan göras mycket snabbare

hur ofta du roterar loggfiler beror på hur många loggar du genererar. Som en tumregel, börja med att rotera dina loggar en gång per dag.

Ställ in Policy för lagring av loggfiler

hur länge behåller du en loggfil?, Det kommer definitivt till affärskrav. Du kan bli ombedd att hålla en veckas värde av loggningsinformation, eller det kan vara ett lagstadgat krav att hålla 10 års värde av data. Vad det än är, loggar måste gå från servern på en eller annan gång.

enligt vår mening, om inte annat krävs, bör du hålla minst en månads värde av loggfiler online, Plus kopiera dem till en sekundär plats (som en loggningsserver). Allt äldre än det kan laddas av till ett separat media. Om du till exempel är på AWS kan dina äldre loggar kopieras till Glacier.,

lagra loggfiler på en separat enhet

loggfiler skrivs ständigt, vilket kan leda till hög disk I / O på upptagna system. Som bästa praxis bör du montera /var/log på en separat lagringsenhet. Detta förhindrar loggfil skriver från att störa prestandan hos dina program, särskilt på diskbaserad Lagring. Detta förhindrar också loggfiler från att fylla upp hela enheten om de blir för stora.

formatera dina loggposter

vilken information ska du fånga i varje loggpost?

det beror på vad du vill använda loggen för., Vill du bara använda den för felsökning, eller vill du fånga allt som händer? Är det ett rättsligt krav att fånga vad varje användare kör eller tittar på?

om du använder loggar för felsökning, spara bara fel, varningar eller dödliga meddelanden. Det finns ingen anledning att fånga felsökningsmeddelanden, till exempel. Appen kan logga felsökningsmeddelanden som standard, eller en annan administratör kan ha aktiverat detta för en annan felsökningsövning, men du måste stänga av det eftersom det definitivt kan fylla upp utrymmet snabbt., På ett minimum, fånga datum, tid, klientapplikationsnamn, källa IP eller klient värdnamn, åtgärd utförs, och själva meddelandet.

tänk till exempel på standardloggningsbeteendet för PostgreSQL. Loggar lagras i /var/log/postgresql, och varje fil börjar med postgresql – följt av datumet. Filer roteras dagligen, och äldre filer bifogas med ett tal baserat på när de roterades. Varje loggrad kan prefixeras med fält som aktuell tidsstämpel, aktuell användare, databasnamn, sessions-ID och transaktions-ID., Du kan ändra dessa inställningar genom att redigera PostgreSQL konfigurationsfil (/etc/postgresql/11/main/postgresql.conf på Debian).

som standard visar varje loggrad tidsstämpel och PostgreSQL-process-ID följt av loggmeddelandet.

övervaka loggfiler med Imfile

traditionellt är det vanligaste sättet för program att logga sina data med filer. Filer är lätta att söka på en enda maskin, men skala inte bra med fler servrar. Med rsyslog kan du övervaka filer för ändringar och importera nya händelser till syslog, där du sedan kan vidarebefordra loggarna till en centraliserad server., Detta görs med imfile-modulen. För att aktivera modulen, skapa en ny konfigurationsfil i /etc/rsyslog.d/ och lägg sedan till en filinmatning så här.

Lägg till dina utmatningsströmmar efter denna konfiguration, och rsyslog skickar loggar från den angivna filen till utmatningsdestinationen.

logga direkt till Syslog-uttaget med imuxsock

ett uttag liknar ett Unix-filhandtag, förutom att det läser data i minnet istället för att skriva det till disken. När det gäller syslog kan du skicka loggar direkt till syslog utan att behöva skriva den till en fil först.,

detta tillvägagångssätt gör effektiv användning av systemresurser om din server begränsas av disk I/O eller om du inte behöver lokala filloggar. Nackdelen med detta tillvägagångssätt är att uttaget har en begränsad köstorlek. Om din syslog daemon går ner eller inte kan hänga med, då kan du förlora loggdata.

för att aktivera socket loggning i rsyslog, Lägg till följande rad i din rsyslog konfiguration (det är aktiverat som standard).

$ModLoad imuxsock

detta skapar ett uttag på /dev/log socket som standard, men du kan ändra detta genom att ändra SysSock.Name parameter., Du kan också ställa in alternativ som hastighetsbegränsande och flödeskontroll. Mer information finns i dokumentationen för rsyslog imuxsock.

UDP loggar med Imupd

vissa program matar ut loggdata i UDP-format, vilket är standardprotokollet när du överför loggfiler via ett nätverk eller din localhost. Din syslog daemon tar emot dessa loggar och kan bearbeta eller överföra dem i ett annat format. Alternativt kan du skicka loggarna till en annan syslog-server eller till en logghanteringslösning.,

använd följande kommando för att konfigurera rsyslog för att acceptera syslog-data över UDP på standardporten 514.

$ModLoad imudp$UDPServerRun 514

hantera konfiguration på många servrar

När du bara har några servrar kan du manuellt konfigurera inloggning på dem. När du har några dussin eller flera servrar kan du dra nytta av verktyg som gör det enklare och mer skalbart. På en grundläggande nivå är målet för varje verktyg att aktivera syslog på var och en av dina servrar, tillämpa en konfiguration och se till att ändringarna träder i kraft.,

Pssh

pssh (eller parallell SSH) låter dig köra ett SSH-kommando på flera servrar parallellt. Använd en pssh-distribution för endast ett litet antal servrar. Om en av dina servrar misslyckas måste du SSH i den misslyckade servern och göra distributionen manuellt. Om du har flera misslyckade servrar kan den manuella distributionen på dem ta lång tid.

Puppet/Chef

Puppet and Chef är konfigurationshanteringsverktyg som automatiskt kan konfigurera alla dina servrar och föra dem till samma tillstånd. De kan övervaka dina servrar och hålla dem synkroniserade., Puppet and Chef är kraftfulla verktyg som kan installera programvara, skapa filer, starta om tjänster och mycket mer. Om du inte är säker på vilken som är mer lämplig för konfigurationshanteringen kan du uppskatta InfoWorlds jämförelse av de två verktygen.

vissa leverantörer erbjuder även moduler eller recept för att konfigurera syslog. Loggly tillhandahåller till exempel en Marionettmodul som använder rsyslog för att automatiskt vidarebefordra loggar från dina agenter. Installera Loggly Puppet module på din marionett mästare, sedan lägga till följande konfiguration till din marionett manifest.,

 # Send syslog events to Loggly class { 'loggly::rsyslog': customer_token => 'YOUR_CUSTOMER_TOKEN', }

När agenterna uppdateras börjar de logga in för att logga in.

Kubernetes

Kubernetes är ett orkestreringsverktyg för hantering av behållare på flera noder. Kubernetes ger en komplett loggningsarkitektur som automatiskt samlar in och skriver containerloggar till en fil på värddatorn. Du kan visa loggar för en viss Pod genom att köra kommandot kubectl loggar <pod namn>, vilket är användbart för att komma åt programloggar på en fjärrserver.,

många loghanteringslösningar tillhandahåller agenter som kan distribueras över Kubernetes för att samla in både applikationsloggar och värdloggar. Loggly tillhandahåller till exempel en DaemonSet som distribuerar en Loggningspod till varje nod i ett kluster. Pod samlar loggar från andra Pods och från värden själv och distribuerar den som en DaemonSet hjälper till att säkerställa att det alltid finns en instans som körs på varje nod. Logga en Kubernetes kluster med Loggly är lika lätt som att köra följande kommandon.

Docker

Docker använder behållare för att köra program oberoende av den underliggande servern., Det används ofta som Behållare runtime för orkestratorer som Kubernetes, men kan användas som en fristående plattform. ZDNet har en djupgående artikel om hur du använder Docker i ditt datacenter.,

det finns flera sätt att logga från Docker behållare inklusive:

• loggning via Docker loggning föraren till värdsystemet (den rekommenderade metoden)
• dirigera alla containerloggar till en enda dedikerad loggning behållare (Detta är hur logspout behållaren fungerar)
• logga in på en Sidecar loggning Behållare
• lägga till en loggning agent till behållaren

Du kan också använda Docker behållare för att samla loggar från värd., Om din behållare har en kör syslog-tjänst kan du antingen skicka loggar från värden till behållaren via syslog eller montera värdens loggfiler i behållaren och använda en filövervakare för att läsa filerna.

skript eller agenter för leverantörer

de flesta lösningar för logghantering erbjuder skript eller agenter för att göra det relativt enkelt att skicka data från en eller flera servrar. Tunga agenter kan använda upp extra systemresurser. Vissa leverantörer integreras med befintliga rsyslog daemons att vidarebefordra loggar utan att använda betydligt fler resurser., Loggly, till exempel, ger ett skript som vidarebefordrar loggar från rsyslog till Loggly förtäring servrar med hjälp av omfwd modulen.