PHP Hata Kayıtlarını Doğru Yapılandırmak: display_errors, error_log ve log_level

PHP Hata Kayıtlarını Neden Ciddiye Almalısınız?

PHP ile çalışan her projede, ister küçük bir kurumsal site ister yoğun trafikli bir e-ticaret altyapısı olsun, hata kayıtlarının nasıl tutulduğu doğrudan projenin sürdürülebilirliğini etkiler. Birçok ekibin yaşadığı ortak sorun şu: Üretim ortamında ara ara çıkan beyaz sayfalar, rastgele 500 hataları veya kaybolan formlar… Sunucuda aslında ne olduğunu göremeyince sorunlar ya tahmin edilerek çözülmeye çalışılıyor ya da zamanla kronikleşiyor. Oysa doğru yapılandırılmış display_errors, error_log ve error_reporting (log_level) ayarlarıyla hem geliştirme sürecini hızlandırmak hem de canlı ortamı güvenli ve stabil tutmak mümkün.

DCHost olarak onlarca PHP uygulamasını taşıdığımız ve sorun giderdiğimiz projelerde gördüğümüz en temel eksik, hata loglarının ya hiç açılmamış olması ya da tersine, her şeyin ekrana basıldığı riskli ve dağınık yapılandırmalar. Bu yazıda günlük hayatta gerçekten işinize yarayacak; geliştirme, test ve canlı ortamlar için pratik PHP hata kaydı stratejilerini, tipik konfigürasyon tuzaklarını ve log dosyalarını büyütmeden yönetmenin yollarını adım adım ele alacağız. Ek olarak, PHP loglarını web sunucu logları ve disk kullanım kontrolüyle birlikte nasıl düşünmeniz gerektiğini de somut örneklerle anlatacağız.

Temel Kavramlar: display_errors, log_errors, error_log ve error_reporting

Başlamadan önce PHP tarafında en çok karıştırılan dört temel ayarı netleştirelim: display_errors, log_errors, error_log ve error_reporting. Bu dördü birlikte, hataların nerede görüneceğini, nereye yazılacağını ve hangi seviyeye kadar loglanacağını belirler.

display_errors: Hataları ekrana basmak

display_errors, PHP hatalarının HTTP çıktısına (sayfaya) yazılıp yazılmayacağını belirler. En kritik noktalardan biri budur.

Temel değerler:

• display_errors = On: Hatalar direkt olarak kullanıcıya (veya geliştiriciye) gösterilir.
• display_errors = Off: Hatalar sayfaya basılmaz, sadece loglanır (log_errors açıksa).

Geliştirme ortamında genellikle display_errors = On kullanmak hayat kurtarıcıdır; hatayı anında görür, hızlıca düzeltirsiniz. Ancak canlı ortamda display_errors kesinlikle Off olmalıdır. Aksi halde:

• Veritabanı bağlantı bilgileri, dosya yolları, sunucu kullanıcı adları gibi kritik bilgiler ziyaretçilere ifşa olabilir.
• HTML çıktısı bozulur, özellikle API veya JSON cevaplarında hatalar ciddi entegrasyon sorunları yaratır.

log_errors: Hataları dosyaya yazmak

log_errors, hataların bir log dosyasına yazılıp yazılmayacağını belirler.

• log_errors = On: Hatalar belirlenen error_log yoluna yazılır.
• log_errors = Off: PHP hiç log yazmaz; ancak web sunucusu (Apache/Nginx) seviyesinde bazı hatalar görülebilir.

Canlı ortamda log_errors her zaman On olmalıdır. Aksi halde ara ara oluşan, kullanıcıların “bazen hata alıyoruz” diye tarif ettiği problemleri geriye dönük inceleme şansınız olmaz.

error_log: Log dosyasının yolu

error_log, PHP hatalarının kaydedileceği dosyanın yolunu belirler. Örnek:

error_log = /var/log/php-errors.log

Paylaşımlı hosting ortamlarında bu ayar kimi zaman PHP-FPM havuzunda veya kullanıcı bazlı olarak önceden tanımlıdır; çoğu zaman ~/logs klasörü gibi bir yol kullanılır. VPS veya dedicated sunucuda ise yolu kendiniz belirlemeniz gerekebilir.

Dikkat edilmesi gerekenler:

• Log dosyası, PHP’nin yazma iznine sahip olduğu bir klasörde olmalı.
• Log klasörünün izinleri güvenli olmalı (örneğin 750/700 ve sadece ilgili kullanıcı tarafından erişilebilir).
• Tek bir devasa dosya yerine, logrotate gibi araçlarla dönen (rotated) log yapısı tercih edilmeli.

