Διεπαφή Ιστού

Αξιοποιώντας στο έπακρο τα αρχεία καταγραφής PHP: Ένας πρακτικός οδηγός



Θα μπορούσε δικαίως να ειπωθεί ότι τα αρχεία καταγραφής είναι ένα από τα πιο υποτιμημένα και μη χρησιμοποιούμενα εργαλεία στο a freelance php προγραμματιστής Διάθεση. Παρά τον πλούτο των πληροφοριών που μπορούν να προσφέρουν, δεν είναι ασυνήθιστο να είναι τα αρχεία καταγραφής τελευταίος τοποθετήστε έναν προγραμματιστή όταν προσπαθεί να επιλύσει ένα πρόβλημα.

Στην πραγματικότητα, τα αρχεία καταγραφής PHP θα πρέπει σε πολλές περιπτώσεις να είναι τα αρχεία πρώτα μέρος για να αναζητήσετε ενδείξεις όταν εμφανίζονται προβλήματα. Συχνά, οι πληροφορίες που περιέχουν θα μπορούσαν να μειώσουν σημαντικά το χρόνο που αφιερώνεται τραβώντας τα μαλλιά σας προσπαθώντας να εντοπίσετε ένα έντονο σφάλμα.



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



Αρχεία καταγραφής PHP



Αυτό το άρθρο παρέχει μια σειρά από συμβουλές για πώς να ρυθμίσετε τα αρχεία καταγραφής σας , καθώς πώς να επεξεργαστείτε τις πληροφορίες που περιέχουν , προκειμένου να μεγιστοποιηθεί το όφελος που παρέχουν.

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



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

Παράδειγμα έργου αρχείου καταγραφής PHP

Ως παράδειγμα έργου για λόγους συζήτησης σε αυτό το άρθρο, θα λάβουμε Πρότυπο Symfony ως έργο εργασίας και θα το ρυθμίσουμε στο Debian 7 Wheezy με rsyslogd, nginx, και PHP-FPM.



composer create-project symfony/framework-standard-edition my '2.6.*'

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



καθολικός χειριστής εξαιρέσεων ελατηρίου εκκίνησης

Συμβουλές για τη διαμόρφωση των αρχείων καταγραφής σας

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

Διαμόρφωση αρχείου καταγραφής σφαλμάτων

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



Τα αρχεία καταγραφής σφαλμάτων είναι συνήθως αρκετά εύκολα στη διαμόρφωση.

Για ένα πράγμα, όλα τα μηνύματα λάθους και σφαλμάτων μπορούν να καταγραφούν στο αρχείο καταγραφής σφαλμάτων με την ίδια ακριβώς μορφή στην οποία διαφορετικά θα παρουσιάζονταν σε έναν χρήστη. Με κάποια απλή διαμόρφωση, ο τελικός χρήστης δεν θα χρειαστεί ποτέ να δει αυτά τα άσχημα ίχνη σφάλματος στον ιστότοπό σας, ενώ οι υπολογιστές θα μπορούν ακόμα να παρακολουθούν το σύστημα και να ελέγχουν αυτά τα μηνύματα σφάλματος με όλες τις λεπτομέρειες. Δείτε πώς μπορείτε να ρυθμίσετε αυτό το είδος σύνδεσης στο PHP:



log_errors = On error_reporting = E_ALL error_log = /path/to/my/error/log

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

display_errors = Off display_startup_errors = Off

Διαμόρφωση συστήματος (syslog) Διαμόρφωση

Υπάρχουν πολλές γενικά συμβατές υλοποιήσεις του syslog δαίμονας στον κόσμο ανοιχτού κώδικα, συμπεριλαμβανομένων:

  • syslogd και sysklogd - πιο συχνά εμφανίζεται σε οικογενειακά συστήματα BSD, CentOS , Mac OS X , και άλλοι
  • syslog-ng - προεπιλογή για μοντέρνα Gentoo και SUSE χτίζει
  • rsyslogd - χρησιμοποιείται ευρέως στο Ντέμπιαν και Μαλακό καπέλλο οικογένειες λειτουργικών συστημάτων

(Σημείωση: Σε αυτό το άρθρο, θα χρησιμοποιήσουμε τα rsyslogd για τα παραδείγματα μας.)

Η βασική διαμόρφωση του syslog είναι γενικά επαρκής για την καταγραφή των μηνυμάτων καταγραφής σας σε ένα αρχείο καταγραφής σε ολόκληρο το σύστημα (συνήθως /var/log/syslog; μπορεί επίσης να είναι /var/log/messages ή /var/log/system.log ανάλογα με τη διανομή που χρησιμοποιείτε) .

