Phenquestions
Forståelse af logfiler er vigtig: hvis du nogensinde falder på en server, der har en fejl eller er hacket, er din eneste måde generelt at forstå, hvad der skete, via logfiler. Hovedapplikationen, vi skal bruge, er journalctl, deraf navnet på artiklen. Så lyt omhyggeligt som på den rigtige dag, du kan være glad for at vide, hvordan det fungerer.
Hvor gemmes systemd-logfiler? Og hvilket format det er gemt i?
Vi antager, at du har et normalt system, fordi systemd kan tilpasses til at være på ekstraordinære steder. Der er også nogle Linux-distributioner som Ubuntu 16.04 deaktiveret vedvarende logning som standard, hvilket forhindrer systemd i at udføre sit job korrekt. Hvis du har en sådan distribution, skal du redigere / etc / systemd / journald.conf-fil, skift Storage = auto til Storage = vedvarende, og til sidst genstart.
Så du finder normalt systemd-logfiler i / var / log / journal. Journalling-systemet er i sig selv en tjeneste kaldet system-journald.service. Lad os prøve at liste filerne i denne mappe:
# ls / var / log / journal / -R/ var / log / journal /:
15e43c1734090ac7fbea6b40fcd99d31
/ var / log / journal / 15e43c1734090ac7fbea6b40fcd99d31:
system @ a39da368947bd2ba-231f9bfc18a7a356.journal ~
system @ 62ac1299826d036cb043d6c06a9493b7-0000000000000001-00067d6410099a19.tidsskrift
bruger-1000 @ b27e98812223a9bc-387e0521703f73d9.journal ~
bruger-1000 @ 2123bc076b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.tidsskrift
bruger-1000.tidsskrift
[mange andre filer som dem ovenfor ...]
Fordi jeg vil have dig til at fortsætte med at læse, var jeg nødt til at forkorte output, da det indeholder mange filer (i mit eksempel mere end 60 filer), undskyld det! Fristet til at åbne en måske?
# head --bytes = 512 / var / log / journal / 15e43c1734090ac7fbea6b40fcd99d31 / [email protected]b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.tidsskrift
?s, q?n / FLz???Ulz?l?]????
?_?b???z????o?y1KN ?jeg?eO??W?u? ?=?x0?L?d?7??X4n #?e? d3l?
s??o | MFO:?!qs?.tK??R?\??1?| 5 ????$?g??#?S??;??B7???????t???Y????mN?q????ZQ
?Yv?e?????BD?C?? wF??d |
?2?? 7???????[??Un?= 8????c?2 = s?&?" ?0
????*????_?? ???
5?????yk?G? ?6?|??u??w: # 12?Y??
3 TU;???''?jX??2?x'?=??[[e-mail-beskyttet]
[e-mail beskyttet]?_?>??3S???,lR?.?$?g?L???s?/ E??M1??q???
Hej, se, det ser ikke rigtig ud som de sædvanlige logfiler, du ser rigtigt? Bare rolig, denne fil er ikke beskadiget, du har lige opdaget et aspekt af systemd: systemd gemmer filer i et binært format. Derfor er det så lille som muligt: strukturerede data såsom tid eller sted lagres lige i binær, hvilket generelt tager mindre byte end tekst gør. Men det er ikke den eneste grund.
systemd gemmer ikke kun loglinjer. Dens hensigt er at gøre logsovervågning og udforskning lettere. For at hjælpe med denne opgave er logmeddelelser faktisk en tekstlinje ledsaget af data såsom log sværhedsgrad (advarsel, fejl osv.) eller endda felter, der kun ville være nyttige for din applikation (URL anmodet for eksempel).
# journalctl --output = detaljeret - altPRIORITET = 6
_UID = 0
_GID = 0
_CAP_EFFECTIVE = 3fffffffff
_BOOT_ID = ee4cc2ce7e8273aaffb5fc59c873ce7b
_MACHINE_ID = bc422e0feaab64bb7dd218c24e6830e5
_HOSTNAME = linux
SYSLOG_FACILITY = 3
SYSLOG_IDENTIFIER = systemd
ENHED = dnf-makecache.service
_TRANSPORT = journal
_PID = 1
_COMM = systemd
_EXE = / usr / lib / systemd / systemd
_CMDLINE = / usr / lib / systemd / systemd - switched-root --system - deserialize 76
_SYSTEMD_CGROUP = / init.rækkevidde
_SYSTEMD_UNIT = init.rækkevidde
_SYSTEMD_SLICE =-.skive
_SELINUX_CONTEXT = system_u: system_r: init_t: s0
CODE_FILE = src / kerne / job.c
CODE_LINE = 795
CODE_FUNCTION = job_log_status_meddelelse
MESSAGE_ID = a76e08846f5f0971371dbb11126e62e1
MESSAGE = Startet dnf makecache.
# journalctl --catalog --lines = 3000 - side-ende "_TRANSPORT = kerne" RESULTAT = færdig
_SOURCE_REALTIME_TIMESTAMP = 1532886335471422
Jeg har fortalt dig, at der er mange felter (her er 25 felter eller 29 tidsstempler tæller), alt ovenstående uddrag er kun til en enkelt logmeddelelse! Den store fordel er, at du kan køre en søgning ved at filtrere på ethvert felt i denne logmeddelelse. Dette giver dig virkelig mulighed for avanceret filtrering.
Et af de mest åbenlyse filter, du ønsker, er at filtrere efter tjenesten. Som du kan se ovenfor, er der et UNIT-felt, så du nemt kan filtrere for kun at få logbeskeder fra en tjeneste. Jeg fortæller dig mere om det senere.
Men denne mængde data betyder også noget andet: i næsten alle tilfælde åbner du aldrig en logfil manuelt, og du rører aldrig til mappen / var / log / journal. Du bruger journalctl til enhver opgave relateret til logning. Der er ingen sådan log rotations ting, alt styres af log besked tid.
Antallet af felter vil også afhænge af, hvor god integrationen af systemd er i din applikation. Jo flere felter en logmeddelelse indeholder, jo bedre er den. For basissystemtjenester tog systemd allerede sig af at gøre en god integration, men for andre applikationer og tjenester varierer kvaliteten af integration meget. Normalt skal dette blive bedre over tid, da folk bliver vant til systemd.
Okay, nu er det tid til at opdage journalctls funktioner.
Mest anvendte kommandoer til journalctl
Den første kommando, du måske vil se på, er den, der viser Linux-kernens logfiler. Ja, systemd håndterer også opbevaring af kernelogfiler, så du også kan få logfiler fra tidligere støvler. Her er kommandoen:
# journalctl --catalog --lines = 3000 - side-ende "_TRANSPORT = kerne"Det viser dig en personsøger, hvor du kan se de sidste meddelelser. Du kan rulle op til de sidste 3.000 linjer ved hjælp af piletasterne (↑ / ↓) eller Side op / Side ned. Flaget -catalog instruerer journalctl om at vise kontekst omkring loglinjer, ligesom computeren genstarter eller i andre sammenhænge en tjeneste, der stopper / starter. Jeg sætter altid dette flag, da kontekst altid betyder noget, det hjælper at vide, i hvilken situation loglinjen dukkede op, så du kan gætte, hvorfor du fik denne loglinje.
Nu, måske vil du kun se loglinjerne fra den aktuelle boot:
# journalctl --catalog --lines = 35000 --pager-end --boot "_TRANSPORT = kernel"Bemærk, at kommandolinjeargumentet -boot fungerer i alle situationer, ikke kun med kernelogfiler. Hvis du foretrækker at starte fra starten:
# journalctl --catalog --boot "_TRANSPORT = kerne"Jeg ved ikke, om det er tilfældet for dig, men jeg har nok af kernelogfiler! Og hvad med at have et generelt overblik over din maskine?
# journalctl --catalog --lines = 3000 - side-endeWow, der sker mange ting på dit system! En smule filtrering vil være nyttigt her. Et af de mest anvendte filtre matcher en bestemt tjeneste (som din SSH-server eller HTTP-server), systemd-enhedens filnavn til SSH-tjenesten er sshd.service, så:
# journalctl --catalog --lines = 3000 - personsøger-ende - enhed = sshd.serviceDet er sejt, ikke?? Det er kun anvendeligt, hvis du kender navnet på tjenesten - men i mange tilfælde kender du ikke navnet på den service. Hvis du er i en sådan situation, vil du muligvis have en liste over tjenesterne, deres beskrivelser og deres status:
# systemctl liste-enheder --type = serviceOkay, dette problem er nu løst. Men nogle gange har du en fejlmeddelelse, du får fra et eksternt system som dit eget websted eller fra et program på dit skrivebord. Så du vil sandsynligvis søge i et bestemt ord eller en bestemt sætning i logmeddelelsen. Da systemd v237 er det nu muligt.
I journalctl er søgningen ikke store og små bogstaver, hvis det ord, du søger, alle er med små bogstaver. Så hvis du søger i ordporten, søger den også i ordporten med store bogstaver. Et eksempel:
# journalctl --catalog --lines = 3000 --pager-end --grep = "port"Nu, hvis du søger på et ord som CPU, vil det kun søge CPU med alle store bogstaver, det søger ikke CPU.
# journalctl --catalog --lines = 3000 --pager-end --grep = "CPU"Du husker fejlmeddelelsen fra det eksterne system? Generelt indeholder disse meddelelser en tidsstempel. For at filtrere logbeskeden kan du bruge den tidsstempel. journalctl kan vise dig alle logbeskeder siden en bestemt dato og tid med argumentet -since:
# journalctl --catalog --since = "30-07-2018 09:30:00"Hvis det eksterne system er eksternt eller bruger UTC-tidsstempler, skal du filtrere baseret på en UTC-dato og et klokkeslæt og vise UTC-tidsstemplerne i terminalen, så du ikke behøver at konvertere det i dit hoved, det har tendens til at være virkelig forvirrende. For at gøre dette skal du tilføje UTC efter tidsstrengen i -siden-argumentet. Du skal derefter tilføje -utc-flag. Så for eksempel:
# journalctl --catalog --since = "30-07-2018 10:45:00 UTC" --utcBemærk, at du kan bruge -utc-flag alene, i dette tilfælde vil det stort set vise alle datoer og tidspunkter i UTC-tidszone.
# journalctl --catalog --lines = 3000 - personsøger-slut --utcLogfiler styres bedre med journalctl
Som du kan se med alle tidligere kommandoer, gør systemd journaling filtrering og så fejlretning lettere, da du kan vælge gennem alle loglinjer ved hjælp af en enkelt kommando, journalctl. Nogle af jer vidste sandsynligvis gamle tider, hvor man skulle åbne hver fil i / var / log manuelt for at få en generel idé om problemet og hvad der skete. Med alle de tip, du lærte her, vil du eje solide værktøjer til at se på dine logmeddelelser på den måde, du ønsker det.