error_reporting (log_level): Hangi seviyeye kadar loglanacağını belirlemek

error_reporting, hangi tür PHP hatalarının loglanacağını tanımlar. Sıklıkla “log_level” olarak adlandırılır. Örneğin:

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

Başlıca hata türleri:

• E_ERROR: Ölümcül hatalar, script çalışmayı durdurur.
• E_WARNING: Uyarılar, script devam eder ama beklenmedik davranışlar olabilir.
• E_NOTICE: Bilgilendirme; genelde tanımsız değişken kullanımı gibi “kötü pratik”ler.
• E_DEPRECATED: Gelecekte kaldırılacak fonksiyon, özellik kullanımı.
• E_ALL: Tüm hata türleri.

Doğru error_reporting seviyesi, geliştirme ve canlı ortamda farklı olmalıdır. Buna birazdan detaylı değineceğiz.

Geliştirme, Test ve Canlı Ortam İçin Farklı Stratejiler

PHP hata loglamasını tek ayarla tüm ortamlar için çözmek mümkün değil. En sağlıklı yaklaşım, geliştirme, staging/test ve canlı ortam için ayrı konfigürasyonlar kullanmak.

Geliştirme ortamı için ideal ayarlar

Geliştirme ortamında temel önceliğiniz, hataları mümkün olduğunca erken ve görünür şekilde yakalamaktır. Önerilen tipik yapılandırma:

display_errors = On
display_startup_errors = On
log_errors = On
error_log = /var/log/php-dev-errors.log
error_reporting = E_ALL

Burada dikkat edilmesi gerekenler:

• Hem ekrana hem dosyaya log yazdığınız için, sorunları hem anlık görür hem de geriye dönük inceleyebilirsiniz.
• E_ALL ile tüm hata, uyarı ve deprecation mesajlarını yakalarsınız; framework veya eklentilerde gelecekte sorun çıkarabilecek kısımları da erkenden görmüş olursunuz.
• Bu ortam internete açık değilse bile, kritik verilerin loglara yazılmamasına özen gösterin (şifreler, token’lar vb.).

Staging/Test ortamı için denge

Staging/test ortamı canlıya en yakın yapı olmalı, ama hâlâ hata yakalamak için daha konuşkan (verbose) kalabilir. İyi bir strateji:

display_errors = Off
log_errors = On
error_log = /var/log/php-staging-errors.log
error_reporting = E_ALL & ~E_NOTICE

Burada:

• Hatalar ekrana basılmaz; böylece HTML/JSON çıktısı canlıya daha benzer olur.
• E_NOTICE dışındaki her şey loglanır; gereksiz gürültü büyük oranda azalır.
• Staging ortamında gerçek kullanıcı verisi kullanıyorsanız, KVKK/GDPR açısından loglarda anonimizasyon yapmayı düşünmelisiniz.

Canlı (production) ortam için güvenli ve temiz konfigürasyon

Canlı ortamda temel hedef üçlüdür: güvenlik, stabilite ve izlenebilirlik. Tipik bir canlı konfigürasyon şu şekilde olabilir:

display_errors = Off
log_errors = On
error_log = /var/log/php-prod-errors.log
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED

Bu yapılandırma:

• Kullanıcıya asla hata detayı göstermez, sadece temiz bir 500 sayfası veya uygulama bazlı hata ekranı sunarsınız.
• Önemli uyarıları ve hataları loglar, ancak gereksiz notice/deprecated gürültüsünü filtrelersiniz.
• Log dosyaları düzenli olarak döndürülür ve izlenirse, sorunları kullanıcılar fark etmeden önce yakalama şansınız olur.

Canlı ortam optimizasyonu yaparken, PHP’nin diğer kritik ayarlarını da gözden geçirmek faydalıdır. Örneğin memory_limit, max_execution_time ve upload_max_filesize gibi değerleri dengeli seçmek için şu rehbere de göz atabilirsiniz: PHP ayarlarını doğru yapmak için hazırladığımız detaylı rehber.

PHP Hata Loglarını Nereye ve Nasıl Yazdırmalı?

Hataları loglamaya karar verdiniz, ancak nereye yazdıracağınız en az ayarlar kadar önemli. Yanlış seçilmiş bir log yolu, diski dolduran devasa dosyalar veya yetki hatalarıyla sonuçlanabilir.

Merkezi log dosyası mı, site bazlı log mu?

İki yaygın yaklaşım var:

• Merkezi log dosyası: Tüm PHP uygulamaları / vhost’lar aynı dosyaya yazar (örn. /var/log/php-errors.log).
• Site bazlı log: Her domain / proje için ayrı bir PHP log dosyası kullanılır (örn. /home/user/logs/domain-php-errors.log).

Paylaşımlı hosting senaryosunda, genellikle her hesabın kendi log dizini olur ve bu dizin panel tarafından otomatik yönetilir. VPS veya dedicated sunucuda ise tercihinizi kendiniz belirlemelisiniz. Birkaç site barındırıyorsanız site bazlı log mantıklıdır; onlarca proje barındıran bir ajanssanız, merkezi log + filtrasyon (örneğin request ID veya hostname bazlı) daha yönetilebilir olabilir.

php.ini, .htaccess ve ini_set arasındaki fark

PHP hata loglama ayarlarını üç farklı seviyede değiştirebilirsiniz:

1. Global php.ini: Tüm siteleri etkiler. VPS/dedicated ortamda kök düzeyinde yapılır.
2. .htaccess veya kullanıcı bazlı ini: Belirli bir site veya dizin için geçerli olur.
3. ini_set(): Uygulama kodu içinden çalıştırıldığı anda geçerli olur (sadece o request için).

Örneğin sadece bir Laravel projesinde daha detaylı loglama yapmak istiyorsanız, public/index.php içinde:

<?php
ini_set('display_errors', '0');
ini_set('log_errors', '1');
ini_set('error_log', __DIR__ . '/../storage/logs/php-error.log');
ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);

gibi bir yapı kullanabilirsiniz. Ancak mümkün olduğunca konfigürasyonları koddan ayrı tutmak (php.ini, panel veya .htaccess üzerinden) uzun vadede daha yönetilebilir olur.

Log dosyası izinleri ve güvenlik

Log dosyalarının yetkileri, güvenlik açısından kritik bir nokta. Genel öneriler:

• Log dosyası web üzerinden erişilebilir bir dizinde olmamalı (örneğin public_html altında error.log tutmak risklidir).
• İzinler gereğinden fazla geniş olmamalı (örneğin 777 yerine 640/600).
• Aynı sunucuda başka kullanıcılar varsa (paylaşımlı ortam), log dosyalarına sadece ilgili kullanıcı ve root erişebilmeli.

Sunucu loglarının genel güvenliği ve analizi için şu yazımıza da göz atabilirsiniz: Apache ve Nginx loglarını okuyarak 4xx/5xx hatalarını teşhis etme rehberi. PHP hataları ile web sunucu hatalarını bir arada okumak, sorun çözme sürecini ciddi şekilde hızlandırır.

Log dosyalarının şişmesini önlemek: logrotate ve disk kullanımı

İyi yapılandırılmış bir PHP log sistemi bile, logrotate veya benzeri bir döndürme mekanizması yoksa kısa sürede diski doldurabilir. Özellikle yoğun trafikli sitelerde birkaç gün içinde onlarca GB’lık php-errors.log dosyası görmek mümkün.

Linux ortamında tipik bir logrotate yapılandırması şöyle olabilir:

/var/log/php-prod-errors.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
    postrotate
        systemctl reload php-fpm.service > /dev/null 2>&1 || true
    endscript
}

Bu sayede:

• Her gün yeni dosya açılır, eskiler sıkıştırılır.
• Belirli bir süre (örneğin 14 gün) sonrasına ait loglar otomatik silinir.
• PHP-FPM log dosyasını yeniden açacak şekilde reload edilir.

Disk doluluğu sorunlarını önlemek için detaylı bir rehbere ihtiyacınız varsa, VPS disk kullanımı ve logrotate ile “No Space Left on Device” hatasını önleme rehberimizi mutlaka inceleyin.

Doğru log_level (error_reporting) Seçimi

PHP’de hata seviyelerini doğru seçmek, hem log dosyanızdaki gürültüyü azaltır hem de önemli sinyalleri kaçırmanızı engeller. error_reporting ayarını, kod tabanınızın olgunluğu ve framework’ünüzün davranışına göre optimize etmelisiniz.

E_ALL her zaman iyi mi?

Geliştirme ortamında E_ALL neredeyse her zaman mantıklıdır. Tüm uyarıları görmek, gelecekte sorun çıkarabilecek kod parçalarını erkenden düzeltmenizi sağlar. Ancak canlı ortamda E_ALL kullanmak, özellikle eski eklenti ve temalarla çalışan WordPress veya karmaşık kurumsal uygulamalarda:

• Log dosyalarının çok hızlı şişmesine,
• Binlerce E_NOTICE ve E_DEPRECATED mesajı arasında asıl kritik hataları kaçırmanıza

sebep olabilir.

Canlı ortam için pratik bir seviye

Çoğu proje için uygulanabilir bir başlangıç seviyesi şudur:

error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED

Böylece:

• Gerçek hataları (E_ERROR, E_WARNING vb.) ve önemli uyarıları görürsünüz.
• Hâlâ belli ölçüde gürültü olabilir; logları izleyip, projenize özel filtrelemeler yapabilirsiniz.

Framework seviyesinde kendi log sistemi (örneğin Laravel, Symfony, WordPress debug.log) olan projelerde, PHP error_reporting ayarını daha konservatif tutup, detaylı debug’u framework loglarına bırakmak da iyi bir yaklaşımdır.

Deprecation (E_DEPRECATED) uyarılarını ne yapmalı?

PHP 7.x’ten 8.x’e geçişte birçok fonksiyon ve davranış “deprecated” oldu. Geliştirme/staging ortamında E_DEPRECATED uyarılarını mutlaka görmenizi öneririz; çünkü bir sonraki major versiyonda bu fonksiyonlar tamamen kaldırılabilir.

Bu nedenle:

• Geliştirme/staging: error_reporting = E_ALL veya en azından E_DEPRECATED içerecek bir kombinasyon.
• Canlı: Gürültü çok fazlaysa ~E_DEPRECATED ile filtreleyin, ama düzenli olarak staging ortamındaki deprecated uyarılarını gözden geçirin.

Güvenlik, Performans ve Yasal Boyut

PHP hata loglarını yapılandırırken yalnızca “hata görünsün yeter” demek uzun vadede sorun getirir. Güvenlik, performans ve hukuki gereksinimleri birlikte düşünmek gerekiyor.

Güvenlik: Hata mesajlarında veri sızıntısı

En temel kuralı tekrar vurgulayalım: Canlı ortamda display_errors daima Off olmalı. Aksi halde:

• Veritabanı bağlantı string’leri (hostname, kullanıcı adı, şifre),
• Dosya yolları (uygulamanın dizin yapısı, kullanıcı isimleri),
• Üçüncü parti API anahtarları veya token parçaları

ziyaretçilere (veya botlara) ifşa olabilir. Bu, sadece teorik bir risk değil; hacklenmiş PHP sitelerinde gördüğümüz backdoor’ların önemli kısmı, saldırganların hata mesajlarından öğrendikleri dizin ve konfigürasyon bilgilerine dayanıyor. Bu konuda daha geniş bir perspektif edinmek için hacklenmiş PHP sitelerini temizleme rehberimizde paylaştığımız gerçek senaryolara göz atabilirsiniz.

Performans: Çok fazla log yazmanın bedeli

Loglama ücretsiz değil; her log satırı disk I/O demek. Özellikle:

• Yoğun trafik altında her istekte onlarca NOTICE ve DEPRECATED üreten uygulamalar,
• SSD yerine yavaş disk kullanılan ortamlarda,
• Log sıkıştırma ve döndürme doğru yapılandırılmadığında

log yazma işlemleri fark edilir performans kaybına yol açabilir. Bu, özellikle CPU ve disk I/O’su sınırlı paylaşımlı hosting ortamlarında daha hızlı hissedilir. DCHost altyapısında NVMe diskler ve doğru yapılandırılmış logrotate ile bu etkiyi minimize ediyoruz; ancak uygulama seviyesinde gereksiz log gürültüsünü azaltmak hâlâ sizin elinizde.

KVKK/GDPR ve log anonimleştirme

Hata logları çoğu zaman IP adresi, kullanıcı ajanı, URL parametreleri ve bazen de kullanıcıya ait kişisel verileri içerebilir. KVKK ve GDPR kapsamında bu verilerin:

• Gereğinden uzun süre saklanmaması,
• Mümkün olduğunca anonimleştirilmesi (IP maskeleme vb.),
• Yetkisiz kişilerce erişilemeyecek şekilde korunması

gerekiyor. Özellikle e-ticaret ve üyelikli sistemlerde, hata loglarında istemeden kişisel veri birikmesi yaygın bir durum. Bu konuda detaylı teknik örnekler için KVKK ve GDPR için log anonimleştirme rehberimizi inceleyebilirsiniz.

DCHost Ortamında Pratik Öneriler

