最終更新日： 2014年9月18日
【Squid Home / FAQトップ】

6. Squidのログファイル

ログは、Squidの働きやパフォーマンスに関する貴重な情報源です。ログレコードは、アクセス記録だけでなく、システム構成のエラーやリソース消費（例えば、メモリ、ディスクスペース）などが記録されます。それらのログによってSquidは維持されます。いくつかは、実行時の安全のために非活性化されているため、明示的にコンパイル時に活性化されなければなりません。

すべてのログファイルに共通するいくつかの基本的なポイントがあります。特に明記しない限り、ログファイルに記録さタイムスタンプは、通常はUTC時間です。初期タイムスタンプは、通常、ミリ秒の拡張子が含まれています。

Squidのログ解析に関しては最初にこちらを読んで頂いた方が良いかもしれません。

6.1 squid.out

SquidをRunCacheスクリプトから起動すると、Squidの実行状況がここに記録されます。　もし、SquidがエラーとなってRunCacheによって再起動された場合にはその痕跡が残ります。

6.2 cache.log

cache.logはSquidによって生成され、エラーやデバックメッセージが記録されます。　もしRunCacheスクリプトか-sオプションを付けてSquidを起動したなら、syslogの情報も記録されることでしょう。

6.3 store.log

store.logには、キャッシュに記録されたもしくは削除されたオブジェクトの記録が残ります。　また、どんな情報にどれだけアクセスされたのかの調査にも利用できます。
このログファイルの記録内容は1行で１エントリを表し、スペースでセパレートされた11項目であらわされます。　
11項目はsec/store_log.cの中の storeLog() 関数で定義されています。
その内容は、
"%9d.%03d %-7s %08X %4d %9d %9d %9d %s %d/%d %s %s\n"
となっており順に、
・ time
ミリ秒であらわされるUTC時間（1970/1/1を基点とした時間）です。
・ action
オブジェクトのストア状態を報告します。

CREATE ： 存在しなかったので作成されたようです。
RELEASE ： キャッシュから開放されたようです。
SWAPOUT ： オブジェクトはディスクに退避されました。
SWAPIN ： ディスクにあるオブジェクトをキャッシュへロードしました。
・ file number
file numberはオブジェクト格納ファイルを表している。　設定のcache_dir で指定されたディレクトリパスの中のファイルを示す値となる。
file numberが FFFFFFFF のものは、メモリのみに存在するオブジェクトである。いくつかのactionコードでは、このようなメモリオブジェクトを参照します。例えばRELEASEアクションではメモリオブジェクトから開放されるため、file number はFFFFFFFF となります。
・ status
HTTPの応答コードです。
・ datehdr
これは、HTTPの応答ヘッダーの"Date:"の値です。
・ lastmod
これは、HTTPの応答ヘッダーの"Last-Modified"（最終変更日？）の値です。
・ expires
これは、HTTPの応答ヘッダーの"Expires:"（保存期間？）の値です。
・ type
HTTPの"Content-Type"を返します。　判らないときは"unknown"を返します。
・ sizes
ここにはスラッシュで区切られた２つの値が入ります。

1). HTTPの応答ヘッダーの"Content-Length: "の値。
2). 実際に読み取った値。
・ method
オブジェクトへのリクエストメソッド。 例えばGET。
・ key
オブジェクトへのキー、通常はURL。

6.4 hierarchy.log

これはsquid1.0だけのためにあるログファイルです。フォーマットは

[date] URL peerstatus peerhost

となっています。

6.5 access.log

殆どのアクセス解析プログラムは、access.log を調べることで可能です。squid2ではaccess.logとして２つの形式をサポートしています。
Squid3では logformat ディレクティブを使い、ログのフォーマットを自由に設定できるようになっています。　また、Squid独自のログフォーマット以外に標準で common, combined, referrer, useragent の４つのフォーマットが定義されています。（Debianではsquid,squidmime,common,combinedの4つが定義されていますが、コメント化されているためデフォルトではSquid標準しか利用できないないようになっています）

Squid2までは、利用するログフォーマットの指定は"emulate_httpd_log "オプションを使うことでhttpd互換（CERN web daemon互換：common log file format（CLF）と言います）のフォーマット、そうでない場合はsquid本来のログ形式をサポートしています。
Squid3.4では、 ogformat ディレクティブとaccess_logディレクティブを組み合わせて定義するようになっています。

CLFフォーマットは、squid本来のlogフォーマットに比べ多くの情報を持ち、かつ、ログファイルとしては小さくなります。　squid本来のログには管理者のためにキャッシュ評価に関する情報が多く含まれます。

