Mga log sa Linux: journalctl, /var/log, rsyslog, at logrotate

Kapag bumagsak ang serbisyo sa gabi, kadalasan nasa mga log ang sagot — ang tanong ay kung saan ito hahanapin. Sa mga modernong distribusyon (Ubuntu, Debian, RHEL, Fedora, Arch), kinokolekta ng serbisyong journald ang mga event, at binabasa ang mga ito gamit ang command na journalctl. Kasabay nito, maraming programa ang nagsusulat ng ordinaryong text file sa /var/log, at binabantayan ng logrotate ang laki ng mga ito. Narito ang praktikal na paggamit ng journalctl logs linux, kung nasaan ang iba pang log, at kung paano hindi mawala ang mahalagang datos sa rotation.

Saan nakalagay ang mga log sa Linux

Tatlong pinagmulan ang mayroon, at makatutulong na tandaan ang mga ito bilang mapa:

• journald — binaryong log ng systemd. Tumatanggap ng stdout at stderr ng lahat ng serbisyo, mga mensahe ng kernel, at syslog. Nakalagay sa /var/log/journal/ (permanente) o /run/log/journal/ (hanggang sa reboot).
• /var/log — mga text file. Isinusulat ng rsyslog (halimbawa, /var/log/syslog, /var/log/auth.log) o ng mga application mismo: nginx, PostgreSQL, MySQL.
• Ring buffer ng kernel — mga mensahe ng driver at hardware, ipinapakita ng dmesg o journalctl -k.

Karamihan ng file sa /var/log ay nababasa lang ng root o ng grupong adm, kaya madalas kailangang patakbuhin ang mga command sa pagbasa gamit ang sudo.

journalctl: mga pangunahing command

Kapag walang argumento, ipinapakita ng journalctl ang buong log mula sa pinakalumang entry, sa pamamagitan ng pager na less. Bihira itong kailanganin — kadalasan agad itong pinaliliit.

journalctl              # buong log, mula sa luma hanggang bago
journalctl -e           # bukas agad sa dulo
journalctl -n 50        # huling 50 linya
journalctl -r           # baligtad na ayos, bago sa itaas
journalctl --no-pager   # walang less, maganda para sa mga script at grep

Sa loob ng pager, gumagana ang mga karaniwang key ng less: / — paghahanap, G — sa dulo, q — lumabas. Pinuputol ang mahahabang linya ayon sa lapad ng screen; ang mga arrow sa kaliwa at kanan ay nagsi-scroll sa mga ito.

Mga log ng partikular na serbisyo: journalctl -u

Ang pinakakaraniwang senaryo ay tingnan ang isinulat ng isang systemd unit. Hindi na kailangang hanapin ang file at i-grep ito:

$ sudo journalctl -u nginx -n 20
Oct 14 03:12:41 web1 systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 03:12:41 web1 nginx[1834]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Failed with result 'exit-code'.

Maaaring ulitin ang flag na -u: ang journalctl -u nginx -u php8.2-fpm ay magpapakita ng dalawang serbisyo na magkahalo ayon sa oras, kapaki-pakinabang kapag nangyayari ang error sa pagitan nila. Para sa user unit (systemctl --user), gamitin ang journalctl --user -u pangalan.

Mga log sa real time: journalctl -f

sudo journalctl -u nginx -f

Katumbas ito ng tail -f: ipinapakita nito ang huling 10 entry at naghihintay ng bago. Kapaki-pakinabang na hawakan ito sa hiwalay na terminal habang nire-restart ang serbisyo o ginagaya ang error. Lumabas gamit ang Ctrl+C.

Mga filter ayon sa oras at boot

Kung alam mo kung kailan nangyari ang aberya, pumili ng saklaw ng oras gamit ang --since at --until. Tumatanggap ang mga ito ng eksaktong petsa at mga kamag-anak na halaga:

journalctl --since "2026-10-14 02:50" --until "2026-10-14 03:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u nginx --since "10 min ago"

Ang pangalawang kapaki-pakinabang na hiwa ay ayon sa boot ng sistema. Kung kusang nag-reboot ang server, hinahanap ang sanhi sa dulo ng nakaraang session:

$ journalctl --list-boots
 -2 8f1c...  Sat 2026-10-12 09:01:12 UTC  Sun 2026-10-13 22:47:03 UTC
 -1 a7d2...  Sun 2026-10-13 22:48:30 UTC  Tue 2026-10-14 03:05:51 UTC
  0 c3e9...  Tue 2026-10-14 03:07:02 UTC  Tue 2026-10-14 09:15:40 UTC

