Apache ve Nginx Loglarıyla 4xx–5xx Hatalarını Teşhis Etmek

Sunucu loglarını anlayamadan sorun çözmek neden bu kadar zor?

Bir web projesinin kapasite planlamasında günlük ziyaretçi, saniyede istek, CPU ve RAM kullanım oranları değerlendirilebilir. Bu verileri tamamlayan bir kaynak da sunucu loglarıdır. Access ve error loglarını sistematik şekilde okumak, yaşadığınız 4xx–5xx hatalarını tahminlerle değil, kayıtlarla araştırmanıza yardımcı olur. “Herhalde cache yüzünden” veya “Muhtemelen bir eklenti bozdu” gibi varsayımları değerlendirmek için ilgili kayıtları ve diğer izleme verilerini birlikte incelemek gerekir.

Logların mevcut olması, onların karar almak için kullanıldığı anlamına gelmez. Apache/Nginx access ve error logları, kaydedilen istekleri ve sunucu mesajlarını incelemenizi sağlar. 404’lerin SEO açısından önemini, 500 hatalarının siparişlere veya 503 hatalarının kampanya trafiğine etkisini değerlendirmek için bu kayıtları arama performansı ve uygulama verileriyle birlikte ele almak gerekir. Bu yazıda, bir sistem yöneticisi kadar derine inmeden, ama bir geliştiricinin işini görecek kadar detayla hosting sunucu loglarını okumayı, özellikle de 4xx–5xx hatalarını teşhis etmeyi anlatacağız. Örnek komutlar, gerçekçi senaryolar ve log analizini kolaylaştıracak pratiklerle ilerleyeceğiz.

Hangi log dosyaları nerede? Apache ve Nginx yol haritası

Önce “nerede ne var?” sorusunu netleştirelim. Apache ve Nginx tabanlı bir Linux sunucuda tipik olarak iki ana log türüyle ilgilenirsiniz: access log ve error log.

Access log nedir, ne işe yarar?

Access log, web sunucusuna ulaşan HTTP isteklerini etkin log yapılandırmasının kapsamına göre satır satır kaydeder. Her satırda tipik olarak şunlar yer alır:

• İstek yapan IP adresi
• Tarih ve saat
• HTTP methodu (GET, POST vb.)
• İstenen URL
• HTTP durum kodu (200, 301, 404, 500…)
• Cevap boyutu
• Referer (isteğin geldiği sayfa)
• User-Agent (tarayıcı / bot bilgisi)

4xx–5xx hatalarını analiz ederken ilk bakacağınız yer çoğu zaman access log’dur; çünkü hangi URL’lerin ne sıklıkla hata verdiğini buradan çok hızlı görebilirsiniz.

Error log nedir, ne işe yarar?

Error log, web sunucusunun hata ve uyarı mesajlarını içerir; yapılandırmaya bağlı olarak uygulamadan aktarılan mesajlar da burada görülebilir. PHP-FPM ve uygulama loglarını ayrıca incelemek gerekebilir. Örnekler:

• Dosya bulunamadı (File does not exist)
• Yetki hatası (Permission denied)
• PHP fatal error, parse error
• Upstream timeout (504) veya bad gateway (502) mesajları
• Konfigürasyon hataları

Access log size “ne oldu?”yu gösterirken, error log “neden oldu?” sorusu için ipuçları sağlar. İkisini birlikte okumak, özellikle 5xx hatalarında kök neden analizini destekler; ancak her hata için açıklayıcı bir error log kaydı bulunmayabilir.

Googlebot isteklerinde 5xx görülüyorsa “Googlebot 5xx Hataları: Hosting Kaynaklı Crawl Sorunları” rehberi, Search Console bulgularını sunucu loglarıyla aynı zaman aralığında karşılaştırmayı açıklar.

Varsayılan log yolları

Dağıtıma, panele ve kuruluma göre yollar değişebilir; ama sık görülen dizinler şunlardır:

• Apache access log: /var/log/apache2/access.log veya /var/log/httpd/access_log
• Apache error log: /var/log/apache2/error.log veya /var/log/httpd/error_log
• Nginx access log: /var/log/nginx/access.log
• Nginx error log: /var/log/nginx/error.log

