Siirry suoraan sisältöön

Evästeasetukset

Valitse, mitä evästetyyppejä sallit. Voit muuttaa valintaasi milloin tahansa jokaisen sivun alareunassa olevasta kohdasta Evästeasetukset. Tietosuojaseloste

Välttämättömät

Aina käytössä

Tarvitaan sisäänkirjautumiseen, ostoskorin säilyttämiseen ja valintojesi muistamiseen. Nämä ovat aina käytössä.

Mitkä evästeet?
  • weboke_sessie, weboke_klant, weboke_remember: istuntosi ja sisäänkirjautuneena pysyminen
  • weboke_basket: ostoskorisi
  • wkBtwIncl: hintojen näyttäminen verollisina tai verottomina
  • wok_cookies: evästevalintasi, 12 kuukautta

Mittaa, mikä mainos johtaa käyntiin tai tilaukseen, jotta emme maksa mainoksista, joista ei ole hyötyä.

Mitkä evästeet?
  • Google Ads Google Tag Managerin kautta (_gcl_au, _gcl_aw), enintään 90 päivää
  • OpenAI Ads, mainokset ChatGPT-palvelussa
  • wok_aff: minkä kumppanin kautta tulit meille (kumppaniohjelma), 60 päivää

4,6

Maa ja kieli

Jokaisella maalla on oma sivustonsa, jossa on kyseisen maan hinnat ja ALV.

Näytä

Lokien lukeminen journalctl:llä

Moduuli 6: Palvelut ja lokit · Lukuaika: 11 minuuttia

Tavoite: Tämän oppitunnin jälkeen osaat etsiä journalctl:llä kohdennetusti palvelimesi lokeista (palvelun, prioriteetin ja ajan mukaan), tiedät, missä muut lokitiedostot ovat, ja osaat estää lokeja täyttämästä levyäsi.

Keskeiset käsitteet: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioriteetti (err, warning, info), pysyvä tallennus, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Loki on ensimmäinen todistaja

Kun jokin ei toimi palvelimellasi, syy löytyy lähes aina lokista. Sivusto, joka näyttää virhesivun, palvelu, joka ei käynnisty, varmuuskopio, joka jäi viime yönä tekemättä: palvelin on kirjannut sen ylös. Hyvä ylläpitäjä katsoo ensin lokia ja vasta sen jälkeen alkaa muuttaa asioita.

Nykyaikaisilla Linux-palvelimilla journald (osa systemd:tä) kerää ytimen, systemd:n itsensä ja kaikkien palveluiden viestit yhteen lokiin: journaliin. Luet sitä komennolla journalctl.

Jotta voit lukea kaiken, sinun pitää kuulua ryhmään adm tai systemd-journal tai käyttää komentoa sudo. Ilman näitä oikeuksia näet vain omat viestisi.

Missä se on? Pysyvä vai haihtuva

journald säilyttää journalin jommassakummassa kahdesta paikasta:

  • hakemistossa /var/log/journal/: pysyvä, lokit säilyvät uudelleenkäynnistyksen yli;
  • hakemistossa /run/log/journal/: haihtuva, muistissa, katoaa uudelleenkäynnistyksessä.

Oletusasetus (Storage=auto tiedostossa /etc/systemd/journald.conf) valitsee pysyvän tallennuksen, jos hakemisto /var/log/journal/ on olemassa. Debianissa systemd-paketti luo tämän hakemiston jo Debian 11:stä lähtien, ja myös Ubuntussa se on olemassa. Tarkista asia:

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

Jos näet vain yhden käynnistyskerran, vaikka palvelin on jo käynnistetty uudelleen, lokisi ovat haihtuvia. Luo hakemisto (sudo mkdir -p /var/log/journal ja sudo systemd-tmpfiles --create --prefix /var/log/journal) ja käynnistä journald uudelleen. Tämä on tärkeää: kaatumisen jälkeen haluat nimenomaan tietää, mitä tapahtui ennen uudelleenkäynnistystä.

Debian 12:sta lähtien Debian ei enää asenna rsyslogia oletuksena. Tämä ohjelma kirjoitti aiemmin tekstitiedostoja, kuten /var/log/syslog ja /var/log/auth.log. Uudella Debian-palvelimella niitä ei siis ole, vaan kaikki on journalissa. Ubuntussa rsyslog on vielä mukana. Ohjeet, joissa sanotaan "katso tiedostoa /var/log/auth.log", voit Debianissa kääntää muotoon journalctl -u ssh.