$ journalctl -b -1 -e      # dulo ng nakaraang boot
$ journalctl -b            # boot na ito lang

Available lang ang listahan ng boot kung nakalagay sa disk ang journal. Paano ito i-enable, nasa seksyon sa ibaba tungkol sa configuration ng journald.

Filter ayon sa kalubhaan: journalctl -p

May priority ng syslog ang bawat entry, mula 0 hanggang 7. Ipinapakita ng flag na -p ang tinukoy na antas at ang mas mahalaga pa rito:

journalctl -p err -b              # lahat ng error mula sa simula ng boot
journalctl -p warning..err -u ssh # saklaw ng antas para sa isang serbisyo

Ang journalctl -p err -b ay magandang unang pagsusuri pagkatapos ng reboot o update: sa loob ng ilang segundo, makikita kung ano ang pumalpak.

Paghahanap at iba pang filter

Nagtatago ang journald ng mga structured field sa bawat entry, at maaaring i-filter ayon sa mga ito nang hindi kailangan ng grep:

journalctl _PID=1834                 # ayon sa numero ng proseso
journalctl _COMM=sshd                # ayon sa pangalan ng programa
journalctl _UID=1000                 # ayon sa user
journalctl /usr/sbin/sshd            # ayon sa path ng executable
journalctl -k                        # mga mensahe ng kernel lang (tulad ng dmesg)
journalctl -t CRON                   # ayon sa syslog identifier
journalctl -g "Out of memory"        # paghahanap sa teksto, regular expression

Lumitaw ang flag na -g (--grep) sa systemd 237; sa mas lumang sistema, gamitin ang karaniwang pipeline na journalctl --no-pager | grep .... Ang mga filter sa iba't ibang field ay pinagsasama gamit ang “AT”, kaya ang journalctl -u nginx -p err --since today ay magbabalik lang ng error ng nginx ngayong araw.

Mga format ng output

Binabago ng flag na -o ang format. Ang pinakakapaki-pakinabang:

• -o short-iso — oras sa ISO 8601, madaling ikumpara sa log ng application.
• -o verbose — lahat ng field ng entry, kasama ang _SYSTEMD_UNIT, _PID, _BOOT_ID.
• -o json o json-pretty — para sa pagproseso ng script o jq.
• -o cat — teksto ng mensahe lang, walang petsa at host.

journalctl -u myapp -o json --since today | jq -r '.MESSAGE'

Pag-configure ng journald: storage at laki

