1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
4 <!-- English Revision: 807930:1173368 (outdated) -->
5 <!-- =====================================================
6 Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
7 Reviewed by: Orhan Berent <berent belgeler.org>
8 ========================================================== -->
11 Licensed to the Apache Software Foundation (ASF) under one or more
12 contributor license agreements. See the NOTICE file distributed with
13 this work for additional information regarding copyright ownership.
14 The ASF licenses this file to You under the Apache License, Version 2.0
15 (the "License"); you may not use this file except in compliance with
16 the License. You may obtain a copy of the License at
18 http://www.apache.org/licenses/LICENSE-2.0
20 Unless required by applicable law or agreed to in writing, software
21 distributed under the License is distributed on an "AS IS" BASIS,
22 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
23 See the License for the specific language governing permissions and
24 limitations under the License.
27 <manualpage metafile="logs.xml.meta">
29 <title>Günlük Dosyaları</title>
32 <p>Bir HTTP sunucusunu verimli şekilde yönetebilmek için oluşabilecek
33 sorunlardan başka sunucunun başarımı ve etkinliği hakkında da bazı geri
34 bildirimler almak gerekir. Apache HTTP Sunucusu çok kapsamlı ve esnek
35 bir günlükleme yeteneğine sahiptir. Bu belgede sunucunun günlükleme
36 yeteneğini nasıl yapılandıracağınızdan ve günlük kayıtlarını nasıl
37 yorumlayacağınızdan bahsedilecektir.</p>
40 <section id="security">
41 <title>Güvenlik Uyarısı</title>
43 <p>Apache’nin günlük dosyalarını yazdığı dizine yazabilen birinin sunucuyu
44 başlatan kullanıcı kimliğine (bu genellikle root olur) erişim
45 kazanabileceğine hemen hemen kesin gözüyle bakılabilir. Sonuçlarının
46 neler olacağını kestiremiyorsanız günlüklerin yazıldığı dizinde <em>hiç
47 kimseye</em> yazma erişimi vermeyin; ayrıntılı bilgi için <a
48 href="misc/security_tips.html">güvenlik ipuçları</a> belgesine
51 <p>Buna ilaveten, günlük dosyaları istemci tarafından sağlanmış bilgiler
52 de içerebilir. Bu nedenle, kötü niyetli istemcilerin günlük dosyalarına
53 denetim karakterleri girmeleri olasılığına karşı ham günlükler ele
54 alınırken dikkatli olunmalıdır.</p>
57 <section id="errorlog">
58 <title>Hata Günlüğü</title>
61 <directive module="core">ErrorLog</directive>
62 <directive module="core">LogLevel</directive>
66 <p>İsmi ve yeri <directive module="core">ErrorLog</directive> yönergesi
67 ile belirtilen sunucu hata günlüğü, en önemli günlük dosyasıdır. Apache
68 httpd tarafından istekler işlenirken saptanan hatalar ve tanı bilgileri
69 bu dosyaya gönderilir. Sunucuyu başlatırken veya sunucu çalışırken bir
70 sorunla karşılaşıldığında, neyin yanlış gittiğini öğrenmek için
71 bakılacak ilk yer burasıdır. Günlük kaydı çoğunlukla sorunun nasıl
72 düzeltileceği ile ilgili ayrıntıları da içerir.</p>
74 <p>Hata günlüğü normal olarak bir dosyaya yazılır (genellikle, dosyanın
75 ismi Unix sistemlerinde <code>error_log</code>, OS/2 ve Windows’ta ise
76 <code>error.log</code>’dur). Ayrıca, Unix sistemlerinde sunucunun
77 hataları <code>syslog</code>’a veya <a href="#piped">borulamak suretiyle
78 bir programa</a> aktarması da mümkündür.</p>
80 <p>Hata günlüğünün biçemi anlaşılır olup içeriği kısmen serbestçe
81 belirlenir. Çoğu hata günlüğü girdisinde bulunan belli başlı bilgiler
82 vardır. Örnek tipik bir hata iletisi içermektedir:</p>
85 [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
86 client denied by server configuration:
87 /export/home/live/ap/htdocs/test
90 <p>Günlük girdisinin ilk öğesi iletinin yazıldığı tarih ve saatten oluşur.
91 İkinci öğe raporlanan bilginin önem derecesini belirtir. Hata günlüğüne
92 gönderilecek hata türlerinin önem seviyesini belirlemek için <directive
93 module="core">LogLevel</directive> yönergesi kullanılır. Üçüncü öğe
94 hatanın üretilmesine sebep olan istemcinin IP adresini içerir. Kalanı
95 iletinin kendisidir (duruma bakılırsa sunucu istemci erişimini reddetmek
96 üzere yapılandırılmış). Sunucu istenen belgenin (belge yolunu değil)
97 dosya sistemindeki yolunu raporlamıştır.</p>
99 <p>Hata günlüğünde görünebilecek ileti çeşitliliği oldukça fazladır. Çoğu
100 yukarıdaki örneğin benzeridir. Hata günlüğü ayrıca, CGI betiklerinin
101 hata ayıklama çıktılarını da içerir. Bir CGI betiği tarafından standart
102 hataya (<code>stderr</code>) yazılan her türlü bilgi doğrudan hata
103 günlüğüne kopyalanır.</p>
105 <p>Hata günlüğünü bilgi ekleyerek veya kaldırarak kişiselleştirmek
106 mümkündür. Bununla birlikte, hata günlüğü girdilerinin ilgili olduğu
107 isteklerin <a href="#accesslog">erişim günlüğünde</a> de girdileri
108 vardır. Örneğin, yukarıdaki girdi, erişim günlüğünde 403 durum kodlu bir
109 girdiyle ilgilidir. Erişim günlüğünü de kişiselleştirmek mümkün
110 olduğundan hata durumlarında bu günlük dosyasını da kullanarak daha
111 fazla bilgi sağlayabilirsiniz.</p>
113 <p>Sunucuyu denerken olası sorunlara karşı hata günlüğünü sürekli
114 izlemelisiniz. Unix sistemlerinde bunu şöyle bir komutla
115 sağlayabilirsiniz:</p>
122 <section id="accesslog">
123 <title>Erişim Günlüğü</title>
127 <module>mod_log_config</module>
128 <module>mod_setenvif</module>
131 <directive module="mod_log_config">CustomLog</directive>
132 <directive module="mod_log_config">LogFormat</directive>
133 <directive module="mod_setenvif">SetEnvIf</directive>
137 <p>Sunucu erişim günlüğü sunucu tarafından işleme alınan tüm istekleri
138 kaydeder. Erişim günlüğünün yeri ve içeriği <directive
139 module="mod_log_config">CustomLog</directive> yönergesi ile belirlenir.
140 <directive module="mod_log_config">LogFormat</directive> yönergesi ile
141 günlük içeriğini kişiselleştirmek mümkündür. Bu bölümde sunucunun
142 bilgileri erişim günlüğüne kaydetmesi için nasıl yapılandırılacağından
145 <p>Şüphesiz, bilginin erişim günlüğünde saklanması günlük yönetiminde ilk
146 adımı oluşturur. Sonraki adım yararlı istatistikleri üretmek için bu
147 bilgiyi incelemektir. Günlük incelemesi bu belgenin kapsamına dahil
148 değildir ve aslında bu işlem sunucunun yaptığı işlerden biri değildir.
149 Bu konu ve günlük incelemesi yapan uygulamalar hakkında daha ayrıntılı
150 bilgi edinmek için <a
151 href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/"
152 >dmoz.org</a> veya <a
153 href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/"
154 >Yahoo</a>’ya bakınız.</p>
156 <p>Apache httpd’nin çeşitli sürümlerinde erişim günlüklerini denetlemek
157 için kullanılan diğer modüller ve yönergeler arasında mod_log_referer,
158 mod_log_agent modülleri ve <code>TransferLog</code> yönergesi
159 sayılabilir. Artık, daha eski tüm diğer yönergelerin işlevselliklerini
160 bir araya toplayan <directive module="mod_log_config"
161 >CustomLog</directive> yönergesi kullanılmaktadır.</p>
163 <p>Erişim günlüğünün girdi biçemi kolayca isteğe göre
164 düzenlenebilmektedir. Biçemi belirtmekte kullanılan biçem dizgesi, C
165 tarzı printf(1) biçem dizgesini andırır. Sonraki bölümlerde bazı
166 örneklere yer verilmiştir. Biçem dizgesini oluşturan belirteçlerin tam
167 listesi için <module>mod_log_config</module> belgesinin <a
168 href="mod/mod_log_config.html#formats">Günlük Girdilerinin
169 Kişiselleştirilmesi</a> bölümüne bakınız.</p>
171 <section id="common">
172 <title>Ortak Günlük Biçemi (OGB)</title>
174 <p>Erişim günlüğü için sıklıkla kullanılan bir yapılandırma:</p>
177 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
178 CustomLog logs/access_log common
181 <p>İlk satırda belli bir biçem dizgesi için <code>common</code> diye bir
182 <em>takma ad</em> tanımlanmaktadır. Biçem dizgesi, sunucuya hangi
183 belli bir bilgi parçalarını günlükleyeceğini söyleyen % imli biçem
184 belirteçlerinden oluşur. Biçem dizgesine ayrıca dizgesel sabitler de
185 yerleştirilebilir ve bunlar erişim günlüğüne oldukları gibi
186 kopyalanırlar. Biçem dizgesi içinde çift tırnak karakteri (") biçem
187 dizgesini vaktinden önce sonlandırmaması için ters bölü çizgisi ile
188 öncelenmelidir. Biçem dizgesi ayrıca, satır sonlarını belirtmek için
189 "<code>\n</code>" ve sekmeleri belirtmek için "<code>\t</code>"
190 denetim karakterlerini de içerebilir.</p>
192 <p><directive module="mod_log_config">CustomLog</directive> yönergesi
193 evvelce tanımlanmış bir <em>takma adı</em> kullanarak yeni bir günlük
194 dosyası tanımlar. Erişim günlüğünün dosya ismi bölü çizgisi ile
195 başlamadıkça dosya yolunun <directive module="core"
196 >ServerRoot</directive> değerine göreli olduğu varsayılır.</p>
198 <p>Yukarıdaki yapılandırma günlük dosyasına girdileri Ortak Günlük
199 Biçemi (Common Log Format) adı verilen standart biçemde yazar.
200 Bu standart biçem başka HTTP sunucuları tarafından da kullanılır ve
201 çoğu günlük inceleme yazılımı tarafından tanınır. Ortak Günlük
202 Biçeminde üretilen günlük girdileri şöyle görünür:</p>
205 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
206 /apache_pb.gif HTTP/1.0" 200 2326
209 <p>Bu günlük girdisini parça parça açıklayalım:</p>
212 <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
214 <dd>Bu, sunucuya istek yapan istemcinin (uzak konağın) IP adresidir.
215 Eğer <directive module="core">HostnameLookups</directive>
216 yönergesine <code>On</code> değeri atanmışsa sunucu bu IP adresi
217 için DNS sorgusu yapacak ve IP adresi yerine bulduğu konak ismini
218 yazmaya çalışacaktır. Bununla birlikte, bu işlem sunucuyu epeyce
219 yavaşlattığından önerilmemektedir. Konak isimlerini saptamak için en
220 iyisi günlük girdilerini <program>logresolve</program> gibi bir
221 günlük işlemcisinden geçirmektir. Burada raporlanan IP adresi
222 doğrudan istemcinin IP adresi olmayabilir. Eğer sunucu ile istemci
223 arasında bir vekil sunucu varsa bu IP adresi, vekil sunucunun IP
224 adresi olacaktır.</dd>
226 <dt><code>-</code> (<code>%l</code>)</dt>
228 <dd>Çıktıdaki bir "tire" imi istenen bilgi parçasının mevcut olmadığı
229 anlamına gelir. Bu durumda, mevcut olmayan bilgi istemci makine
230 üzerinde <code>identd</code> tarafından belirlenen istemcinin RFC
231 1413 kimliğidir. Bu bilgi oldukça güvenilmezdir ve sıkıca denetlenen
232 iç ağlar haricinde hemen hemen asla kullanılmamalıdır. Apache,
233 <directive module="core">IdentityCheck</directive> yönergesine
234 <code>On</code> değeri atanmış olmadıkça bu bilgiyi saptamaya
237 <dt><code>frank</code> (<code>%u</code>)</dt>
239 <dd>Bu, belge isteğinde bulunan kişinin HTTP kimlik doğrulamasıyla
240 saptanan kullanıcı kimliğidir. Bu değer CGI betiklerine
241 <code>REMOTE_USER</code> ortam değişkeni ile sağlanır. Eğer istek
242 için durum kodu 401 ise (aşağıya bakınız) henüz kullanıcının kimliği
243 doğrulanmamış olacağından bu değere güvenilmemelidir. Eğer belge
244 parola korumalı değilse günlüğün bu kısmı da yukarıdaki gibi
245 "<code>-</code>" olacaktır.</dd>
247 <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
248 (<code>%t</code>)</dt>
250 <dd>İsteğin alındığı tarih ve saat. Biçemi şöyledir:
253 <code>[gün/ay/yıl:saat:dakika:saniye dilim]<br />
258 dakika = 2 hane<br />
259 saniye = 2 hane<br />
260 dilim = (`+' | `-') 4 hane</code>
262 Günlük biçem dizgesinde zaman gösterim biçemini
263 <code>%{<em>biçem</em>}t</code> şeklinde belirtmek de mümkündür.
264 Buradaki <code><em>biçem</em></code> dizgesi, stardart C
265 kütüphanesindeki <code>strftime(3)</code> işlevi için tanımlanmış
266 biçem belirteçleriyle oluşturulabilir.
269 <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
270 (<code>\"%r\"</code>)</dt>
272 <dd>İstemciden alınan istek satırının çift tırnaklar arasında
273 gösterilmesi istenmiştir. İstek satırı en yararlı bilgi parçalarını
274 içerir. Birincisi, istemci tarafından kullanılan yöntem
275 <code>GET</code>’miş. İkinci olarak istemci
276 <code>/apache_pb.gif</code> dosyasını istemiş ve üçüncü olarak
277 istemci <code>HTTP/1.0</code> protokolünü kullanmış. İstek satırının
278 bazı parçalarını bağımsız olarak da günlüklemek mümkündür. Örneğin,
279 "<code>%m %U%q %H</code>" dizgesi, yöntem, yol, sorgu dizgesi ve
280 protokolü kaydedecektir; bu dizge "<code>%r</code>" biçem
281 belirtecinin tek başına yaptığı işi yapar.</dd>
283 <dt><code>200</code> (<code>%>s</code>)</dt>
285 <dd>Bu, sunucunun istemciye gönderdiği durum kodudur. İsteğin
286 başarıyla yerine getirilip getirilmediğini gösterdiği için bu bilgi
287 çok değerlidir. Durum kodu 2 ile başlıyorsa istek başarıyla yerine
288 getirilmiştir, 3 ile başlıyorsa yönlendirilmiştir, 4 ile başlıyorsa
289 istemci tarafında bir hata oluşmuştur, 5 ile başlıyorsa sunucuda bir
290 hata oluşmuştur. Olası hata kodlarının tam listesi <a
291 href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">RFC2616 Hiper
292 Metin Aktarım Protokolü</a>nün 10. bölümünde bulunabilir.</dd>
294 <dt><code>2326</code> (<code>%b</code>)</dt>
296 <dd>Son parça istemciye döndürülen nesnenin yanıt başlığı hariç
297 uzunluğudur. Eğer istemciye bir içerik döndürülmemişse bu değer
298 "<code>-</code>" olacaktır. Bunun yerine günlüğe "<code>0</code>"
299 yazdırmak için <code>%B</code> belirtecini kullanınız.</dd>
303 <section id="combined">
304 <title>Birleşik Günlük Biçemi</title>
306 <p>Sıklıkla kullanılan diğer bir biçem dizgesi Birleşik Günlük Biçemi
307 (Combined Log Format) olup şöyle kullanılabilir:</p>
310 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
311 \"%{User-agent}i\"" combined<br />
312 CustomLog log/access_log combined
315 <p>Bu biçem ilaveten 2 alan içermesi dışında Ortak Günlük Biçemi ile
316 aynıdır. İlave alanların ikisi de <code>%{<em>başlık</em>}i</code>
317 biçeminde olup buradaki <code><em>başlık</em></code>, HTTP isteğindeki
318 başlık alanlarından biridir. Bu biçemin kullanıldığı bir erişim
319 günlüğü girdisi şöyle olurdu:</p>
322 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
323 /apache_pb.gif HTTP/1.0" 200 2326
324 "http://www.example.com/start.html" "Mozilla/4.08 [en]
331 <dt><code>"http://www.example.com/start.html"</code>
332 (<code>\"%{Referer}i\"</code>)</dt>
334 <dd>HTTP istek başlığı "Referer". İstemcinin raporladığı isteğin
335 kaynaklandığı URI. (Bu isteğin yapılmasını sağlayan bağlantıyı
336 içeren URL veya istek bir sayfanın bileşenleri ile ilgiliyse istenen
337 sayfanın URL’si olabilir.)</dd>
339 <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
340 (<code>\"%{User-agent}i\"</code>)</dt>
342 <dd>Tarayıcı kimliğini içeren HTTP istek başlığı. Bu istemcinin
343 tarayıcısının raporladığı kendi tanıtım bilgisidir.</dd>
347 <section id="multiple">
348 <title>Çok Sayıda Erişim Günlüğü</title>
350 <p>Yapılandırma dosyasında çok sayıda <directive
351 module="mod_log_config">CustomLog</directive> yönergesi kullanarak çok
352 sayıda erişim günlüğü kolayca oluşturulabilir. Örneğin aşağıdaki
353 yönergelerle 3 tane erişim günlüğü oluşturulacaktır. İlki temel OGB
354 bilgisini içerirken diğer ikisi isteğin kaynaklandığı yeri ve tarayıcı
355 kimliğini içerir. Son iki <directive module="mod_log_config"
356 >CustomLog</directive> satırı ayrıca, <code>ReferLog</code> ve
357 <code>AgentLog</code> yönergelerinin etkilerinin nasıl taklit
358 edileceğini de göstermektedir.</p>
361 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
362 CustomLog logs/access_log common<br />
363 CustomLog logs/referer_log "%{Referer}i -> %U"<br />
364 CustomLog logs/agent_log "%{User-agent}i"
367 <p>Bu örnek ayrıca, <directive module="mod_log_config"
368 >LogFormat</directive> yönergesi ile bir takma ad tanımlamanın şart
369 olmadığını da göstermektedir. Günlük biçemi doğrudan <directive
370 module="mod_log_config">CustomLog</directive> yönergesinde
374 <section id="conditional">
375 <title>Şarta Bağlı Günlükler</title>
377 <p>Bazı durumlarda istemcinin yaptığı isteğe bağlı olarak erişim
378 günlüğünde belli girdilerin dışlanması gerekebilir. Bu, <a
379 href="env.html" >ortam değişkenleri</a> sayesinde kolayca yerine
380 getirilebilir. Önce isteğin belli koşulları sağladığını belirten bir
381 ortam değişkeni ataması yapılır. Bu işlem <directive
382 module="mod_setenvif">SetEnvIf</directive> yönergesi ile yapılır.
383 Sonra da, ortam değişkenine bağlı olarak isteklerin günlüğe dahil
384 edilip edilmeyeceği <directive
385 module="mod_log_config">CustomLog</directive> yönergesinin
386 <code>env=</code> deyimi kullanılarak belirtilir. Bazı örnekler:</p>
389 # yerel konaktan kaynaklanan istekleri imleyelim<br />
390 SetEnvIf Remote_Addr "127\.0\.0\.1" kaydetme<br />
391 # robots.txt dosyası isteklerini imleyelim<br />
392 SetEnvIf Request_URI "^/robots\.txt$" kaydetme<br />
393 # Kalanları günlüğe kaydedelim<br />
394 CustomLog logs/access_log common env=!kaydetme
397 <p>Başka bir örnek olarak, Türkçe belge isteklerini bir dosyaya diğer
398 dillerdeki istekleri başka bir dosyaya kaydedelim.</p>
401 SetEnvIf Accept-Language "tr" turkce<br />
402 CustomLog logs/turkce_log common env=turkce<br />
403 CustomLog logs/diger_diller_log common env=!turkce
406 <p>Şarta bağlı günlük kaydının çok esnek ve güçlü olabileceğini
407 göstermiş olsak da günlük içeriğini denetlemenin tek yolu bu değildir.
408 Günlük dosyaları sunucu etkinliğini eksiksiz olarak kaydedebildikleri
409 takdirde daha yararlı olurlar. Günlük dosyalarını sonradan işleme tabi
410 tutarak istenmeyen girdileri kaldırılmış bir kopya almak hem kolay hem
411 de daha yararlıdır.</p>
415 <section id="rotation">
416 <title>Günlük Çevrimi</title>
418 <p>Yükü ağır sunucularda günlük dosyalarına kaydedilen bilginin miktarı
419 çok büyük boyutlara ulaşabilir. 10.000 istek içeren bir erişim günlüğü
420 yaklaşık 1MB yer kaplar. Etkin günlük dosyasını belirli aralıklarla
421 değiştirmek veya silmek gerekebilir. Apache çalışırken dosyayı sürekli
422 açık tuttuğu ve yazdığı için bu işlem sunucu çalışırken yapılamaz. Bu
423 bakımdan, günlük dosyası değiştirildikten veya silindikten sonra yeni
424 dosyanın açılması için <a href="stopping.html">sunucunun yeniden
425 başlatılması</a> gerekir.</p>
427 <p><a href="stopping.html#graceful">Nazikçe yeniden başlatmak</a>
428 suretiyle sunucunun, mevcut ve bekleyen bağlantıları kaybetmeden yeni
429 günlük dosyalarını açması sağlanabilir. Bununla birlikte, bu işlem
430 sırasında sunucunun eski isteklere sunumu bitirene kadar eski günlük
431 dosyalarına yazmaya devam edebilmesi gerekir. Bu bakımdan, yeniden
432 başlatmanın ardından eski günlük dosyaları üzerinde bir işlem yapmadan
433 önce biraz beklemek gerekir. Günlük dosyalarını döndürürken kullanılan
434 senaryolarda genellikle eski günlük dosyaları yer kazanmak için
438 mv access_log access_log.old<br />
439 mv error_log error_log.old<br />
440 apachectl graceful<br />
442 gzip access_log.old error_log.old
445 <p>Günlük çevrimi yapmanın başka bir yolu da sonraki bölümde açıklandığı
446 gibi <a href="#piped">borulu günlükler</a> kullanmaktır.</p>
450 <title>Borulu Günlükler</title>
452 <p>Apache httpd hata ve erişim günlüklerini doğrudan bir dosyaya yazmak
453 yerine bir boru üzerinden başka bir sürece yazabilir. Bu yetenek ana
454 sunucuya herhangi bir kod eklemeksizin günlükleme esnekliğini şaşırtıcı
455 derecede arttırır. Günlükler boruya yazılmak istenirse dosya ismini boru
456 karakteriyle ("<code>|</code>") değiştirip ardına günlük girdilerini
457 standart girdisinden kabul edecek programın ismini eklemek yeterlidir.
458 Apache sunucusu başlatıldığı zaman borulu günlük işlemini de
459 başlatacaktır. Eğer sunucu çalışırken günlükleri kabul eden süreç
460 çökerse Apache bu programı yeniden başlatır. (Bu son özelliği sebebiyle
461 bu tekniğe “güvenilir borulu günlükleme” adını veriyoruz.)</p>
463 <p>Borulu günlük süreçleri ana Apache httpd süreci tarafından başlatılır
464 ve bu süreçler ana Apache httpd sürecinin kullanıcı kimliğini miras
465 alırlar. Yani borulu günlükleme programları aslında root tarafından
466 çalıştırılmış gibi olur. Bu bakımdan, bu programları basit ve güvenilir
467 kılmak çok önemlidir.</p>
469 <p>Borulu günlüklerin önemli kullanım alanlarından biri de sunucuyu
470 yeniden başlatmak gerekmeksizin günlük çevrimini mümkün kılmaktır.
471 Apache HTTP sunucusu bu amaçla kullanılmak üzere
472 <program>rotatelogs</program> diye bir program içerir. Örneğin,
473 günlükleri 24 saatte bir döndürmek isterseniz bunu şöyle
477 CustomLog "|/usr/local/apache/bin/rotatelogs
478 /var/log/access_log 86400" common
481 <p>Borunun diğer ucundaki süreci başlatacak komutun tırnak içine
482 alındığına dikkat ediniz. Bu örnekler erişim günlüğü için verilmişse de
483 aynı teknik hata günlüğü için de kullanılabilir.</p>
485 <p>Hariçten bir uygulama olarak <a
486 href="http://www.cronolog.org/">cronolog</a> isminde buna benzer ancak
487 çok daha esnek bir program daha vardır.</p>
489 <p>Borulu günlükler de şarta bağlı günlükleme kadar güçlü olmakla beraber
490 çevrimdışı ardıl işlemler gibi daha basit çözümler için
491 kullanılmamalıdır.</p>
494 <section id="virtualhost">
495 <title>Sanal Konaklar</title>
497 <p>Bir sunucu çok sayıda <a href="vhosts/">sanal konak</a> ile hizmet
498 sunarken bunların günlük kayıtları için çeşitli seçenekler mevcuttur.
499 İlk seçenekte, sanki sunucu tek bir konakla hizmet sunuyormuş gibi
500 günlük kaydı yapılır. Günlükleme yönergelerini <directive module="core"
501 type="section">VirtualHost</directive> bölümlerinin dışına, ana sunucu
502 bağlamına yerleştirerek tüm isteklerin aynı erişim ve hata günlüğüne
503 yazılmasını sağlamak olasıdır. Bu teknik, tek tek sanal konaklar için
504 kolayca istatistik toplamaya izin vermez.</p>
506 <p>Eğer <directive module="mod_log_config">CustomLog</directive>
507 veya <directive module="core">ErrorLog</directive> yönergesi bir
508 <directive module="core" type="section">VirtualHost</directive> bölümüne
509 yerleştirilirse bu sanal konağa bütün erişimler veya hatalar belirtilen
510 dosyaya günlüklenecektir. Böyle günlükleme yönergeleri içermeyen sanal
511 konakların günlükleri hala ana sunucunun hata ve erişim günlüklerine
512 yazılmaya devam edecektir. Bu teknik az sayıda sanal konak barındıran
513 sunucular için çok kullanışlıdır. Fakat sanal konak sayısı çok fazlaysa
514 bu teknikle günlük dosyalarını yönetmek çok karmaşık bir hal alabilir.
515 Ayrıca, <a href="vhosts/fd-limits.html">yetersiz dosya tanıtıcısı</a>
516 sorunlarıyla çok sık karşılaşılabilir.</p>
518 <p>Erişim günlükleri için çok az bir fedakarlıkla çok iyi bir çözüm vardır.
519 Günlük biçemine sanal konaklarla ilgili bilgi eklemek suretiyle tüm
520 konakların aynı günlük dosyasını kullanmaları olasıdır. Böylece günlük
521 dosyası sonradan her sanal konak için ayrı bir dosya oluşturmak üzere
522 ayrıştırılabilir. Örneğin, bu işlem için şu yönergeler kullanılıyor
526 LogFormat "%v %l %u %t \"%r\" %>s %b"
528 CustomLog logs/access_log ortaksankon
531 <p><code>%v</code> belirteci isteği sunan sanal konağın ismini günlüğe
532 yazmak için kullanılır. Daha sonra <a
533 href="programs/other.html">split-logfile</a> gibi bir program
534 kullanarak, bu dosyadan her sanal konak için ayrı birer dosya elde
539 <title>Diğer Günlük Dosyaları</title>
543 <module>mod_logio</module>
544 <module>mod_log_forensic</module>
545 <module>mod_cgi</module>
546 <module>mod_rewrite</module>
549 <directive module="mod_log_config">LogFormat</directive>
550 <directive module="mod_log_forensic">ForensicLog</directive>
551 <directive module="mpm_common">PidFile</directive>
552 <directive module="mod_rewrite">RewriteLog</directive>
553 <directive module="mod_rewrite">RewriteLogLevel</directive>
554 <directive module="mod_cgi">ScriptLog</directive>
555 <directive module="mod_cgi">ScriptLogBuffer</directive>
556 <directive module="mod_cgi">ScriptLogLength</directive>
561 <title>Gönderilen ve alınan bayt sayısının günlüklenmesi</title>
563 <p><module>mod_logio</module> modülü <directive
564 module="mod_log_config">LogFormat</directive> yönergesinde kullanılan
565 biçem belirteçlerine alınan ve gönderilen bayt sayıları için iki
566 belirteç (%I ve %O) ekler.</p>
570 <title>Adli Günlük</title>
572 <p><module>mod_log_forensic</module> modülü istemci isteklerinin kanıt
573 olarak kullanılmak amacıyla günlüklenmesini sağlar. Günlükleme her
574 istek için isteğe hizmet sunmadan önce ve sonra olmak üzere iki defa
575 yapılır. Böylece günlük dosyasında başarılı her istek için iki satır
576 bulunur. Adli günlükleme çok sıkı kurallara tabi olup
577 kişiselleştirilemez. Güvenlik ve hata ayıklama aracı olarak yararlı
581 <section id="pidfile">
582 <title>PID Dosyası</title>
584 <p>Apache httpd başlatıldığında, ana httpd sürecinin kimliği (PID)
585 <code>logs/httpd.pid</code> dosyasına kaydedilir. Bu dosyanın ismi
586 <directive module="mpm_common">PidFile</directive> yönergesi ile
587 değiştirilebilir. Bu süreç kimliği sistem yöneticisi tarafından ana
588 sürece sinyal göndererek artalan sürecini sonlandırmak veya yeniden
589 başlatmak için kullanılır. Windows üzerinde bu işlem için
590 <code>-k</code> komut satırı seçeneği kullanılır. Bu konuda daha
591 ayrıntılı bilgi edinmek için <a href="stopping.html">Durdurma ve
592 Yeniden Başlatma</a> belgesine bakınız.</p>
595 <section id="scriptlog">
596 <title>Betik Günlüğü</title>
598 <p><directive module="mod_cgi">ScriptLog</directive> yönergesi CGI
599 betiklerinin girdi ve çıktılarını kaydetmenizi mümkün kılmak suretiyle
600 hata ayıklamaya yardımcı olur. Bu sadece deneysel amaçla kullanılmalı,
601 asıl sunucuya uygulanmamalıdır. <a href="mod/mod_cgi.html">mod_cgi</a>
602 belgesinde daha fazla bilgi bulunabilir.</p>
605 <section id="rewritelog">
606 <title>Yeniden Yazım Günlüğü</title>
608 <p>Güçlü ve karmaşık <a href="mod/mod_rewrite.html">mod_rewrite</a>
609 özellikleri kullanılırken, hata ayıklamaya yardımcı olmak için
610 <directive module="mod_rewrite">RewriteLog</directive> yönergesini
611 kullanmak gerekebilir. Yönerge, günlük dosyasında yeniden yazım
612 motorunun istekleri nasıl dönüştürdüğüyle ilgili ayrıntılı bir döküm
613 üretir. Ayrıntı seviyesi <directive module="mod_rewrite"
614 >RewriteLogLevel</directive> yönergesi ile belirlenir.</p>