cPanel, Plesk, DirectAdmin gibi panelli ortamlarda her domain için ayrı log dosyaları da olabilir. Aşağıdaki komutları sunucuda çalıştırmak için kabuk/SSH erişimi ve ilgili dosyaları okuma yetkisi gerekir. Paylaşımlı hosting hesaplarında SSH veya /var/log altındaki dosyalara erişim bulunmayabilir. Gerçek log yollarını ve erişim yöntemini sağlayıcınızın ya da panelinizin belgelerinden netleştirin; panelden log indirme veya destek üzerinden kayıt isteme seçeneklerini sorun. İndirilen loglar da uygun araçların bulunduğu yerel bir ortamda, dosya yolları uyarlanarak incelenebilir. Log saklama politikalarıyla ilgili daha detaylı bir perspektif için hosting ve e-posta altyapısında log saklama süreleri hakkında detaylı rehber yazımıza da göz atabilirsiniz.

Access log formatını okumayı öğrenmek

Access log, başta karmaşık görünür ama bir kez formatı çözdüğünüzde gözünüz alışır. Apache için klasik bir satır örneği:

203.0.113.10 - - [05/Dec/2025:10:15:32 +0300] "GET /urun/123 HTTP/1.1" 404 512 "https://www.example.com/kategori/ayakkabi" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Bu satırı parçalara ayıralım:

• 203.0.113.10: Kaydedilen istemci IP adresi. Güvenlik, bot trafiği ve rate limiting için önemli; ancak proxy/CDN arkasında gerçek ziyaretçiyi temsil edip etmediği log yapılandırmasına bağlıdır.
• [05/Dec/2025:10:15:32 +0300]: Sunucunun log saat dilimine göre zaman damgası.
• “GET /urun/123 HTTP/1.1”: HTTP methodu, path ve protokol.
• 404: HTTP durum kodu. Burada kritik kısmımız bu.
• 512: Cevap gövdesinin bayt cinsinden boyutu.
• “https://www.example.com/kategori/ayakkabi”: Referer; istemcinin bildirdiği kaynak sayfa.
• User-Agent: İstemcinin bildirdiği tarayıcı ya da bot bilgisi. Bu iki alan eksik veya yanıltıcı olabilir; tek başına kaynak ya da bot kimliğini doğrulamaz.

Nginx’te de benzer bir “combined” format kullanılır. Özelleştirilmiş formatlarda alan sırası değişebilir; istek süresi ve upstream süresi gibi metrikler eklenebilir. Konfigürasyonda log_format direktifiyle bu alanları özelleştirmek mümkündür.

Gerçekçi bir senaryo: 404 yağmuru nereden geliyor?

Varsayalım ki SEO ekibiniz, “Son haftada 404 hataları artmış” diyor. Aşağıdaki komutlar ilk inceleme içindir: yalnızca mevcut access.log dosyasını, zaman filtresi olmadan tararlar. Tek başlarına son haftanın tamamını, haftalık URL sıralamasını veya bir artışı göstermezler.

Haftalık analiz için önce başlangıç ve bitiş zamanını logların saat dilimine göre belirleyin. İlgili site ve sunuculardaki mevcut dosyayla birlikte bu aralığı kapsayan döndürülmüş ve sıkıştırılmış logları da incelemeye katın; eksik veya yinelenen kayıt olup olmadığını kontrol edin. Toplanan kayıtlardan yalnızca seçilen zaman aralığını ayırdıktan sonra durum koduna göre filtreleme ve URL sayımı yapın. Saklama süresi nedeniyle kayıtlar eksikse tam haftaya ilişkin sonuç çıkarmayın. Artışı değerlendirmek için aynı kapsam ve eşit süreyle seçilmiş karşılaştırılabilir bir dönem kullanın; trafik hacmi değişebileceğinden 404 sayısının yanında toplam isteklere oranını da karşılaştırın.

1. Önce access log’dan 404 kodlarını filtrelersiniz. Aşağıdaki komutlar, yukarıdaki örnek gibi durum kodunun dokuzuncu, path’in yedinci boşlukla ayrılmış alan olduğu satırlar içindir; farklı formatlara uyarlanmalıdır:

   awk '$9 == "404"' /var/log/nginx/access.log | head
   