◆Squid2の場合
ログはcache_access_log ディレクティブで指定された場所に記録されます。
1) common log fileのフォーマット
common log fileフォーマットは多くのhttpサーバで利用されています。　このファイルは７のフィールドによって構成されます。
remotehost rfc931 authuser [date] "method URL" status bytes
common log fileのフォーマットは多様なツールで利用できます。　またこのフォーマットには、HTTPのバージョンのようにsquid本来のログと異なる情報を含みます。
2) squid本来のlogフォーマット（ネイティブフォーマット）
squid本来のlogフォーマットはsquidのバージョンによって形式が異なります。squid1.0では以下の形式となります。
time elapsed remotehost code/status/peerstatus bytes method URL
squid1.1からは、階層に関する情報がhierarchy.logからaccess.logに移されました。結果ログの形式は、つぎのようになります。
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type
squid2.0でも同じ形式を使っています。
CLFとsquid独自のログの違いは、リクエスト継続時間・タイムアウト情報・上流サーバアドレス・コンテンツタイプなどです。
squid2common.pl はCERN プロキシ形式のログフォーマットへの変換ツールです。この形式にすることで、多くの分析ツールの利用が可能になります。

access.logネイティブフォーマットの細部

squidのネイティブログを利用することで、多くの情報を解析できることでしょう。ネイティブフォーマットは次のような構成になっています。
"%9d.%03d %6d %s %s/%03d %d %s %s %s %s%s/%s %s"
これは順に、
・ time
ミリ秒で示されるUTC時間（1970年1月1日を基点の時間）です。これは以下の perl スクリプトで読みやすい時間に変換できます。
#! /usr/bin/perl -p
s/^\d+\.\d+/localtime $&/e;
上記のスクリプト適当な名前で作成して、chmodで実行属性を付けた後、squidのログを標準入力で与えて実行させればログの時間が変換されます。
・ duration
キャッシュから読み出すのみ必要とした時間をミリ秒で表します。これはTCPｔｐUDPでは解釈の仕方が異なります。
  • HTTP/1.0ではaccept() からcllose()までの時間です
  • 持続性のある接続ではスケジューリングから応答が終了するまでの経過時間です
  • ICPにおいてはスケジューリングから応答が終了するまでの経過時間です
これらがログに記録されるのは応答が終了してからという点に注意してください。
・ client address
リクエストしてきたクライアントのIPアドレスです。　
log_fqdnオプションを設定ファイルで指定することで、ログのアドレスはFQDN(完全修飾名）で記録されるようになりますが、パフォーマンスには影響を与えます。
・ result codes
結果を知らせます。これはスラッシュで２つの内容で構成されています。　
  1. キャッシュへの要求の結果。
    キャッシュへの要求の結果のコードが返されます。　これで例えばキャッシュがヒットしたのか失敗したのかわかります。コードの意味についてはこちら。
    いくつかのコードは古いバージョンのもので、今では使われなくなっています。　特にERR_* に関してはこれ以上記録されることはありません。
  2. 状況部分。
    状況部分にはHTTPでの詳細結果やRFCで定義されているコードを記録します。状況コードに関してはこちら。
・ byte
byte
クライアントへ渡された総バイト数です。ヘッダーを含めたサイズですので、表示されるオブジェクトのバイト数でないことに気を付けてください。　エラーページの表示では、当然そのサイズが記録されます。
・ request method（リクエストメソッド）
オブジェクトを得るための要求です。　これについてはここを参照してください。 設定ファイルでlog_icp_queriesをOFFにしたなら、ICP exchangesの情報は記録されません。 また、設定ファイルACLの記述で、"method purge"をenableにしたときのみ、PURGEメソッドは記録されます。
・ URL
リクエストされたURLが記録されます。　URLには空白が記録されることがあるので注意してください。　ただし設定ファイルでuri_whitespaceを無効にしているので、デフォルトでは空白のURLは拒否しています。
・ rfc931
リクエストしたクライアントのident lookupを記録します。　パフォーマンスに影響を与えるため、デフォルトでは設定ファイルでident_loookups offとしているので記録されません。単に"-"がひとつ記録されていることでしょう。
・ hierarchy code（階層コード）
階層コードは３つのパターンがあります。
  1. ICPリクエストがタイムアウトになったなったような場合には、常にTIMEOUT_という接頭語付けたログが残ります。　
  2. どのように要求を処理したかの記録が残ります。　例えばpeerサーバに転送したとか、直接サーバへアクセスしたとか。　階層コードやリムーブコードの詳細についてはこちら
  3. リクエストをフォワードした際のIPアドレスまたはホスト名。　これは起源サーバのアドレスです。これは隣接のキャッシュサーバのアドレスです。
・ type
HTTPヘッダーにリプライされてきたオブジェクトのコンテンツタイプです。　ICPのキャッシュ交換の場合にはここは"-"になることに留意してください。またいいくつかの奇妙なリプライには":"や空白を記録します。
注意：
logformat, access_logディレクティブについては、Squid3の各マイナーバージョン間で微妙に書式が違います。詳細については原典のリファレンスを参照してください。

◆Squid3.4の場合：
ログフォーマットについては、logformat ディレクティブを参照してください。
またログファイルは access_log ディレクティブで指定されたファイルに書き込まれます。例えばログ形式をCLFで記録したい場合には、squid.confでは次のように記述します。
logformat common %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %>Hs %<st %Ss:%Sh
access_log モジュール名:ファイル名 logformat=フォーマット名 （ex. access_log daemon:/usr/local/squid/var/logs/access.log logformat=common)
このとき、モジュールとしてはCPUへの負担の少ない" daemon"を使うことが推奨されています。 なお、詳しくは access_log ディレクティブを参照してください。
また、access_logディレクティブでは古い形式として、
logformat common %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %>Hs %<st %Ss:%Sh
access_log モジュール名:ファイル名 フォーマット名 （ex. access_log daemon:/usr/local/squid/var/logs/access.log common)
という記述も推奨はされてませんが可能です。

