Sådan overvåges systembrug, afbrydelser og fejlfinding af Linux-servere - Del 9
Selvom Linux er meget pålidelig, bør kloge systemadministratorer finde en måde at holde øje med systemets adfærd og anvendelse til enhver tid. At sikre en oppetid så tæt på 100% som muligt og tilgængeligheden af ressourcer er kritiske behov i mange miljøer. Undersøgelse af systemets tidligere og nuværende status vil give os mulighed for at forudse og sandsynligvis forhindre mulige problemer.
Introduktion til Linux Foundation-certificeringsprogrammet
I denne artikel vil vi præsentere en liste over et par værktøjer, der er tilgængelige i de fleste opstrøms distributioner for at kontrollere systemstatus, analysere afbrydelser og fejlfinde igangværende problemer. Specifikt af de utallige tilgængelige data vil vi fokusere på CPU, lagerplads og hukommelsesudnyttelse, grundlæggende processtyring og loganalyse.
Udnyttelse af lagerplads
Der er 2 kendte kommandoer i Linux, der bruges til at inspicere lagerpladsbrug: df og du .
Den første, df (som står for diskfri), bruges typisk til at rapportere den samlede diskpladsforbrug efter filsystem.
Uden indstillinger rapporterer df diskpladsforbrug i bytes. Med flagget -h viser det de samme oplysninger ved hjælp af MB eller GB i stedet. Bemærk, at denne rapport også inkluderer den samlede størrelse for hvert filsystem (i 1-K-blokke), de ledige og tilgængelige pladser og monteringspunktet for hver lagerenhed.
# df # df -h
Det er bestemt rart - men der er en anden begrænsning, der kan gøre et filsystem ubrugeligt, og det løber tør for inoder. Alle filer i et filsystem er tilknyttet en inode, der indeholder dens metadata.
# df -hTi
du kan se mængden af brugte og tilgængelige inoder:
I henhold til ovenstående billede er der 146 anvendte inoder ( 1% ) i/home, hvilket betyder at du stadig kan oprette 226K filer i det filsystem.
Bemærk, at du kan løbe tør for lagerplads længe inden du løber tør for inoder og omvendt. Af den grund skal du ikke kun overvåge lagerudnyttelsen, men også antallet af inoder, der bruges af filsystemet.
Brug følgende kommandoer til at finde tomme filer eller mapper (som optager 0B), der bruger inoder uden grund:
# find /home -type f -empty # find /home -type d -empty
Du kan også tilføje flagget -delete i slutningen af hver kommando, hvis du også vil slette de tomme filer og mapper:
# find /home -type f -empty --delete # find /home -type f -empty
Den foregående procedure slettede 4 filer. Lad os kontrollere igen antallet af brugte/tilgængelige noder igen i/home:
# df -hTi | grep home
Som du kan se, er der 142 brugte inoder nu (4 mindre end før).
Hvis brugen af et bestemt filsystem er over en foruddefineret procentdel, kan du bruge du (forkortelse for diskbrug) til at finde ud af, hvilke filer der har mest plads.
Eksemplet er givet til /var , som som du kan se på det første billede ovenfor, bruges til 67%.
# du -sch /var/*
Bemærk: At du kan skifte til en af ovenstående underkataloger for at finde ud af nøjagtigt, hvad der er i dem, og hvor meget hver vare optager. Du kan derefter bruge disse oplysninger til enten at slette nogle filer, hvis der ikke er behov for det, eller udvide størrelsen på den logiske lydstyrke, hvis det er nødvendigt.
Læs også
- 12 Nyttige “df” -kommandoer til kontrol af diskplads
- 10 Nyttige “du” -kommandoer til at finde diskbrug af filer og kataloger
Hukommelse og CPU-udnyttelse
Det klassiske værktøj i Linux, der bruges til at udføre en samlet kontrol af CPU/hukommelsesudnyttelse og processtyring er htop, men jeg har slået mig til top, fordi det er installeret out-of-the-box i enhver Linux-distribution.
For at starte øverst skal du blot skrive følgende kommando i din kommandolinje og trykke på Enter.
# top
Lad os undersøge en typisk top output:
I række 1 til 5 vises følgende oplysninger:
1. Den aktuelle tid (20:41:32 pm) og oppetid (7 timer og 41 minutter). Kun en bruger er logget på systemet og belastningsgennemsnittet i henholdsvis de sidste 1, 5 og 15 minutter. 0,00, 0,01 og 0,05 indikerer, at systemet i løbet af disse tidsintervaller var inaktivt i 0% af tiden (0,00: ingen processer ventede på CPU'en), det blev derefter overbelastet med 1% (0,01: et gennemsnit på 0,01 processer ventede på CPU'en) og 5% (0,05). Hvis mindre end 0 og jo mindre tallet (f.eks. 0,65), var systemet inaktivt i 35% i løbet af de sidste 1, 5 eller 15 minutter, afhængigt af hvor 0,65 vises.
2. I øjeblikket kører der 121 processer (du kan se den komplette liste i 6). Kun 1 af dem kører (øverst i dette tilfælde, som du kan se i% CPU-kolonnen), og de resterende 120 venter i baggrunden, men "sover" og forbliver i den tilstand, indtil vi kalder dem. Hvordan? Du kan bekræfte dette ved at åbne en mysql-prompt og udføre et par forespørgsler. Du vil bemærke, hvordan antallet af kørende processer stiger.
Alternativt kan du åbne en webbrowser og navigere til en hvilken som helst side, der serveres af Apache, og du får det samme resultat. Disse eksempler antager selvfølgelig, at begge tjenester er installeret på din server.
3. os (tidskørsel af brugerprocesser med ikke-ændret prioritet), sy (tidskørsel af kerneprocesser), ni (tidskørsel af brugerprocesser med ændret prioritet), wa (ventetid på I/O-færdiggørelse), hej (tid brugt på at afbryde hardware afbrydelser), si (tid brugt på at afbryde software til afbrydelser), st (tid stjålet fra den aktuelle VM af hypervisoren - kun i virtualiserede miljøer).
4. Fysisk hukommelsesforbrug.
5. Skift pladsforbrug.
For at inspicere RAM-hukommelse og swap-brug kan du også bruge kommandoen gratis .
# free
Naturligvis kan du også bruge switchene -m (MB) eller -g (GB) til at vise de samme oplysninger i menneskelig læsbar form:
# free -m
Uanset hvad skal du være opmærksom på, at kernen reserverer så meget hukommelse som muligt og gør den tilgængelig for processer, når de anmoder om det. Især viser linjen " -/+ buffere/cache " de faktiske værdier, efter at denne I/O-cache er taget i betragtning.
Med andre ord mængden af hukommelse, der bruges af processer, og den mængde, der er tilgængelig for andre processer (i dette tilfælde henholdsvis 232 MB anvendt og 270 MB ). Når processer har brug for denne hukommelse, reducerer kernen automatisk størrelsen på I/O-cachen.
Læs også : 10 Nyttig "gratis" kommando til kontrol af Linux-hukommelsesbrug
Ser vi nærmere på processer
Til enhver tid kører der mange processer på vores Linux-system. Der er to værktøjer, som vi vil bruge til nøje at overvåge processer: ps og pstree .
Ved hjælp af indstillingerne -e og -f kombineret til en ( -ef ) kan du liste alle de processer, der i øjeblikket kører på dit system. Du kan pibe denne output til andre værktøjer, såsom grep (som forklaret i del 1 i LFCS-serien) for at indsnævre output til den eller de ønskede processer:
# ps -ef | grep -i squid | grep -v grep
Ovenstående procesliste viser følgende oplysninger:
procesens ejer, PID, Forældre-PID (den overordnede proces), processorudnyttelse, tidspunktet, hvor kommandoen startede, tty (? angiver, at det er en dæmon), den kumulerede CPU-tid og kommandoen, der er knyttet til processen.
Men måske har du ikke brug for alle disse oplysninger og vil gerne vise ejeren af processen, kommandoen, der startede den, dens PID og PPID og procentdelen af hukommelse, den i øjeblikket bruger - i den rækkefølge og sorter efter hukommelsesbrug i faldende rækkefølge (bemærk, at ps som standard er sorteret efter PID).
# ps -eo user,comm,pid,ppid,%mem --sort -%mem
Hvor minustegnet foran% mem angiver sortering i faldende rækkefølge.
Hvis en proces af en eller anden grund begynder at tage for meget systemressourcer, og det sandsynligvis vil bringe systemets samlede funktionalitet i fare, vil du stoppe eller stoppe udførelsen af den og videregive et af følgende signaler ved hjælp af kill-programmet til det. Andre grunde til, at du overvejer at gøre dette, er når du har startet en proces i forgrunden, men ønsker at sætte den på pause og genoptage i baggrunden.
Når den normale udførelse af en bestemt proces indebærer, at der ikke sendes noget output til skærmen, mens den kører, kan du enten starte den i baggrunden (tilføje et ampersand i slutningen af kommandoen).
process_name &
eller,
Når den er begyndt at køre i forgrunden, skal du sætte den på pause og sende den i baggrunden med
Ctrl + Z
# kill -18 PID
Bemærk, at hver distribution giver værktøjer til yndefuldt at stoppe/starte/genstarte/genindlæse almindelige tjenester, såsom service i SysV-baserede systemer eller systemctl i systemd-baserede systemer.
Hvis en proces ikke reagerer på disse værktøjer, kan du dræbe den med magt ved at sende den SIGKILL-signalet til den.
# ps -ef | grep apache # kill -9 3821
Så .. Hvad skete der/sker der?
Når der har været nogen form for afbrydelse i systemet (det være sig strømafbrydelse, hardwarefejl, en planlagt eller ikke planlagt afbrydelse af en proces eller nogen som helst abnormitet), logger log ind i /var/log er dine bedste venner til at bestemme, hvad der skete, eller hvad der kan forårsage de problemer, du står over for.
# cd /var/log
Nogle af elementerne i /var/log er almindelige tekstfiler, andre er mapper, og endnu en gang er komprimerede filer med roterede (historiske) logfiler. Du vil gerne kontrollere dem med ordfejlen i deres navn, men inspektion af resten kan også være praktisk.
Forestil dig dette scenarie. Dine LAN-klienter kan ikke udskrive til netværksprintere. Det første trin til fejlfinding af denne situation er at gå til mappen /var/log/cups og se, hvad der er derinde.
Du kan bruge kommandoen hale til at få vist de sidste 10 linjer i error_log-filen eller tail -f error_log til en realtidsvisning af loggen.
# cd /var/log/cups # ls # tail error_log
Ovenstående skærmbillede giver nogle nyttige oplysninger for at forstå, hvad der kan forårsage dit problem. Bemærk, at det at følge trinene eller rette fejlfunktion i processen stadig ikke måske løser det overordnede problem, men hvis du bliver brugt lige fra starten til at kontrollere logfiler, hver gang der opstår et problem (det være sig et lokalt eller et netværk), Jeg vil helt sikkert være på rette vej.
Selvom hardwarefejl kan være vanskeligt at foretage fejlfinding, skal du kontrollere dmesg og meddelelseslogfiler og grep for relaterede ord til en hardware-del, der antages at være defekt.
Billedet nedenfor er taget fra /var/log/messages efter at have ledt efter ordfejlen ved hjælp af følgende kommando:
# less /var/log/messages | grep -i error
Vi kan se, at vi har et problem med to lagerenheder: /dev/sdb og /dev/sdc , hvilket igen forårsager et problem med RAID-arrayet.
Konklusion
I denne artikel har vi undersøgt nogle af de værktøjer, der kan hjælpe dig med altid at være opmærksom på dit systems overordnede status. Derudover skal du sørge for, at dit operativsystem og dine installerede pakker opdateres til deres seneste stabile versioner. Og aldrig, nogensinde, glem at kontrollere logfiler! Så bliver du på vej i den rigtige retning for at finde den endelige løsning på eventuelle problemer.
Du er velkommen til at efterlade dine kommentarer, forslag eller spørgsmål - hvis du har nogen - ved hjælp af nedenstående formular.