Pereiti prie turinio

Slapukų nustatymai

Pasirinkite, kokių rūšių slapukus leidžiate. Pasirinkimą bet kada galite pakeisti per „Slapukų nustatymai“ kiekvieno puslapio apačioje. Privatumo pareiškimas

Būtinieji

Visada įjungti

Reikalingi prisijungti, išsaugoti krepšelį ir įsiminti Jūsų pasirinkimus. Jie visada įjungti.

Kokie slapukai?
  • weboke_sessie, weboke_klant, weboke_remember: Jūsų sesija ir prisijungimo išlaikymas
  • weboke_basket: Jūsų krepšelis
  • wkBtwIncl: kainų rodymas su PVM arba be PVM
  • wok_cookies: Jūsų slapukų pasirinkimas, 12 mėnesių

Matuoja, kuri reklama atveda prie apsilankymo ar užsakymo, kad nemokėtume už neveiksmingas reklamas.

Kokie slapukai?
  • Google Ads per Google Tag Manager (_gcl_au, _gcl_aw), iki 90 dienų
  • OpenAI Ads, reklamos ChatGPT
  • wok_aff: per kurį partnerį atėjote pas mus (partnerių programa), 60 dienų

4,6

Šalis ir kalba

Kiekviena šalis turi savo svetainę su tos šalies kainomis ir PVM.

Peržiūrėti

Žurnalų skaitymas su journalctl

6 modulis: Paslaugos ir žurnalai · Skaitymo laikas: 11 min.

Mokymosi tikslas: Po šios pamokos galėsite su journalctl tikslingai ieškoti savo serverio žurnaluose (pagal paslaugą, prioritetą ir laiką), žinosite, kur yra kiti žurnalų failai, ir neleisite žurnalams užpildyti disko.

Pagrindinės sąvokos: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritetas (err, warning, info), nuolatinis saugojimas, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Žurnalas kaip pirmasis liudytojas

Jei kažkas Jūsų serveryje neveikia, priežastis beveik visada yra įrašyta žurnale. Svetainė, rodanti klaidos puslapį, paslauga, kuri nepasileidžia, atsarginė kopija, kuri šiąnakt nebuvo padaryta: serveris visa tai užrašė. Geras administratorius pirmiausia pažiūri į žurnalą ir tik po to ką nors keičia.

Šiuolaikiniuose Linux serveriuose journald (systemd dalis) surenka branduolio, paties systemd ir visų paslaugų pranešimus į vieną žurnalą: journal. Jį skaitote su journalctl.

Kad galėtumėte skaityti viską, turite priklausyti grupei adm arba systemd-journal arba naudoti sudo. Be šių teisių matysite tik savo pranešimus.

Kur jis saugomas? Nuolatinis ar laikinas

journald saugo journal vienoje iš dviejų vietų:

  • /var/log/journal/: nuolatinis, žurnalai išlieka po paleidimo iš naujo;
  • /run/log/journal/: laikinas, atmintyje, dingsta po paleidimo iš naujo.

Numatytasis nustatymas (Storage=auto faile /etc/systemd/journald.conf) pasirenka nuolatinį saugojimą, jei katalogas /var/log/journal/ egzistuoja. Debian sistemoje systemd paketas šį katalogą sukuria jau nuo Debian 11, Ubuntu jis taip pat yra. Patikrinkite:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Jei matote tik vieną paleidimą, nors serveris jau buvo paleistas iš naujo, Jūsų žurnalai yra laikini. Sukurkite katalogą (sudo mkdir -p /var/log/journal ir sudo systemd-tmpfiles --create --prefix /var/log/journal) ir iš naujo paleiskite journald. Tai svarbu: po strigties norėsite žinoti būtent tai, kas vyko prieš paleidimą iš naujo.

Nuo Debian 12 rsyslog nebėra diegiamas pagal numatytuosius nustatymus. Ši programa anksčiau rašė tekstinius failus, tokius kaip /var/log/syslog ir /var/log/auth.log. Naujame Debian serveryje jų nėra, viskas yra journal. Ubuntu rsyslog vis dar turi. Instrukcijas, kuriose sakoma "žiūrėkite /var/log/auth.log", Debian sistemoje galite pakeisti į journalctl -u ssh.

