php günlüğe kaydetme PHP'de oturum açma. Bir günlük dosyasına veri yazmak için bir komut dosyası listesi

  • 03.11.2019

her gerçek PHP uygulamalar, hatalar ve istisnalar zaman zaman ortaya çıkıyor, uyarılar ve mesajlar çıkıyor. Bu bilgiyi (log) kaydetmek için uyanmazsak, o zaman güzel bir an, bu hataların ve istisnaların uygulamanın hangi bölümünde meydana geldiğini anlamak imkansız hale gelecek ve buna bağlı olarak bunları çözemeyeceğiz. Ek olarak, olayların günlüğe kaydedildiği durumlar vardır, örneğin bir kullanıcının sistemde oturum açması ve sistemden çıkması durumunda olduğu gibi eylemler basitçe gereklidir.

V PHP zaten gerekli günlük oluşturma olanaklarına sahiptir: işlev error_log ()- sistem günlüğüne bir mesaj göndermek için, fonksiyon set_error_handler () uyarıları ve hataları yakalamak için. Bu işlevler özel hata yönetimi için kullanılabilir ve kod geliştiriciye hata işleme ve filtreleme mantığını bağımsız olarak yönetme yeteneği verir.

Bununla birlikte, bu tür düşük seviyeli erişim, kodun sık tekrarlanmasına yol açar ve daha da önemlisi, bu tür kodlar hataya daha açıktır. Bu nedenle, hazır bileşenler, "savaş" koşullarında iyi test edilmiş ve kanıtlanmış programcının yardımına gelir.

Bu bileşenler şunları içerir: zend günlüğü bileşeni itibaren Zend çerçevesi... Bileşen zend günlüğüçok amaçlı bir günlük kaydı bileşeni, tüm işlemlerin bir tür jack'ı olarak kullanılabilir. Birçok günlük mesajı formatını ve kayıt tabanı türlerini (dosyalar, veritabanları) destekler, ayrıca her şey iyi gelişmiş bir mesaj filtreleme sistemine ve çok daha fazlasına sahiptir. Ayrıca zend günlüğü ile uyumlu PSR-3 kayıt standardı. Bu şekilde yüklendi:

Besteci zendframework / zend-log gerektirir

Aşağıdaki şekilde kullanılır (örneğin, proje kökündeki index.php dosyası kullanılır):

"vendor / autoload.php" gerektir;

Zend \ Log \ Logger'ı kullanın;
Zend \ Log \ Writer \ Stream'i kullanın;

$ günlükçü = yeni Kaydedici;

// hataları konsola gönder
$ yazar = yeni Akış ("php: // çıktı");

$ kaydedici -> addWriter ($ yazar);
$ logger -> log (Logger :: INFO, "Bazı bilgiler");

Yukarıdaki kodu çalıştırmanın sonucu:

2017-09-26T10: 40:34 + 03:00 BİLGİ (6): Bazı bilgiler

Özet satırı olay zamanı, öncelik ve mesajı içerir. Görüntülenen mesajın formatı, elbette, gerekirse yöntem kullanılarak değiştirilebilir. setFormatter ()... Varsayılan olarak, günlük satırı aşağıdaki şablonla tanımlanır:

% zaman damgası%% öncelikAdı% (% öncelik%):% mesaj%% ekstra%

  1. % zaman damgası% bir zaman damgasıdır
  2. % öncelikAdı% - öncelikli metin etiketi
  3. % öncelik% - sayısal öncelik etiketi
  4. % mesaj% - mesaj
  5. % extra% - ek bilgi için isteğe bağlı değer

Mesaj biçimini değiştirmek istiyorsanız, bu şu şekilde yapılır:

$ formatlayıcı = new Zend \ Log \ Formatter \ Simple ("message% mesaj%". PHP_EOL);
$ yazar -> setFormatter ($ formatlayıcı);

Bileşen zend günlüğü PHP yorumlayıcısının kendisinde hataları ve istisnaları günlüğe kaydetmek için de kullanılabilir. Bunun için Logger sınıfında iki statik metot vardır: Kaydedici :: registerErrorHandler ($ kaydedici)- hataları yakalamak ve Kaydedici :: registerExceptionHandler ($ kaydedici)- istisnaları yakalamak için.

