Master JournalCTL Forstå systemd logger

SystemD er det nye verktøyet for styringstjenester. Opprettet opprinnelig av Red Hat, og gjør det bedre å administrere tjenester via en sentralisert prosess som overvåker og lanserer tjenester etter behov. Men SystemD inkluderer også et contaatsystem, et CRON -system, en måte å tilby midlertidige kataloger til tjenester på en sikker måte og også et loggingssystem - det er der vi skal fokusere her.

Å forstå logger er viktig: Hvis du noen gang faller på en server som har en feil eller er hacket, er det vanligvis din eneste måte å forstå hva som skjedde via logger. Hovedprogrammet vi skal bruke er JournalCtl, derav navnet på artikkelen. Så lytt nøye som på den rette dagen, kan du være glad for å vite hvordan det fungerer.

Hvor er lagrede SystemD -logger? Og hvilket format det er lagret i?

Vi antar at du har et normalt system, fordi SystemD kan tilpasses for å være på eksepsjonelle steder. Også noen Linux -distribusjoner som Ubuntu 16.04 Deaktivert vedvarende logging som standard, som forhindrer at Systemd gjør jobben sin riktig. Hvis du har slik distribusjon, rediger/etc/Systemd/Journald.Conf File, Endre lagring = Auto til lagring = vedvarende og til slutt, omstart på nytt.

Så du finner normalt SystemD Logs -filene i/var/log/journal. Journaling-systemet er i seg selv en tjeneste som heter System-Journald.service. La oss prøve å liste opp filene i denne katalogen:

# ls/var/log/journal/-r
/var/log/journal/:
15E43C1734090AC7FBEA6B40FCD99D31
/var/log/journal/15e43c1734090ac7fbea6b40fcd99d31:
[email protected] ~
System@62ac1299826d036cb043d6c06a9493b7-000000000000000001-00067D6410099A19.tidsskrift
[email protected] ~
Bruker-1000@2123BC076B58569FE1FB13E9DBC1B0E0-000000000000000001-0007FE36AC2810E0.tidsskrift
Bruker-1000.tidsskrift
[Mange andre filer som de ovenfor…]

Fordi jeg vil at du fortsetter å lese, måtte jeg forkorte utdataene da den inneholder mange filer (i mitt eksempel mer enn 60 filer), beklager det! Fristet til å åpne en kanskje?

