Linux Logs beheren

een belangrijke best practice voor loggen is het centraliseren of aggregeren van uw logs op een enkele locatie, vooral als u meerdere servers of architectuurlagen hebt. Moderne toepassingen hebben vaak meerdere niveaus van infrastructuur die een mix van on-premise servers en clouddiensten kan omvatten. Proberen om het juiste bestand op te sporen om een fout op te lossen zou ongelooflijk moeilijk zijn, en proberen om problemen tussen systemen te correleren zou nog moeilijker zijn., Er is niets frustrerender dan het vinden van de informatie die u wilde niet werd vastgelegd in een logbestand, of dat het logbestand dat het antwoord had kunnen houden werd verloren na een server herstart.

in deze sectie wordt uitgelegd hoe centralisatie services te gebruiken om je Linux logbestanden te verzamelen en centraliseren.

voordelen

voordelen van het centraliseren van Logboeken

het centraliseren van uw logboeken maakt het zoeken door loggegevens eenvoudiger en sneller, omdat al uw logboeken op één locatie toegankelijk zijn., In plaats van te raden welke server het juiste bestand heeft, kunt u eenvoudig toegang krijgen tot uw repository met loggegevens om naar relevante gebeurtenissen te zoeken. Centralisatie is een belangrijk onderdeel van grote managementoplossingen, omdat het hen in staat stelt om logs te analyseren, te ontleden en te indexeren voordat ze op een enkele locatie worden opgeslagen. Dit maakt het oplossen en oplossen van productieproblemen eenvoudiger en sneller. Centralisatie biedt ook deze voordelen.

• Logs worden op een aparte locatie geback-upt, waardoor ze worden beschermd tegen onopzettelijk of onopzettelijk verlies., Dit houdt ze ook toegankelijk in het geval uw servers uitvallen of niet meer reageren.
• u hoeft geen SSH of inefficiënte grep-commando ‘ s te gebruiken, die waardevolle computerbronnen kunnen gebruiken voor complexe zoekopdrachten.
• u kunt de hoeveelheid schijfruimte die door logbestanden wordt gebruikt verminderen.
• ingenieurs kunnen productieproblemen oplossen zonder direct toegang te krijgen tot systemen.

hoewel gecentraliseerd logbeheer over het algemeen de betere optie is, zijn er nog steeds enkele risico ‘ s, zoals een slechte netverbinding die leidt tot gegevensverlies, of logs die veel netwerkbandbreedte gebruiken., We zullen in de onderstaande paragrafen bespreken hoe we deze kwesties op intelligente wijze kunnen aanpakken.

populair

populaire hulpmiddelen voor het centraliseren van Logs

De meeste Linux-systemen centraliseren al logs met behulp van een syslog-daemon. Zoals we in de Linux Logging Basics sectie hebben uitgelegd, is syslog een service die logbestanden verzamelt van services en applicaties die op de host draaien. Het kan deze logs naar een bestand schrijven, of ze doorsturen naar een andere server via het syslog protocol., Er zijn verschillende syslog-implementaties die u kunt gebruiken, waaronder:

• Rsyslog-een lichtgewicht daemon geïnstalleerd op de meest voorkomende Linux-distributies.
• syslog-ng – de tweede meest populaire Syslog daemon voor Linux.
• logstash-een zwaardere agent die meer geavanceerde verwerking en parsing kan doen. Het kan syslog-berichten lezen met behulp van de syslog-invoerplug-in en ze doorsturen naar een willekeurig aantal uitvoerbestemmingen.
• fluentd– een andere agent met geavanceerde verwerkingsmogelijkheden. Het ondersteunt ook syslog input met behulp van de in_syslog plugin.,

Rsyslog is de meest populaire syslog-implementatie en wordt standaard geïnstalleerd in veel Linux-distributies. Als u meer geavanceerde filtering of aangepaste parsing mogelijkheden nodig, Logstash is de volgende meest populaire keuze. Logstash is ook nauw geïntegreerd met de Elastic Stack, die een complete log management oplossing biedt. Voor deze gids, zullen we ons richten op het gebruik van rsyslog omdat het zo veel gebruikt.