2. Daha sonra en çok hangi URL’lerin 404 verdiğini görmek istersiniz:

   awk '$9 == "404" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20
   

   Bu örnekte $7 alanı istenen path’i temsil ediyor (formatınıza göre değişebilir).

3. Sonuçta /blog/eski-yazi veya /urun/123 gibi sık tekrarlanan path’ler görebilirsiniz. Eşdeğer bir yeni sayfa varsa 301 yönlendirme, yanlışlıkla kaldırılmış içerik için yeniden yayınlama düşünülebilir. İçerik gerçekten yoksa ve uygun bir karşılığı bulunmuyorsa 404’ü korumak veya kalıcı kaldırma için 410 kullanmak da seçeneklerdir.

404 ve diğer durum kodlarının SEO etkisini derinlemesine anlamak isterseniz, HTTP durum kodları ve SEO etkileri yazımız bu yazıyı güzel tamamlar.

Error log ile 4xx ve 5xx kök neden analizi

Access log size “hangi URL hata veriyor?”u söyledi, şimdi sıra “neden?” sorusunda. Bu aşamada error log devreye girer.

404 ve 403 için tipik error log mesajları

Apache 2.4 için temsili örnekler aşağıdadır. Dosya bulunamadı mesajı info düzeyindedir ve varsayılan warn seviyesinde error log’a yazılmaz. Bu mesajları görmek için ilgili core modülünde info düzeyini kapsayan bir LogLevel ayarı gerekir; resmî belgede LogLevel warn core:info örneği verilir. Her 404 yanıtında açıklayıcı bir error log kaydı bulunacağını varsaymayın:

[Fri Dec 05 10:15:32.123456 2025] [core:info] [pid 12345] [client 203.0.113.10:51234] AH00128: File does not exist: /var/www/html/urun/123
[Fri Dec 05 10:16:01.654321 2025] [authz_core:error] [pid 12346] [client 198.51.100.5:42311] AH01630: client denied by server configuration: /var/www/html/admin

• File does not exist: Çoğu zaman 404 ile sonuçlanır. Yanlış URL, eksik deploy, silinmiş dosya gibi durumları gösterir.
• client denied by server configuration: Tipik olarak 403 (Forbidden). IP bazlı kısıtlama, dizin yetkisi veya .htaccess ile getirilen yasaklar olabilir.

5xx araştırması: upstream bağlantısının erken kapanması

5xx kategorisi, sunucu taraflı sorunları işaret eder. Nginx üzerinden bir örnek:

2025/12/05 10:20:11 [error] 1234#1234: *56789 upstream prematurely closed connection while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /odeme HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Bu mesaj, Nginx’in PHP-FPM’den yanıt başlığını okurken upstream bağlantısının erken kapandığını bildirir. Tek başına bir zaman aşımını, istemciye dönen durum kodunu veya kök nedeni kanıtlamaz; bunları aynı isteğin access log kaydı ve PHP-FPM loglarıyla karşılaştırın. İncelenebilecek alanlar:

• PHP-FPM süreçlerinin beklenmedik kapanma veya sonlandırılma kayıtları
• PHP-FPM süreç kapasitesi ve bekleyen istekler
• Uzun süren sorgular ve harici API çağrıları
• CPU ve RAM kullanımı ile bellek yetersizliği nedeniyle süreç sonlandırma kayıtları

Paylaşımlı hosting kullanıyorsanız, limitlere takılma konusunu anlamak için cPanel’de kaynak limitleri ve ‘Resource Limit Reached’ hatası yazısı, bu bölümle güzel bir bağ kuracaktır.

4xx hatalarını teşhis etmek: 400, 401, 403, 404, 410

4xx kodları istemci hatası sınıfındadır; ancak yanlış yönlendirme, bozuk link, eksik deploy gibi sizin çözebileceğiniz problemlerle de ilişkili olabilir. Her 4xx bir arıza değildir: bulunmayan bir URL’ye 404 veya erişimi bilerek kısıtlanan bir alana 403 dönmesi beklenen davranış olabilir.

404: Bulunamayan URL’lerin SEO açısından değerlendirilmesi

