Τα αρχεία καταγραφής Linux που πρέπει να παρακολουθείτε σε RHEL 9 και 10

Κάθε πρόβλημα σε έναν server Linux αφήνει κάπου ένα ίχνος: μια αποτυχημένη σύνδεση, μια υπηρεσία που δεν ξεκίνησε, μια ενημέρωση πακέτου που άλλαξε μια βιβλιοθήκη, ένας δίσκος που άρχισε να βγάζει σφάλματα. Το να ξέρετε ποιο αρχείο καταγραφής κρατά ποιο ίχνος είναι η διαφορά ανάμεσα σε μια διάγνωση πέντε λεπτών και ένα απόγευμα εικασιών. Αυτός ο οδηγός καλύπτει τα αρχεία καταγραφής που μετρούν σε Red Hat Enterprise Linux 9 και 10, και σε συμβατά συστήματα όπως Oracle Linux, AlmaLinux και Rocky Linux, με τις εντολές που χρησιμοποιούμε για να τα διαβάζουμε.

Δύο μέρη όπου ζουν τα logs σε RHEL: το journal και το /var/log

Σε RHEL 9 και 10 σχεδόν τα πάντα συλλέγονται πρώτα από το systemd-journald. Το journal είναι ένα δομημένο, ευρετηριασμένο αποθετήριο που το διαβάζετε με journalctl. Σε μια τυπική εγκατάσταση, το rsyslog διαβάζει στη συνέχεια το journal και γράφει τα γνωστά αρχεία κειμένου στο /var/log: messages, secure, cron, maillog και boot.log. Κάποιες υπηρεσίες κρατούν ούτως ή άλλως δικά τους αρχεία, ιδίως ο audit daemon, οι web servers, οι βάσεις δεδομένων και το dnf.

Ελέγξτε ότι το rsyslog είναι εγκατεστημένο και τρέχει πριν βασιστείτε στα αρχεία κειμένου. Τα minimal και container images μπορεί να μην το περιλαμβάνουν:

rpm -q rsyslog systemctl status rsyslog # if it is missing: dnf install rsyslog systemctl enable --now rsyslog

Τα περισσότερα αρχεία στο /var/log διαβάζονται μόνο από τον root, οπότε τρέξτε τις παρακάτω εντολές ως root ή με sudo.

Το systemd journal

Το journal είναι το πρώτο μέρος όπου κοιτάτε, γιατί κρατά την έξοδο κάθε systemd unit, του kernel και οτιδήποτε καταγράφει μέσω syslog, όλα με ακριβείς χρονοσφραγίδες και μεταδεδομένα στα οποία μπορείτε να φιλτράρετε.

Εντολές που αξίζει να απομνημονεύσετε

# everything from one service, newest last journalctl -u nginx # follow a service live, like tail -f journalctl -u sshd -f # only errors and worse, from the current boot journalctl -p err -b # warnings and worse from the previous boot (useful after a crash) journalctl -p warning -b -1 # a time window journalctl --since "1 hour ago" journalctl -u php-fpm --since "2026-10-22 08:00" --until "2026-10-22 09:00" # kernel messages only (the replacement for reading a dmesg file) journalctl -k -b # search message text journalctl -u sshd -g "Failed password" # list the boots the journal knows about journalctl --list-boots

Πολλές επιλογές -u μπορούν να συνδυαστούν, κάτι χρήσιμο όταν ένα αίτημα περνά από περισσότερες από μία υπηρεσίες: journalctl -u nginx -u php-fpm --since "10 min ago".

Κάντε το journal μόνιμο

Σε μια προεπιλεγμένη εγκατάσταση RHEL το journal κρατιέται στο /run/log/journal, στη μνήμη, και χάνεται μετά από επανεκκίνηση. Αυτή είναι ακριβώς η στιγμή που το θέλετε περισσότερο. Για να το κρατήσετε στον δίσκο, δημιουργήστε ένα drop-in και επανεκκινήστε το journald:

mkdir -p /etc/systemd/journald.conf.d vi /etc/systemd/journald.conf.d/persistent.conf

[Journal] Storage=persistent SystemMaxUse=2G

systemctl restart systemd-journald journalctl --flush ls -ld /var/log/journal journalctl --disk-usage

Το SystemMaxUse περιορίζει τον χώρο που μπορεί να χρησιμοποιήσει το journal. Επιλέξτε μια τιμή που ταιριάζει στον δίσκο. Μετά την επόμενη επανεκκίνηση, το journalctl --list-boots δείχνει περισσότερες από μία εγγραφές και το journalctl -b -1 δουλεύει.