Paieška: filtrai, kuriuos tikrai naudosite

Be filtro journalctl rodo viską, pradedant nuo seniausio įrašo. Retai to norite. Svarbiausi filtrai, kuriuos galite derinti:

FiltrasPavyzdysKą daro
-u <unit>journalctl -u nginxtik ta paslauga
-p <prioriteit>journalctl -p errtik klaidos ir rimtesni įvykiai
--since, --until--since "2026-11-09 03:00" --until "04:00"laikotarpis; taip pat today, yesterday, "1 hour ago"
-bjournalctl -b, journalctl -b -1nuo šio paleidimo arba ankstesnis paleidimas
-fjournalctl -u nginx -fstebėti tiesiogiai (kaip tail -f), sustabdyti su Ctrl+C
-ejournalctl -u ssh -eperšokti į pabaigą
-njournalctl -u ssh -n 50paskutinės 50 eilučių
-kjournalctl -ktik branduolio pranešimai
--no-pagerbe puslapiavimo, patogu su grep

Prioritetai eina nuo 0 (emerg) iki 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Su -p err gaunate err ir viską, kas rimčiau. -p warning rodo ir įspėjimus.

Tipiškas paieškos kelias. Jūsų svetainė nuo šio ryto rodo klaidą 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Priežastis parašyta pažodžiui: rašybos klaida konfigūracijos failo 42 eilutėje. Būsena 78 (CONFIG) patvirtina, kad tai konfigūracijos klaida. Nieko spėlioti nereikia.

Du patarimai skaitant:

  • Skaitykite iš viršaus į apačią ir ieškokite pirmosios klaidos. Viena klaida dažnai sukelia visą seką tolesnių pranešimų. Pirmoji paprastai ir yra priežastis.
  • Atkreipkite dėmesį į laiką. Kas pasikeitė apie tą laiką? Automatinis atnaujinimas (pamoka 4.2: /var/log/unattended-upgrades/), Jūsų atliktas pakeitimas, paleidimas iš naujo?

Kiti žurnalų failai

Ne viskas yra journal. Daug programų taip pat (arba tik) rašo savo failus kataloge /var/log/:

Failas arba katalogasKas jame
/var/log/nginx/access.log ir error.logkiekviena nginx užklausa ir klaida
/var/log/apt/history.logką ir kada įdiegė apt
/var/log/unattended-upgrades/automatiniai atnaujinimai (pamoka 4.2)
/var/log/fail2ban.logblokavimai (pamoka 5.3)
/var/log/mysql/ arba journalMariaDB/MySQL, priklausomai nuo nustatymų

Didelius tekstinius failus skaitote su less (paieška su /), pabaigą su tail -n 50, tiesiogiai su tail -f, o filtruojate su grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Docker konteinerių žurnalai yra ne /var/log, o pačiame Docker: docker compose logs (pamoka 9.3).

Žurnalai neturi užpildyti disko

Pilnas diskas yra viena dažniausių priežasčių, kodėl serveris "staiga" nustoja veikti: duomenų bazės sustoja, atnaujinimai nepavyksta, kartais net nebegalite prisijungti. Dažnai kalti būna žurnalai.

Journal pats save riboja. Pagal numatytuosius nustatymus jis naudoja ne daugiau kaip 10% failų sistemos, daugiausia 4 GB (SystemMaxUse=). Kiek jis naudoja dabar ir kaip išvalyti:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # senesni nei 30 dienų šalinami
anna@web1:~$ sudo journalctl --vacuum-size=500M    # iki 500 MB

Jei norite fiksuotos ribos, įrašykite ją į drop-in failą /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

ir iš naujo paleiskite journald su sudo systemctl restart systemd-journald.

Tekstinius failus kataloge /var/log prižiūri logrotate: kiekvieną dieną ar savaitę failas pervadinamas (error.log.1), senesnės versijos suspaudžiamos (.gz), o seniausios ištrinamos. Kiekvienos programos taisyklės yra /etc/logrotate.d/. Distribucijos paketai atsineša savo taisykles. Jei Jūsų pačių programa ar scenarijus rašo į atskirą žurnalo failą, sukurkite taisyklę patys, kitaip failas augs be galo.