Haku: suodattimet, joita oikeasti käytät

Ilman suodatinta journalctl näyttää kaiken vanhimmasta alkaen. Sitä haluat harvoin. Tärkeimmät suodattimet, joita voit yhdistellä:

SuodatinEsimerkkiMitä
-u <unit>journalctl -u nginxvain kyseinen palvelu
-p <prioriteit>journalctl -p errvain virheet ja sitä vakavammat
--since, --until--since "2026-11-09 03:00" --until "04:00"aikaväli; myös today, yesterday, "1 hour ago"
-bjournalctl -b, journalctl -b -1tämän käynnistyksen jälkeen tai edellinen käynnistys
-fjournalctl -u nginx -fseuraa reaaliajassa (kuten tail -f), lopeta painamalla Ctrl+C
-ejournalctl -u ssh -ehyppää loppuun
-njournalctl -u ssh -n 50viimeiset 50 riviä
-kjournalctl -kvain ytimen viestit
--no-pagerilman selausta, kätevä yhdessä grep:n kanssa

Prioriteetit kulkevat arvosta 0 (emerg) arvoon 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Valinnalla -p err saat err-tason ja kaiken sitä vakavamman. -p warning näyttää myös varoitukset.

Tyypillinen hakupolku. Sivustosi on antanut aamusta asti virheen 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'.

Syy lukee siinä suoraan: kirjoitusvirhe asetustiedoston rivillä 42. Tila 78 (CONFIG) vahvistaa, että kyse on asetusvirheestä. Sinun ei tarvitse arvailla.

Kaksi vinkkiä lukemiseen:

  • Lue ylhäältä alas ja etsi ensimmäinen virhe. Yksi virhe aiheuttaa usein kokonaisen sarjan seurannaisviestejä. Ensimmäinen on yleensä syy.
  • Kiinnitä huomiota aikaan. Mikä muuttui tuon hetken tienoilla? Automaattinen päivitys (oppitunti 4.2: /var/log/unattended-upgrades/), oma muutoksesi, uudelleenkäynnistys?

Muut lokitiedostot

Kaikki ei ole journalissa. Monet ohjelmat kirjoittavat myös (tai pelkästään) omia tiedostojaan hakemistoon /var/log/:

Tiedosto tai hakemistoMitä
/var/log/nginx/access.log ja error.lognginxin jokainen pyyntö ja jokainen virhe
/var/log/apt/history.logmitä apt asensi ja milloin
/var/log/unattended-upgrades/automaattiset päivitykset (oppitunti 4.2)
/var/log/fail2ban.logestot (oppitunti 5.3)
/var/log/mysql/ tai journalMariaDB/MySQL, asetuksista riippuen

Suuria tekstitiedostoja luet komennolla less (haku painamalla /), lopun komennolla tail -n 50, reaaliajassa komennolla tail -f ja suodatat komennolla grep:

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

Docker-konttien lokit eivät ole hakemistossa /var/log vaan Dockerilla itsellään: docker compose logs (oppitunti 9.3).

Lokit eivät saa täyttää levyä

Täysi levy on yksi yleisimmistä syistä siihen, että palvelin "yhtäkkiä" lakkaa toimimasta: tietokannat pysähtyvät, päivitykset epäonnistuvat ja joskus et pääse edes kirjautumaan sisään. Syyllisiä ovat usein lokit.

Journal rajoittaa itse kokoaan. Oletuksena se käyttää enintään 10 % tiedostojärjestelmästä, kuitenkin enintään 4 Gt (SystemMaxUse=). Näin näet, paljonko se nyt käyttää, ja näin siivoat:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # yli 30 päivää vanhat pois
anna@web1:~$ sudo journalctl --vacuum-size=500M    # enintään 500 MB

Jos haluat kiinteän rajan, lisää drop-in-tiedostoon /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

ja käynnistä journald uudelleen komennolla sudo systemctl restart systemd-journald.

Tekstitiedostoja hakemistossa /var/log hoitaa logrotate: joka päivä tai viikko tiedosto nimetään uudelleen (error.log.1), vanhemmat versiot pakataan (.gz) ja vanhimmat poistetaan. Ohjelmakohtaiset säännöt ovat hakemistossa /etc/logrotate.d/. Jakelun paketit tuovat mukanaan oman sääntönsä. Jos oma ohjelmasi tai skriptisi kirjoittaa omaan lokitiedostoon, tee sille itse sääntö, muuten tiedosto kasvaa loputtomiin.