Zend \ Log \ Logger'ı kullanın;
Zend \ Log \ Writer'ı kullanın;

$ günlükçü = yeni Kaydedici;
$ yazar = yeni Yazar \ Akış (__ DIR__. "/test.log");
$ logger-> addWriter ($ yazar);

// Günlük hataları
Kaydedici :: registerErrorHandler ($ kaydedici);

// İstisnaları günlüğe kaydet
Kaydedici :: registerExceptionHandler ($ kaydedici);

Daha önce bahsedildiği gibi, zend günlüğü bize günlük kaydı için mesajları filtreleme olanağı sağlar, yani. log'a mesaj yazmadan önce kriterlerimize uygun olup olmadığını görebiliriz ve eğer öyleyse onu yazarız.

İşte bir örnek:

$ filtre = yeni Zend \ Log \ Filter \ Priority (Logger :: CRIT);

// Writer arayüzünün addFilter yöntemi
$ yazar-> addFilter ($ filtre);

Bu örnekte, yalnızca önceliği kritik değerinden küçük veya buna eşit olan iletileri günlüğe kaydedeceğiz ( Kaydedici :: KRİTİK).

Sınıfta tanımlanan önceliklerin tam listesi Zend \ Günlük \ Kaydedici:

Sabit ÇIKIŞ = 0; // Alarm: Sistem kullanılamaz durumda
const ALERT = 1; // Alarm: acil eylem gerekli
const CRIT = 2; // Kritik durum
sabit HATA = 3; // Hata
const WARN = 4; // Bir uyarı
const BİLDİRİM = 5; // Dikkat
const BİLGİ = 6; // Bilgi
const HATA AYIKLAMA = 7; // Hata ayıklama, hata ayıklama

Ayrıca mesajları normal ifadelere, zaman damgalarına vb. göre filtreleyebiliriz. Böylece, PHP günlüğü- geliştirme sırasında bu önemli ve bazen gerekli bir şeydir internet uygulamaları.

Ciddi sitelerde, tarayıcıda kullanıcıya en beklenmedik yerlerde hataların ne zaman görüntülendiğini görmek garip. Neden göründükleri ayrı bir konuşma. Ama neden sergileniyorlar? Sonuçta, hata metni hata ayıklama için bilgidir ve istemci için değil geliştirici için tasarlanmıştır.

Ayrıca, genellikle kötü niyetli bilgisayar korsanlarının siteyi kırmasına yardımcı olan bu hizmet bilgileridir. Klasik bir örnek olarak, hata durumunda sorgu çıktısı ile seçeneği verebiliriz: "WHERE id =" yakınındaki sorguda bir hatanız var... Çok teşekkür ederim. "WHERE id = ..." satırından sonra "0 OR 1> 0" satırını değiştirin ve sorgu tüm tablo boyunca yürütülür. Silme talebi varsa, o zaman ... bilirsiniz, eğlence =). Bu nedenle, sorgulardaki değişkenleri her zaman tırnak içine alırım. Her ihtimale karşı...

Ama kendimi kaptırdım. Bugün bununla ilgili değil. Bugün, tüm mesajları bellek için web yöneticisine kaydederken, istemciye hataların görüntülenmesini nasıl önleyeceğimiz hakkında konuşacağız.

PHP'deki hata türlerine kısa bir genel bakışla başlayalım.