config

rsyslog configureren.conf

het hoofdconfiguratiebestand van rsyslog bevindt zich op /etc/rsyslog.conf., U kunt extra configuratiebestanden opslaan in /etc/rsyslog.d / directory. Op Ubuntu bijvoorbeeld bevat deze map /etc/rsyslog.d/50-default.conf, die rsyslog instrueert om de systeemlogboeken naar een bestand te schrijven. U kunt meer lezen over de configuratie bestanden in de rsyslog documentatie.

het configureren van rsyslog omvat het instellen van invoerbronnen (waar rsyslog logs ontvangt), evenals bestemmingsregels voor waar en hoe logs worden geschreven. Rsyslog biedt al standaardwaarden voor het ontvangen van syslog-gebeurtenissen, dus normaal gesproken hoeft u alleen maar uw centralisatieserver als uitvoer toe te voegen., Rsyslog gebruikt RainerScript voor zijn configuratie syntaxis. In dit voorbeeld sturen we onze logs door naar de server op central.example.com via TCP poort 514.

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

als alternatief kunnen we onze logs naar een logbeheeroplossing sturen. Cloud-based log management providers zoals SolarWinds ® Loggly® zullen u voorzien van een hostnaam en poort waar u uw logs naar kunt sturen door simpelweg de velden target en port te wijzigen. Raadpleeg de documentatie van uw provider bij het configureren van rsyslog..,

direct

logbestanden en mappen

Rsyslog biedt de imfile-module, waarmee logbestanden op nieuwe gebeurtenissen kunnen worden gecontroleerd. Hiermee kunt u een bestand of map opgeven als logboekbron. Rsyslog kan individuele bestanden en hele mappen te controleren.

bijvoorbeeld, we willen logbestanden die door de Apache server zijn aangemaakt controleren. We kunnen dit doen door een nieuw bestand aan te maken in /etc/rsyslog.d/ genaamd apache.conf, de imfile module te laden en Apache ‘ s logbestanden als invoer toe te voegen.,

De bestandsparameter ondersteunt jokertekens voor het monitoren van meerdere bestanden en mappen.

protocol

welk Protocol: UDP, TCP of RELP?

Er zijn drie hoofdprotocollen waaruit u kunt kiezen bij het verzenden van loggegevens: UDP, TCP en RELP.

UDP verstuurt berichten zonder levering of ontvangstbevestiging (ACK) te garanderen. Het doet een enkele poging om een pakket te verzenden, en als de levering mislukt, het niet opnieuw proberen. Het is veel sneller en gebruikt minder middelen dan andere protocollen, maar mag alleen worden gebruikt op betrouwbare netwerken zoals localhost., UDP ondersteunt ook het versleutelen van logs niet.

TCP is het meest gebruikte protocol voor streaming over het Internet, omdat het een ACK vereist voordat het volgende pakket wordt verzonden. Als de bezorging mislukt, zal het opnieuw proberen totdat het bericht met succes wordt afgeleverd. TCP vereist echter een handshake en een actieve verbinding tussen de afzender en de ontvanger, die extra netwerkbronnen gebruikt.

RELP (Reliable Event Logging Protocol) is speciaal ontworpen voor rsyslog en is misschien wel de meest betrouwbare van deze drie protocollen., Het bevestigt de ontvangst van gegevens in de applicatielaag en zal opnieuw verzenden als er een fout is. Omdat het minder gebruikelijk is, moet u ervoor zorgen dat uw bestemming ook dit protocol ondersteunt.

als rsyslog een probleem ondervindt bij het opslaan van logs, zoals een niet-beschikbare netwerkverbinding, zal het de logs in de wachtrij zetten totdat de verbinding is hersteld. De logboeken in de wachtrij worden standaard in het geheugen opgeslagen. Het geheugen is echter beperkt en als het probleem aanhoudt, kunnen de logboeken de geheugencapaciteit overschrijden, wat kan leiden tot gegevensverlies. Om dit te voorkomen, kunt u overwegen schijfwachtrijen te gebruiken.,