◆Squid3.1の場合：
Debian7.6(wheezy)のパッケージで提供されているSquidは 2014/9現在、 バージョン3.1.20のようです。バージョン3.1では3.4と若干書式が違います。
ログファイルは access_log ディレクティブで指定されたファイルに書き込まれます。例えばログ形式をCLFで記録したい場合には、squid.confでは次のように記述します。
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %>Hs %<st %Ss:%Sh
access_log ファイル名 フォーマット名 （ex. access_log /var/log/squid3/access.log common)
詳しくは、原典のリファレンスを参照してください。
　　

6.6 useragent.log

ユーザエージェントログは、維持されているだけのファイルです。　
  1. コンパイル時に--enable-useragent-log オプションをつけてコンパルイルし、かつ、
  2. 設定ファイルで、"useragent_log"を使うように設定した時
のために用意されています。
これを有効にすることで、ユーザが利用しているブラウザのディストリビューション名を得ることができます。
このオプションはSquidの中に統合すべきではないアイデアかもしれません。

6.7 Squid result codes （リザルトコード）

HTTPへのリクエストはTCP_として、ICPへのリクエストにはUDP_として結果コードを記録します。ICPのログをとらないなら、設定ファイルで、log_icp_queriesを無効にしなさい。
以下のリザルトコードは、Squid-2でのものです。
以下のコードは、Squid-2でもはや利用できません:

6.8 HTTP status codes （ステータスコード）

Squid-2ではRFC2616の内、307（Temporary Redirect），416 (Request Range Not Satisfiable)，417 (Expectation Failed)を除く殆どのコードが使われます。拡張用コードの0と600も無効なヘッダーやプロキシエラーの際に使います。またWebDAVの為のRFC2518のためのコードも返されます。　
000 Used mostly with UDP traffic.

100 Continue
101 Switching Protocols
*102 Processing

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
*207 Multi Status

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy
[307 Temporary Redirect]

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request URI Too Large
415 Unsupported Media Type
[416 Request Range Not Satisfiable]
[417 Expectation Failed]
*424 Locked
*424 Failed Dependency
*433 Unprocessable Entity

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
*507 Insufficient Storage

600 Squid header parsing error

6.9 Request methods （リクエストメソッド）

SquidはRFC2616で認められた幾つかのリクエストについて認めます。　Squid2.2-STABLE5以上では、WevDAVの拡張によるRFC2518の拡張も認めます。
method defined cachabil. meaning
------ ------ ------ -------------------------------------------
GET HTTP/0.9 possibly object retrieval and simple searches.
HEAD HTTP/1.0 possibly metadata retrieval.
POST HTTP/1.0 CC or Exp. submit data (to a program).
PUT HTTP/1.1 never upload data (e.g. to a file).
DELETE HTTP/1.1 never remove resource (e.g. file).
TRACE HTTP/1.1 never appl. layer trace of request route.
OPTIONS HTTP/1.1 never request available comm. options.
CONNECT HTTP/1.1r3 never tunnel SSL connection.

ICP_QUERY Squid never used for ICP based exchanges.
PURGE Squid never remove object from cache.

PROPFIND rfc2518 ? retrieve properties of an object.
PROPATCH rfc2518 ? change properties of an object.
MKCOL rfc2518 never create a new collection.
COPY rfc2518 never create a duplicate of src in dst.
MOVE rfc2518 never atomically move src to dst.
LOCK rfc2518 never lock an object against modifications.
UNLOCK rfc2518 never unlock an object.

6.10 Hierarchy Codes（階層コード）