Το αρχείο καταγραφής συστήματος παρέχει πολλές εγκαταστάσεις καταγραφής, οκτώ εκ των οποίων (LOG_LOCAL0 έως LOG_LOCAL7) προορίζονται για έργα που έχουν αναπτυχθεί από χρήστες. Εδώ, για παράδειγμα, είναι πώς μπορείτε να ρυθμίσετε LOG_LOCAL0 για εγγραφή σε 4 ξεχωριστά αρχεία καταγραφής, με βάση το επίπεδο καταγραφής (δηλ. σφάλμα, προειδοποίηση, πληροφορίες, εντοπισμός σφαλμάτων):

# /etc/rsyslog.d/my.conf local0.err /var/log/my/err.log local0.warning /var/log/my/warning.log local0.info -/var/log/my/info.log local0.debug -/var/log/my/debug.log

Τώρα, όποτε γράφετε ένα μήνυμα καταγραφής στο LOG_LOCAL0 εγκατάσταση, τα μηνύματα σφάλματος θα μεταβούν στο /var/log/my/err.log, τα προειδοποιητικά μηνύματα θα μεταβούν στο /var/log/my/warning.log και ούτω καθεξής. Σημειώστε, ωστόσο, ότι ο δαίμονας syslog φιλτράρει μηνύματα για κάθε αρχείο με βάση τον κανόνα 'αυτό το επίπεδο και υψηλότερο'. Έτσι, στο παραπάνω παράδειγμα, όλα τα μηνύματα σφάλματος θα εμφανίζονται και στα τέσσερα διαμορφωμένα αρχεία, θα εμφανίζονται προειδοποιητικά μηνύματα εκτός από το αρχείο καταγραφής σφαλμάτων, τα μηνύματα πληροφοριών θα εμφανίζονται στα αρχεία καταγραφής πληροφοριών και εντοπισμού σφαλμάτων και τα μηνύματα εντοπισμού σφαλμάτων θα μεταβούν μόνο στο debug.log.

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

Για να τερματίσετε ένα λιγότερο σημαντικό επίπεδο καταγραφής (π.χ. σε διακομιστή παραγωγής), μπορείτε απλώς να ανακατευθύνετε σχετικά μηνύματα στο /dev/null (δηλαδή, πουθενά):

local0.debug /dev/null # -/var/log/my/debug.log

Μια συγκεκριμένη προσαρμογή που είναι χρήσιμη, ειδικά για την υποστήριξη ορισμένων αναλύσεων αρχείων καταγραφής PHP που θα συζητήσουμε αργότερα σε αυτό το άρθρο, είναι να χρησιμοποιήσετε την καρτέλα ως οριοθέτη χαρακτήρα στα μηνύματα καταγραφής. Αυτό μπορεί εύκολα να γίνει προσθέτοντας το ακόλουθο αρχείο στο /etc/rsyslog.d

# /etc/rsyslog.d/fixtab.conf $EscapeControlCharactersOnReceive off

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

service rsyslog restart

Διαμόρφωση αρχείου καταγραφής διακομιστή

Σε αντίθεση με τα αρχεία καταγραφής εφαρμογών και τα αρχεία καταγραφής σφαλμάτων στα οποία μπορείτε να γράψετε, τα αρχεία καταγραφής διακομιστών γράφονται αποκλειστικά από τους αντίστοιχους δαίμονες διακομιστή (π.χ. διακομιστής ιστού, διακομιστής βάσης δεδομένων κ.λπ.) σε κάθε αίτημα. Ο μόνος «έλεγχος» που έχετε σε αυτά τα αρχεία καταγραφής είναι στο βαθμό που ο διακομιστής σας επιτρέπει να διαμορφώσετε τη λειτουργικότητα καταγραφής. Παρόλο που μπορεί να υπάρχουν πολλά για να εξεταστούν σε αυτά τα αρχεία, είναι συχνά ο μόνος τρόπος για να αποκτήσετε μια σαφή αίσθηση του τι συμβαίνει «κάτω από την κουκούλα» με τον διακομιστή σας.

Ας αναπτύξουμε το παράδειγμα εφαρμογής Symfony Standard σε περιβάλλον nginx με το backend αποθήκευσης MySQL. Εδώ είναι το nginx host config που θα χρησιμοποιήσουμε:

server { server_name my.log-sandbox; root /var/www/my/web; location / { # try to serve file directly, fallback to app.php try_files $uri /app.php$is_args$args; } # DEV # This rule should only be placed on your development environment # In production, don't include this and don't deploy app_dev.php or config.php location ~ ^/(app_dev|config).php(/|$) { fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_split_path_info ^(.+.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS off; } # PROD location ~ ^/app.php(/|$) { fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_split_path_info ^(.+.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS off; # Prevents URIs that include the front controller. This will 404: # http://domain.tld/app.php/some-path # Remove the internal directive to allow URIs like this internal; } error_log /var/log/nginx/my_error.log; access_log /var/log/nginx/my_access.log; }

Όσον αφορά τις δύο τελευταίες οδηγίες παραπάνω: access_log αντιπροσωπεύει το γενικό ημερολόγιο αιτημάτων, ενώ error_log είναι για σφάλματα και, όπως συμβαίνει με τα αρχεία καταγραφής σφαλμάτων εφαρμογής, αξίζει να ρυθμίσετε επιπλέον παρακολούθηση για να ειδοποιείστε για προβλήματα, ώστε να μπορείτε να αντιδράτε γρήγορα.

πώς να λάβετε στοιχεία πιστωτικής κάρτας

Σημείωση: Αυτό είναι ένα σκόπιμα υπερ-απλοποιημένο αρχείο διαμόρφωσης nginx που παρέχεται μόνο για παράδειγμα. Δεν δίνει σχεδόν καμία προσοχή στην ασφάλεια και την απόδοση και δεν πρέπει να χρησιμοποιείται όπως είναι σε οποιοδήποτε «πραγματικό» περιβάλλον.

Αυτό μπαίνουμε στο /var/log/nginx/my_access.log μετά την πληκτρολόγηση http://my.log-sandbox/app_dev.php/ στο πρόγραμμα περιήγησης και το χτύπημα Enter.

192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /app_dev.php/ HTTP/1.1' 200 6715 '-' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/framework/css/body.css HTTP/1.1' 200 6657 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/framework/css/structure.css HTTP/1.1' 200 1191 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/css/demo.css HTTP/1.1' 200 2204 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-quick-tour.gif HTTP/1.1' 200 4770 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-demo.gif HTTP/1.1' 200 4053 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-configure.gif HTTP/1.1' 200 3530 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /favicon.ico HTTP/1.1' 200 6518 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:30 +0300] 'GET /app_dev.php/_wdt/e50d73 HTTP/1.1' 200 13265 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36'

Αυτό δείχνει ότι, για την εξυπηρέτηση μίας σελίδας, το πρόγραμμα περιήγησης πραγματοποιεί 9 κλήσεις HTTP. 7 από αυτά, ωστόσο, είναι αιτήματα για στατικό περιεχόμενο, το οποίο είναι απλό και ελαφρύ. Ωστόσο, εξακολουθούν να λαμβάνουν πόρους δικτύου και αυτό μπορεί να βελτιστοποιηθεί χρησιμοποιώντας διάφορα ξωτικά και τεχνικές ελαχιστοποίησης.

Ενώ αυτές οι βελτιστοποιήσεις πρόκειται να συζητηθούν σε άλλο άρθρο, αυτό που έχει σημασία εδώ είναι ότι μπορούμε να καταγράψουμε αιτήματα σε στατικό περιεχόμενο ξεχωριστά χρησιμοποιώντας ένα άλλο location οδηγία για αυτούς:

location ~ .(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js)$ { access_log /var/log/nginx/my_access-static.log; }

Θυμηθείτε ότι nginx | ​​_ + _ | εκτελεί απλή τακτική αντιστοίχιση έκφρασης, ώστε να μπορείτε να συμπεριλάβετε όσες επεκτάσεις στατικού περιεχομένου θέλετε να αποστείλετε στον ιστότοπό σας.

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

Άλλα αρχεία καταγραφής που αξίζει να αναφερθούν

Δύο άλλα αρχεία καταγραφής PHP που αξίζει να αναφερθούν είναι το αρχείο καταγραφής εντοπισμού σφαλμάτων και το αρχείο αποθήκευσης δεδομένων.

Το αρχείο καταγραφής εντοπισμού σφαλμάτων

Ένα άλλο βολικό πράγμα για τα αρχεία καταγραφής nginx είναι το αρχείο καταγραφής εντοπισμού σφαλμάτων. Μπορούμε να το ενεργοποιήσουμε αντικαθιστώντας το location γραμμή της διαμόρφωσης με τα ακόλουθα (απαιτεί να εγκατασταθεί η μονάδα εντοπισμού σφαλμάτων nginx):

error_log

Η ίδια ρύθμιση ισχύει για το Apache ή οτιδήποτε άλλο διακομιστή ιστού χρησιμοποιείτε.

Και παρεμπιπτόντως, τα αρχεία καταγραφής εντοπισμού σφαλμάτων είναι δεν σχετίζονται με αρχεία καταγραφής σφαλμάτων, παρόλο που έχουν ρυθμιστεί στο error_log /var/log/nginx/my_error.log debug; διευθυντικός.

Παρόλο που το αρχείο καταγραφής εντοπισμού σφαλμάτων μπορεί πράγματι να είναι λεκτικό (ένα μόνο αίτημα nginx, για παράδειγμα, δημιούργησε 127 KB δεδομένων καταγραφής!), Μπορεί να είναι πολύ χρήσιμο. Η περιήγηση σε ένα αρχείο καταγραφής μπορεί να είναι δυσκίνητη και κουραστική, αλλά συχνά μπορεί γρήγορα να παρέχει ενδείξεις και πληροφορίες που βοηθούν σημαντικά στην επιτάχυνση της διαδικασίας εντοπισμού σφαλμάτων.

Συγκεκριμένα, το αρχείο καταγραφής εντοπισμού σφαλμάτων μπορεί πραγματικά να βοηθήσει με τον εντοπισμό σφαλμάτων διαμορφώσεις nginx, ειδικά τα πιο περίπλοκα μέρη, όπως error_log αντιστοίχιση και location αλυσίδες.

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

Αρχεία αποθήκευσης δεδομένων

Ένας άλλος τύπος καταγραφής διακομιστή (χρήσιμος για εντοπισμό σφαλμάτων) είναι τα αρχεία καταγραφής αποθήκευσης δεδομένων. Στο MySQL, μπορείτε να τα ενεργοποιήσετε προσθέτοντας αυτές τις γραμμές:

rewrite

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

Γράφοντας στα αρχεία καταγραφής σας

Η ίδια η PHP παρέχει λειτουργίες για άνοιγμα, εγγραφή και κλείσιμο αρχείων καταγραφής ( [mysqld] general_log = 1 general_log_file = /var/log/mysql/query.log , openlog() , και syslog() , αντίστοιχα).

Υπάρχουν επίσης πολλές βιβλιοθήκες καταγραφής για τον προγραμματιστή PHP, όπως Μονόλογος (δημοφιλές μεταξύ Συμφωνία και Λάραβελ χρήστες), καθώς και διάφορες υλοποιήσεις για συγκεκριμένα πλαίσια, όπως ενσωματωμένες δυνατότητες καταγραφής CakePHP . Γενικά, βιβλιοθήκες όπως το Monolog όχι μόνο τυλίγουν closelog() κλήσεις, αλλά επιτρέπουν επίσης τη χρήση άλλων λειτουργιών και εργαλείων backend.

Ακολουθεί ένα απλό παράδειγμα για το πώς να γράψετε στο αρχείο καταγραφής:

syslog()

Η κλήση μας εδώ για :

  • διαμορφώνει την PHP ώστε να προσθέτει ένα μοναδικό αναγνωριστικό σε κάθε μήνυμα καταγραφής συστήματος εντός της διάρκειας ζωής του σεναρίου
  • το θέτει να καθυστερήσει το άνοιγμα της σύνδεσης syslog μέχρι την πρώτη openlog πραγματοποιήθηκε κλήση
  • σύνολα syslog() ως προεπιλεγμένη εγκατάσταση καταγραφής

Ακολουθεί το περιεχόμενο του αρχείου καταγραφής μετά την εκτέλεση του παραπάνω κώδικα:

σε ποια γλώσσα είναι γραμμένο το ρουμπίνι
LOG_LOCAL0

Μεγιστοποίηση της αξίας των αρχείων καταγραφής PHP

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

Αρχικά, ας δημιουργήσουμε τα σενάρια # cat /var/log/my/info.log Mar 2 00:23:29 log-sandbox 54f39161a2e55: It works! (για σωστό άνοιγμα και διαμόρφωση των αρχείων καταγραφής μας) και src/log-begin.php (για καταγραφή πληροφοριών σχετικά με την επιτυχή ολοκλήρωση). Λάβετε υπόψη ότι, για απλότητα, θα γράψουμε απλώς όλα τα μηνύματα στο αρχείο καταγραφής πληροφοριών.

src/log-end.php

Ας απαιτήσουμε αυτά τα σενάρια στο # src/log-begin.php # src/log-end.php :

app.php

Για το περιβάλλον ανάπτυξης, θέλουμε να απαιτήσουμε αυτά τα σενάρια στο επισης. Ο κωδικός για να γίνει αυτό θα είναι ο ίδιος όπως παραπάνω, εκτός εάν θα ορίσουμε το app_dev.php έως MODE αντί για DEV.

Θέλουμε επίσης να παρακολουθούμε ποιοι ελεγκτές καλούνται, οπότε ας προσθέσουμε μια ακόμη γραμμή στο PROD, ακριβώς στην αρχή του AcmeDemoBundleEventListenerControllerListener μέθοδος:

ControllerListener::onKernelController()

Σημειώστε ότι αυτές οι αλλαγές συνολικά είναι μόνο 15 επιπλέον γραμμές κώδικα, αλλά μπορούν συλλογικά να παράγουν πληθώρα πληροφοριών.

Ανάλυση των δεδομένων στα αρχεία καταγραφής σας

Για αρχάριους, ας δούμε πόσα αιτήματα HTTP απαιτούνται για την προβολή κάθε φόρτωσης σελίδας.

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

syslog(LOG_INFO, 'CONTROLLER ' . get_class($event->getController()[0]));

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

Στην πραγματικότητα υπάρχουν δύο σημεία που αξίζει να αναφερθούν εδώ. Πρώτον, τα δύο αιτήματα ανά φόρτωση σελίδας είναι για τη χρήση του Symfony σε λειτουργία dev (το οποίο έχω κάνει σε όλο αυτό το άρθρο). Μπορείτε να αναγνωρίσετε κλήσεις λειτουργίας dev αναζητώντας Mar 3 12:04:20 log-sandbox 54f58724b1ccc: BEGIN Mar 3 12:04:20 log-sandbox 54f58724b1ccc: URI /app_dev.php/ Mar 3 12:04:20 log-sandbox 54f58724b1ccc: CLIENT 192.168.56.1 1b101cd Mar 3 12:04:20 log-sandbox 54f58724b1ccc: MODE DEV Mar 3 12:04:23 log-sandbox 54f58724b1ccc: CONTROLLER AcmeDemoBundleControllerWelcomeController Mar 3 12:04:25 log-sandbox 54f58724b1ccc: DISPATCH TIME 4.51 Mar 3 12:04:25 log-sandbox 54f58724b1ccc: END Mar 3 12:04:25 log-sandbox 54f5872967dea: BEGIN Mar 3 12:04:25 log-sandbox 54f5872967dea: URI /app_dev.php/_wdt/59b8b6 Mar 3 12:04:25 log-sandbox 54f5872967dea: CLIENT 192.168.56.1 1b101cd Mar 3 12:04:25 log-sandbox 54f5872967dea: MODE DEV Mar 3 12:04:28 log-sandbox 54f5872967dea: CONTROLLER SymfonyBundleWebProfilerBundleControllerProfilerController Mar 3 12:04:29 log-sandbox 54f5872967dea: DISPATCH TIME 4.17 Mar 3 12:04:29 log-sandbox 54f5872967dea: END Τμήματα διευθύνσεων URL. Δεύτερον, ας υποθέσουμε ότι κάθε φόρτωση σελίδας προβάλλεται με δύο επόμενα αιτήματα στην εφαρμογή Symfony. Όπως είδαμε νωρίτερα στα αρχεία καταγραφής πρόσβασης nginx, στην πραγματικότητα υπάρχουν περισσότερες κλήσεις HTTP, μερικές από τις οποίες αφορούν στατικό περιεχόμενο.

Εντάξει, ας περιηγηθούμε λίγο στον ιστότοπο επίδειξης (για να δημιουργήσουμε τα δεδομένα στα αρχεία καταγραφής) και ας δούμε τι άλλο μπορούμε να μάθουμε από αυτά τα αρχεία καταγραφής.

Πόσα αιτήματα προβλήθηκαν συνολικά από την αρχή του αρχείου καταγραφής;

/app-dev.php/

Απέτυχε κάποιο από αυτά (το σενάριο έκλεισε χωρίς να φτάσει στο τέλος);

# grep -c BEGIN info.log 10

Βλέπουμε ότι ο αριθμός των # grep -c END info.log 10 και BEGIN ταιριάζουν με τα αρχεία, οπότε αυτό μας λέει ότι όλες οι κλήσεις ήταν επιτυχημένες. (Εάν το σενάριο PHP δεν είχε ολοκληρωθεί με επιτυχία, δεν θα είχε φτάσει στην εκτέλεση του σεναρίου END.)

Ποιο ήταν το ποσοστό των αιτημάτων στη ρίζα του ιστότοπου;

src/log-end.php

Αυτό μας λέει ότι υπήρχαν 2 φορτώσεις σελίδας της ρίζας του ιστότοπου. Δεδομένου ότι προηγουμένως μάθαμε ότι (α) υπάρχουν 2 αιτήματα για την εφαρμογή ανά φόρτωση σελίδας και (β) υπήρχαν συνολικά 10 αιτήματα HTTP, το ποσοστό των αιτημάτων για τη ρίζα του ιστότοπου ήταν 40% (δηλαδή, 2x2 / 10).

Ποια τάξη ελεγκτή είναι υπεύθυνη για την εξυπηρέτηση αιτημάτων για τη ριζική τοποθεσία;

# `grep -cE 's/app_dev.php/$' info.log` 2

Εδώ χρησιμοποιήσαμε το μοναδικό αναγνωριστικό ενός αιτήματος για να ελέγξουμε όλα τα μηνύματα καταγραφής που σχετίζονται με αυτό το μεμονωμένο αίτημα. Με αυτόν τον τρόπο καταφέραμε να προσδιορίσουμε ότι η κλάση ελεγκτή που είναι υπεύθυνη για την εξυπηρέτηση αιτημάτων στο root site είναι # grep -E 's/$|s/app_dev.php/$' info.log | head -n1 Mar 3 12:04:20 log-sandbox 54f58724b1ccc: URI /app_dev.php/ # grep 54f58724b1ccc info.log | grep CONTROLLER Mar 3 12:04:23 log-sandbox 54f58724b1ccc: CONTROLLER AcmeDemoBundleControllerWelcomeController .

Ποιοι πελάτες με IPs υποδικτύου AcmeDemoBundleControllerWelcomeController έχετε πρόσβαση στον ιστότοπο;

192.168.0.0/16

Όπως ήταν αναμενόμενο σε αυτήν την απλή δοκιμαστική περίπτωση, μόνο ο κεντρικός υπολογιστής μου έχει πρόσβαση στον ιστότοπο. Αυτό είναι φυσικά ένα πολύ απλοϊκό παράδειγμα, αλλά η ικανότητα που αποδεικνύει (να μπορεί να αναλύει τις πηγές της κυκλοφορίας στον ιστότοπό σας) είναι προφανώς αρκετά ισχυρή και σημαντική.

Πόσο μέρος της επισκεψιμότητας στον ιστότοπό μου προήλθε από τον FireFox;

Έχοντας # grep CLIENT info.log | cut -d':' -f4 | cut -f2 | sort | uniq 192.168.56.1 ως κατακερματισμός του Firefox User-Agent, μπορώ να απαντήσω σε αυτήν την ερώτηση ως εξής:

1b101cd

Απάντηση: 80% (δηλαδή, 8/10)

Ποιο είναι το ποσοστό των αιτημάτων που απέδωσαν αργή απόκριση;

πώς να σχεδιάσετε μια παρουσίαση

Για τους σκοπούς αυτού του παραδείγματος, θα ορίσουμε το 'αργό' ως περισσότερο από 5 δευτερόλεπτα για να δώσουμε μια απάντηση. Αναλόγως:

# grep -c 1b101cd info.log 8 # grep -c CLIENT info.log 10

Απάντηση: 20% (δηλ. 2/10)

Κάποιος παρείχε ποτέ παραμέτρους GET;

# grep 'DISPATCH TIME' info.log | grep -cE 's[0-9]{2,}.|s[5-9].' 2

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

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

Άλλα πράγματα που πρέπει να θυμάστε

Κρατώντας τα πράγματα ασφαλή

Ένα άλλο head-up είναι για την ασφάλεια. Ίσως πιστεύετε ότι τα αιτήματα καταγραφής είναι καλή ιδέα, στις περισσότερες περιπτώσεις είναι πράγματι. Ωστόσο, είναι σημαντικό να είστε εξαιρετικά προσεκτικοί σχετικά με την κατάργηση τυχόν δυνητικά ευαίσθητων πληροφοριών χρήστη προτού τις αποθηκεύσετε στο αρχείο καταγραφής.

Bloat File Log Καταπολέμηση

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

Το πιο εύκολο είναι περιστρέψτε τα αρχεία καταγραφής . Περιστρεφόμενα αρχεία καταγραφής σημαίνει:

  • Περιοδικά αντικαθιστώντας το αρχείο καταγραφής με ένα νέο κενό αρχείο για περαιτέρω γραφή
  • Αποθήκευση του παλιού αρχείου για την ιστορία
  • Αφαίρεση αρχείων που έχουν 'ηλικία' επαρκώς για να ελευθερώσετε χώρο στο δίσκο
  • Βεβαιωθείτε ότι η εφαρμογή μπορεί να γράψει στα αρχεία καταγραφής χωρίς διακοπή όταν πραγματοποιούνται αυτές οι αλλαγές αρχείων

Η πιο κοινή λύση για αυτό είναι # grep URI info.log | grep ? , το οποίο αποστέλλεται προεγκατεστημένο με τις περισσότερες διανομές * nix. Ας δούμε ένα απλό αρχείο διαμόρφωσης για περιστροφή των αρχείων καταγραφής μας:

logrotate

Μια άλλη, πιο προηγμένη προσέγγιση είναι να κάνετε /var/log/my/debug.log /var/log/my/info.log /var/log/my/warning.log /var/log/my/error.log { rotate 7 daily missingok notifempty delaycompress compress sharedscripts postrotate invoke-rc.d rsyslog rotate > /dev/null endscript } γράφει μηνύματα σε αρχεία, δημιουργημένα δυναμικά με βάση την τρέχουσα ημερομηνία και ώρα. Αυτό θα απαιτούσε ακόμη μια προσαρμοσμένη λύση για την αφαίρεση παλαιότερων αρχείων, αλλά επιτρέπει στους υπολογιστές να διαχειρίζονται τα χρονικά πλαίσια με ακρίβεια για κάθε αρχείο καταγραφής. Για το παράδειγμά μας:

rsyslogd

Με αυτόν τον τρόπο, $template DynaLocal0Err, '/var/log/my/error-%$NOW%-%$HOUR%.log' $template DynaLocal0Info, '/var/log/my/info-%$NOW%-%$HOUR%.log' $template DynaLocal0Warning, '/var/log/my/warning-%$NOW%-%$HOUR%.log' $template DynaLocal0Debug, '/var/log/my/debug-%$NOW%-%$HOUR%.log' local1.err -?DynaLocal0Err local1.info -?DynaLocal0Info local1.warning -?DynaLocal0Warning local1.debug -?DynaLocal0Debug θα δημιουργήσει ένα μεμονωμένο αρχείο καταγραφής κάθε ώρα και δεν θα χρειαστεί να τα περιστρέψετε και να κάνετε επανεκκίνηση του δαίμονα. Δείτε πώς μπορούν να καταργηθούν αρχεία καταγραφής παλαιότερα των 5 ημερών για την επίτευξη αυτής της λύσης:

rsyslog

Απομακρυσμένα αρχεία καταγραφής

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

Για να το λύσετε, σκεφτείτε να δημιουργήσετε ένα κεντρικός διακομιστής καταγραφής . Το μόνο που χρειάζεστε είναι ένα άλλο πλαίσιο με ανοιχτή τη θύρα UDP 514 (προεπιλογή). Για να κάνετε find /var/log/my/ -mtime +5 -print0 | xargs -0 rm ακούστε συνδέσεις, προσθέστε την ακόλουθη γραμμή στο αρχείο config:

rsyslogd

Έχοντας αυτό, η ρύθμιση του πελάτη είναι τόσο εύκολη όσο:

τι είναι /c/
$UDPServerRun 514

(όπου *.* @HOSTNAME:514 είναι το όνομα κεντρικού υπολογιστή του απομακρυσμένου διακομιστή καταγραφής).

συμπέρασμα

Αν και αυτό το άρθρο έχει δείξει μερικούς από τους δημιουργικούς τρόπους με τους οποίους τα αρχεία καταγραφής μπορούν να προσφέρουν πολύ πιο πολύτιμες πληροφορίες από ό, τι φανταζόμασταν προηγουμένως, είναι σημαντικό να υπογραμμίσουμε ότι έχουμε μόνο γρατσουνίσει το ό, τι είναι δυνατό. Η έκταση, το εύρος και η μορφή αυτού που μπορείτε να καταγράψετε είναι σχεδόν απεριόριστη. Αυτό σημαίνει ότι - εάν υπάρχουν δεδομένα χρήσης ή αναλυτικών στοιχείων που θέλετε να εξαγάγετε από τα αρχεία καταγραφής σας - πρέπει απλώς να τα καταγράψετε με τρόπο που θα διευκολύνει στη συνέχεια την ανάλυση και ανάλυση. Επιπλέον, αυτή η ανάλυση μπορεί συχνά να πραγματοποιηθεί με τυπικά εργαλεία γραμμής εντολών Linux όπως HOSTNAME, grep ή sed.

Πράγματι, τα αρχεία καταγραφής PHP είναι ένα πιο ισχυρό εργαλείο που μπορεί να έχει τεράστιο όφελος.

Πόροι

Κωδικός στο GitHub: https://github.com/isanosyan/toptal-blog-logs-post-example

Παράρτημα: Ανάγνωση και χειρισμός αρχείων καταγραφής στο Unix Shell

Ακολουθεί μια σύντομη εισαγωγή σε μερικά από τα πιο κοινά εργαλεία γραμμής εντολών * nix με τα οποία θέλετε να είστε εξοικειωμένοι με την ανάγνωση και τον χειρισμό των αρχείων καταγραφής σας.

  • awk είναι ίσως το πιο απλό. Εκτυπώνει ολόκληρο το αρχείο στη ροή εξόδου. Για παράδειγμα, η ακόλουθη εντολή θα εκτυπώσει cat στην κονσόλα:

    logfile1

  • cat logfile1 Ο χαρακτήρας επιτρέπει στο χρήστη να ανακατευθύνει την έξοδο, για παράδειγμα σε άλλο αρχείο. Ανοίγει τη ροή στόχου σε λειτουργία εγγραφής (που σημαίνει σκούπισμα περιεχομένου στόχου). Δείτε πώς αντικαθιστούμε τα περιεχόμενα του > με περιεχόμενο tmpfile:

    logfile1

  • cat logfile1 > tmpfile ανακατευθύνει την έξοδο και ανοίγει τη ροή στόχου σε λειτουργία προσάρτησης. Τα τρέχοντα περιεχόμενα του αρχείου προορισμού θα διατηρηθούν, νέες γραμμές θα προστεθούν στο κάτω μέρος. Αυτό θα προσαρτηθεί >> περιεχόμενο σε logfile1:

    tmpfile

  • cat logfile1 >> tmpfile φιλτράρει το αρχείο με κάποιο μοτίβο και εκτυπώνει μόνο γραμμές που ταιριάζουν. Η παρακάτω εντολή θα εκτυπώσει μόνο γραμμές grep που περιέχει logfile1 μήνυμα:

    Bingo

  • grep Bingo logfile1 εκτυπώνει περιεχόμενο μιας μεμονωμένης στήλης (με αριθμό που ξεκινά από 1). Από προεπιλογή, αναζητούνται χαρακτήρες καρτελών ως οριοθέτες μεταξύ της στήλης. Για παράδειγμα, εάν έχετε αρχείο γεμάτο χρονικές σφραγίδες σε μορφή cut, αυτό θα σας επιτρέψει να εκτυπώσετε μόνο χρόνια:

    YYYY-MM-DD HH:MM:SS

  • cut -d'-' -f1 logfile1 εμφανίζει μόνο τις πρώτες γραμμές ενός αρχείου

  • head εμφανίζει μόνο τις τελευταίες γραμμές ενός αρχείου

  • tail ταξινομεί τις γραμμές στην έξοδο

  • sort φιλτράρει διπλές γραμμές

  • uniq μετρά τις λέξεις (ή γραμμές όταν χρησιμοποιούνται με τη σημαία wc)

  • -l (δηλαδή, το σύμβολο 'σωλήνας') παρέχει έξοδο από τη μία εντολή ως είσοδο στην επόμενη. Ο σωλήνας είναι πολύ βολικός για το συνδυασμό εντολών. Για παράδειγμα, δείτε πώς μπορούμε να βρούμε μήνες του 2014 που πραγματοποιούνται εντός ενός συνόλου χρονικών σημείων:

    |

Εδώ ταιριάζουμε πρώτα τις γραμμές με την κανονική έκφραση «ξεκινά με το 2014» και μετά κόβουμε μήνες. Τέλος, χρησιμοποιούμε συνδυασμό grep -E '^2014' logfile1 | cut -d'-' -f2 | sort | uniq και sort για εκτύπωση εμφανίσεων μόνο μία φορά.

EdTech Industry Analysis & Trends (2020)

Αύξηση Των Εσόδων

EdTech Industry Analysis & Trends (2020)
Επισκόπηση και συμβατότητα του επεξεργαστή Apple M1

Επισκόπηση και συμβατότητα του επεξεργαστή Apple M1

Τεχνολογία