Για τα αρχεία καταγραφής με το journald

Θα μπω αμέσως στο ζουμί. Μια από τις μεγαλύτερες κριτικές απέναντι στο systemd είναι το ότι χρησιμοποιεί δυαδικά αρχεία για την αποθήκευση των αρχείων καταγραφής. Που είναι το πρόβλημα σε αυτό; Μα το ότι παραβιάζει την “φιλοσοφία του UNIX”. Ναι είναι αληθές αυτό. Αλλά η ερώτηση είναι “Και που ακριβώς είναι το πρόβλημα;”

Τόσο το gnome όσο και το kde εδώ και πολλά χρόνια χρησιμοποιούν δυαδικά αρχεία για την αποθήκευση των ρυθμίσεων. Αυτό και αν παραβιάζει την “φιλοσοφία του UNIX”, αλλά είδατε κανέναν να ξηλώνει το gnome ή να λέει ότι είναι κακό για αυτόν το λόγο; Για να αλλάξεις μια ρύθμιση από το τερματικό θα χρησιμοποιήσεις το gsettings ή θα χρησιμοποιήσεις το control panel. Και κανένας δεν ρωτά αν οι ρυθμίσεις είναι αποθηκευμένες σε αρχεία κειμένου ή σε δυαδικά αρχεία. Οπότε θα επαναλάβω την ερώτηση “Που ακριβώς είναι το πρόβλημα;” Ο τρόπος αποθήκευσης είναι στην τελική απλά μια μικρή τεχνική λεπτομέρεια.

Ο παραδοσιακός τρόπος

Καλύτερο νομίζω είναι να καταλάβουμε πρώτα γιατί έγινε αυτή η σχεδιαστική επιλογή. Εδώ και 40+ χρόνια τα αρχεία καταγραφής τα αναλαμβάνει μια υπηρεσία συστήματος που αν και έχουμε περάσει από πολλά διαφορετικά προγράμματα που την υλοποιούν ο τρόπος παραμένει ακριβώς ίδιος. Και παρότι πέρασαν τόσες δεκαετίες δεν έχει συμφωνηθεί μια προδιαγραφή για την μορφή των μηνυμάτων.

Αν είχαμε αυτόν τον τρόπο για τόσα χρόνια και δούλευε, τότε γιατί θα πρέπει να τον αλλάξεις; Γιατί ειδικά στον κόσμο των servers τα αρχεία καταγραφής είναι μια σοβαρή υπόθεση. Στο παρελθόν τα αρχεία καταγραφής ήταν σχεδόν άδεια. Κατέγραφαν που και που την είσοδο και την έξοδο κάποιου χρήστη, για να του στείλουν τον λογαριασμό.

Ένα παλιό μου άρθρο εξηγεί κάποια πράγματα για το πως δουλεύει η υπηρεσία syslog σταματήστε την ανάγνωση και ρίξτε του πρώτα μια ματιά.

Το syslog θα συγκεντρώσει τα μηνύματα και θα τα σπάσει σε μικρότερα αρχεία. Τα αρχεία αυτά μεγαλώνουν συνεχώς σε μέγεθος και θέλεις μια δεύτερη υπηρεσία την logrotate να τα συμμαζεύει. Και σε ένα server θα τα βάλεις σε διαφορετική κατάτμηση γιατί ένας κακόβουλος μπορεί να σου γεμίσει το σύστημα με καταγραφές και να βγάλει εκτός λειτουργίας τον υπολογιστή. Για να στήσω μια υπηρεσία θα πρέπει να φτιάξω μια ρύθμιση στο syslog ώστε να μεταφέρει την πληροφορία στο κατάλληλο αρχείο. Και στην συνέχεια να ενημερώσω το logrotate για αυτά τα αρχεία. Και δεν κάνουν όλα τα προγράμματα χρήση της υπηρεσίας και θα πρέπει να τα ρυθμίσω επίσης ξεχωριστά. Ή εντολή sudo ls -lR |wc -l μου δείχνει 348 αρχεία καταγραφής.

Για να βρω την πληροφορία θα πρέπει να χρησιμοποιήσω τις αργές εντολές grep,cat,awk.

Γιατί δυαδικά αρχεία;

Ας δούμε μια απλή καταγραφή από την υπηρεσία syslog

Jul  6 22:20:41 Minty ananicy[1003]: renice: cinnamon[2192/72455] 0 -> -10

Ας δούμε τώρα όλα τα στοιχεία της καταγραφής στο journald