DCHost olarak hem paylaşımlı hosting, hem VPS, hem de dedicated sunucu ve colocation ortamlarında PHP tabanlı yüzlerce projeyi barındırıyoruz. Sahada işleyen, pratik birkaç öneriyi doğrudan paylaşalım.

Paylaşımlı hosting kullanıcıları için

• cPanel veya benzeri panelinizde PHP Selector / MultiPHP gibi araçlar varsa, display_errors ve error_reporting ayarlarını buradan yönetmeyi tercih edin.
• Log dosyalarınız genelde logs klasörü altında tutulur; düzenli aralıklarla boyutlarını kontrol edin.
• WordPress kullanıyorsanız, wp-config.php içinde WP_DEBUG_LOG ve WP_DEBUG_DISPLAY ayarlarını canlı ortamda dikkatle yönetin; hataları kullanıcıya değil sadece log dosyasına yazdırın.

Paylaşımlı ortamda beyaz ekran, beklenmedik 500 hataları gibi sorunlarla karşılaşıyorsanız, WordPress beyaz ekran hatası çözümü rehberimizde paylaştığımız PHP ve log ayarları da işinize yarayacaktır.

VPS ve dedicated sunucu kullanıcıları için

Kendi VPS veya fiziksel sunucusunu kullanan ekipler için birkaç ekstra tavsiye:

• PHP-FPM havuzlarını site bazlı ayarlayın ve her havuz için php_admin_value[error_log] ile ayrı log dosyaları tanımlayın.
• Log dosyalarınızı merkezi bir sistemde toplamak (örneğin Loki, ELK vb.) istiyorsanız, PHP loglarını da aynı pipeline’a dahil edin.
• VPS üzerinde kapsamlı bir log mimarisi kurmak isterseniz, VPS log yönetimi ve merkezi loglama rehberimizde Loki + Promtail gibi çözümlerle nasıl entegre edebileceğinizi detaylı anlattık.

DCHost ekibinin sık kullandığı kontrol listesi

Yeni bir PHP projesi DCHost altyapısına taşındığında genellikle şu mini kontrol listesini uyguluyoruz:

1. Canlı ortamda display_errors = Off mu?
2. log_errors = On ve error_log yolu web kökünün (public_html) dışında mı?
3. error_reporting seviyesi, logları gereksiz doldurmayacak şekilde optimize edilmiş mi?
4. Logrotate veya benzeri bir mekanizma ile loglar döndürülüyor mu?
5. Log dosyaları KVKK/GDPR açısından makul bir süre sonra otomatik siliniyor veya arşivleniyor mu?

Bu 5 adımı geçirip düzeltmek, çoğu projede hem stabiliteyi hem de izlenebilirliği gözle görülür şekilde artırıyor.

Özet ve Sonraki Adımlar

PHP hata kayıtlarını doğru yapılandırmak, “bir kere ayarlayıp unuturuz” türünden bir iş değil; geliştirme, test ve canlı ortamlar arasında bilinçli farklar koymanız gereken, güvenlik, performans ve yasal gereksinimlerle iç içe bir süreç. Bu yazıda display_errors, log_errors, error_log ve error_reporting (log_level) ayarlarının pratikte nasıl bir araya gelmesi gerektiğini; geliştirme ortamında daha konuşkan, canlı ortamda ise daha kontrollü bir log stratejisinin neden kritik olduğunu detaylandırdık.

Bir sonraki adım olarak, kendi projenizde hangi ortamda hangi ayarların geçerli olduğunu gerçekten doğrulamanızı öneririm. Küçük bir PHP test dosyasıyla phpinfo() çıktısını kontrol edin, log dosyalarınızın gerçekten yazıldığını ve döndürüldüğünü teyit edin. Ardından, web sunucusu loglarınızla birlikte okuyarak; yavaş istekler, 4xx/5xx hataları ve PHP fatal error’lar arasındaki bağlantıyı inceleyin. Bu noktada hem sunucu loglarını okuma rehberi hem de geliştirme, test ve canlı ortam mimarisi yazımız size iyi bir yol arkadaşı olacaktır.

Eğer DCHost üzerinde paylaşımlı hosting, VPS, dedicated sunucu veya colocation hizmetlerinden birini kullanıyorsanız ve PHP hata loglarınızı nasıl optimize edeceğiniz konusunda emin değilseniz, teknik ekibimizle ticket açarak mevcut konfigürasyonunuzu birlikte gözden geçirebiliriz. Doğru konfigüre edilmiş bir log altyapısı, hem beklenmedik kesintileri azaltır hem de sorun çıktığında panik yerine sakin ve veriye dayalı hareket etmenizi sağlar.