Waarschuwing: U kunt gegevens verliezen als u logs alleen in het geheugen opslaat.

que

betrouwbaar verzenden met Disk-assisted wachtrijen

Rsyslog kan uw logs in de wachtrij plaatsen als het geheugen vol is. Disk-assisted wachtrijen maken het transport van logs betrouwbaarder. Hier is een voorbeeld van het configureren van een log forwarding regel in rsyslog met een disk-assisted queue.

versleutel

Versleutel Logs met behulp van TLS

wanneer gegevensbeveiliging en privacy een punt van zorg zijn, moet u overwegen om uw logs te versleutelen. Sniffers en tussenpersonen kunnen uw loggegevens lezen als u deze in duidelijke tekst over het internet verzendt., U moet uw logs versleutelen als ze privé-informatie, gevoelige identificatiegegevens of door de overheid gereguleerde gegevens bevatten. De rsyslog daemon kan uw logs versleutelen met behulp van het TLS-protocol en uw gegevens veiliger houden.

het proces om TLS-versleuteling in te schakelen hangt af van uw logboekinstellingen. In het algemeen gaat het om de volgende stappen.

1. Maak een Certificate Authority (CA) aan. Er zijn voorbeeldcertificaten in rsyslog ‘ s /contrib/gnutls directory, die alleen goed zijn voor testen, maar je moet je eigen maken voor productie., Als u gebruik maakt van een log management service, zal het een voor u klaar.
2. Genereer een digitaal certificaat voor uw server om TLS in te schakelen, of gebruik er een van uw log management service provider.
3. configureer uw rsyslog-service om TLS-versleutelde gegevens naar uw logbeheerservice te verzenden.

Hier is een voorbeeld van rsyslog configuratie met TLS encryptie. Vervang CERT en DOMAIN_NAME door uw eigen server instelling.,

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

Log management services zoals SolarWinds Loggly bieden vaak hun eigen Ca ‘ s en certificaten, die u gewoon nodig hebt om te verwijzen in uw rsyslog configuratie. Als u bijvoorbeeld TLS met Loggly inschakelt, hoeft u alleen het loggly certificaat naar uw /etc/rsyslog te downloaden.d / directory, update uw configuratie, en herstart de rsyslog service.

download eerst het certificaat.

$ 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

open vervolgens het /etc/rsyslog.d/22-loggly.conf configuratiebestand en voeg het volgende toe:

ten slotte herstart rsyslog.,

$ sudo service rsyslog restart

praktijk

Best Practices for Application Logging

naast de logs die Linux standaard maakt, is het ook een goed idee om logs van belangrijke toepassingen te centraliseren. Bijna alle Linux-gebaseerde servertoepassingen schrijven hun statusinformatie in aparte, speciale logbestanden. Dit omvat database producten zoals PostgreSQL of MySQL, webservers zoals Nginx of Apache, firewalls, print en file sharing diensten, directory en DNS servers, enzovoort.

het eerste wat beheerders doen na het installeren van een toepassing is om het te configureren., Linux applicaties hebben meestal een .conf bestand ergens in de / etc directory. Het kan ook ergens anders zijn, maar dat is de eerste plaats waar mensen naar configuratiebestanden zoeken. Afhankelijk van hoe complex of groot de toepassing is, kan het aantal instelbare parameters enkele of honderden zijn. Raadpleeg de documentatie van de toepassing voor meer informatie, of gebruik de opdracht lokaliseren om het bestand zelf te zoeken.

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

Stel een standaardlocatie in voor Logbestanden

Linux-systemen slaan hun logbestanden gewoonlijk op onder /var/log map., Dit werkt prima, maar controleer of de toepassing opslaat onder een specifieke map onder /var/log. Als dat zo is, geweldig. Zo niet, dan kunt u een speciale map voor de app maken onder /var/log. Waarom? Dat komt omdat andere toepassingen hun logbestanden ook opslaan onder /var/log en als uw app meer dan één logbestand opslaat—misschien één keer per dag of na elke herstart van de service—kan het een beetje moeilijk zijn om door een grote map te kruipen om het gewenste bestand te vinden.,