Näin etsit, mikä vie tilaa:

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

Lokit ja tietosuoja

Lokit sisältävät IP-osoitteita, käyttäjänimiä ja joskus sähköpostiosoitteita: ne ovat henkilötietoja. Älä säilytä niitä pidempään kuin on tarpeen (muutamasta viikosta muutamaan kuukauteen on tavallista pienellä palvelimella), älä jätä niitä julkisesti saataville (hakemisto /logs webrootissa on tunnettu virhe) äläkä kopioi niitä noin vain muiden palveluihin.

AlmaLinuxissa ja Rocky Linuxissa

journalctl toimii samalla tavalla. Niissä rsyslog on edelleen oletuksena käytössä, ja tiedostoja ovat esimerkiksi /var/log/messages ja /var/log/secure (vastine tiedostolle auth.log). SELinuxin viestit ovat tiedostossa /var/log/audit/audit.log; ausearch -m avc -ts recent näyttää viimeaikaiset estot.

Yhteenveto

  • journald kerää kaikki viestit journaliin; lue sitä komennolla journalctl ja suodata palvelun (-u), prioriteetin (-p), ajan (--since) ja käynnistyksen (-b) mukaan.
  • Tarkista, että journal on pysyvä (/var/log/journal on olemassa), muuten menetät lokisi uudelleenkäynnistyksessä.
  • Debian 12:ssa ja uudemmissa ei ole oletuksena rsyslogia eikä siis tiedostoja /var/log/auth.log ja /var/log/syslog; kaikki on journalissa.
  • Etsi ensimmäinen virhe ja katso, mikä muuttui tuon hetken tienoilla.
  • Seuraa kokoa: journal rajoittaa itse kokoaan (--disk-usage, --vacuum-*), tekstitiedostot hoitaa logrotate.

Tietovisa (quiz)

1. Mikä komento näyttää vain nginxin tämänpäiväiset virheet?



2. Palvelimesi käynnistettiin viime yönä uudelleen kaatumisen jälkeen. journalctl -b -1 antaa viestin "Specifying boot ID or boot offset has no effect, no persistent journal was found". Mitä se tarkoittaa?



3. Ohjeen mukaan epäonnistuneet SSH-kirjautumiset löytyvät tiedostosta /var/log/auth.log, mutta uudella Debian 13 -palvelimellasi tiedostoa ei ole. Mistä katsot?



4. Lokissa on kaksikymmentä virheilmoitusta peräkkäin. Mistä aloitat?



5. Levysi on täynnä, ja journalctl --disk-usage kertoo 400 Mt. Mikä on paras seuraava askel?



Tehtävä

Tehtävä Z6.2: Kaatuvan palvelun selvittäminen. Esimerkkitiedostossa journal-crash-1.txt on komentojen systemctl status ja journalctl tuloste palvelusta, joka käynnistyy yhä uudelleen ja lopulta luovuttaa. Vastaa: mikä palvelun nimi on, kuinka monta kertaa systemd yritti käynnistää sen, millä poistumiskoodilla se pysähtyi, mikä on syy ensimmäisen virheilmoituksen mukaan ja mihin aikaan systemd luovutti? Ohjelma vertaa vastauksiasi kiinteään avaimeen. Katso sen jälkeen omalla palvelimellasi, näyttääkö journalctl -p err -b virheitä ja onko journalisi pysyvä.

Tehtävä Z6.2: Kaatuvan palvelun selvittäminen

Tähän tehtävään liittyvä tiedosto: journal-crash-1.txt







Sitä, mitä kirjoitat ja mitä löydämme, ei tallenneta. Selaimesi muistaa vastauksesi ja sen, oletko suorittanut tehtävän. Jos olet kirjautunut sisään, tallennamme kohtaan Omat kurssit vain sen, että tehtävä oli (lähes) oikein; voit poistaa sen myös sieltä.

Lue lisää

Hetkinen…

Määritä verkkotunnuksesi

Määritä kullekin verkkotunnukselle nimipalvelimet, liitos webhotelliin ja se, kuka tulee omistajaksi.

Ladataan verkkotunnuksia…