{
  "MESSAGE": "renice: cinnamon[2192/72455] 0 -> -10",
  "__CURSOR": "s=161c00174fec451f936425deae749f1b;i=3d6bb;b=f31c7b70ff3b47548e4048ce158b1da1;m=77413df0;t=5a9c9ec54eeab;x=de6c29ed502e5a29",
  "_PID": "1003",
  "__MONOTONIC_TIMESTAMP": "2000764400",
  "_BOOT_ID": "f31c7b70ff3b47548e4048ce158b1da1",
  "_SYSTEMD_UNIT": "ananicy.service",
  "_EXE": "/usr/bin/python3.8",
  "_STREAM_ID": "73e8711416114419a4ea4dde1171e7af",
  "_CAP_EFFECTIVE": "3fffffffff",
  "_HOSTNAME": "Minty",
  "SYSLOG_FACILITY": "3",
  "_TRANSPORT": "stdout",https://cerebrux.net/2020/04/22/%cf%80%cf%89%cf%82-%ce%b2%ce%bb%ce%ad%cf%80%cf%89-logs-linux-journalctl/
  "_MACHINE_ID": "b76cc7b1bbdc489e93909d2043031de8",
  "PRIORITY": "6",
  "_SYSTEMD_SLICE": "system.slice",
  "SYSLOG_IDENTIFIER": "ananicy",
  "_GID": "0",
  "_SYSTEMD_CGROUP": "/system.slice/ananicy.service",
  "__REALTIME_TIMESTAMP": "1594059602063019",
  "_SELINUX_CONTEXT": "unconfined\n",
  "_COMM": "python3",
  "_SYSTEMD_INVOCATION_ID": "f5e183b3fca24f429c4955c58171acf2",
  "_UID": "0",
  "_CMDLINE": "python3 /usr/bin/ananicy start"
}

Βλέπουμε ένα μεγάλο και τυποποιημένο σύνολο πληροφοριών. Τώρα θέλω από ένα μεγάλο σύνολο να βρω αυτές που με ενδιαφέρουν. Ποιος είναι ο ποιο αποδοτικός τρόπος να το κάνω αυτό; Σίγουρα δεν είναι η grep. Μια μορφή βάσης δεδομένων που να κάνεις ανάκληση με κάποια ερωτήματα είναι σίγουρα ο σωστότερος τρόπος. Ας δω για παράδειγμα τις τελευταίες καταγραφές και την κατάσταση με μια ματιά της σχετικής υπηρεσίας (systemctl status anacity -n 5 --no-pager).

