Web sunucunuzun neden yava\u015flad\u0131\u011f\u0131n\u0131, hangi sayfalar\u0131n pop\u00fcler oldu\u011funu veya beklenmedik bir hatan\u0131n nereden kaynakland\u0131\u011f\u0131n\u0131 hi\u00e7 merak ettiniz mi? NGINX loglar\u0131, bu sorular\u0131n cevaplar\u0131n\u0131 sunan alt\u0131n de\u011ferinde bir kaynakt\u0131r. Bu kapsaml\u0131 rehber, NGINX’in eri\u015fim ve hata g\u00fcnl\u00fcklerini s\u0131f\u0131rdan anlay\u0131p yorumlaman\u0131za yard\u0131mc\u0131 olacak.<\/p>\n
Modern web uygulamalar\u0131n\u0131n ve sunucular\u0131n\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 d\u00fc\u015f\u00fcn\u00fcld\u00fc\u011f\u00fcnde, sistemlerin sa\u011fl\u0131kl\u0131 bir \u015fekilde \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 anlamak giderek zorla\u015f\u0131yor. \u0130\u015fte tam bu noktada NGINX loglar\u0131 devreye giriyor. Bir web sunucusu y\u00f6neticisi, geli\u015ftirici veya DevOps m\u00fchendisi olarak, NGINX loglar\u0131n\u0131 anlamak ve do\u011fru bir \u015fekilde yorumlamak, sorun giderme, performans optimizasyonu ve g\u00fcvenlik analizi i\u00e7in vazge\u00e7ilmez bir beceridir. Bu g\u00fcnl\u00fckler, sunucunuzla etkile\u015fime giren her iste\u011fin ve sunucunuzda meydana gelen her t\u00fcrl\u00fc i\u00e7 hatan\u0131n detayl\u0131 bir kayd\u0131n\u0131 tutar. Peki, bu loglar tam olarak nedir ve neden bu kadar \u00f6nemlidir?<\/p>\n
Temelde NGINX iki ana t\u00fcrde log dosyas\u0131 \u00fcretir: Eri\u015fim G\u00fcnl\u00fckleri (Access Logs) ve Hata G\u00fcnl\u00fckleri (Error Logs). Her ikisi de farkl\u0131 ama\u00e7lara hizmet eder ve farkl\u0131 t\u00fcrde bilgiler i\u00e7erir. Eri\u015fim g\u00fcnl\u00fckleri, sunucuya gelen her iste\u011fin ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131, hangi IP adresinden geldi\u011fini, hangi kaynaklara eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve ne kadar s\u00fcrd\u00fc\u011f\u00fcn\u00fc kaydeder. Bu, web sitenizin trafi\u011fini anlamak, pop\u00fcler i\u00e7erikleri belirlemek ve potansiyel k\u00f6t\u00fc niyetli faaliyetleri tespit etmek i\u00e7in kritik \u00f6neme sahiptir. \u00d6rne\u011fin, belirli bir sayfan\u0131n aniden \u00e7ok fazla istek ald\u0131\u011f\u0131n\u0131 fark ederseniz, bu bir DDoS sald\u0131r\u0131s\u0131n\u0131n veya beklenmedik bir trafik art\u0131\u015f\u0131n\u0131n g\u00f6stergesi olabilir. Bu t\u00fcr senaryolarda, eri\u015fim g\u00fcnl\u00fckleri ilk bak\u0131\u015fta size ne oldu\u011funu g\u00f6steren bir pencere g\u00f6revi g\u00f6r\u00fcr.<\/p>\n
Di\u011fer yandan, hata g\u00fcnl\u00fckleri, sunucunun i\u00e7 i\u015fleyi\u015finde meydana gelen sorunlar\u0131 kaydeder. Bir dosya bulunamad\u0131\u011f\u0131nda, bir izin hatas\u0131 olu\u015ftu\u011funda veya NGINX’in kendisi bir problemle kar\u015f\u0131la\u015ft\u0131\u011f\u0131nda, bu bilgiler hata g\u00fcnl\u00fcklerine yaz\u0131l\u0131r. Bu g\u00fcnl\u00fckler, web sitenizin kullan\u0131c\u0131lar i\u00e7in g\u00f6r\u00fcn\u00fcr olan hatalar\u0131n\u0131 (\u00f6rne\u011fin 500 Internal Server Error) veya arka planda sessizce meydana gelen ancak performans\u0131 etkileyen sorunlar\u0131 tespit etmede kilit rol oynar. Bir uygulaman\u0131n neden beklenmedik bir \u015fekilde \u00e7\u00f6kt\u00fc\u011f\u00fcn\u00fc veya bir iste\u011fin neden zaman a\u015f\u0131m\u0131na u\u011frad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in hata g\u00fcnl\u00fckleri, sorunun k\u00f6kenine inmenizi sa\u011flayan en g\u00fcvenilir kaynakt\u0131r. Dolay\u0131s\u0131yla, NGINX loglar\u0131 sadece birer kay\u0131t de\u011fil, ayn\u0131 zamanda sunucunuzun nabz\u0131n\u0131 tutan, gelecekteki sorunlar\u0131 \u00f6nlemenize ve mevcut durumunu iyile\u015ftirmenize yard\u0131mc\u0131 olan canl\u0131 bir veri ak\u0131\u015f\u0131d\u0131r.<\/p>\n
Bu g\u00fcnl\u00fcklerin \u00f6nemi sadece sorun giderme ile s\u0131n\u0131rl\u0131 de\u011fildir. Performans optimizasyonu da b\u00fcy\u00fck \u00f6l\u00e7\u00fcde log verilerine dayan\u0131r. Eri\u015fim g\u00fcnl\u00fcklerindeki yan\u0131t s\u00fcrelerini analiz ederek, yava\u015f y\u00fcklenen sayfalar\u0131 veya API u\u00e7 noktalar\u0131n\u0131 belirleyebilirsiniz. Bu bilgilerle, \u00f6nbellekleme stratejilerinizi geli\u015ftirebilir, veritaban\u0131 sorgular\u0131n\u0131z\u0131 optimize edebilir veya sunucu kaynaklar\u0131n\u0131 daha verimli kullanabilirsiniz. G\u00fcvenlik a\u00e7\u0131s\u0131ndan bak\u0131ld\u0131\u011f\u0131nda ise, eri\u015fim g\u00fcnl\u00fckleri \u015f\u00fcpheli IP adreslerini, ba\u015far\u0131s\u0131z oturum a\u00e7ma giri\u015fimlerini veya s\u0131k s\u0131k denenen sald\u0131r\u0131 modellerini (SQL enjeksiyonu, XSS denemeleri vb.) izlemek i\u00e7in birincil ara\u00e7t\u0131r. Bu sayede, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131z\u0131 g\u00fcncelleyebilir veya sald\u0131r\u0131 \u00f6nleme sistemlerinizi daha etkili hale getirebilirsiniz. K\u0131sacas\u0131, NGINX loglar\u0131, sunucu sa\u011fl\u0131\u011f\u0131n\u0131n, performans\u0131n\u0131n ve g\u00fcvenli\u011finin temelini olu\u015fturan, her web y\u00f6neticisinin ustala\u015fmas\u0131 gereken bir konudur.<\/p>\n
Eri\u015fim g\u00fcnl\u00fckleri, NGINX sunucusuna gelen her ba\u015far\u0131l\u0131 veya ba\u015far\u0131s\u0131z iste\u011fin detayl\u0131 bir kayd\u0131n\u0131 tutar. Bu g\u00fcnl\u00fckler, web sitenizin trafi\u011fi hakk\u0131nda paha bi\u00e7ilmez bilgiler sa\u011flar ve kullan\u0131c\u0131 davran\u0131\u015flar\u0131n\u0131, pop\u00fcler i\u00e7erikleri ve potansiyel g\u00fcvenlik tehditlerini anlaman\u0131za yard\u0131mc\u0131 olur. Varsay\u0131lan olarak, NGINX eri\u015fim g\u00fcnl\u00fcklerini genellikle NGINX’in varsay\u0131lan eri\u015fim g\u00fcnl\u00fc\u011f\u00fc format\u0131 genellikle “combined” format\u0131d\u0131r ve a\u015fa\u011f\u0131daki gibi bir yap\u0131ya sahiptir:<\/p>\n Bu formatta, her bir alan\u0131n ne anlama geldi\u011fini detayland\u0131ral\u0131m:<\/p>\n Bu varsay\u0131lan format \u00e7o\u011fu senaryo i\u00e7in yeterli olsa da, NGINX’in Bu \u00f6rnekte, Diyelim ki web sitenizde baz\u0131 sayfalar\u0131n son zamanlarda yava\u015f y\u00fcklendi\u011fine dair kullan\u0131c\u0131 \u015fikayetleri al\u0131yorsunuz. Sorunu tespit etmek i\u00e7in eri\u015fim g\u00fcnl\u00fcklerinizi incelemeye karar verdiniz. \u00d6zel Yukar\u0131daki log sat\u0131rlar\u0131n\u0131 inceledi\u011finizde, NGINX hata g\u00fcnl\u00fckleri, sunucunun i\u00e7 i\u015fleyi\u015finde meydana gelen problemleri, uyar\u0131lar\u0131 ve bilgilendirme mesajlar\u0131n\u0131 kaydeder. Eri\u015fim g\u00fcnl\u00fckleri istemci-sunucu etkile\u015fimlerini kaydederken, hata g\u00fcnl\u00fckleri sunucunun kendi i\u00e7indeki sorunlara odaklan\u0131r. Bu g\u00fcnl\u00fckler, web sitenizin veya uygulaman\u0131z\u0131n neden d\u00fczg\u00fcn \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in hayati \u00f6neme sahiptir. Varsay\u0131lan olarak, NGINX hata g\u00fcnl\u00fcklerini genellikle Hata g\u00fcnl\u00fcklerindeki her mesaj, bir \u00f6nem seviyesi ile etiketlenir. Bu seviyeler, mesaj\u0131n ciddiyetini belirtir ve NGINX yap\u0131land\u0131rman\u0131zda NGINX yap\u0131land\u0131rman\u0131zda hata g\u00fcnl\u00fc\u011f\u00fc seviyesini \u015fu \u015fekilde ayarlayabilirsiniz:<\/p>\n Bu \u00f6rnek, Hata g\u00fcnl\u00fc\u011f\u00fc sat\u0131rlar\u0131 genellikle a\u015fa\u011f\u0131daki formatta g\u00f6r\u00fcn\u00fcr:<\/p>\n Bu sat\u0131r\u0131 par\u00e7alayal\u0131m:<\/p>\n Web sitenizde aniden “502 Bad Gateway” hatalar\u0131 almaya ba\u015flad\u0131n\u0131z. Bu hata genellikle NGINX’in arka u\u00e7 (upstream) sunucusuyla (\u00f6rne\u011fin, PHP-FPM, Gunicorn, Node.js uygulamas\u0131) ileti\u015fim kuramad\u0131\u011f\u0131 durumlarda ortaya \u00e7\u0131kar. Sorunu \u00e7\u00f6zmek i\u00e7in NGINX hata g\u00fcnl\u00fcklerinizi kontrol ettiniz ve a\u015fa\u011f\u0131daki gibi bir \u00e7\u0131kt\u0131 g\u00f6rd\u00fcn\u00fcz:<\/p>\n Bu hata g\u00fcnl\u00fc\u011f\u00fc sat\u0131r\u0131 bize \u00e7ok de\u011ferli bilgiler veriyor:<\/p>\n Bu analize dayanarak, sorunun NGINX’ten de\u011fil, arka u\u00e7 uygulamas\u0131ndan (PHP-FPM) kaynakland\u0131\u011f\u0131n\u0131 hemen anlayabiliriz. \u00c7\u00f6z\u00fcm ad\u0131mlar\u0131 \u015funlar olabilir:<\/p>\n G\u00f6r\u00fcld\u00fc\u011f\u00fc gibi, hata g\u00fcnl\u00fckleri, karma\u015f\u0131k sistemlerde bile sorunlar\u0131n k\u00f6kenini h\u0131zl\u0131 ve etkili bir \u015fekilde tespit etmek i\u00e7in paha bi\u00e7ilmez bir ara\u00e7t\u0131r. Bu sayede, “502 Bad Gateway” gibi genel bir hatan\u0131n arkas\u0131ndaki ger\u00e7ek nedeni kolayca bulabilirsiniz.<\/p>\n NGINX loglar\u0131, sunucunuzun sa\u011fl\u0131\u011f\u0131 ve performans\u0131 hakk\u0131nda kritik bilgiler sunarken, zamanla \u00e7ok b\u00fcy\u00fck boyutlara ula\u015fabilirler. B\u00fcy\u00fck log dosyalar\u0131, disk alan\u0131n\u0131 t\u00fcketmekle kalmaz, ayn\u0131 zamanda log analizini zorla\u015ft\u0131r\u0131r ve I\/O performans\u0131n\u0131 olumsuz etkileyebilir. Bu nedenle, NGINX loglar\u0131n\u0131 do\u011fru bir \u015fekilde yap\u0131land\u0131rmak ve y\u00f6netmek, her sunucu y\u00f6neticisinin bilmesi gereken \u00f6nemli bir konudur.<\/p>\n NGINX loglar\u0131n\u0131n varsay\u0131lan konumlar\u0131n\u0131 ve seviyelerini de\u011fi\u015ftirmek olduk\u00e7a kolayd\u0131r. Log dosyalar\u0131n\u0131n konumunu Bu yap\u0131land\u0131rma, eri\u015fim loglar\u0131n\u0131 Logrotate, Linux sistemlerinde log dosyalar\u0131n\u0131 otomatik olarak d\u00f6nd\u00fcrmek, s\u0131k\u0131\u015ft\u0131rmak ve silmek i\u00e7in kullan\u0131lan standart bir ara\u00e7t\u0131r. NGINX loglar\u0131 i\u00e7in Logrotate’\u0131 kullanmak, disk alan\u0131n\u0131n dolmas\u0131n\u0131 engeller ve log dosyalar\u0131n\u0131 y\u00f6netilebilir boyutlarda tutar. Logrotate olmadan, NGINX log dosyalar\u0131 s\u0131n\u0131rs\u0131zca b\u00fcy\u00fcyerek sonunda sunucunuzun diskini doldurabilir ve kritik hizmetlerin durmas\u0131na neden olabilir.<\/p>\n NGINX i\u00e7in tipik bir Logrotate yap\u0131land\u0131rmas\u0131 Bu yap\u0131land\u0131rma dosyas\u0131ndaki direktifleri inceleyelim:<\/p>\n Y\u00fcksek trafikli sunucularda, her bir iste\u011fin logunu an\u0131nda diske yazmak, I\/O y\u00fck\u00fcn\u00fc art\u0131rabilir ve performans\u0131 d\u00fc\u015f\u00fcrebilir. NGINX, bu sorunu \u00e7\u00f6zmek i\u00e7in Bu ayarlar, \u00f6zellikle yo\u011fun I\/O i\u015flemleri olan veya SSD \u00f6mr\u00fcn\u00fc korumak isteyen sistemlerde olduk\u00e7a faydal\u0131d\u0131r. Do\u011fru yap\u0131land\u0131rma ve Logrotate kullan\u0131m\u0131, NGINX sunucunuzun istikrarl\u0131 ve performansl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n temel ta\u015flar\u0131ndan biridir.<\/p>\n NGINX loglar\u0131 ham veri y\u0131\u011f\u0131nlar\u0131d\u0131r ve bu verileri anlaml\u0131 bilgilere d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in \u00e7e\u015fitli ara\u00e7lara ve tekniklere ihtiya\u00e7 duyar\u0131z. Manuel olarak binlerce hatta milyonlarca log sat\u0131r\u0131n\u0131 incelemek imkans\u0131zd\u0131r. Bu b\u00f6l\u00fcmde, loglar\u0131 analiz etmek i\u00e7in kullanabilece\u011finiz temel komut sat\u0131r\u0131 ara\u00e7lar\u0131ndan, pop\u00fcler log analiz yaz\u0131l\u0131mlar\u0131na ve ger\u00e7ek zamanl\u0131 izleme stratejilerine kadar \u00e7e\u015fitli ileri d\u00fczey teknikleri ele alaca\u011f\u0131z.<\/p>\n K\u00fc\u00e7\u00fck \u00f6l\u00e7ekli sorun giderme veya h\u0131zl\u0131 kontroller i\u00e7in Linux’un standart komut sat\u0131r\u0131 ara\u00e7lar\u0131 paha bi\u00e7ilmezdir:<\/p>\n Bu komut, eri\u015fim g\u00fcnl\u00fcklerindeki IP adreslerini ay\u0131klar ( Daha b\u00fcy\u00fck \u00f6l\u00e7ekli ve s\u00fcrekli analizler i\u00e7in \u00f6zel log analiz ara\u00e7lar\u0131 devreye girer:<\/p>\n ELK Stack, b\u00fcy\u00fck veri hacimlerini y\u00f6netme, karma\u015f\u0131k sorgular \u00e7al\u0131\u015ft\u0131rma ve \u00f6zelle\u015ftirilmi\u015f raporlar olu\u015fturma yetene\u011fiyle \u00f6ne \u00e7\u0131kar. Ancak kurulumu ve bak\u0131m\u0131 daha karma\u015f\u0131kt\u0131r.<\/p>\n<\/li>\n Loglar\u0131 sadece analiz etmekle kalmay\u0131p, kritik olaylar meydana geldi\u011finde an\u0131nda haberdar olmak da \u00f6nemlidir. Ger\u00e7ek zamanl\u0131 izleme ve uyar\u0131 sistemleri, proaktif bir yakla\u015f\u0131m benimsemenizi sa\u011flar:<\/p>\n Log y\u00f6netimi ve analizi genellikle masa\u00fcst\u00fc ortam\u0131nda yap\u0131l\u0131rken, modern DevOps yakla\u015f\u0131mlar\u0131 ve uzaktan \u00e7al\u0131\u015fma modelleri, log verilerine mobil cihazlardan da eri\u015febilme ve hatta analiz edebilme ihtiyac\u0131n\u0131 ortaya \u00e7\u0131karm\u0131\u015ft\u0131r. NGINX loglar\u0131 do\u011frudan mobil cihazlarda g\u00f6r\u00fcnt\u00fclenmese de, log analiz ara\u00e7lar\u0131n\u0131n web aray\u00fczlerinin veya \u00f6zel olarak geli\u015ftirilmi\u015f panolar\u0131n mobil uyumlu olmas\u0131, y\u00f6neticilerin her an her yerden sistemlerinin durumu hakk\u0131nda bilgi sahibi olmalar\u0131n\u0131 sa\u011flar.<\/p>\n Mobil uyumlu bir log y\u00f6netim panosu veya web aray\u00fcz\u00fc tasarlarken, duyarl\u0131 (responsive) tasar\u0131m prensipleri uygulanmal\u0131d\u0131r. Bu, farkl\u0131 ekran boyutlar\u0131na ve cihazlara (ak\u0131ll\u0131 telefonlar, tabletler) otomatik olarak uyum sa\u011flayan bir kullan\u0131c\u0131 aray\u00fcz\u00fc demektir. Temel olarak, CSS Media Query’leri bu uyumlulu\u011fu sa\u011flamak i\u00e7in kullan\u0131l\u0131r. \u0130\u015fte basit bir CSS media query \u00f6rne\u011fi:<\/p>\n Yukar\u0131daki CSS \u00f6rne\u011fi, GoAccess gibi ara\u00e7lar varsay\u0131lan olarak terminal tabanl\u0131 olsa da, HTML raporlar\u0131 olu\u015fturabilir ve bu raporlar genellikle temel bir duyarl\u0131l\u0131k sunar. ELK Stack’in Kibana panolar\u0131 da mobil uyumlu olacak \u015fekilde tasarlanabilir veya mobil uygulamalar arac\u0131l\u0131\u011f\u0131yla eri\u015filebilir. Baz\u0131 \u00fc\u00e7\u00fcnc\u00fc taraf log y\u00f6netim hizmetleri de mobil uygulamalar veya duyarl\u0131 web aray\u00fczleri sunarak bu ihtiyac\u0131 kar\u015f\u0131lar.<\/p>\n Mobil uyumlu log g\u00f6r\u00fcnt\u00fcleme, \u00f6zellikle acil durum m\u00fcdahaleleri s\u0131ras\u0131nda veya saha \u00e7al\u0131\u015fmas\u0131 yaparken sunucu durumunu h\u0131zl\u0131ca kontrol etmek i\u00e7in b\u00fcy\u00fck avantaj sa\u011flar. Bir hata an\u0131nda, y\u00f6neticinin bir masa\u00fcst\u00fc bilgisayara eri\u015fimi olmasa bile, mobil cihaz\u0131ndan kritik hata loglar\u0131n\u0131 inceleyebilir ve ilk te\u015fhisleri koyabilir. Bu, sorun giderme s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131r ve sistemin kesinti s\u00fcresini minimize etmeye yard\u0131mc\u0131 olur.<\/p>\n Bu kapsaml\u0131 rehber boyunca, NGINX’in eri\u015fim ve hata g\u00fcnl\u00fcklerinin ne kadar \u00f6nemli oldu\u011funu, nas\u0131l yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131n\u0131, okundu\u011funu ve analiz edildi\u011fini detayl\u0131 bir \u015fekilde inceledik. NGINX loglar\u0131, sadece birer kay\u0131t y\u0131\u011f\u0131n\u0131 olmaktan \u00f6te, web sunucunuzun sa\u011fl\u0131\u011f\u0131n\u0131, performans\u0131n\u0131 ve g\u00fcvenli\u011fini anlamak i\u00e7in bir pencere g\u00f6revi g\u00f6r\u00fcr. \u0130ster basit bir ki\u015fisel blog y\u00f6netiyor olun, ister y\u00fcksek trafikli bir e-ticaret sitesi i\u015fletin, loglar\u0131 do\u011fru bir \u015fekilde yorumlama becerisi, kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131z bir\u00e7ok sorunu h\u0131zl\u0131 ve etkili bir \u015fekilde \u00e7\u00f6zmenizi sa\u011flayacakt\u0131r.<\/p>\n Eri\u015fim g\u00fcnl\u00fckleri sayesinde kullan\u0131c\u0131 davran\u0131\u015flar\u0131n\u0131, trafik kaynaklar\u0131n\u0131 ve performans darbo\u011fazlar\u0131n\u0131 tespit edebilir; hata g\u00fcnl\u00fckleri ile sunucunuzun i\u00e7 i\u015fleyi\u015findeki sorunlar\u0131, uygulama hatalar\u0131n\u0131 ve yap\u0131land\u0131rma yanl\u0131\u015flar\u0131n\u0131 anlayabilirsiniz. Logrotate gibi ara\u00e7larla log dosyalar\u0131n\u0131 d\u00fczenli tutmak, komut sat\u0131r\u0131 ara\u00e7lar\u0131 veya GoAccess, ELK Stack gibi geli\u015fmi\u015f analiz platformlar\u0131yla verileri anlaml\u0131 bilgilere d\u00f6n\u00fc\u015ft\u00fcrmek, sunucu y\u00f6netimindeki verimlili\u011finizi art\u0131racakt\u0131r. Ayr\u0131ca, mobil uyumlu log y\u00f6netim panolar\u0131 sayesinde, nerede olursan\u0131z olun sisteminizin nabz\u0131n\u0131 tutabilir ve olas\u0131 sorunlara an\u0131nda m\u00fcdahale edebilirsiniz.<\/p>\n Unutmay\u0131n ki log analizi, s\u00fcrekli bir \u00f6\u011frenme ve pratik gerektiren bir aland\u0131r. G\u00fcnl\u00fcklerinizi d\u00fczenli olarak incelemek, belirli kal\u0131plar\u0131 ve anormallikleri tan\u0131ma yetene\u011finizi geli\u015ftirecektir. Bu sayede, potansiyel sorunlar\u0131 daha ortaya \u00e7\u0131kmadan \u00f6nce fark edebilir, proaktif \u00f6nlemler alabilir ve web hizmetlerinizin kesintisiz ve g\u00fcvenli bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayabilirsiniz. NGINX loglar\u0131na hakim olmak, modern web altyap\u0131s\u0131n\u0131 y\u00f6netmenin temel ta\u015flar\u0131ndan biridir.<\/p>\n Y\u00fcksek trafikli web sitelerinde her bir kullan\u0131c\u0131 iste\u011fi bir log sat\u0131r\u0131 olu\u015fturdu\u011fu i\u00e7in log dosyalar\u0131 h\u0131zla b\u00fcy\u00fcyebilir. Bu durum disk alan\u0131n\u0131 t\u00fcketebilir ve analizi zorla\u015ft\u0131rabilir. Bu sorunu \u00e7\u00f6zmek i\u00e7in Linux’un \/var\/log\/nginx\/access.log<\/code> konumunda saklar. Ancak bu konum, NGINX yap\u0131land\u0131rman\u0131za ba\u011fl\u0131 olarak de\u011fi\u015febilir. Her bir log sat\u0131r\u0131, belirli bir istekle ilgili \u00e7e\u015fitli alanlar\u0131 i\u00e7erir ve bu alanlar, sunucunuzun nas\u0131l yan\u0131t verdi\u011fine dair kapsaml\u0131 bir resim sunar.<\/p>\n\n log_format combined '$remote_addr - $remote_user [$time_local] '\n '\"$request\" $status $body_bytes_sent '\n '\"$http_referer\" \"$http_user_agent\"';\n<\/code><\/pre>\n\n
$remote_addr<\/code>: \u0130ste\u011fi yapan istemcinin IP adresi. Bu, co\u011frafi konum analizi ve k\u00f6t\u00fc niyetli IP’leri engellemek i\u00e7in \u00f6nemlidir.<\/li>\n$remote_user<\/code>: E\u011fer HTTP kimlik do\u011frulamas\u0131 kullan\u0131l\u0131yorsa, kimli\u011fi do\u011frulanm\u0131\u015f kullan\u0131c\u0131 ad\u0131. Genellikle bu alan bo\u015ftur (-<\/code>).<\/li>\n[$time_local]<\/code>: \u0130ste\u011fin sunucu taraf\u0131ndan i\u015flendi\u011fi yerel saat ve tarih.<\/li>\n\"$request\"<\/code>: \u0130stemcinin yapt\u0131\u011f\u0131 tam istek sat\u0131r\u0131 (\u00f6rne\u011fin, \"GET \/index.html HTTP\/1.1\"<\/code>). Bu, istek y\u00f6ntemini (GET, POST), istenen URL’yi ve HTTP protokol s\u00fcr\u00fcm\u00fcn\u00fc i\u00e7erir.<\/li>\n$status<\/code>: Sunucunun iste\u011fe verdi\u011fi HTTP durum kodu (\u00f6rne\u011fin, 200 OK, 404 Not Found, 500 Internal Server Error). Bu kodlar, bir iste\u011fin ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 veya bir sorunla kar\u015f\u0131la\u015f\u0131p kar\u015f\u0131la\u015fmad\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/li>\n$body_bytes_sent<\/code>: Sunucu taraf\u0131ndan istemciye g\u00f6nderilen yan\u0131t\u0131n bayt cinsinden boyutu (HTTP ba\u015fl\u0131klar\u0131 hari\u00e7). Bu, bant geni\u015fli\u011fi kullan\u0131m\u0131 ve performans analizi i\u00e7in \u00f6nemlidir.<\/li>\n\"$http_referer\"<\/code>: \u0130stemcinin iste\u011fi yapmadan \u00f6nce geldi\u011fi sayfan\u0131n URL’si. Bu, trafik kaynaklar\u0131n\u0131 anlamak i\u00e7in faydal\u0131d\u0131r.<\/li>\n\"$http_user_agent\"<\/code>: \u0130stemcinin taray\u0131c\u0131 ve i\u015fletim sistemi bilgilerini i\u00e7eren User-Agent ba\u015fl\u0131\u011f\u0131. Bu, mobil\/masa\u00fcst\u00fc trafi\u011fi analizi i\u00e7in kullan\u0131l\u0131r.<\/li>\n<\/ul>\nlog_format<\/code> direktifi sayesinde kendi \u00f6zel g\u00fcnl\u00fck formatlar\u0131n\u0131z\u0131 tan\u0131mlayabilirsiniz. \u00d6rne\u011fin, yan\u0131t s\u00fcresi veya \u00f6nbellek durumu gibi ek bilgiler eklemek isteyebilirsiniz. A\u015fa\u011f\u0131da, yan\u0131t s\u00fcresini ve \u00f6nbellek durumunu i\u00e7eren \u00f6zel bir log format\u0131 \u00f6rne\u011fi verilmi\u015ftir:<\/p>\n\n log_format custom_timing '$remote_addr - $remote_user [$time_local] '\n '\"$request\" $status $body_bytes_sent '\n '\"$http_referer\" \"$http_user_agent\" '\n '$request_time $upstream_response_time $upstream_cache_status';\n<\/code><\/pre>\n$request_time<\/code> (iste\u011fin tamamlanmas\u0131 i\u00e7in ge\u00e7en s\u00fcre) ve $upstream_response_time<\/code> (arka u\u00e7 sunucusunun yan\u0131t s\u00fcresi) gibi de\u011fi\u015fkenler eklenmi\u015ftir. Bu de\u011fi\u015fkenler, performans darbo\u011fazlar\u0131n\u0131 belirlemede kritik \u00f6neme sahiptir. \u00d6zel bir format\u0131 tan\u0131mlad\u0131ktan sonra, bunu NGINX yap\u0131land\u0131rman\u0131zda (genellikle http<\/code> veya server<\/code> blo\u011funda) access_log<\/code> direktifi ile kullanman\u0131z gerekir:<\/p>\n\n http {\n log_format custom_timing '...';\n server {\n listen 80;\n server_name example.com;\n access_log \/var\/log\/nginx\/custom_access.log custom_timing;\n # ... di\u011fer yap\u0131land\u0131rmalar ...\n }\n }\n<\/code><\/pre>\naccess_log off;<\/code> kullanarak baz\u0131 sanal host’lar i\u00e7in eri\u015fim g\u00fcnl\u00fcklerini tamamen kapatabilir veya buffer<\/code> ve flush<\/code> parametrelerini kullanarak log yazma i\u015flemini optimize edebilirsiniz. \u00d6rne\u011fin, access_log \/var\/log\/nginx\/access.log custom_timing buffer=32k;<\/code> komutu, loglar\u0131n 32KB’l\u0131k bir tamponda birikmesini ve doldu\u011funda diske yaz\u0131lmas\u0131n\u0131 sa\u011flar. Bu teknikle performans\u0131 %40 art\u0131rabilirsiniz.\n<\/div>\nVaka Analizi 1: Performans Sorununu Eri\u015fim Loglar\u0131ndan Anlama<\/h3>\n
custom_timing<\/code> format\u0131n\u0131 kulland\u0131\u011f\u0131n\u0131z\u0131 ve g\u00fcnl\u00fcklerinizin a\u015fa\u011f\u0131daki gibi g\u00f6r\u00fcnd\u00fc\u011f\u00fcn\u00fc varsayal\u0131m:<\/p>\n\n 192.168.1.10 - - [01\/Jan\/2023:10:00:01 +0300] \"GET \/urunler\/laptop-modeli-a HTTP\/1.1\" 200 15234 \"-\" \"Mozilla\/5.0 (...)\" 0.523 0.480 MISS\n 192.168.1.11 - - [01\/Jan\/2023:10:00:02 +0300] \"GET \/hakkimizda HTTP\/1.1\" 200 4567 \"-\" \"Mozilla\/5.0 (...)\" 0.015 0.010 HIT\n 192.168.1.12 - - [01\/Jan\/2023:10:00:03 +0300] \"GET \/urunler\/laptop-modeli-a HTTP\/1.1\" 200 15234 \"http:\/\/example.com\/anasayfa\" \"Mozilla\/5.0 (...)\" 0.610 0.550 MISS\n 192.168.1.13 - - [01\/Jan\/2023:10:00:04 +0300] \"GET \/api\/kullanici\/profil HTTP\/1.1\" 200 2345 \"-\" \"PostmanRuntime\/7.29.0\" 0.080 0.075 -\n<\/code><\/pre>\n\/urunler\/laptop-modeli-a<\/code> sayfas\u0131na yap\u0131lan isteklerin $request_time<\/code> (iste\u011fin tamam\u0131) ve $upstream_response_time<\/code> (arka u\u00e7 yan\u0131t s\u00fcresi) de\u011ferlerinin di\u011fer sayfalara g\u00f6re daha y\u00fcksek oldu\u011funu fark edersiniz (0.5 saniyenin \u00fczerinde). Ayr\u0131ca, $upstream_cache_status<\/code> alan\u0131n\u0131n “MISS” oldu\u011funu g\u00f6r\u00fcrs\u00fcn\u00fcz. Bu durum, bu sayfan\u0131n \u00f6nbellekten sunulmad\u0131\u011f\u0131n\u0131 ve her seferinde arka u\u00e7 sunucusundan yeniden olu\u015fturuldu\u011funu g\u00f6sterir. Bu analize dayanarak, sorunun muhtemelen \/urunler\/laptop-modeli-a<\/code> sayfas\u0131n\u0131n arka u\u00e7ta yava\u015f i\u015flenmesinden veya \u00f6nbelle\u011fe al\u0131nmamas\u0131ndan kaynakland\u0131\u011f\u0131n\u0131 \u00e7\u0131karabilirsiniz. \u00c7\u00f6z\u00fcm olarak, bu sayfa i\u00e7in \u00f6nbellekleme kurallar\u0131n\u0131 g\u00f6zden ge\u00e7irebilir veya arka u\u00e7 uygulamas\u0131n\u0131n bu b\u00f6l\u00fcm\u00fcn\u00fc optimize edebilirsiniz. Eri\u015fim g\u00fcnl\u00fckleri, bu t\u00fcr performans sorunlar\u0131n\u0131 h\u0131zl\u0131ca te\u015fhis etmek i\u00e7in size somut veriler sunar.<\/p>\nHata G\u00fcnl\u00fckleri (Error Logs) Nas\u0131l Okunur ve Yorumlan\u0131r?<\/h2>\n
\/var\/log\/nginx\/error.log<\/code> konumunda saklar.<\/p>\nerror_log<\/code> direktifi ile ayarlanabilir. \u0130\u015fte yayg\u0131n hata seviyeleri ve anlamlar\u0131:<\/p>\n\n
debug<\/code>: En d\u00fc\u015f\u00fck seviye. Geli\u015ftirme ve derinlemesine sorun giderme i\u00e7in \u00e7ok detayl\u0131 bilgiler i\u00e7erir. Genellikle \u00fcretim ortam\u0131nda kullan\u0131lmaz.<\/li>\ninfo<\/code>: Bilgilendirme mesajlar\u0131. Normal operasyonel olaylar\u0131 kaydeder.<\/li>\nnotice<\/code>: \u00d6nemli ancak kritik olmayan olaylar. \u00d6rne\u011fin, bir yap\u0131land\u0131rma de\u011fi\u015fikli\u011fi.<\/li>\nwarn<\/code>: Uyar\u0131lar. Potansiyel sorunlara i\u015faret eder ancak operasyonu durdurmaz.<\/li>\nerror<\/code>: Hatalar. Bir i\u015flemin ba\u015far\u0131s\u0131z oldu\u011fu ancak sunucunun \u00e7al\u0131\u015fmaya devam etti\u011fi durumlar. \u00d6rne\u011fin, bir dosya bulunamad\u0131.<\/li>\ncrit<\/code>: Kritik hatalar. Bir uygulaman\u0131n veya sistemin \u00f6nemli bir b\u00f6l\u00fcm\u00fcn\u00fcn \u00e7al\u0131\u015fmay\u0131 durdurdu\u011fu durumlar.<\/li>\nalert<\/code>: Acil durumlar. Hemen m\u00fcdahale gerektiren ciddi sorunlar.<\/li>\nemerg<\/code>: En y\u00fcksek seviye. Sistem kullan\u0131lamaz hale geldi\u011finde veya \u00e7\u00f6kt\u00fc\u011f\u00fcnde.<\/li>\n<\/ul>\n\n error_log \/var\/log\/nginx\/error.log warn;\n<\/code><\/pre>\nwarn<\/code> seviyesindeki ve daha y\u00fcksek ciddiyetteki (error, crit, alert, emerg) mesajlar\u0131n g\u00fcnl\u00fc\u011fe yaz\u0131lmas\u0131n\u0131 sa\u011flar. \u00dcretim ortamlar\u0131nda genellikle warn<\/code> veya error<\/code> seviyesi kullan\u0131l\u0131r. Sorun giderme yaparken ge\u00e7ici olarak info<\/code> veya debug<\/code> seviyesine y\u00fckseltmek faydal\u0131 olabilir, ancak bu seviyeler \u00e7ok fazla veri \u00fcretece\u011fi i\u00e7in uzun s\u00fcre a\u00e7\u0131k b\u0131rak\u0131lmamal\u0131d\u0131r.<\/p>\n\n 2023\/01\/01 10:05:30 [error] 12345#0: *123 open() \"\/var\/www\/html\/nonexistent.html\" failed (2: No such file or directory), client: 192.168.1.10, server: example.com, request: \"GET \/nonexistent.html HTTP\/1.1\", host: \"example.com\"\n<\/code><\/pre>\n\n
2023\/01\/01 10:05:30<\/code>: Hatan\u0131n meydana geldi\u011fi tarih ve saat.<\/li>\n[error]<\/code>: Hatan\u0131n \u00f6nem seviyesi.<\/li>\n12345#0<\/code>: NGINX worker process ID’si ve connection ID’si.<\/li>\n*123<\/code>: \u0130stek ID’si.<\/li>\nopen() \"\/var\/www\/html\/nonexistent.html\" failed (2: No such file or directory)<\/code>: Hatan\u0131n a\u00e7\u0131klamas\u0131. Burada bir dosyan\u0131n bulunamad\u0131\u011f\u0131 belirtiliyor.<\/li>\nclient: 192.168.1.10<\/code>: \u0130ste\u011fi yapan istemcinin IP adresi.<\/li>\nserver: example.com<\/code>: Hatan\u0131n meydana geldi\u011fi sanal host.<\/li>\nrequest: \"GET \/nonexistent.html HTTP\/1.1\"<\/code>: Hatan\u0131n tetiklendi\u011fi istek.<\/li>\nhost: \"example.com\"<\/code>: \u0130stemcinin Host ba\u015fl\u0131\u011f\u0131.<\/li>\n<\/ul>\nVaka Analizi 2: 502 Bad Gateway Hatas\u0131n\u0131 Error Loglar ile \u00c7\u00f6zme<\/h3>\n
\n 2023\/01\/01 11:15:20 [crit] 12345#0: *456 connect() to 127.0.0.1:9000 failed (111: Connection refused) while connecting to upstream, client: 192.168.1.15, server: example.com, request: \"GET \/app\/dashboard HTTP\/1.1\", upstream: \"fastcgi:\/\/127.0.0.1:9000\", host: \"example.com\"\n<\/code><\/pre>\n\n
[crit]<\/code>: Hatan\u0131n kritik oldu\u011funu g\u00f6steriyor.<\/li>\nconnect() to 127.0.0.1:9000 failed (111: Connection refused)<\/code>: NGINX’in 127.0.0.1<\/code> adresindeki 9000<\/code> portuna ba\u011flanmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ancak ba\u011flant\u0131n\u0131n reddedildi\u011fini belirtiyor. Bu genellikle arka u\u00e7 uygulamas\u0131n\u0131n (bu \u00f6rnekte muhtemelen PHP-FPM) \u00e7al\u0131\u015fmad\u0131\u011f\u0131 veya bu portu dinlemedi\u011fi anlam\u0131na gelir.<\/li>\nwhile connecting to upstream<\/code>: Hatan\u0131n arka u\u00e7 sunucusuna ba\u011flan\u0131rken olu\u015ftu\u011funu do\u011fruluyor.<\/li>\nupstream: \"fastcgi:\/\/127.0.0.1:9000\"<\/code>: Hatan\u0131n FastCGI protokol\u00fc \u00fczerinden 127.0.0.1:9000<\/code> adresindeki bir upstream ile ilgili oldu\u011funu g\u00f6steriyor.<\/li>\n<\/ul>\n\n
sudo systemctl status php-fpm<\/code> (veya benzeri bir komut).<\/li>\nsudo systemctl start php-fpm<\/code>.<\/li>\n127.0.0.1:9000<\/code> portunu dinledi\u011finden emin olun. PHP-FPM yap\u0131land\u0131rma dosyas\u0131nda (genellikle \/etc\/php-fpm.d\/www.conf<\/code> veya benzeri) listen = 127.0.0.1:9000<\/code> sat\u0131r\u0131n\u0131 aray\u0131n.<\/li>\nNGINX Log Yap\u0131land\u0131rmas\u0131 ve Y\u00f6netimi: Logrotate ile Verimli Kullan\u0131m<\/h2>\n
Log Dosyas\u0131 Konumunu ve Seviyelerini Ayarlama<\/h3>\n
nginx.conf<\/code> dosyas\u0131nda veya ilgili sanal host yap\u0131land\u0131rma dosyalar\u0131nda (server<\/code> blo\u011fu i\u00e7inde) belirtebilirsiniz. \u00d6rne\u011fin:<\/p>\n\n http {\n # ...\n access_log \/var\/log\/nginx\/my_custom_access.log combined;\n error_log \/var\/log\/nginx\/my_custom_error.log error;\n # ...\n }\n<\/code><\/pre>\nmy_custom_access.log<\/code> dosyas\u0131na, hata loglar\u0131n\u0131 ise my_custom_error.log<\/code> dosyas\u0131na error<\/code> seviyesinde yazacakt\u0131r. Hata log seviyesi, debug<\/code>, info<\/code>, notice<\/code>, warn<\/code>, error<\/code>, crit<\/code>, alert<\/code>, emerg<\/code> de\u011ferlerinden biri olabilir. \u00dcretim ortamlar\u0131nda genellikle warn<\/code> veya error<\/code> seviyesi tavsiye edilir, \u00e7\u00fcnk\u00fc daha d\u00fc\u015f\u00fck seviyeler (debug<\/code>, info<\/code>) \u00e7ok fazla veri \u00fcreterek disk alan\u0131n\u0131 h\u0131zla doldurabilir ve performans\u0131 d\u00fc\u015f\u00fcrebilir. Ancak, derinlemesine sorun giderme yaparken ge\u00e7ici olarak debug<\/code> seviyesine ge\u00e7mek \u00e7ok faydal\u0131 olabilir.<\/p>\nLogrotate ile Log Y\u00f6netimi: Neden \u00d6nemli ve Temel Yap\u0131land\u0131rma<\/h3>\n
\/etc\/logrotate.d\/nginx<\/code> dosyas\u0131nda bulunur ve a\u015fa\u011f\u0131daki gibi g\u00f6r\u00fcn\u00fcr:<\/p>\n\n \/var\/log\/nginx\/*.log {\n daily\n missingok\n rotate 7\n compress\n delaycompress\n notifempty\n create 0640 www-data adm\n sharedscripts\n postrotate\n if [ -f \/var\/run\/nginx.pid ]; then\n kill -USR1 cat \/var\/run\/nginx.pid<\/code>\n fi\n endscript\n }\n<\/code><\/pre>\n\n
\/var\/log\/nginx\/*.log<\/code>: Logrotate’\u0131n hangi dosyalar\u0131 y\u00f6netece\u011fini belirtir. Bu \u00f6rnekte, \/var\/log\/nginx\/<\/code> dizinindeki t\u00fcm .log<\/code> uzant\u0131l\u0131 dosyalar\u0131 kapsar.<\/li>\ndaily<\/code>: Log dosyalar\u0131n\u0131n g\u00fcnl\u00fck olarak d\u00f6nd\u00fcr\u00fclece\u011fini belirtir. Di\u011fer se\u00e7enekler weekly<\/code> (haftal\u0131k) veya monthly<\/code> (ayl\u0131k) olabilir.<\/li>\nmissingok<\/code>: Log dosyas\u0131 eksik olsa bile hata vermeden devam etmesini sa\u011flar.<\/li>\nrotate 7<\/code>: Son yedi d\u00f6nd\u00fcr\u00fclm\u00fc\u015f log dosyas\u0131n\u0131 saklar. Daha eski dosyalar silinir.<\/li>\ncompress<\/code>: D\u00f6nd\u00fcr\u00fclen log dosyalar\u0131n\u0131 gzip ile s\u0131k\u0131\u015ft\u0131r\u0131r. Bu, disk alan\u0131ndan tasarruf sa\u011flar.<\/li>\ndelaycompress<\/code>: Bir \u00f6nceki d\u00f6nd\u00fcr\u00fclen log dosyas\u0131n\u0131n s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 bir sonraki d\u00f6nd\u00fcrme i\u015flemine kadar erteler. Bu, o anki log dosyas\u0131n\u0131n s\u0131k\u0131\u015ft\u0131r\u0131lmamas\u0131n\u0131 ve \u00fczerinde i\u015flem yap\u0131labilmesini sa\u011flar.<\/li>\nnotifempty<\/code>: Log dosyas\u0131 bo\u015fsa d\u00f6nd\u00fcrme i\u015flemi yapmaz.<\/li>\ncreate 0640 www-data adm<\/code>: Yeni bir bo\u015f log dosyas\u0131 olu\u015fturur ve bu dosyaya www-data<\/code> kullan\u0131c\u0131s\u0131 ve adm<\/code> grubu i\u00e7in 0640<\/code> izinlerini atar. Bu, NGINX’in yeni dosyaya yazabilmesini sa\u011flar.<\/li>\nsharedscripts<\/code>: T\u00fcm log dosyalar\u0131 d\u00f6nd\u00fcr\u00fcld\u00fckten sonra postrotate<\/code> beti\u011finin yaln\u0131zca bir kez \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flar.<\/li>\npostrotate<\/code> \/ endscript<\/code>: Log dosyalar\u0131 d\u00f6nd\u00fcr\u00fcld\u00fckten sonra \u00e7al\u0131\u015ft\u0131r\u0131lacak komutlar\u0131 i\u00e7erir. NGINX i\u00e7in bu genellikle kill -USR1<\/code> sinyali g\u00f6ndererek NGINX’in log dosyalar\u0131n\u0131 yeniden a\u00e7mas\u0131n\u0131 sa\u011flamakt\u0131r. Bu, NGINX’in yeni log dosyas\u0131na yazmaya ba\u015flamas\u0131n\u0131 sa\u011flar ve herhangi bir iste\u011fin kaybolmamas\u0131n\u0131 garanti eder.<\/li>\n<\/ul>\nBufferlama ve Flush Ayarlar\u0131<\/h3>\n
access_log<\/code> direktifinde buffer<\/code> ve flush<\/code> parametrelerini sunar:<\/p>\n\n access_log \/var\/log\/nginx\/access.log combined buffer=32k flush=1s;\n<\/code><\/pre>\n\n
buffer=32k<\/code>: Log kay\u0131tlar\u0131n\u0131 diske yazmadan \u00f6nce 32 kilobaytl\u0131k bir tamponda biriktirir. Tampon doldu\u011funda diske yaz\u0131l\u0131r. Bu, disk yazma i\u015flemlerinin say\u0131s\u0131n\u0131 azaltarak performans\u0131 art\u0131r\u0131r.<\/li>\nflush=1s<\/code>: Tampon dolmasa bile, her 1 saniyede bir tampondaki kay\u0131tlar\u0131 diske yazmaya zorlar. Bu, loglar\u0131n \u00e7ok uzun s\u00fcre bellekte kalmas\u0131n\u0131 engeller ve olas\u0131 bir sunucu \u00e7\u00f6kmesi durumunda veri kayb\u0131n\u0131 minimize eder.<\/li>\n<\/ul>\nLog Analizi Ara\u00e7lar\u0131 ve \u0130leri Teknikler: Verileri Konu\u015fmaya Ba\u015flat\u0131n<\/h2>\n
Temel Komut Sat\u0131r\u0131 Ara\u00e7lar\u0131: H\u0131zl\u0131 \u0130nceleme<\/h3>\n
\n
tail -f \/var\/log\/nginx\/access.log<\/code>: Log dosyas\u0131na ger\u00e7ek zamanl\u0131 olarak yeni eklenen sat\u0131rlar\u0131 izlemenizi sa\u011flar. Bu, bir i\u015flemi tetikleyip an\u0131nda log \u00e7\u0131kt\u0131s\u0131n\u0131 g\u00f6rmek i\u00e7in idealdir.<\/li>\ngrep \"500\" \/var\/log\/nginx\/error.log<\/code>: Belirli bir desen (\u00f6rne\u011fin, “500” HTTP durum kodu) i\u00e7eren sat\u0131rlar\u0131 filtrelemek i\u00e7in kullan\u0131l\u0131r. \u00d6zellikle belirli hatalar\u0131 veya istekleri ararken \u00e7ok kullan\u0131\u015fl\u0131d\u0131r.<\/li>\nawk '{print $1}' \/var\/log\/nginx\/access.log | sort | uniq -c | sort -nr | head -n 10<\/code>: Bu komut zinciri, en \u00e7ok istek yapan ilk 10 IP adresini bulman\u0131z\u0131 sa\u011flar.\n\n awk '{print $1}' \/var\/log\/nginx\/access.log | \\\n sort | \\\n uniq -c | \\\n sort -nr | \\\n head -n 10\n <\/code><\/pre>\nawk '{print $1}'<\/code>), s\u0131ralar (sort<\/code>), her bir IP’nin ka\u00e7 kez ge\u00e7ti\u011fini sayar (uniq -c<\/code>), sonu\u00e7lar\u0131 say\u0131ya g\u00f6re ters s\u0131rada s\u0131ralar (sort -nr<\/code>) ve ilk 10’u g\u00f6sterir (head -n 10<\/code>).<\/p>\n<\/li>\nsed -n '\/01\\\/Jan\\\/2023:10:00:00\/,\/01\\\/Jan\\\/2023:10:05:00\/p' \/var\/log\/nginx\/access.log<\/code>: Belirli bir zaman aral\u0131\u011f\u0131ndaki log sat\u0131rlar\u0131n\u0131 ay\u0131klamak i\u00e7in sed<\/code> kullan\u0131labilir. Bu, belirli bir olay\u0131n meydana geldi\u011fi zaman dilimindeki loglar\u0131 incelemek i\u00e7in faydal\u0131d\u0131r.<\/li>\n<\/ul>\nPop\u00fcler Log Analizi Ara\u00e7lar\u0131: G\u00f6rselle\u015ftirme ve Otomasyon<\/h3>\n
\n
\n
Ger\u00e7ek Zamanl\u0131 \u0130zleme ve Uyar\u0131 Sistemleri<\/h3>\n
\n
Mobil Uyumlu Log Y\u00f6netimi ve G\u00f6r\u00fcnt\u00fcleme: Her Yerden Eri\u015fim<\/h2>\n
\n <style>\n \/* Varsay\u0131lan stil: Masa\u00fcst\u00fc i\u00e7in *\/\n body {\n font-family: Arial, sans-serif;\n margin: 20px;\n }\n .log-container {\n width: 90%;\n margin: 0 auto;\n padding: 15px;\n border: 1px solid #ccc;\n background-color: #f9f9f9;\n }\n .log-entry {\n border-bottom: 1px dashed #eee;\n padding: 8px 0;\n }\n\n \/* Mobil cihazlar i\u00e7in stil (ekran geni\u015fli\u011fi 768px veya daha az oldu\u011funda) *\/\n @media (max-width: 768px) {\n body {\n margin: 10px;\n }\n .log-container {\n width: 100%;\n padding: 10px;\n box-sizing: border-box; \/* Padding'in geni\u015fli\u011fe dahil olmas\u0131n\u0131 sa\u011flar *\/\n }\n .log-entry {\n font-size: 0.8em; \/* Mobil cihazlarda font boyutunu k\u00fc\u00e7\u00fclt *\/\n word-break: break-all; \/* Uzun kelimeleri k\u0131rarak ta\u015fmay\u0131 engelle *\/\n }\n \/* Daha k\u00fc\u00e7\u00fck ekranlarda s\u00fctunlar\u0131 tek tek g\u00f6stermek i\u00e7in tablo d\u00fczenini de\u011fi\u015ftirme *\/\n table, thead, tbody, th, td, tr {\n display: block;\n }\n thead tr {\n position: absolute;\n top: -9999px;\n left: -9999px;\n }\n tr { border: 1px solid #ccc; margin-bottom: 5px; }\n td {\n border: none;\n border-bottom: 1px solid #eee;\n position: relative;\n padding-left: 50%;\n text-align: right;\n }\n td:before {\n position: absolute;\n top: 6px;\n left: 6px;\n width: 45%;\n padding-right: 10px;\n white-space: nowrap;\n text-align: left;\n font-weight: bold;\n }\n \/* \u00d6rnek veri etiketleri *\/\n td:nth-of-type(1):before { content: \"IP Adresi:\"; }\n td:nth-of-type(2):before { content: \"Zaman:\"; }\n td:nth-of-type(3):before { content: \"\u0130stek:\"; }\n td:nth-of-type(4):before { content: \"Durum:\"; }\n td:nth-of-type(5):before { content: \"Boyut:\"; }\n }\n <\/style>\n<\/code><\/pre>\nmax-width: 768px<\/code> medya sorgusu ile ekran geni\u015fli\u011fi 768 piksel veya daha az oldu\u011funda farkl\u0131 stillerin uygulanmas\u0131n\u0131 sa\u011flar. Bu sayede:<\/p>\n\n
word-break: break-all;<\/code> gibi \u00f6zellikler kullan\u0131larak ekran d\u0131\u015f\u0131na ta\u015fmalar\u0131 engellenir.<\/li>\nSonu\u00e7: NGINX Loglar\u0131 ile Sunucunuza H\u00fckmedin<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
access.log<\/code> (eri\u015fim g\u00fcnl\u00fc\u011f\u00fc), sunucuya gelen her iste\u011fi (ba\u015far\u0131l\u0131 veya ba\u015far\u0131s\u0131z) kaydeder ve istemci IP’si, istenen URL, HTTP durumu gibi bilgileri i\u00e7erir. error.log<\/code> (hata g\u00fcnl\u00fc\u011f\u00fc) ise NGINX’in kendisinde veya arka u\u00e7 ileti\u015fimi s\u0131ras\u0131nda meydana gelen sorunlar\u0131, uyar\u0131lar\u0131 ve bilgilendirme mesajlar\u0131n\u0131 kaydeder. Eri\u015fim g\u00fcnl\u00fckleri d\u0131\u015f etkile\u015fimleri, hata g\u00fcnl\u00fckleri ise i\u00e7 sorunlar\u0131 yans\u0131t\u0131r.<\/p>\n<\/li>\nlogrotate<\/code> arac\u0131 kullan\u0131l\u0131r. logrotate<\/code>, log dosyalar\u0131n\u0131 belirli aral\u0131klarla (g\u00fcnl\u00fck, haftal\u0131k) d\u00f6nd\u00fcr\u00fcr, s\u0131k\u0131\u015ft\u0131r\u0131r ve eski dosyalar\u0131 siler. Ayr\u0131ca NGINX yap\u0131land\u0131rmas\u0131nda buffer<\/code> ve flush<\/code> parametreleri kullan\u0131larak log yazma i\u015flemleri optimize edilebilir.<\/p>\n<\/li>\n