als er meer dan één instantie van de toepassing draait in uw netwerk, is deze aanpak ook handig. Denk na over een situatie waarin u een dozijn webservers draaien in uw netwerk. Als uw logs worden opgeslagen op een centrale syslog server, Hoe weet u dan welk logbestand de logs van welke server bevat? Door elke server in een aparte map te loggen, weet u precies waar u moet zoeken bij het oplossen van problemen met een server.

gebruik een statische bestandsnaam

veel toepassingen voegen dynamische gegevens toe aan hun logbestandsnaam, zoals de huidige datum of tijdstempel., Dit is handig voor het automatisch splitsen van logs op datum, maar het maakt het moeilijker voor diensten zoals rsyslog om het laatste bestand te vinden. Een betere aanpak is om een niet-veranderende naam te gebruiken voor uw logbestand, gebruik dan logrotate om een tijdstempel of nummer toe te passen op oudere logbestanden.

logbestanden toevoegen en roteren

toepassingen moeten bestaande logbestanden toevoegen in plaats van ze te overschrijven. Dit helpt ervoor te zorgen dat alle logregels worden vastgelegd en er geen gegevens verloren gaan, zelfs als de toepassing opnieuw wordt opgestart. Logbestanden kunnen echter na verloop van tijd zeer groot worden., Als u probeert om de oorzaak van een probleem te vinden, kunt u uiteindelijk zoeken door tienduizenden regels.

we raden aan om uw logboeken toe te voegen aan een enkel bestand, maar we raden ook aan om de toepassing zo in te stellen dat de logbestanden om de zoveel tijd roteren. Tools zoals logrotate kunnen dit automatisch doen door het huidige logbestand naar een nieuwe locatie te kopiëren, het een unieke naam te geven en het huidige logbestand af te korten., Dit heeft een aantal voordelen, waaronder:

1. Logs zijn verdeeld over bestanden op datum en tijd, waardoor het gemakkelijk is om logbestanden te vinden voor een specifieke datum
2. elk logbestand is veel kleiner, waardoor ze gemakkelijker te doorzoeken en gemakkelijker te verzenden zijn over een netwerk
3. back-up van logbestanden is veel gemakkelijker, en het verwijderen of archiveren van oudere logbestanden kan veel sneller worden gedaan

hoe vaak u logbestanden roteert hangt af van hoeveel logs u genereert. Als vuistregel, begin met het draaien van uw logs een keer per dag.

bewaarbeleid voor Logbestanden

Hoe lang bewaart u een logbestand?, Dat komt zeker neer op zakelijke eisen. Je zou kunnen worden gevraagd om een week van de waarde van de logging informatie te houden, of het kan een wettelijke vereiste zijn om 10 jaar van de waarde van de gegevens te houden. Wat het ook is, logs moeten gaan van de server op een bepaald moment of een ander.

naar onze mening, tenzij anders vereist, moet u minstens een maand aan logbestanden Online houden, plus ze kopiëren naar een secundaire locatie (zoals een logboekserver). Alles wat ouder is dan dat kan worden uitgeladen naar een aparte media. Bijvoorbeeld, als u op AWS, uw oudere logs kunnen worden gekopieerd naar Glacier.,

logbestanden opslaan op een aparte schijf

logbestanden worden constant geschreven, wat kan leiden tot een hoge schijf I / O op drukke systemen. Als een goede gewoonte zou je /var/log op een apart opslagapparaat moeten mounten. Dit voorkomt dat het schrijven van logbestanden interfereert met de prestaties van uw toepassingen, vooral op disk-gebaseerde opslag. Dit voorkomt ook logbestanden van het vullen van de hele schijf in het geval ze te groot worden.

formatteer uw logboekvermeldingen

welke informatie moet u vastleggen in elke logboekvermeldingen?

Dat hangt af van waar u de log voor wilt gebruiken., Wilt u het alleen gebruiken voor het oplossen van problemen, of wilt u alles vastleggen wat er gebeurt? Is het een wettelijke verplichting om vast te leggen wat elke gebruiker draait of bekijkt?