● ananicy.service - Ananicy - ANother Auto NICe daemon
     Loaded: loaded (/lib/systemd/system/ananicy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2020-07-06 20:46:48 EEST; 1h 53min ago
    Process: 993 ExecStartPre=/sbin/sysctl -e kernel.sched_autogroup_enabled=0 (code=exited, status=0/SUCCESS)
   Main PID: 1003 (python3)
      Tasks: 3 (limit: 18964)
     Memory: 15.0M (high: 16.0M max: 64.0M)
        CPU: 11min 38.986s
     CGroup: /system.slice/ananicy.service
             └─1003 python3 /usr/bin/ananicy start

Ιουλ 06 22:20:41 Minty ananicy[1003]: renice: cinnamon[2192/193180] 0 -> -10
Ιουλ 06 22:30:26 Minty ananicy[1003]: renice: cinnamon[2192/211743] 0 -> -10
Ιουλ 06 22:32:00 Minty ananicy[1003]: renice: cinnamon[2192/214731] 0 -> -10
Ιουλ 06 22:32:28 Minty ananicy[1003]: renice: cinnamon[2192/215581] 0 -> -10
Ιουλ 06 22:40:01 Minty ananicy[1003]: renice: cinnamon[2192/230043] 0 -> -10

Καμία ρύθμιση δεν απαιτείτε …

Χρήση της εντολής journalctrl

Μιας και ο @cerebrux έχει γράψει ένα αναλυτικό οδηγό, και δεν θα τα επαναλάβω εδώ. Διαβάστε το:

Μερικά από τα μειονεκτήματα του syslog

Στο κείμενο σχεδιασμού του journald υπάρχει μια εκτενής ανάλυση και απαριθμούνται 14 προβλήματα του syslog καθώς και 14 λόγοι γιατί η νέα προσέγγιση είναι καλύτερη. Διαβάστε το.

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

Για το syslog:

  • Δεν υπάρχει κανένας έλεγχος για το ποιος λέει τι. Κάθε πρόγραμμα μπορεί να ισχυριστεί ότι είναι ένα άλλο.
  • Δεν υπάρχει κάποια τυποποιημένη μορφή. Ένα αυτοματοποιημένο πρόγραμμα που ψάχνει τα αρχεία καταγραφής για να εντοπίσει προβλήματα ή παραβιάσεις έχει μια δύσκολη δουλεία μπροστά του και πολλά regexps. Τα πολλά αρχεία καταγραφής και τα πολλά υποσυστήματα κάνουν την ανάλυση ακόμα ποιο δύσκολη. Τα εργαλεία αυτά είναι συνήθως κλειστού κώδικα.
  • Αν κάποιος hacker πάρει τον έλεγχο του συστήματος θα σβήσει απλά τα ίχνη του πειράζοντας τα αρχεία καταγραφής.
  • Δεν υπάρχει συμπίεση και τα αρχεία καταγραφής τρώνε πολύ χώρο στον δίσκο
  • Δεν έχουμε καταγραφή των γεγονότων όταν ξεκινά και όταν κλείνει ο υπολογιστής.
  • Στο syslog δεν μπορούμε να καταγράψουμε δυαδικά δεδομένα. Τέτοια έχουμε όταν έχουμε να κάνουμε με δίσκους και firmware.

Για το journald:

  • Απλότητα. Δεν υπάρχουν εξαρτήσεις και είναι κομμάτι του βασικού συστήματος
  • Zero Maintenance και ευκολία διαχείρισης
  • Ταχύτητα αποθήκευσης και ανάκτησης της πληροφορίας
  • Γενικής χρήσης: Μπορεί να αποθηκεύσει κάθε καταγραφή ανεξάρτητα από τον τύπο ή το είδος της
  • Ασφάλεια: Λύνει τα προβλήματα που αναφέρθηκαν παραπάνω

Και αν καταστραφεί το journal;

Η μορφή του αρχείου είναι τέτοια που η πλήρης καταστροφή είναι αρκετά δύσκολη. Ναι έκπληξη! Είναι software και κάθε software έχει bugs! Αντίστοιχα προβλήματα και πολύ ποιο σοβαρά έχουμε δει στο παρελθόν και σε κάθε υλοποίηση του syslog. Στο σύστημα μου τρέχω την εντολή journalctl --verify και βλέπω κάποια προβλήματα:

f34570: Data object's entry array not sorted                                                  
File corruption detected at /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system@db095d45ab4742e7ab21aa3ecb6ca359-0000000000000001-0005a9145d9b99d9.journal:5809ec8 (of 100663296 bytes, 91%).
FAIL: /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system@db095d45ab4742e7ab21aa3ecb6ca359-0000000000000001-0005a9145d9b99d9.journal (Bad message)
PASS: /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/user-1000@b185e523db7a4dcbb824155c422073d7-0000000000000615-0005a9145e2c62e9.journal
PASS: /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/user-1000.journal                      
84b4f8: Data object's entry array not sorted                                                   
File corruption detected at /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system@0005a9bb8c49fc4a-2de3743ec2b4735a.journal~:508dde0 (of 92274688 bytes, 91%).
FAIL: /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system@0005a9bb8c49fc4a-2de3743ec2b4735a.journal~ (Bad message)
17731c8: Data object's entry array not sorted                                                  
File corruption detected at /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system.journal:185e418 (of 33554432 bytes, 76%).
FAIL: /var/log/journal/b76cc7b1bbdc489e93909d2043031de8/system.journal (Bad message)

Δεν ξέρω τι τα προκάλεσε, εγώ που σκάλιζα; κάποια κακογραμμένη υπηρεσία; το systemd; Σίγουρα δεν είναι καλό, αλλά και το syslog μπορεί να χάσει μια εγγραφή. Τουλάχιστον εδώ το γνωρίζω. Αλλά το κυριότερο: Τα πάντα εξακολουθούν να λειτουργούν κανονικά. Τίποτα καταστροφικό δεν συνέβη.

Συμπεράσματα

Η χρήση του journaldπαρουσιάζει πολλά πλεονεκτήματα σε σχέση με το απλοί σύστημα. Πρέπει να βγάλεις στην άκρη την αντιπάθεια για τα δυαδικά αρχεία μεν, αλλά στην πράξη απλά κάνεις την δουλεία ευκολότερα. Και μπορείς πάντα να κάνεις grep και awk είτε στα παραδοσιακά αρχεία του syslog που στις περισσότερες διανομές υπάρχουν ακόμα είτε στην έξοδο της εντολής journalctrl, τουλάχιστον μέχρι να την μάθεις. Ναι το να μαθαίνεις από την αρχή πράγματα είναι πρόβλημα.

Δεν ξέρω αν το κίνημα αντικατάστασης του systemd έχει να παρουσιάσει μια αντίστοιχη λύση, τουλάχιστον άλλη από το να μείνουμε στο παρελθόν.

Αν υπάρχει κάτι καλύτερο ή μια άλλη καλύτερη προσέγγιση γράψτε το στα σχόλια.

Διαβάστε:

4 Likes