[Web] nginx erişim günlüklerini otomatik olarak keser

Web erişim günlüğü (access_log), web sunucusuna giden tüm harici istemcilerin erişim davranışını, istemci IP, erişim tarihi, erişilen URL kaynağı, sunucu tarafından döndürülen HTTP durum kodu gibi önemli bilgileri kaydeder.
Tipik bir web erişim günlüğü şöyle görünür:

112.97.37.90 - - [14/Sep/2013:14:37:39 +0800] "GET / HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Linux; U; Android 2.3.6; ZH-CN; Lenovo A326 Build/GRK39F) AppleWebKit/533.1 (KHTML, Gecko gibi) Sürüm/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Planlama:

1. Sorunu çözmek için:

Web sitesi çok sayıda ziyarete sahip olduğunda, çok fazla günlük veri olur ve hepsi bir günlük dosyasına yazılırsa, dosya giderek büyür. Büyük dosyaların hızı, örneğin yüzlerce megabayt dosya gibi yavaşlar. Günlük yazarken işlem hızını etkiler. Ayrıca, erişim kayıtlarına bakmak istersem, birkaç yüz megabitlik bir dosyanın indirilip açılması yavaş oluyor. Üçüncü taraf ücretsiz bir log analiz aracı olan Log Treasure kullanarak, nginx, apache ve iis'ten log dosyalarını yükleyebilirsiniz; bu dosyalar web sitesi güvenliği açısından analiz edilmesine yardımcı olur. Sonuçta, uzmanlaşmak daha profesyoneldir. Log Bao'da ayrıca yüklenen dosyalar için bir boyut sınırı var, 50 metreden fazla olmamalıdır.

2. Nignx'in dosyaları otomatik olarak ayıran ve kayıtları depolayan bir mekanizması yoktur. Çünkü nginx dosyaları otomatik olarak sizin için kaydetmiyor. Bu nedenle, bunu uygulamak için kendi betik yazmanız gerekir.

Shell script dosyası aşağıdaki içerikleri nginx_log_division.sh:

# /bin/bash

logs_path="/data/wwwlogs/"

#以前的日志文件.

log_name="xxx.log"   

pid_path="/usr/local/nginx/logs/nginx.pid"

mv ${logs_path}${log_name} ${logs_path}${log_name}_$(date --date="LAST WEEK" +"%Y-%m-d").log

kill -USR1 'cat ${pid_path}'

Yukarıdaki shell script'in prensibi, önceki log dosyasını önce bir dosyaya taşımak ve yeniden adlandırmaktır; amaç yedeklemektir.

Son Pazartesi ismine göre, script "2013-09-16" zamanında çalıştırıldığında, oluşturulan dosya adı "xxx.log_ 20130909.log" olur.

Öldürmeden önce dosyada mv komutu çalıştırılmış olsa bile -USR1 'cat ${{pid_path}' çalıştırılırDosya adı değiştirildi, nginx her zamanki gibi yeni adlandırılmış "xxx.log_20130909" dosyasına günlük verilerini yazmaya devam eder. Bunun nedeni, Linux sistemlerinde çekirdeğin dosyaları dosya tanımlayıcılarına göre aramasıdır.

---------------- Linux dosya tanımlayıcılarının anlaşılması

Dosya tanımlayıcısı, Linux çekirdeğinin her açık dosya için adlandırdığı tamsayı tanımlayıcıdır.

Linux çekirdeği bir "Dosya Tanımlayıcı TablosuBu dosya tanımlayıcı tablosu "bu süreçle açılan dosyayı (tanımlanmış)" olarak kaydeder.

Bu ortamda, nginx zaten bir log dosyasını açmış ve dosyayı dosya tanımlayıcı tablosuna kaydeden çalışan bir süreçtir.

Log dosyasının yolu değişmiş olsa bile, yine de bulunabilir (dosya tanımlayıcı tablosuna göre bulunabilir).

----------------------------------------------