/var/log/messages: το γενικό αρχείο καταγραφής του συστήματος

Αυτό είναι το αρχείο που τα μαζεύει όλα: εκκινήσεις και τερματισμοί υπηρεσιών, μηνύματα kernel, προειδοποιήσεις hardware και drivers, αλλαγές δικτύου και οτιδήποτε άλλο καταγράφεται σε επίπεδο info ή πάνω και δεν ανήκει στις κατηγορίες mail, ταυτοποίησης ή cron. Είναι το ισοδύναμο σε κείμενο ενός μεγάλου μέρους του journal, και είναι βολικό για grep και για εργαλεία που περιμένουν απλά αρχεία.

tail -f /var/log/messages grep -iE "error|fail|oom" /var/log/messages | tail -50 grep -i "out of memory" /var/log/messages

Μια γραμμή όπως Out of memory: Killed process σημαίνει ότι ο kernel τερμάτισε μια διεργασία επειδή ο server έμεινε από RAM. Η απάντηση είναι να δώσετε στον φόρτο εργασίας περισσότερη μνήμη ή να μειώσετε όσην χρησιμοποιεί (λιγότεροι workers PHP-FPM ή βάσης δεδομένων, μια cache, διόρθωση μιας διαρροής), όχι να κρύψετε το σύμπτωμα.

/var/log/secure: το αρχείο ασφαλείας του Linux για ταυτοποίηση και προνόμια

Κάθε σύνδεση SSH, κάθε αποτυχημένος κωδικός, κάθε sudo και su, και τα μηνύματα PAM καταλήγουν εδώ. Σε RHEL, Oracle Linux, AlmaLinux και Rocky Linux αυτό είναι το αρχείο που παρακολουθείτε για την πρόσβαση στον server.

# failed SSH passwords and the addresses they came from grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head # successful logins grep "Accepted" /var/log/secure # who used sudo, and for what grep "COMMAND=" /var/log/secure

Δύο σχετικά εργαλεία συμπληρώνουν την εικόνα. Το last απαριθμεί τις επιτυχημένες συνδέσεις από το /var/log/wtmp, και το lastb τις αποτυχημένες από το /var/log/btmp. Αν οι λογαριασμοί κλειδώνουν μετά από αποτυχημένες προσπάθειες, το faillock --user alice δείχνει τις προσπάθειες και το faillock --user alice --reset τις καθαρίζει.

/var/log/audit/audit.log: το ίχνος ελέγχου

Το σύστημα audit του Linux καταγράφει γεγονότα σχετικά με την ασφάλεια σε επίπεδο kernel: συνδέσεις, αλλαγές προνομίων, αποφάσεις SELinux και κάθε αρχείο ή κλήση συστήματος που επιλέγετε να παρακολουθείτε. Γράφεται από το auditd και διαβάζεται με ausearch και aureport αντί για grep, γιατί αυτά τα εργαλεία καταλαβαίνουν τη μορφή του.

# summary of everything in the log aureport --summary # failed logins aureport --login --failed # authentication attempts aureport -au # today's events, with numeric IDs turned into names ausearch -ts today -i # failed login events only ausearch -m USER_LOGIN -sv no -i

Παρακολουθήστε τα αρχεία που μετρούν

Οι κανόνες audit σας επιτρέπουν να καταγράφετε κάθε αλλαγή σε ένα ευαίσθητο αρχείο. Βάλτε τους σε ένα αρχείο κάτω από το /etc/audit/rules.d/, για παράδειγμα /etc/audit/rules.d/50-watch.rules:

-w /etc/ssh/sshd_config -p wa -k sshd_config -w /etc/sudoers -p wa -k sudoers -w /etc/sudoers.d/ -p wa -k sudoers -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity

augenrules --load auditctl -l ausearch -k sshd_config -i

Η τελευταία εντολή δείχνει ποιος άλλαξε τη ρύθμιση του SSH, πότε, και με ποιο πρόγραμμα.

Αρνήσεις SELinux

Το RHEL τρέχει με SELinux σε enforcing, και έτσι πρέπει να μείνει. Όταν το SELinux μπλοκάρει κάτι, η άρνηση καταγράφεται ως εγγραφή AVC στο αρχείο audit. Κοιτάξτε εκεί πριν αλλάξετε οτιδήποτε άλλο:

getenforce ausearch -m AVC,USER_AVC -ts recent -i ausearch -m AVC -ts today | audit2why