# head --bytes = 512/var/log/journal/15e43c1734090ac7fbea6b40fcd99d31/user-1000@2123bc076
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?
p??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?Og?"" ?0
????*????_?? ???
5?????YK?G? ?6?|??u??W: #12?Y??
3 tu;???'?jx??2?x '?=??[Q???@Z
T_???3ehmd?@?_?>??3s???,LR?.?$?g?L???s?/E??M1??q???

Hei, se, det ser egentlig ikke ut som de vanlige loggfilene du ser riktig? Ikke bekymre deg, denne filen er ikke ødelagt, du har nettopp oppdaget et aspekt av SystemD: SystemD lagrer filer i et binært format. Derfor er det så lite som mulig: Strukturerte data som tid eller sted lagres rett i binær, noe som generelt tar mindre byte enn tekst. Men det er ikke den eneste grunnen.

SystemD lagrer ikke bare logglinjer. Dets intensjon er å gjøre loggovervåkning og utforskning enklere. For å hjelpe i denne oppgaven, er loggmeldinger faktisk en tekstlinje ledsaget av data som loggens alvorlighetsgrad (advarsel, feil osv.), eller til og med felt som bare ville være nyttige for applikasjonen din (URL ba om for eksempel).

# journalctl -output = verbose -all
Prioritet = 6
_Uid = 0
_Gid = 0
_CAP_Effektiv = 3FFFFFFFF
_Boot_id = EE4CC2CE7E8273AAFFB5FC59C873CE7B
_Machine_ID = BC422E0feAAB64BB7DD218C24E6830E5
_HostName = Linux
Syslog_facility = 3
SYSLOG_Identifier = Systemd
Enhet = 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.omfang
_Systemd_Unit = init.omfang
_Systemd_slice =-.skive
_Selinux_context = System_u: System_r: init_t: S0
Code_file = src/core/jobb.c
Code_line = 795
Code_function = JOB_LOG_STATUS_MESSAGE
Message_id = A76E08846F5F0971371DBB11126E62E1
Melding = startet dnf makecache.
# JournalCTL--Catalog-Lines = 3000-PAGER-END "_TRANSPORT = KERNEL" RESULTAT = Ferdig
_Source_RealTime_Timestamp = 1532886335471422

Jeg har fortalt deg at det er mange felt (her er det 25 felt, eller 29 teller tidsstempler), alt av utdraget ovenfor er bare for en enkelt loggmelding! Den store fordelen er at du kan kjøre et søk ved å filtrere på et hvilket som helst felt i denne loggmeldingen. Dette gjør deg virkelig i stand til avansert filtrering.

Et av de mest åpenbare filterene du ønsker er å filtrere av tjenesten. Som du kan se ovenfor, er det et enhetsfelt, slik at du enkelt kan filtrere for å få bare loggmeldinger fra en tjeneste. Jeg skal fortelle deg mer om det senere.

Men denne datamengden betyr også noe annet: I nesten alle tilfeller vil du aldri åpne en loggfil manuelt, og du vil aldri berøre/var/log/journalmappe. Du bruker JournalCTL for enhver oppgave relatert til logging. Det er ingen slik loggrotasjon ting, alt administreres av loggmeldingstid.

I tillegg vil antall felt avhenge av hvor bra er integrasjonen av SystemD i applikasjonen din. Jo flere felt en loggmelding inneholder, jo bedre er den. For basesystemtjenester tok SystemD allerede vare på å gjøre en god integrasjon, men for andre applikasjoner og tjenester varierer kvaliteten på integrasjonen mye. Normalt bør dette bli bedre over tid etter hvert som folk blir vant til Systemd.

Ok, nå er det på tide å oppdage Journalctls funksjoner.

De fleste brukte kommandoer for journalctl

Den første kommandoen du kanskje vil ta en titt på er den som viser Linux -kjernenes logger. Ja, SystemD håndterer også lagring av Kernels tømmerstokker, slik at du også kan få tømmerstoene til tidligere støvler. Her er kommandoen:

# JournalCTL--Catalog-Lines = 3000-PAGER-END "_TRANSPORT = KERNEL"

Det viser deg en personsøker der du kan se de siste meldingene. Du kan bla opp til de siste 3000 linjene ved hjelp av piltastene (↑ / ↓) eller side opp / side ned. Catalog -flagget instruerer JournalCTL om å vise kontekst rundt logglinjer, omtrent som datamaskinstarter eller, i andre sammenhenger, en tjenestestopp / start. Jeg har alltid lagt dette flagget som kontekst alltid betyr noe, det hjelper å vite i hvilken situasjon logglinjen dukket opp, slik at du kan gjette hvorfor du fikk denne logglinjen.

Nå, kanskje du bare vil se logglinjene fra gjeldende oppstart:

# JournalCTL--Catalog-Lines = 35000-PAGER-END --BOOT "_TRANSPORT = KERNEL"

Legg merke til -Boot -kommandolinje -argumentet fungerer i alle situasjoner, ikke bare med Kernels logger. Hvis du foretrekker å starte fra begynnelsen:

# JournalCTL - -Catalog -Boot "_transport = kjerne"

Jeg vet ikke om det er tilfelle for deg, men jeg har nok av kjernelogger! Og hva med å ha en generell oversikt over maskinen din?

# JournalCTL--Catalog-Lines = 3000-PAGER-END

Wow, det skjer mange ting på systemet ditt! Litt filtrering vil være nyttig her. En av de mest brukte filtrene er å matche en spesifikk tjeneste (som din SSH -server eller HTTP -server), SystemD -enheten for SSH -tjenesten er SSHD.service, så:

# JournalCTL--Catalog-Lines = 3000-PAGER-END-UNIT = SSHD.service

Det er kult, er det ikke? Vel, det er bare brukbart hvis du vet navnet på tjenesten - men i mange tilfeller vet du ikke navnet på den tjenesten. Hvis du er i en slik situasjon, kan det være lurt å ha en liste over tjenestene, beskrivelsene deres og deres status:

# SystemCTL List-Units --Type = Service

Ok, dette problemet er nå løst. Men noen ganger har du en feilmelding du får fra et eksternt system som ditt eget nettsted eller fra en applikasjon på skrivebordet ditt. Så du vil sannsynligvis ønske å søke i et bestemt ord eller setning i loggmeldingen. Siden SystemD V237 er det nå mulig.

I Journalctl er søket tilfelle ufølsomt hvis ordet du søker er i små bokstaver. Så hvis du søker i ordet, vil den også søke i ordport med kapitaliserte bokstaver. Et eksempel:

# JournalCTL--Catalog-Lines = 3000-PAGER-END--GREP = "Port"

Nå, hvis du søker på et ord som CPU, vil det bare søke på CPU med alle kapitaliserte bokstaver, det vil ikke søke CPU.

# Journalctl--Catalog-Lines = 3000-PAGER-END--GREP = "CPU"

Du husker feilmeldingen fra det eksterne systemet? Generelt inneholder disse meldingene en tidsstempel. For å filtrere loggmeldingen, kan det være lurt å bruke den tidsstemplet. JournalCTL kan liste over alle loggmeldinger siden en bestemt dato og klokkeslett med -siden argumentet:

# Journalctl--Catalog--since = "2018-07-30 09:30:00"

Hvis det eksterne systemet er fjernt eller bruker UTC -tidsstempler, vil du filtrere basert på en UTC -dato og tid og vises i terminalen UTC -tidsstemplene slik at du ikke trenger å konvertere det i hodet Virkelig forvirrende. For å gjøre det, må du legge til UTC etter tidsstrengen i -siden argumentet. Du må da legge til -utc -flagget. Så for eksempel:

# Journalctl--Catalog--since = "2018-07-30 10:45:00 UTC" --UTC

Merk at du kan bruke -utc -flagget alene, i dette tilfellet vil det i utgangspunktet vise alle datoer og tider i UTC tidssone.

# JournalCTL--Catalog-Lines = 3000-PAGER-END --UTC

Logger styres bedre med journalctl

Som du kan se med alle tidligere kommandoer, gjør SystemD Journaling filtrering og så feilsøking lettere som du kan velge gjennom alle logglinjer ved hjelp av en enkelt kommando, JournalCTL. Noen av dere visste sannsynligvis eldgamle tider der du måtte åpne hver fil manuelt i /var /log for å ha en generell ide om problemet og hva som har skjedd. Med alle tipsene du har lært her, vil du eie solide verktøy for å se på loggmeldingene dine på den måten du vil ha det.