Tablo 1. PHP4'teki hataların açıklamaları(orijinal liste)
sayısal
anlam
Devamlı Açıklama yakalandı / hayır
1 E_ERROR Ölümcül hatalar. Örneğin, belleğe erişilirken bir hata oluştu. Bu durumda, komut dosyası yürütme kesintiye uğrar. Numara
2 E_UYARI Uyarılar (önemli olmayan hatalar). Komut dosyası kesintiye uğramaz. Evet
4 E_PARSE Sözdizimi ayrıştırma sırasındaki hatalar. Ayrıştırıcı tarafından oluşturulur. Numara
8 E_NOTICE Açıklamalar (uyarılardan daha az ciddi hatalar). Daha ciddi bir hataya neden olabilecek, ancak normal komut dosyası işlemi sırasında meydana gelebilecek bir durumu belirtin. Evet
16 E_CORE_ERROR PHP yüklenirken hatalar. PHP çekirdeği tarafından oluşturulan E_ERROR analogu. Numara
32 E_CORE_WARNING PHP Önyükleme Uyarıları PHP çekirdeği tarafından oluşturulan E_WARNING'e benzer. Numara
64 E_COMPILE_ERROR Kodun derlenmesi sırasında önemli hatalar. Zend motoru tarafından oluşturulan bir E_ERROR analogu. Numara
128 E_COMPILE_UYARI Derleme zamanı uyarıları. Zend motoru tarafından oluşturulan bir E_WARNING analogu. Numara
256 E_USER_ERROR Özel hata. Evet
512 E_USER_WARNING Özel uyarı. Evet
1024 E_USER_NOTICE Özel açıklama Evet

Yakalayabildiğimiz hatalarla ilgileniyoruz. Bunlar şunları içerir: E_WARNING, E_NOTICE ve E_USER_ *. Diğer hata türleri, ya PHP çekirdeğinin kendisi yüklenmeden önce meydana geldikleri için ya da PHP kodunun ayrıştırılması ve derlenmesi aşamasında ortaya çıktıkları için engellenemezler, bu nedenle çıktılarını kapatmanız yeterlidir:

ini_set ("display_errors", 0);

Ama betiklerimizin yeterince hata ayıklandığını, böylece temel sözdizimi hatalarına sahip olmadıklarını varsayıyorum, bu yüzden hiçbir şey kaybetmemeliyiz.

Varsayılan olarak, PHP'deki hata oranı E_ALL & ~ E_NOTICE (veya sayısal biçimde 2039) şeklindedir; bu, notları yok saydığımız, ancak diğer tüm hataları rapor ettiğimiz anlamına gelir.

Bu nedenle, hata çıktı seviyesini E_ALL olarak değiştirelim:

error_reporting (E_ALL);

Şimdi hata işleyiciyi yeniden tanımlayacağız ve bunun yerine şimdi hata işleme ile ilgilenecek olan işlevimizi değiştireceğiz:

set_error_handler ("user_log");

Bu fonksiyona daha yakından bakalım. 5 parametre ona iletilir:

  • hata kodu
  • hata metni
  • hatanın oluştuğu dosyanın adı
  • dosyadaki satır
  • değişken dizisi

Bu işlev herhangi bir şey döndürmek için gerekli değildir. Hata günlüğünü daha sonra göreceğimiz için, örneğin bir dosyaya günlüğü yazmamız gerekiyor, böylece daha sonra onunla çalışmak bizim için uygun olacaktır.