Για μια εξήγηση σε απλή γλώσσα με προτεινόμενες διορθώσεις, εγκαταστήστε το setroubleshoot και τρέξτε το sealert πάνω στο αρχείο:

dnf install setroubleshoot-server sealert -a /var/log/audit/audit.log

Οι περισσότερες αρνήσεις έχουν απλή αιτία: ένα αρχείο με λάθος ετικέτα (διόρθωση με restorecon -Rv <path>), περιεχόμενο τοποθετημένο σε μη τυπικό κατάλογο (δώστε του ετικέτα με semanage fcontext), ή μια λειτουργία που χρειάζεται ένα boolean ενεργοποιημένο (getsebool -a | grep httpd, μετά setsebool -P). Εξαντλήστε αυτά πριν σκεφτείτε ένα custom policy module.

/var/log/cron: προγραμματισμένες εργασίες

Κάθε εργασία που ξεκινά από το crond και το anacron καταγράφεται εδώ, με τον χρήστη και την εντολή. Όταν ένα backup ή μια αναφορά «δεν έτρεξε», αυτό το αρχείο σας λέει αν ξεκίνησε καν.

grep CROND /var/log/cron | tail -20 grep "(root) CMD" /var/log/cron | tail -20

Πολλές εργασίες συντήρησης του RHEL τρέχουν πλέον ως systemd timers αντί για cron jobs. Απαριθμήστε τους με systemctl list-timers και διαβάστε την έξοδό τους με journalctl -u <name>.service, για παράδειγμα journalctl -u logrotate.service.

/var/log/maillog: παράδοση αλληλογραφίας

Το Postfix και άλλο λογισμικό αλληλογραφίας καταγράφουν εδώ κάθε μήνυμα που δέχονται, προωθούν, αναβάλλουν ή επιστρέφουν. Αν μια web εφαρμογή λέει ότι έστειλε ένα email και κανείς δεν το έλαβε, η απάντηση είναι συνήθως σε αυτό το αρχείο.

# the full path of one message, by recipient grep "user@example.org" /var/log/maillog # bounces and deferrals grep -E "status=(bounced|deferred)" /var/log/maillog | tail -20 # what is still waiting in the queue postqueue -p

Κάθε μήνυμα του Postfix έχει ένα queue ID (για παράδειγμα 4F2A81C0B3E). Κάντε grep για αυτό το ID για να δείτε κάθε βήμα της παράδοσής του, μαζί με την απάντηση του server παραλαβής.

/var/log/dnf.log και dnf history: τι άλλαξε

Όταν κάτι χαλάει μετά από συντήρηση, η πρώτη ερώτηση είναι τι άλλαξε. Σε RHEL 9 και 10 οι λειτουργίες πακέτων γίνονται από το dnf, που γράφει /var/log/dnf.log (η ίδια η εκτέλεση του dnf), /var/log/dnf.rpm.log (κάθε πακέτο που εγκαταστάθηκε, αναβαθμίστηκε ή αφαιρέθηκε) και /var/log/dnf.librepo.log (λήψεις από αποθετήρια). Η γρηγορότερη ματιά είναι η βάση ιστορικού:

# every transaction, newest first dnf history # exactly what one transaction did dnf history info last dnf history info 42 # every transaction that touched a package dnf history list nginx # packages changed recently, from the log file grep -E "Install|Upgrade|Erase" /var/log/dnf.rpm.log | tail -30 # does anything need a restart after updates (dnf-plugins-core) dnf needs-restarting -r

Αν μια ενημέρωση πρέπει να αναιρεθεί, το dnf history undo <id> αναιρεί μία συναλλαγή, εφόσον τα παλαιότερα πακέτα είναι ακόμη διαθέσιμα στα αποθετήρια.

/var/log/boot.log και το journal της εκκίνησης

Το /var/log/boot.log κρατά τα μηνύματα κατάστασης εκκίνησης που θα βλέπατε στην κονσόλα. Είναι χρήσιμο για μια γρήγορη ματιά, αλλά η πλήρης καταγραφή μιας εκκίνησης είναι στο journal:

cat /var/log/boot.log journalctl -b -p err journalctl -b -1 -p err # previous boot, needs the persistent journal systemctl --failed # units that did not start systemd-analyze blame | head # what took longest

Logs web server και PHP

Κάθε web server κρατά τα δικά του access και error logs:

• nginx: /var/log/nginx/access.log και /var/log/nginx/error.log, συν όποια αρχεία ανά site ορίσετε με access_log και error_log.
• Apache httpd: /var/log/httpd/access_log, /var/log/httpd/error_log, και ssl_access_log και ssl_error_log όταν είναι εγκατεστημένο το mod_ssl.
• PHP-FPM: /var/log/php-fpm/error.log για τον FPM master και /var/log/php-fpm/www-error.log για σφάλματα PHP από το προεπιλεγμένο pool. Το pool μπορεί επίσης να γράφει ένα slow log με stack trace κάθε αργού αιτήματος μόλις οριστεί το request_slowlog_timeout.

# top client addresses (default nginx log format) awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head # count of server errors (5xx) by URL awk '$9 ~ /^5/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head # the latest errors tail -50 /var/log/nginx/error.log tail -50 /var/log/php-fpm/www-error.log

Μια έξαρση αποκρίσεων 502 ή 504 στο access log, που συνοδεύεται από «upstream timed out» ή «connect() failed» στο error log του nginx, δείχνει το PHP-FPM: είτε όλοι οι workers ήταν απασχολημένοι είτε ένα script έτρεξε πολλή ώρα.

Logs βάσεων δεδομένων

• MariaDB (η βάση δεδομένων των αποθετηρίων RHEL): /var/log/mariadb/mariadb.log, που ορίζεται με log-error στο /etc/my.cnf.d/mariadb-server.cnf.
• MySQL από τα αποθετήρια RHEL: /var/log/mysql/mysqld.log.
• PostgreSQL: /var/lib/pgsql/data/log/, ένα αρχείο ανά ημέρα της εβδομάδας εξ ορισμού.

Το error log δείχνει προβλήματα εκκίνησης, καταρρεύσεις, αλλοιωμένους πίνακες και σφάλματα replication. Για τις επιδόσεις, ενεργοποιήστε το slow query log. Για MariaDB, προσθέστε στην ενότητα [mysqld] του /etc/my.cnf.d/mariadb-server.cnf και επανεκκινήστε:

slow_query_log = 1 slow_query_log_file = /var/log/mariadb/mariadb-slow.log long_query_time = 1

Μετά συνοψίστε το με mysqldumpslow -s t /var/log/mariadb/mariadb-slow.log | head -40 για να δείτε ποια ερωτήματα κοστίζουν τον περισσότερο συνολικό χρόνο.

Κρατώντας τα logs υπό έλεγχο με το logrotate

Το RHEL περιστρέφει τα αρχεία καταγραφής με το logrotate, που τρέχει μία φορά την ημέρα από έναν systemd timer (logrotate.timer). Οι γενικές προεπιλογές είναι στο /etc/logrotate.conf (εβδομαδιαία, τέσσερις περιστροφές, ονόματα αρχείων με ημερομηνία όπως messages-20261018), και κάθε πακέτο προσθέτει τους δικούς του κανόνες κάτω από το /etc/logrotate.d/. Τα αρχεία του συστήματος (messages, secure, cron, maillog) καλύπτονται από το /etc/logrotate.d/rsyslog.

systemctl list-timers logrotate.timer cat /etc/logrotate.d/nginx # dry run: show what would happen, change nothing logrotate -d /etc/logrotate.d/nginx # force a rotation now, verbosely logrotate -vf /etc/logrotate.d/nginx

Για τη δική σας εφαρμογή, προσθέστε ένα αρχείο όπως /etc/logrotate.d/myapp:

/var/log/myapp/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 myapp myapp postrotate /usr/bin/systemctl reload myapp.service >/dev/null 2>&1 || true endscript }

Κρατήστε τα logs των εφαρμογών κάτω από το /var/log: τα αρχεία εκεί παίρνουν την ετικέτα SELinux που το logrotate επιτρέπεται να διαχειρίζεται. Αν ο κατάλογος των logs είναι εγγράψιμος από χρήστη εκτός του root, προσθέστε μια γραμμή su myapp myapp ώστε το logrotate να μπορεί να τον περιστρέφει με ασφάλεια.

Το journal περιστρέφεται μόνο του μέσα στο όριο SystemMaxUse. Για να το περικόψετε με το χέρι, χρησιμοποιήστε journalctl --vacuum-time=30d ή journalctl --vacuum-size=1G.

Κεντρική συλλογή logs με rsyslog

Τα logs που ζουν μόνο στον server που περιγράφουν έχουν δύο αδυναμίες: πρέπει να συνδεθείτε σε κάθε μηχάνημα για να τα διαβάσετε, και ένας επιτιθέμενος που αποκτά root μπορεί να τα επεξεργαστεί. Η προώθηση των logs κάθε server σε έναν κεντρικό συλλέκτη λύνει και τα δύο, και σας επιτρέπει να ψάχνετε σε ένα μέρος κατά τη διάρκεια ενός περιστατικού. Ο συλλέκτης μπορεί να είναι ένας άλλος server RHEL που τρέχει rsyslog, ή μια πλατφόρμα logs όπως το Graylog.