Als u logs gebruikt voor het oplossen van problemen, slaat u alleen fouten, waarschuwingen of fatale berichten op. Er is geen reden om bijvoorbeeld debugberichten vast te leggen. De app kan foutopsporingsberichten standaard inloggen, of een andere beheerder kan dit hebben ingeschakeld voor een andere probleemoplossing oefening, maar je moet dit uitschakelen omdat het zeker de ruimte snel kan vullen., Leg minimaal de datum, tijd, naam van de clienttoepassing, bron-IP-of clienthostnaam, uitgevoerde actie en het bericht zelf vast.

denk bijvoorbeeld aan het standaard loggedrag van PostgreSQL. Logs worden opgeslagen in /var/log/postgresql, en elk bestand begint met postgresql-gevolgd door de datum. Bestanden worden dagelijks geroteerd, en oudere bestanden worden toegevoegd met een nummer op basis van wanneer ze werden geroteerd. Elke logregel kan worden voorafgegaan door velden zoals de huidige tijdstempel, huidige gebruiker, databasenaam, sessie-ID en transactie-ID., U kunt deze instellingen wijzigen door het configuratiebestand van PostgreSQL te bewerken (/etc/postgresql/11/main/postgresql.conf op Debian).

standaard toont elke logregel de tijdstempel en PostgreSQL proces-ID gevolgd door het Logbericht.

logbestanden controleren met Imfile

traditioneel is de meest gebruikelijke manier voor toepassingen om hun gegevens te loggen met bestanden. Bestanden zijn gemakkelijk te zoeken op een enkele machine, maar niet goed schalen met meer servers. Met rsyslog kunt u bestanden controleren op Wijzigingen en nieuwe gebeurtenissen importeren in syslog, waar u de logs vervolgens kunt doorsturen naar een gecentraliseerde server., Dit wordt gedaan met behulp van de imfile module. Om de module in te schakelen, maak je een nieuw configuratiebestand aan in /etc/rsyslog.d/, en voeg je een bestand als dit toe.

voeg uw uitvoerstreams toe na deze configuratie, en rsyslog zal logs van het opgegeven bestand naar de uitvoerbestemming sturen.

Log rechtstreeks naar de Syslog-Socket met Imuxsock

een socket is vergelijkbaar met een UNIX-bestandshandle, behalve dat het gegevens in het geheugen leest in plaats van het naar de schijf te schrijven. In het geval van syslog kun je hiermee logs rechtstreeks naar syslog sturen zonder het eerst naar een bestand te hoeven schrijven.,

deze aanpak maakt efficiënt gebruik van systeembronnen als uw server wordt beperkt door disk I/O of als u geen lokale bestandslogs nodig hebt. Het nadeel van deze aanpak is dat de socket een beperkte wachtrijgrootte heeft. Als je syslog daemon uitvalt of niet kan bijhouden, dan kun je loggegevens verliezen.

om socket logging in rsyslog in te schakelen, voegt u de volgende regel toe aan uw rsyslog configuratie (standaard ingeschakeld).

$ModLoad imuxsock

Dit maakt standaard een socket aan op /dev/log socket, maar u kunt dit wijzigen door de SysSock.Name parameter., U kunt ook opties instellen zoals snelheidsbeperking en flow control. Zie de rsyslog imuxsock-documentatie voor meer informatie.

UDP logt met Imupd

sommige toepassingen voeren loggegevens uit in UDP-formaat, wat het standaardprotocol is bij het overbrengen van logbestanden over een netwerk of uw localhost. Je syslog daemon ontvangt deze logs en kan ze verwerken of verzenden in een ander formaat. Als alternatief kunt u de logs naar een andere syslog-server of naar een logbeheeroplossing sturen.,

gebruik het volgende commando om rsyslog te configureren om syslog-gegevens over UDP op de standaardpoort 514 te accepteren.

$ModLoad imudp$UDPServerRun 514

Configuratie beheren op veel Servers

wanneer u slechts een paar servers hebt, kunt u de logging op deze servers handmatig configureren. Zodra je een paar dozijn of meer servers hebt, kun je gebruik maken van tools die dit gemakkelijker en schaalbaarder maken. Op basisniveau is het doel van elke tool om syslog op elk van je servers in te schakelen, een configuratie toe te passen en ervoor te zorgen dat de wijzigingen van kracht worden.,met