Nasa /etc/systemd/journald.conf ang mga setting (mas mabuting ilagay ang mga override sa /etc/systemd/journald.conf.d/*.conf). Pangunahing parameter ang Storage:

• persistent — isinusulat ang journal sa disk sa /var/log/journal at nananatili pagkatapos ng reboot.
• volatile — nasa memorya lang, sa /run/log/journal.
• auto (default) — sa disk kung umiiral ang direktoryong /var/log/journal.

Sa ilang minimal na image, walang direktoryong iyon, kaya nawawala ang kasaysayan pagkatapos ng reboot. Para i-enable ang permanenteng imbakan:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Para hindi kainin ng journal ang buong disk, magtakda ng limitasyon:

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

Ang default na SystemMaxUse ay 10% ng laki ng file system, pero hindi lalampas sa 4 GB.

Paano linisin ang journalctl

$ journalctl --disk-usage
Archived and active journals take up 1.8G in the file system.

sudo journalctl --vacuum-size=300M   # panatilihin ang hindi lalampas sa 300 MB
sudo journalctl --vacuum-time=2weeks # burahin ang mga entry na mas matanda sa dalawang linggo
sudo journalctl --rotate             # isara ang mga aktibong file para mabura rin ang mga ito

Huwag burahin ang mga file sa /var/log/journal gamit ang rm: ginagawa ng vacuum ang parehong bagay nang maingat at hindi ginagalaw ang aktibong file.

rsyslog: klasikong text log

rsyslog ay daemon na tumatanggap ng mga mensaheng syslog (kasama ang mga ipinasa mula sa journald) at inihihiwalay ang mga ito sa mga file ayon sa mga panuntunan. Nasa /etc/rsyslog.conf at /etc/rsyslog.d/*.conf ang configuration. Binubuo ang panuntunan ng selector na pinagmulan.antas at ng aksyon:

# /etc/rsyslog.d/50-default.conf (bahagi)
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.*                 -/var/log/kern.log

Ang gitling sa unahan ng path ay nangangahulugang hindi isi-sync sa disk pagkatapos ng bawat linya — mas mabilis, pero sa aberya, maaaring mawala ang huling mga linya. Pagkatapos baguhin ang configuration, suriin ang syntax at i-restart ang serbisyo:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Ang pangunahing dahilan kung bakit hawak pa ang rsyslog kasabay ng journald ay ang pagpapasa ng log sa central server. Isang linya lang ang kailangan para maipadala ang lahat sa pamamagitan ng TCP:

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.example.com:514

Ang isang @ ay UDP, at ang dalawang @@ ay TCP. Kung tuluyang bumagsak ang server, nananatili ang kopya ng mga log sa ibang makina. Para isulat ang sarili mong mensahe sa system log mula sa script, gamitin ang logger:

logger -t backup -p user.err "Hindi nagtagumpay ang backup ng database"
journalctl -t backup -n 5

logrotate: pag-rotate ng mga log

Walang katapusang lumalaki ang mga text log hangga't walang nagpuputol sa mga ito. Ito ang gawain ng logrotate: isang beses kada araw (sa pamamagitan ng cron o ng logrotate.timer), pinapalitan nito ang pangalan ng kasalukuyang file, kinokompres ang mga luma, at tinatanggal ang pinakamatatanda. Pangkalahatang setting ang /etc/logrotate.conf, at mga panuntunan ng bawat programa ang nasa /etc/logrotate.d/.

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Para subukan ang panuntunan nang hindi binabago ang anuman, at para puwersahing patakbuhin ang rotation:

sudo logrotate -d /etc/logrotate.d/myapp   # tuyong pagtakbo na may debug
sudo logrotate -f /etc/logrotate.d/myapp   # i-rotate ngayon din

Karaniwang pagkakamali ang paglimot sa postrotate o copytruncate. Kapag nangyari ito, patuloy na sumusulat ang application sa pinalitan-pangalang app.log.1 gamit ang lumang descriptor, at nananatiling walang laman ang bagong app.log.

Pagbasa ng mga text log

Para sa mga file sa /var/log, sapat na ang mga karaniwang utility:

sudo tail -n 100 /var/log/syslog          # huling mga linya
sudo tail -F /var/log/nginx/error.log     # sundan, kahit mapalitan ng rotation
sudo less +G /var/log/auth.log            # bukas sa dulo
sudo zgrep "Failed password" /var/log/auth.log.*.gz   # paghahanap sa mga naka-compress na archive
sudo grep -c " 500 " /var/log/nginx/access.log        # ilang sagot na 500

Pansinin ang tail -F na malaking F: hindi tulad ng -f, muli nitong binubuksan ang file kapag pinalitan ito ng logrotate.

Hakbang-hakbang na pagsusuri ng aberya

Kapag “bumagsak ang serbisyo sa gabi”, makatutulong sundin ang ganitong pagkakasunod-sunod:

1. systemctl status myapp — kasalukuyang estado at mga huling linya ng log.
2. journalctl -u myapp --since "03:00" --until "03:30" — ano ang isinulat ng serbisyo noong bumagsak.
3. journalctl -p err -b — may iba bang error sa sistema sa parehong oras.
4. journalctl -k --since "03:00" -g "Out of memory|Killed process" — pinatay ba ng OOM killer ng kernel ang proseso.
5. Mga log ng application mismo sa /var/log/myapp/, kasama ang mga .gz na archive.
6. Kung nag-reboot ang server — journalctl -b -1 -e.

Buod

Para sa araw-araw na pagtatrabaho sa mga log sa Linux, sapat na ang ilang command: journalctl -u para sa serbisyo, -f para sa daloy, --since at -p err para paliitin ang resulta, at -b -1 para sa pagsusuri ng reboot. Nasa /var/log ang mga text journal, inihihiwalay at ipinapasa ng rsyslog, at ang logrotate at journalctl --vacuum-* ang pumipigil na kainin ng mga log ang disk. Ang paggamit ng journalctl, rotation, at diagnosis ng load ay tinalakay nang praktikal sa aralin ng kurso sa Linux.