404, istenen kaynağın bulunamadığını bildirir; gerçekten kaldırılmış veya hiç var olmamış URL’lerde beklenen bir yanıttır. Erişilebilir olması gereken sayfalardaki 404’leri önceliklendirmek için sorulacak sorular:

• 404 alan URL’ler gerçekten artık var olmayacak sayfalar mı?
• Bu URL’ler arama motorlarında indexlenmiş mi?
• Bu URL’lere site içi link veriliyor mu?

Access log üzerinden en çok 404 alan ilk 100 URL’i çıkarıp, SEO ekibiyle birlikte “404 olarak kalmalı mı, ilgili bir karşılığa 301 mi, kalıcı kaldırma için 410 mu, yeniden yayın mı?” kararını verebilirsiniz. 410 (Gone) kullanımı, özellikle gerçekten kaldırdığınız sayfalarda arama motorlarına daha net sinyal vermenizi sağlar. Bu kodların hepsinin SEO tarafındaki davranışlarını daha derin okumak isterseniz, yine HTTP durum kodları rehberimiz elinizin altında olsun.

403: Yetkisiz erişim mi yanlış konfigürasyon mu?

403 (Forbidden), isteğin anlaşıldığını ancak yerine getirilmesinin reddedildiğini bildirir. İncelenebilecek iki örnek durum:

1. Bilerek yasakladığınız alanlar (admin panelini IP ile kısıtlamak gibi).
2. Farkında olmadan bozduğunuz yetkiler, .htaccess veya Nginx kuralı.

Error log’da client denied by server configuration veya benzeri mesajlar görüyorsanız, önce ilgili erişim denetimi kurallarını ve konfigürasyon bloklarını kontrol edin. Dosya sistemi izinlerini de ilgili hata mesajlarıyla birlikte değerlendirin. Siteniz birdenbire 403 vermeye başladıysa son değişiklikleri (yeni güvenlik kuralı, WAF, .htaccess) hata zamanıyla karşılaştırın; yalnızca zaman yakınlığına dayanarak nedenin bu değişiklikler olduğunu varsaymayın.

400/401: Yanlış istek ve kimlik doğrulama sorunları

400 (Bad Request) çoğu zaman bozuk bir istek, hatalı header veya reverse proxy katmanındaki uyumsuzluklardan kaynaklanır. 401 (Unauthorized) ise genellikle basic auth, JWT veya uygulama içi login mekanizmalarınızla bağlantılıdır. Bu kodlar için:

• Access log’dan en çok 400/401 alan endpoint’leri çıkarmak
• Error log’da ilgili zaman aralığındaki detay mesajları incelemek
• İstemci tarafında (özellikle API çağrılarında) gönderilen header’ları kontrol etmek

Bu adımlar olası nedeni daraltmaya yardımcı olabilir; gerektiğinde kimlik doğrulama servisi ve uygulama loglarını da aynı istekle ilişkilendirin. Header örneklerini paylaşırken parolaları, oturum belirteçlerini ve diğer gizli bilgileri maskeleyin.

5xx hatalarını teşhis etmek: 500, 502, 503, 504

5xx kodları, sunucunun isteği yerine getirirken hata bildirdiğini gösterir. Sunucu tarafı altyapı, uygulama, konfigürasyon veya bağımlı servisler incelenmelidir; kod tek başına hatanın kaynağını belirlemez.

500 Internal Server Error: PHP ve uygulama hataları

PHP uygulamalarında 500 hataları, fatal error veya syntax error kaynaklı olabilir. Loglama yapılandırmasına göre Apache error log’unda veya PHP/PHP-FPM loglarında görülebilecek örnek:

PHP Fatal error:  Uncaught Error: Call to undefined function get_product_price() in /var/www/html/app/cart.php:120

Bu tip bir hata kaydı, dosya ve satır numarasıyla birlikte araştırma için bir başlangıç noktası sağlar. Uygulama geliştiriciniz ilgili kodu, bağımlılıkları ve dağıtım değişikliklerini inceleyerek nedeni doğrulayabilir; logdaki konum tek başına gerekli düzeltmeyi belirlemez.

502 Bad Gateway ve 504 Gateway Timeout: Nginx ve upstream sorunları