Στον συλλέκτη

Δημιουργήστε το /etc/rsyslog.d/10-collector.conf. Ακούει στη θύρα TCP 20514, που η πολιτική SELinux ήδη χαρακτηρίζει ως θύρα syslog (ελέγξτε με semanage port -l | grep syslogd), και γράφει ένα αρχείο ανά host και πρόγραμμα:

module(load="imtcp") template(name="RemotePerHost" type="string" string="/var/log/remote/%HOSTNAME:::secpath-replace%/%PROGRAMNAME:::secpath-replace%.log") ruleset(name="remote") { action(type="omfile" dynaFile="RemotePerHost") } input(type="imtcp" port="20514" ruleset="remote")

Ανοίξτε τη θύρα μόνο για τους servers σας, εδώ μέσω της ζώνης internal του firewalld, και μετά επικυρώστε και επανεκκινήστε:

firewall-cmd --permanent --zone=internal --add-source=10.0.10.0/24 firewall-cmd --permanent --zone=internal --add-port=20514/tcp firewall-cmd --reload rsyslogd -N1 systemctl restart rsyslog ss -tlnp | grep 20514

Αν επιλέξετε θύρα που δεν έχει ήδη ετικέτα, προσθέστε την πρώτα με semanage port -a -t syslogd_port_t -p tcp <port>, στον συλλέκτη και στους αποστολείς. Προσθέστε έναν κανόνα logrotate για το /var/log/remote//.log όπως δείξαμε παραπάνω.

Σε κάθε server

Δημιουργήστε το /etc/rsyslog.d/90-central.conf. TCP με ουρά υποβοηθούμενη από δίσκο σημαίνει ότι μια επανεκκίνηση του συλλέκτη ή μια διακοπή δικτύου καθυστερεί τα μηνύματα αντί να τα χάνει:

*.* action(type="omfwd" target="logs.example.net" port="20514" protocol="tcp" template="RSYSLOG_SyslogProtocol23Format" queue.type="LinkedList" queue.filename="fwd_central" queue.maxDiskSpace="1g" queue.saveOnShutdown="on" action.resumeRetryCount="-1")

rsyslogd -N1 systemctl restart rsyslog

Για να στέλνετε και τα γεγονότα audit, ορίστε active = yes στο /etc/audit/plugins.d/syslog.conf και επανεκκινήστε το auditd με service auditd restart (το auditd δεν δέχεται επανεκκίνηση μέσω systemctl).

Αποδείξτε ότι φτάνει

Στείλτε ένα δοκιμαστικό μήνυμα και βρείτε το στον συλλέκτη:

# on the server logger -t logtest "central logging test from $(hostname)" # on the collector tail /var/log/remote/*/logtest.log

Επαναλάβετε τη δοκιμή μετά από κάθε αλλαγή στον συλλέκτη ή στο firewall, και βάλτε ειδοποίηση για σιωπή: ένας server που σταμάτησε να στέλνει logs είναι εύκολο να σας ξεφύγει, γιατί τίποτα μέσα στα logs δεν σας το λέει.

Μια γρήγορη καθημερινή λίστα ελέγχου

• journalctl -p err -b: κάτι νέο σε επίπεδο σφάλματος από την εκκίνηση;
• aureport --login --failed και lastb | head: ασυνήθιστες αποτυχημένες συνδέσεις;
• ausearch -m AVC -ts today: αρνήσεις SELinux;
• dnf history: άλλαξε κάτι που δεν είχατε σχεδιάσει;
• tail /var/log/nginx/error.log και το error log της βάσης δεδομένων: προβλήματα εφαρμογής;
• journalctl --disk-usage και df -h /var/log: χώρος για να συνεχίσετε την καταγραφή;

Η ανάγνωση αυτών παίρνει λίγα λεπτά. Η αυτοματοποίησή τους, μέσω ενός κεντρικού συλλέκτη και ειδοποιήσεων στα μοτίβα που μετρούν, είναι αυτό που μετατρέπει τα logs από αρχείο σε έγκαιρη προειδοποίηση.

Οι μηχανικοί της EuroVPS χτίζουν, λειτουργούν και παρακολουθούν τέτοιες αλυσίδες logs για πελάτες στους managed servers μας.