Pssh

Pssh (of parallel SSH) kunt u een SSH-opdracht uitvoeren op meerdere servers parallel. Gebruik een pssh implementatie voor slechts een klein aantal servers. Als een van uw servers faalt, dan moet u ssh in de mislukte server en doe de implementatie handmatig. Als je meerdere mislukte servers hebt, dan kan de handmatige implementatie ervan lang duren.

Puppet/Chef

Puppet en Chef zijn configuratiebeheerprogramma ‘ s die automatisch al uw servers kunnen configureren en ze naar dezelfde status brengen. Zij kunnen uw servers bewaken en ze gesynchroniseerd houden., Puppet en Chef zijn krachtige tools die in staat zijn om software te installeren, bestanden te maken, services opnieuw op te starten en meer. Als u niet zeker weet welke het meest geschikt is voor uw implementatieconfiguratiebeheer, kunt u de vergelijking van de twee tools door InfoWorld waarderen.

sommige leveranciers bieden ook modules of recepten voor het configureren van syslog. Loggly biedt bijvoorbeeld een Puppet module die rsyslog gebruikt om automatisch logs van je agenten door te sturen. Installeer de Loggly Puppet module op je Puppet master, voeg dan de volgende configuratie toe aan je Puppet manifest.,

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

zodra uw agenten vernieuwen, zullen ze beginnen met loggen naar Loggly.

Kubernetes

Kubernetes is een instrument voor het beheren van containers op meerdere knooppunten. Kubernetes biedt een complete logging architectuur die automatisch verzamelt en schrijft container logs naar een bestand op de host machine. U kunt logs voor een specifieke Pod bekijken door het commando kubectl logs <pod name> uit te voeren, wat handig is voor toegang tot applicatielogs op een externe server.,

veel logbeheeroplossingen bieden agents die via Kubernetes kunnen worden ingezet om zowel applicatielogs als hostlogs te verzamelen. Loggly biedt bijvoorbeeld een DaemonSet die een Logboekpod implementeert op elk knooppunt in een cluster. De Pod verzamelt logs van andere Pods en van de host zelf, en het implementeren ervan als een DaemonSet helpt ervoor te zorgen dat er altijd een instantie draait op elk knooppunt. Het loggen van een Kubernetes cluster met Loggly is net zo eenvoudig als het uitvoeren van de volgende commando ‘ s.

Docker

Docker gebruikt containers om toepassingen onafhankelijk van de onderliggende server uit te voeren., Het wordt vaak gebruikt als de container runtime voor orkestrators zoals Kubernetes, maar kan worden gebruikt als een standalone platform. ZDNet heeft een diepgaand artikel over het gebruik van Docker in uw datacenter.,

Er zijn verschillende manieren om te loggen vanuit Docker-containers, waaronder:

• loggen via het Docker-Logboekstuurprogramma naar het hostsysteem (de aanbevolen methode)
• routeren van alle containerlogboeken naar een enkele speciale logboekcontainer (zo werkt de logspout-container)
• loggen naar een zijspan logboekcontainer
• een logboekagent toevoegen aan de container

U kunt ook Docker-containers gebruiken om logs te verzamelen van de gastheer., Als je container een actieve syslog-service heeft, kun je ofwel logs van de host naar de container sturen via syslog, of de logbestanden van de host in de container koppelen en een file monitoring agent gebruiken om de bestanden te lezen.

Leverancierscripts of Agents

De meeste logbeheeroplossingen bieden scripts of agents om het verzenden van gegevens vanaf een of meer servers relatief eenvoudig te maken. Zwaargewicht agenten kunnen extra systeembronnen gebruiken. Sommige leveranciers integreren met bestaande rsyslog daemons om logs door te sturen zonder aanzienlijk meer bronnen te gebruiken., Loggly, bijvoorbeeld, biedt een script dat logs van rsyslog doorstuurt naar de loggly ingestion servers met behulp van de omfwd module.