Bir VPS veya dedicated sunucuda Nginx’in istekleri PHP-FPM ya da başka bir uygulama sunucusuna (Node.js, Gunicorn, vb.) ilettiği bir mimari kullanılabilir. 502/504 hatalarının yaygın nedenleri:

• Uygulama sürecinin çökmesi veya hiç başlamamış olması
• Uzun süren sorgularla tıkanan PHP-FPM havuzları
• Nginx proxy_read_timeout / fastcgi_read_timeout sürelerinin çok kısa ayarlanması
• Bellek yetersizliği nedeniyle süreçlerin öldürülmesi veya CPU darboğazı nedeniyle yanıtların gecikmesi

Nginx error log’da upstream timed out, upstream prematurely closed connection gibi mesajlar görürseniz, bir sonraki adımınız uygulama logları ve sistem kaynak kullanımını incelemektir.

503 Service Unavailable: Kapasite ve bakım sinyali

503, hizmetin isteği geçici olarak karşılayamadığını bildirir. Bakım ve kapasite sorunları için iki örnek senaryo:

1. Sunucuyu bilinçli olarak bakıma almışsınızdır.
2. Kapasite yetmediği için süreçler yeni bağlantıları reddediyordur.

Örneğin yoğun bir kampanya sırasında kısa süreli ama tekrarlayan 503’ler oluştuğunu varsayalım. Bu noktada yoğun trafikli kampanyalar için hosting ölçeklendirme rehberi ve kaynak planlama yazılarımızdan yararlanabilirsiniz. Loglar ve kaynak metrikleri kapasite darboğazını doğruluyorsa, konfigürasyonun yanında kapasite tasarımını da ele almak gerekir.

Konsoldan log okuma ve filtreleme: Pratik komutlar

Logları okumayı öğrenmenin ikinci ayağı, onları komut satırından hızlıca filtreleyebilmektir. İşinize en çok yarayacak birkaç temel komutu toparlayalım.

tail ile canlı log izleme

tail -f /var/log/nginx/access.log

Bu komut, access log’a yeni satır eklendikçe canlı olarak görmenizi sağlar. Özellikle deploy sonrası veya bir hatayı tekrar üretirken çok işe yarar.

grep ile durum kodu veya URL metnini aramak

# 500 hatalarını bul
grep " 500 " /var/log/nginx/access.log

# Belirli bir URL için tüm istekler
grep "/odeme" /var/log/nginx/access.log

Bu grep örnekleri durum kodu veya URL alanını ayrıştırmaz; satırın herhangi bir yerindeki eşleşmeyi döndürür. Örneğin “ 500 ” yanıt boyutu alanında, “/odeme” ise referer içinde de bulunabilir. Kesin sayım öncesinde eşleşmenin ilgili alanda olduğunu doğrulayın. Çıktıyı başka komutlara pipe ederek daha gelişmiş analizler yapabilirsiniz.

Hata sıralaması için aday IP ve URL’leri bulmak

# En çok 404 üreten ilk 10 IP
grep " 404 " /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 10

# En çok 500 üreten ilk 20 URL
grep " 500 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -n 20

Bu komutlar, boşlukla ayrılmış alanlarda IP’nin birinci, istek hedefinin yedinci alan olduğu log düzenini varsayar. Özel log formatlarında alan numaralarını uyarlayın. Önceki grep sınırlaması burada da geçerlidir: sonuçlar kesin hata sıralaması değil, durum kodu alanı doğrulanması gereken aday listelerdir. Doğrulanmış kayıtlar güvenlik, SEO ve uygulama hataları için ipucu sağlayabilir.

Sıkıştırılmış eski logları incelemek: zgrep

Birçok sistemde eski loglar .gz olarak sıkıştırılır. Eski bir sorunu geçmişe dönük incelemek için:

zgrep " 500 " /var/log/nginx/access.log.1.gz | head

komutunu kullanabilirsiniz. Bu da satır içi metin aramasıdır; bulunan “ 500 ” değerinin durum kodu alanında olduğunu doğrulayın.

E-ticaret ve SaaS senaryoları: 4xx–5xx ile gelir kaybı riskini araştırmak