Squid-2では以下の階層コードが使われます。
以下の階層コードはSquid-2からは除外されました。
code meaning
-------------------- -------------------------------------------------
PARENT_UDP_HIT_OBJ hit objects are not longer available.
SIBLING_UDP_HIT_OBJ hit objects are not longer available.
SSL_PARENT_MISS SSL can now be handled by squid.
FIREWALL_IP_DIRECT No special logging for hosts inside the firewall.
LOCAL_IP_DIRECT No special logging for local networks.

6.11 cache/log (Squid-1.x)

このファイルは不適切な名前を持っています。　これはswap logと呼ばれるべきものでディスクに書き込まれたオブジェクトの記録です。Squidのスタート時にリロードされます。もしSquidが動いていないときにこのファイルをリムーブすれば、キャッシュコンテンツの中をきれいにできます。Squidは新たにこのファイルを作り出します。　もっとも簡単な方法は、プロセスを次のように、
% squid -k shutdown
としてシャットダウンしてから、
% squid -k rotate
として、ログのローテーションをしてしまうと良いでしょう。Squid-1.1のログには6つの項目が記録されます。

6.12 swap.state (Squid-2.x)

Squid-2からは、スワップログファイルは swap.state と呼んでいます。これはMD5によるチェックサムを含むバイナリファイルです。ファイルと内容に関する詳しくは、プログラマーガイドをご覧ください。
Squidが動作中にもし、swap.stateファイルを削除したければ、Squidにログローテーションのシグナルを渡してください。
% squid -k rotate
この場合、Squidは終了前にswap.stateを書き直し、Squidを終了します。
Squidが起動していないときにswap.stateを削除する場合には、どんな情報もキャッシュから失うことはないでしょう。
Squidはすべてのキャッシュディレクトリとスワップファイルを調べてキャッシュを再構築します。これはとても長い時間（我慢を）必要とする作業です。

6.13 どのようにすれば安全にログを削除できますか？

Squidが起動している最中は、決して access.log, store.log, cache.log, swap.stat を削除すべきではありません。UNIXではプロセスが実行中でオープンしているファイルでも削除できます。しかし、そのスペースはプログラムが終了してファイルをクローズするまで回収されません。swap.stateは先に説明の通り、削除しても再度構成することができますが、他のファイルは再構成はできません。
Squidの"rotate"機能を使って一日一回はログをローテションすると良いでしょう。　ログは拡張数（*.1,*,2のような）をつけて保存されます。ローテションは、swap.stateをクリーンにします。しかし、拡張数をつけて残すようにはなっていません。
ローテーションを行うコマンドは、
% squid -k rotate
です。たとえば、このコマンドをCRONを使い夜中に実行すると良いでしょう。
0 0 * * * /usr/local/squid/bin/squid -k rotate

6.14 どうすればログを行わないようにできますか？

access.logを無効にするには、設定ファイルで
cache_access_log /dev/null
とします。
store.logを無効にするには、
cache_store_log none
とします。
多くの重要な情報とデバックの際の情報となるため、cache.logを無効にするのは薦められません。　しかしどうしてもしたければ、
cache_log /dev/null
で無効にできます。

6.15 ログファイルがとても大きくなります。

cronの機能を使って、ログをローテションすれば良いでしょう。
例：
0 0 * * * /usr/local/squid/bin/squid -k rotate

6.17 ログファイルの管理

分析の有効なファイルは、access.logです。評価を長期間行うためには、適宜、ログをローテーションしていくと良いでしょう。　
Squidには、ローテションのためのAPIが組み込まれており、実行中であっても混乱させることなくログをローテーションできます。
ログファイルの為のディスクスペースを確保して、cronによって例えば、24や12や8時間ごとにローテーションして行くことが望ましいです。
ログファイルは、余裕のある時間帯に圧縮することもできます。log_icp_queriesなどを有効にしていると一日で役1GBのログを生成してしまうかも知れません。
ログの管理にあたり、EUのDESIREプロジェクトでは、ログの管理についての基本ルールを策定しました。
  1. 公表にあたってはクライアントのプライバシーを保つ。
  2. 解析が終わっても、ログは長い時間保存してください。　殆どの国ではプライバシーに関する法律によって多くの時間、記録を保存していくことが求められます。
  3. 少なくとも一日一回はログをローテーションすべきです。そのままにしておくとそれは大きなファイルになってしまいます。
  4. 容量を意識しておいてください。　ログの生成よりもログの処理のほうが余計に時間はかかります。

6.18 ERR_NO_CLIENTS_BIG_OBJ というメッセージがでます。

これは要求されたオブジェクトが"あとで削除する"といモードで転送中に、ユーザがアボートしたことを意味します。このようなモードででの転送は、

6.19 ERR_LIFETIME_EXP は何を意味しますか？

クライアントからの要求を転送中にタイムアウトが発生したことを意味しています。多くは検索に時間がかかったためにクライアントが要求をアボートした為でしょう。
【Squid Home / FAQトップ】

参考：