= (LOG_FILE_MAXSIZE * 1024)) (// log_rotate ayarlanmışsa ayarları kontrol edin, // sonra eski dosyaları bir aşağı kaydırıp boş bir günlük oluşturuyoruz // değilse, eski günlük yerine temizleyip yazıyoruz if (LOG_ROTATE === true ) ($ i = 1; // dizindeki eski günlükleri oku while (is_file (LOG_FILE_NAME. ".". $ i)) ($ i ++;) $ i--; / / her biri sırayla sayıyı 1 artırın while ($ i> 0) (yeniden adlandırın (LOG_FILE_NAME. "..". $ i, LOG_FILE_NAME. ".". (1 + $ i--));) rename (LOG_FILE_NAME, LOG_FILE_NAME. ". 1"); (LOG_FILE_NAME);'e dokunun) elseif (is_file (LOG_FILE_NAME)) (// logları yukarıdan yazarsak, // silin ve tekrar boş bir dosya oluşturun unlink (LOG_FILE_NAME); touch (LOG_FILE_NAME);)) / * böyle bir dosya olup olmadığını kontrol edin yoksa - varsa oluşturabilir miyiz - ona yazabilir miyiz * / if (! is_file (LOG_FILE_NAME)) (eğer (! touch (LOG_FILE_NAME)) ) (döndür "can \" t günlük dosyası oluşturabilir ";)) elseif ( ! is_writable (LOG_FILE_NAME)) (dönüş "can \" t günlük dosyasına yazabilir ";) // işleve dikkat edin hangi günlüğü yazıyoruz. error_log ($ err_str, 3, LOG_FILE_NAME); )?>

Tabii ki, bu tür amaçlar için daha mantıklı bir depolama alanı kullanmak mümkün olacaktır - veritabanı, ancak çoğunlukla hatalar tam olarak veritabanıyla çalışırken ortaya çıkar, bu yüzden ona güvenmem.

Aslında hepsi bu. Gerisi, özellikle dosya () işlevlerini kullanırsanız, sizin için zor olmayacağını düşünüyorum; & patlat (); ... Ve eğer öyleyse, [bu kodu burada] kullanabilirsiniz.

"Neden bu durumda kullanmak mantıklı görünen CSV'yi kullanmadım?" Sorusunu tahmin ederek yanıtlıyorum: hata mesajları bilinmeyen sayıda hizmet karakteri (diğer bir deyişle virgül ve noktalı virgül) içerebilir, bu açıkça işi zorlaştırır CSV'yi ayrıştırmak için. Ve günlüğü Excel'de görmeyeceğim.

Bu konuda hala farklı düşünceler:

  • gz günlüğü güncel değilse, "dosyayı kopyalayın ve arşive koyun;
  • aynı, ancak postaneye bir paket ile;
  • kritik hatalar oluşursa - bir posta gönderin (işlev kılavuzundaki örneğe bakın)

PHP'de oturum açmak, web uygulamanızın / sitenizin / php betiğinizin ne tür hataları size ve nasıl bildireceği anlamına gelir.

Bir uygulamadan hata almanın 2 (3) ana yolu vardır:

  1. Bu hataları doğrudan ekranda görüntüleme
  2. Bu hataları özel bir günlük dosyasına yazmak
  3. veya aynı anda her iki seçenek: bu hataları ekranda görüntüleyin ve özel bir günlük dosyasına yazın

Kural olarak, geliştirme sırasında (yerel bir ortamda) tüm hataların doğrudan ekranda gösterilmesi, böylece onları yakalamanın ve düzeltmenin daha kolay ve daha verimli olması ve savaş ortamında (üretimde) hataların giderilmesi uygulanır. hiç gösterilmez (çünkü kullanıcı için gereksiz bilgilerdir) ve bunlarla ilgili tüm bilgiler geliştiricinin düzenli olarak gözden geçirdiği bir günlük dosyasına yazılır.

Günlüğe kaydetme hataları için ayarlar

  1. error_reporting- bu en önemli parametredir. Günlük dosyasına ne tür hata mesajlarının gösterileceğinden / yazılacağından sorumludur.Kullanılabilecek sadece 2 seçenek olduğuna inanıyorum:
    • -1 (veya E_ALL) - her türlü hata rapor edilir;
    • 0 - hiçbir hata türü bildirilmez

    Yalnızca -1 (veya E_ALL) kullanmanızı öneririm.
    Çünkü Uygulamada prensip olarak herhangi bir hata olmamalıdır. Bu seçenek, php.ini dosyasındaki yapılandırma dosyası aracılığıyla veya işlev çağrılarak doğrudan php komut dosyasında ayarlanabilir. error_reporting:

    Error_reporting (-1); error_reporting (E_ALL);

    Bu arada, PHP'de işlev olarak kullanılabilen tek seçenek bu. Diğer tüm seçenekler yalnızca php.ini yapılandırma dosyasını düzenleyerek veya işlevi çağırarak ayarlanabilir. ini_set () sırasıyla, gerekli parametreyi ve bunun için değeri iletmek.

  2. display_errors- bu parametre, hataların gerçekten oluştuktan sonra ekranda doğrudan görüntülenmesinden sorumludur. Bu parametrenin değeri 0 veya 1 veya Açık / Kapalı olabilir. Onlar. ya ekranda hataları göster ya da gösterme.
  3. display_startup_errors- bu seçenek PHP başlatıldıktan sonra oluşan hataları göstermekten sorumludur. Örneğin, yapılandırma dosyasında bir sözdizimi hatası varsa, bununla ilgili bilgi gösterilecektir. Bu parametrenin değeri 0 veya 1 veya Açık / Kapalı olabilir.
  4. log_errors- bu yönerge, günlük dosyasına hata mesajlarının yazılmasından sorumludur. Bu parametrenin değeri 0 veya 1 veya Açık / Kapalı olabilir. Onlar. günlük hataları veya değil.
  5. error_log- bu ayar, uygulamada meydana gelen tüm hataları kaydedecek olan dosyanın (günlük dosyası) yolundan sorumludur.
  6. html_errors- bu seçenek, uygulama hatalarının görüntülenme biçiminden sorumludur. 1 veya Açık olarak ayarlanırsa, hata HTML kullanılarak gösterilir, yani. hatanın kaynağını takip edecek ve her şey oldukça bilgilendirici ve renkli olacaktır. Bu ayarın değeri 0 veya Kapalı olarak ayarlanırsa, hatalar az sayıda satır şeklinde düz metin olarak görüntülenecektir.

1. Ekranda hataları görüntüleme ayarları




ini_set ("html_errors", 1);
ini_set ("log_errors", 0);

2. Bir günlük dosyasına hata yazma ayarları

Error_reporting (-1); // ini_set ("hata_raporlama", -1);
ini_set ("display_errors", 0);
ini_set ("display_startup_errors", 0);
ini_set ("log_errors", 1);

3. Hataların aynı anda görüntülenmesi ve bunların bir günlük dosyasına kaydedilmesi için ayarlar

Error_reporting (-1); // ini_set ("hata_raporlama", -1);
ini_set ("display_errors", 1);
ini_set ("display_startup_errors", 1);
ini_set ("log_errors", 1);
ini_set ("html_errors", 1);
ini_set ("error_log", "/var/log/php/error.log");

Ayrıca, bu seçenekler php.ini yapılandırma dosyasında veya sanal ana bilgisayar dosyanızda ayarlanabilir.

Sitedeki tüm soruların çoğu "Yardım, çalışmıyor, başlamıyor ..." ile başlıyor. Tüm cevaplar ipuçlarına ve tavsiyelere bağlı, ancak bu yüzden hataları nasıl ve nerede arayacağımız veya günlüklerin kullanımı hakkında bir makale yazmak aklıma gelmedi, bilmiyorum. Bu nedenle, boşluğu dolduruyoruz ve herkese bu makaleyi okumasını tavsiye ediyorum.

Kayıt (kütükler) - (İng. kayıt, dosyaları daha önce görmüş olabilirsiniz * .kayıt), kural olarak, bir olay listesinin, bir olay günlüğünün, bir günlüğün, bir girişin, bir protokolün vb. kronolojik sırayla gittiği bir metin dosyası. Günlükler çeşitli programlar, hizmetler, işletim sistemleri tarafından oluşturulur. Her program kendi günlüğünü (metin dosyası) oluşturabilir.

Bir web geliştiricisi için bir site geliştirirken oluşturulan günlükler değerli olacaktır:
1. işletim sistemi günlükleri:
- Bilgisayarım - Denetim Masası - Yönetimsel Araçlar - Olay Görüntüleyici
- Bilgisayarım - Çalıştır - "eventvwr.msc"


Bu, Windows işletim sistemindeki tüm olayların kayıtlarını içerir. Burada sekmeler dahil:
- Özel Görünümler / İdari olaylar
- Windows Günlükleri / Sistem

Apache hizmetiyle ilgili günlükleri (Apache web sunucusu bir hizmet olarak çalışıyorsa) ve örneğin php uzantılarının neden olduğu diğer hataları bulabilirsiniz. Genel olarak, tüm Windows hataları burada günlüğe kaydedilir. Bir hizmet olarak Apache, Windows'un bir parçası olarak kabul edilir, bu nedenle Apache hizmetini başlatırken herhangi bir hata oluşursa, bu hatanın şifresinin çözülmesini burada da aramanız gerekir. Ayrıca, günlüklerdeki hatanın şifresinin çözülmesi sorunun ne olduğunu anlamanıza izin vermiyorsa, günlüğün ana bölümlerini google'a kopyalayın ve benzer sorunları arayın. Büyük olasılıkla size yardımcı olacak cevaplar bulacaksınız. Herhangi bir oyuna, programa, hizmete başladığınızda, bir hata oluştuğunda, günlüklerde hatanın daha ayrıntılı bir açıklamasıyla yeni bir giriş görünür. Buna dayanarak, cevabı her zaman internette bulabilirsiniz.

2. Apache seviye günlükleri:
Windows günlüklerine ek olarak, Apache'nin kendisi de bir metin dosyası biçiminde kendi günlüğünü oluşturur. Dosyada Apache web sunucusunu kurarken ve yapılandırırken httpd.conf bir satır var: ErrorLog "C: /Apache/error.log" burada, "C: /apache/error.log", Apache web sunucusu günlük dosyasının yoludur. Yolunuzu ayarlayın veya Apache'yi başlatırken hata olması durumunda, bu dosyayı açmanız ve hataların nedenlerini yansıtacak en son girişleri bulmanız gerektiğini unutmayın. Ayrıca Apache web sunucusu, her sanal ana bilgisayar için ayrı ayrı günlükler oluşturmanıza olanak tanır. Bir dosyadaki sanal ana bilgisayarlara bir örnek conf / ekstra / httpd-vhosts.conf:


DocumentRoot "C: / apache / symfony / www / web"
Sunucu Adı symfony
ServerAlias ​​www.symfony
ErrorLog "C: /apache/symfony/error.log"
CustomLog "C: /apache/symfony/access.log" ortak


DocumentRoot "C: / apache / phpmyadmin"
SunucuAdı phpmyadmin
SunucuAlias ​​www.phpmyadmin
ErrorLog "C: /apache/phpmyadmin/error.log"
CustomLog "C: /apache/phpmyadmin/access.log" ortak

3. php düzeyinde günlükler:
dosyada php yapılandırmasını ayarlarken php.ini, günlüklerin görüntüsünü yapılandırmak için aşağıdaki satırları buluyoruz:

error_reporting = E_ALL & ˜E_NOTICE & ˜E_STRICT // günlüğe kaydedilen görüntülenen hataların türleri ve türleri
log_errors = Açık // günlük kaydı etkinleştir
log_errors_max_len = 1024 // günlük dosyasının maksimum boyutunu tanımlayın (1024 bayt)
error_log = php_errors.log // günlüklerin kaydedileceği dosyanın adını belirtin, bu dosyalar sanal ana makinenizin kök dizininde oluşturulacaktır. Her ana bilgisayar için bir dosya oluşturulacaktır.

Tüm php hatalarının dosyaya yazılacağı gerçeğine ek olarak, error_log işlevini kullanarak bir php betiğinin yürütülmesi sırasında da günlükler oluşturabilirsiniz. Bu, aktif olarak try ... catch in kodunuzu kullanırsanız faydalı olabilir, bu durumda, kritik hatalar durumunda betikler sonlandırılmaz ve tüm öngörülemeyen hatalar her zaman günlüklerde not edilir.

denemek (
$r = 5/0;
) yakalama (İstisna $ hariç) (
error_log ($ exc-> getMessage());
}

Bu kodu yürütmenin sonuçlarına göre, günlük dosyasına php_errors.logşöyle bir satır eklenecek:

PHP Uyarısı: 5. satırda C: \ apache \ test \ www \ index.php'de sıfıra bölme

Hepsi bu kadar, mümkün olan her yerde günlükleri kullanın ve koddaki hataları ve yanlış veri işlemenin nedenlerini hızla bulacaksınız.

483