E-ticaret sitelerinde gerçek kullanıcıların sepet ve ödeme adımlarındaki 4xx–5xx hataları sipariş kaybı riski oluşturabilir. Loglar sorunlu istekleri gösterir; terk edilen sepetleri ve gelir etkisini belirlemek için bu kayıtları sipariş ve dönüşüm verileriyle birlikte değerlendirmek gerekir.

• /sepet endpoint’inde 200 oranı yüksek ama /odeme endpoint’inde 5xx artıyorsa, ödeme adımında uygulama, entegrasyon veya altyapı sorunu olabilir.
• Belirli kampanya URL’lerinden gelen trafikte 404 artışı varsa, bozuk link, kaldırılmış sayfa veya eksik yönlendirme olasılıklarını inceleyin.
• Belirli bir IP aralığından gelen isteklerde 403/429 oranları yüksekse, WAF veya rate limiting kayıtlarıyla karşılaştırın. Meşru istekler engelleniyor olabilir; ancak yüksek oran, kuralların istenmeyen trafiği doğru biçimde engellemesinden de kaynaklanabilir.
• SaaS projelerinde giriş, abonelik yenileme veya kritik API endpoint’lerindeki 4xx–5xx oranlarını izleyin. Örneğin abonelik yenileme isteğinde 5xx görülmesi işlemin tamamlanmadığını tek başına kanıtlamaz; aynı zaman aralığındaki uygulama olayları ve abonelik/ödeme kayıtlarıyla sonucu doğrulayın.

Bu konuyu pratik alarm kurallarıyla birlikte ele aldığımız e-ticaret sepet ve ödeme adımlarını loglarla izlemek yazısı, burada bahsettiğimiz yaklaşımı bir adım ileri taşıyıp otomasyona dönüştürmek için iyi bir kaynak olacaktır.

Log saklama, KVKK ve operasyonel pratikler

Log okumayı öğrendikten sonra gelen bir sonraki soru şudur: Bu logları ne kadar süre saklamalıyız? Cevap; teknik ihtiyaçlar, yasal zorunluluklar ve gizlilik politikalarınızın kesişiminde bulunur.

• Performans ve hata analizi için örneğin 30–90 günlük bir pencere değerlendirilebilir; bu bir standart veya hukuki süre değildir. Süreyi analiz ihtiyacına ve veri minimizasyonuna göre belirleyin.
• Güvenlik olaylarını araştırmak için gereken süreyi ayrıca değerlendirin; daha uzun saklama ihtiyacını gerekçelendirin.
• IP gibi kişisel veriler içerebilen loglar için saklama ve silme sürelerini, erişim yetkilerini ve paylaşım kurallarını politikanızda tanımlayın. Uygulanabilir KVKK/GDPR yükümlülüklerini hukuki değerlendirmeyle netleştirin.

Bu dengeyi kurarken, hem log saklama süreleri hakkında detaylı rehber yazımızı hem de KVKK ve GDPR uyumlu hostingte loglama yaklaşımı yazımızı birlikte okumanızı öneririz. Bu rehberler planlamaya yardımcı olabilir; hukuki uygunluk, size uygulanabilen yükümlülüklerin ayrıca değerlendirilmesini gerektirir.

Çok sunuculu altyapıda log yönetimi ve merkezi izleme

Tek bir VPS’te SSH ile log okumak nispeten kolaydır. Ancak birkaç VPS, staging/canlı ortamı, belki ayrı veritabanı ve cache sunucuları devreye girdiğinde log yönetimi hızla karmaşıklaşır. Bu noktada iki yaklaşım öne çıkar:

1. Yerel log okuma: Her sunucuya SSH ile bağlanıp tail, grep komutlarını kullanmak.
2. Merkezi loglama: Tüm sunuculardaki logları tek bir platformda toplayıp arama, filtre ve dashboard üzerinden görmek.