Kaip rasti, kas užima vietą:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Žurnalai ir privatumas

Žurnaluose yra IP adresų, naudotojų vardų ir kartais el. pašto adresų: tai asmens duomenys. Nesaugokite jų ilgiau nei reikia (mažam serveriui įprasta nuo kelių savaičių iki kelių mėnesių), nepalikite jų viešai prieinamų (katalogas /logs Jūsų svetainės šakniniame kataloge yra žinoma klaida) ir nekopijuokite jų be priežasties į kitų tiekėjų paslaugas.

AlmaLinux ir Rocky Linux sistemose

journalctl veikia taip pat. Ten rsyslog vis dar įjungtas pagal numatytuosius nustatymus, su tokiais failais kaip /var/log/messages ir /var/log/secure (auth.log atitikmuo). SELinux pranešimai yra /var/log/audit/audit.log; ausearch -m avc -ts recent rodo naujausius atmetimus.

Santrauka

  • journald surenka visus pranešimus į journal; skaitykite jį su journalctl, filtruodami pagal paslaugą (-u), prioritetą (-p), laiką (--since) ir paleidimą (-b).
  • Patikrinkite, ar journal yra nuolatinis (/var/log/journal egzistuoja), kitaip po paleidimo iš naujo prarasite žurnalus.
  • Debian 12 ir naujesnės versijos pagal numatytuosius nustatymus neturi rsyslog, todėl nėra ir /var/log/auth.log bei /var/log/syslog; viskas yra journal.
  • Ieškokite pirmosios klaidos ir žiūrėkite, kas pasikeitė apie tą laiką.
  • Stebėkite dydį: journal pats save riboja (--disk-usage, --vacuum-*), tekstinius failus tvarko logrotate.

Testas (quiz)

1. Kuri komanda rodo tik šiandienos nginx klaidas?



2. Jūsų serveris šiąnakt buvo paleistas iš naujo po strigties. journalctl -b -1 pateikia "Specifying boot ID or boot offset has no effect, no persistent journal was found". Ką tai reiškia?



3. Instrukcijoje sakoma, kad nepavykusius SSH prisijungimus rasite /var/log/auth.log, tačiau Jūsų naujame Debian 13 serveryje šio failo nėra. Kur žiūrėsite?



4. Žurnale yra dvidešimt klaidų pranešimų iš eilės. Nuo kurio pradėsite?



5. Jūsų diskas pilnas, o journalctl --disk-usage rodo 400 MB. Koks geriausias tolesnis žingsnis?



Užduotis

Užduotis Z6.2: Strigusios paslaugos analizė. Pavyzdiniame faile journal-crash-1.txt yra paslaugos, kuri vis iš naujo pasileidžia ir galiausiai pasiduoda, systemctl status ir journalctl išvestis. Atsakykite: kaip vadinasi paslauga, kiek kartų systemd bandė ją paleisti, kokiu išėjimo kodu ji sustojo, kokia priežastis pagal pirmąjį klaidos pranešimą ir kelintą valandą systemd pasidavė? Programa palygina atsakymus su nustatytu raktu. Po to savo serveryje patikrinkite, ar journalctl -p err -b rodo klaidų ir ar Jūsų journal yra nuolatinis.

Užduotis Z6.2: Strigusios paslaugos analizė

Failas šiai užduočiai: journal-crash-1.txt







Ko, ką įvedate ir ką randame, nesaugome. Jūsų naršyklė atsimena Jūsų atsakymus ir tai, ar užduotį atlikote. Jei esate prisijungę, skiltyje Mano kursai išsaugome tik tai, kad užduotis buvo atlikta (ar beveik atlikta); ten tai galite ir pašalinti.

Skaitykite daugiau

Akimirką…

Nustatykite domenus

Kiekvienam domenui nustatykite vardų serverius, susiejimą su talpinimu ir tai, kas taps valdytoju.

Įkeliami Jūsų domenai…