"kill -USR1 'cat ${pid_path}'" komutunu çalıştırırken, nginx.pid dosyasında kaydedilen aslında bir sayıdır (açıp bakabilirsiniz, ben 894 numaradayım) ve nginx ana sürecinin pid'ini (süreç numarasını) nginx.pid dosyasına yazar, böylece ana işlem numarasını cat komutu üzerinden doğrudan alabilir ve belirtilen işlem numarasını doğrudan çalıştırabilirsiniz.

kill -USR1 'cat ${pid_path}' eşdeğerdir

kill –USR1 894 #指定发信号 (USR1) bu süreci numaralandırmak için sinyal veriyor.

Linux sistemlerinde, Linux sinyaller aracılığıyla "çalışan süreçlerle" iletişim kurar. Linux sistemlerinde ayrıca SIGHUP gibi birçok önceden tanımlanmış sinyal de vardır. USR1, kullanıcı tarafından tanımlanan bir sinyaldir. Bu, sürecin bu sinyali aldığında ne yapacağını tanımlaması olarak anlaşılabilir (yani, süreç yazarı bu sinyali alıp almamaya karar verir ve tamamen geliştiriciye bırakır). nginx'te, USR1 sinyali aldığımda nginx'in log dosyasını yeniden açmasını sağlamak için kendi kodunu yazıyor. Özel ilke şöyledir:

1. nginx'in ana süreci USR1 sinyalini alır ve log dosyasını yeniden açar (nginx yapılandırma dosyasındaki log adından adını alır; bu değer yapılandırma dosyasındaki access_log öğe tarafından belirlenir ve dosya yoksa, otomatik olarak yeni bir dosya xxx.log oluşturulur).

2. Sonra log dosyasının sahibini "işçi süreci" olarak değiştirin, böylece işçi süreci log dosyasına okuma ve yazma izinlerine sahip olsun (ana ve işçi genellikle farklı kullanıcılar olarak çalışır, bu yüzden sahibin değiştirilmesi gerekir).

3. nginx ana süreci, yuptanet log dosyasını kapatacak (yani, az önce mv komutuyla xxx.log_ olarak yeniden adlandırılan dosya 20130909.log şu anda değiştirilmiş),ve çalışan sürecine yeni açılan log dosyasını kullanmasını bildirir(xxx.log ana süreç tarafından az önce açılan dosya). Özel uygulama daha ayrıntılıdır, ana süreç USR1 sinyalini çalışana gönderir ve bu sinyali aldıktan sonra işçi log dosyasını (yani yapılandırma dosyasında üzerinde anlaşılan xxx.log) yeniden açar

=================================== Scriptleri düzenli aralıklarla çalıştır

Yukarıdaki shell script dosyasını planlanmış göreve eklenecek şekilde ayarlayın. crontab, Linux altında planlanmış bir görev sürecidir. Bu süreç, cihazı açtığınızda başlar ve ara sıra yapılması gereken görevler olup olmadığını görmek için listesine girer.

crontab -e

* 04 * * 1 /data/wwwlogs/nginx_log_division.sh

Yukarıdaki kod eklendiğinde bir dosya açılır

Format "Shell dosya yolu yürütülecek"dir. * "her dakika", her saat, her ay vb. olarak anlaşılabilir.

Pazartesi günü sabah 4'te nginx_log_division.sh çalıştıracak bir script kurdum ve scriptin içeriği yeni bir log dosyasını yeniden oluşturmak.

Ekli:HazırlamaknginxLogların nasıl yapılandırıldığı

log_format sitesi '$remote_addr - $remote_kullanıcı [$time_local] "$request" '

             '$status $body_bytes_sent "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

access_log /data/wwwlogs/xxxx.com.log sitesi

#第二个参数表示使用那个日志格式, her log formatı için bir isim belirlenir ve site, o ada karşılık gelir log_format

Yukarıdaki durum crontab planlanmış görev yöneticisinin kullanımını içerir.

Ayrıca tam bir anlayış ve hataların olmadığı yerler de vardır. Umarım gelecekte güncelleme yaparız.