Birden fazla VPS veya dedicated sunucu kullanılan ortamlarda ikinci yaklaşım değerlendirilebilir. Yeni merkezi loglama kurulumlarında Grafana Loki’ye log göndermek için Grafana Alloy gibi desteklenen bir toplayıcı kullanın; access ve error loglarını merkezi olarak sorgulayıp 4xx–5xx artışlarını grafiklerle izleyebilirsiniz. Grafana’nın resmi uyarısına göre Promtail, 2 Mart 2026 itibarıyla kullanım ömrünü tamamlamıştır (EOL); ticari desteği sona ermiştir ve gelecekte destek veya güncelleme sağlanmayacaktır. Yeni özellik geliştirmeleri Grafana Alloy’da yapılacaktır. Bu durum lambda-promtail istemcisini kapsamaz. Mevcut Promtail kullanıcılarının Alloy’a veya başka bir desteklenen istemciye geçmesi gerekir. VPS log yönetimini merkezi hale getirmek rehberimiz, eski Promtail tabanlı kurulum için bir referanstır; yeni kurulum başlangıcı olarak kullanılmamalıdır. Bu mimarideki Promtail toplayıcısını değiştirmek için Grafana’nın resmi Promtail sayfasındaki güncel geçiş yönlendirmelerini izleyin; mevcut yapılandırmanın Alloy’da değiştirilmeden çalışacağını varsaymayın.

Merkezi loglama tasarımında, kritik 4xx–5xx artışlarını ilgili ekiplere ileten alarm kuralları tanımlanabilir. Yönetilen bir hizmet seçerken log analizinin kapsamını, alarm alıcılarını ve müdahale sorumluluklarını hizmet sözleşmesinde netleştirin.

Özet ve sonraki adımlar

Hosting sunucu loglarını okumayı öğrenmek, ilk bakışta “sistemci işi” gibi görünebilir. Oysa bir ürün yöneticisinden SEO uzmanına, backend geliştiriciden e-ticaret operasyon sorumlusuna kadar herkes için son derece değerli bir beceridir. Apache/Nginx access log’ları sayesinde hangi URL’lerin ne sıklıkla 4xx–5xx ürettiğini, error log’lar sayesinde de bu hataların kök nedenlerine ilişkin ipuçlarını görebiliyorsunuz. Kök nedeni doğrulamak için uygulama logları ve diğer izleme verileriyle karşılaştırma yapmak gerekebilir. Böylece “tahmin” yerine veriyle konuşmaya başlıyorsunuz.

Buradan sonra atabileceğiniz pratik adımlar:

• Access ve error log yollarınızı, erişim yönteminizi ve okuma yetkilerinizi netleştirip bir kenara not edin.
• 404, 500, 502, 503 ve 504 için log formatınıza uygun grep/awk komutlarının küçük bir “şablon” dosyasını oluşturun; metin araması sonuçlarında durum kodu alanını doğrulayın.
• Seçtiğiniz zaman aralığını kapsayan mevcut ve döndürülmüş loglardan en çok 404 veren ilk 100 URL’i çıkarıp SEO ekibiyle birlikte aksiyon planı hazırlayın.
• E-ticaret projenizde sepet → ödeme akışını, SaaS projenizde giriş veya abonelik yenileme gibi kritik işlemleri loglarla izleyen bir rapor tasarlayın. İş sonuçlarını sipariş, dönüşüm veya abonelik kayıtlarıyla doğrulayın.
• Çoklu sunucu yapınız varsa merkezi loglamayı değerlendirin. Yeni Loki kurulumlarında Grafana Alloy veya başka bir desteklenen toplayıcı kullanın. Yukarıda bağlantısı verilen Loki/Promtail rehberini yalnızca eski kurulumu anlamak için kullanın; geçiş için resmi Grafana yönlendirmelerini izleyin ve yapılandırmanın değiştirilmeden çalışacağını varsaymayın.

Log analizi, alarm kuralları veya ölçeklendirmeyle ilgili destek taleplerinde, sorun yaşanan zaman aralığını ve ilgili log örneklerini paylaşmak teşhise yardımcı olabilir. Paylaşmadan önce örneklerdeki kişisel verileri, oturum belirteçlerini ve diğer gizli bilgileri maskeleyin. Yeni bir hosting, VPS, dedicated sunucu veya colocation kurgusu planlarken log yönetimini en baştan mimarinin bir parçası yapın; loglara erişim, saklama süresi ve merkezi toplama gereksinimlerini belirleyin.