LOGFILE logfilenameです。あるいは、他の引数無しでコマンドラインでログファイル名を与えれば良い。 例えば、analog ログファイル名 とやります。- 記号あるいは stdin という単語は、標準入力を意味します。この形式は、Unix ではパイプを作成するときに便利です。全てのログファイルは、あなたのコンピュータシステムの内部のファイルシステムになければなりません。（ディスク上か、少なくとも Unix 上でマウントされたディスクか、NT 上の共有されたドライブ上になければなりません。） -- analog は、インターネット上から FTP あるいは HTTP を使ってファイルを持ってくることはできません。Mac 版では、analog のアイコン上に一個の特定のログファイルをドラッグすれば、解析できます。
LOGFILE コマンドを幾つか書くことができます。ログファイル名にワイルドカードを含めることもできますし（しかし、必ずしもディレクトリ名に入れる必要は無いが、これはシステムに依存します。）、（スペースを含まない）コンマで区切ってログファイルの一覧を書くこともできます。従って、以下のコマンドは、logfile1、c:\logs\logfile2、それに .log で終わる全てのファイルを、analog は読みます：
LOGFILE logfile1,*.log LOGFILE c:\logs\logfile2または、Mac を使っているなら、以下の様に書きます。
LOGFILE "Hard Drive:Internet Applications:Analog:Logs:*"LOGFILE コマンドは、以下の場合を除いて蓄積型です（即ち、書かれたファイル名を全て読み込みます）。コマンドラインで与えられた、またはユーザが指定した環境設定ファイル中のどのログファイルは、初期設定の環境設定ファイル 中のログファイルに取って代わるし、それら自身も、必須の環境設定ファイル 中のどのファイルによっても取って代わられます。また以下の特別なコマンドがあります。
LOGFILE noneこれは、今まで指定されたログファイルの一覧を無効にします。
もしあなたのログファイルが標準の形式でない時でも、LOGFORMAT コマンドを使って、他の形式について analog に教えることができるので、多分まだ大丈夫です。これは、次章 で説明されます。しかし大部分のユーザは標準形式のログファイルを持っているので、これについて知る必要はありません。最善の方法は、とにかくログファイルを解析してみて、analog が理解するかどうかを確かめてみることです。理解してくれれば、LOGFORMAT について心配する必要はありません。
もし analog が あなたのログファイルを理解できない時には、ログファイル形式を認識できない、あるいは多くの異常な行を見つけたと注意を与えるでしょう。これが起きる理由としては、基本的に4つの理由が考えられます。
LOGFILE log1,log2 http://www.%v.mydomain.comは、ファイル名 /file.html を log1 あるいは log2 のログファイル中の仮想ホスト host1 を使い、http://www.host1.mydomain.com/file.html と翻訳されます。LOGFILE コマンドの2個目の引数を使うなら、SUBDIR コマンドも多分必要となるでしょう。
引数に %v が含まれているが、ログファイル行に仮想ホストが無い場合には、その行は異常とみなされます。VHOSTLOWMEM 3 が指定されていれば、%v は翻訳されずに、出力には単に %v と現れるでしょう。
UNCOMPRESS *.gz,*.Z /usr/bin/gzcat一方 Windows NT 上では、以下の様に書ける。
UNCOMPRESS *.gz ("c:\Program Files\gzip\gzip" -cd)
VMS 上では、以下の様になります。
UNCOMPRESS *.LOG-GZ;* "gunzip -c"これは、初期環境設定ファイル に含めるには最適のコマンドであろう。
ログファイルが解凍し始めたが、analog がそのファイルは解析に必要ないと判断した時、2つの予期しないことが起き得る。ログファイルが完全に解凍しきるまで、プログラムが止まってしまうか、"broken pipe" エラーが出てくるかもしれない。これは、システムに依存し、analog の制御外のことです。
共通ログ形式は大部分のサーバーによって書かれている。それらの行は、以下の様になる。
jay.bird.com - fred [25/Dec/1998:17:45:35 +0000] "GET /~sret1/ HTTP/1.0" 200 1243マイクロソフト社のソフトのある版では、以下の様に HTTP の前に余分の2重引用符が付いてしまうバグがある。
jay.bird.com - fred [25/Dec/1998:17:45:35 +0000] "GET /~sret1/ "HTTP/1.0" 200 1243analog はこれら両方を理解しますが、（2種類の形式が存在するという意味で）もし形式が途中で形式が変わってしまう時には、それらの行を排除してしまいます。
[25/Dec/1998:17:45:35] http://www.site.com/ -> /~sret1/and the browser (or agent) log looks like
[25/Dec/1998:17:45:35] Mozilla/2.0 (X11; I; HP-UX A.09.05)参照元ログでは、日にちは省略され得る。
jay.bird.com - fred [25/Dec/1998:17:45:35 +0000] "GET /~sret1/ HTTP/1.0" 200 1243 "http://www.site.com/" "Mozilla/2.0 (X11; I; HP-UX A.09.05)"実際は一行である。Apache サーバを使っている時には、この形式は、mod_log_config モジュールを用い、以下のコマンドを使って生成される。
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
別々のログよりも組み合わせのログの方が通常良い。何故なら、より少ないスペースで多くの情報を蓄えられるからです。
192.64.25.41, -, 25/12/98, 17:45:35, W3SVC1, HOST1, 192.16.225.10, 2178, 303, 1243, 200, 0, GET, /~sret1/, -,（実際は一行である。） しかしながら、この形式は、日にちが地域的な時間表現に則っているという点に於いて、非常にまずく設計されている。即ち、北米では上記の例は、12/25/98 という日にちになる。analog は、可能な限りログファイルがどの形式であるか診断する。しかし、日にちも月も最大１２しか記録されていない時には、どちらの形式か判断できない。この場合には、以下のコマンド、北米の日にち形式に対しては、 LOGFORMAT MICROSOFT-NA あるいは国際日にち形式に対しては、LOGFORMAT MICROSOFT-INT を使うように進言する。幾つかの国では、日にちはこれらのどちらの形式でもない。このときには、それ専用の LOGFORMAT コマンドを書く必要がある。
またマイクロソフト形式には、例えばブラウザーや参照元を含めるための、各種の第３者による拡張がある。しかしそれらは全て異なる方法で行っており、そのため analog はそれらを自動的に診断できず、再度であるがそれら専用の LOGFORMAT コマンドを書く必要がある。
12/25/98 17:45:35 jay.bird.com host1 Server fred GET /~sret1/ http://www.site.com/ Mozilla/2.0 (X11; I; HP-UX A.09.05) 200 1243 2178（実際は一行であり、書く項目はタブで区切られている。）（上記の） IIS のログファイルと同様に、あいまいな日にちの問題がある。従って、LOGFORMAT WEBSITE-NA か、LOGFORMAT WEBSITE-INT を使わなければならないか、あるいは専用の LOGFORMAT コマンドを書かなければならない。
もし 先頭行が壊れていると analog が判断した時には、何が悪いのかも伝える。ここに2つの共通した問題がある。最初は、2個の異なる名前であっても、先頭行は同じ項目を2回含んではならない。（これは、analog がどちらを使ったらよいか分からないからである。）もし同じ項目が2個含まれている時には、LOGFORMAT コマンドを用いて無視したい方を指定しなければならない。
2つ目は、日付無しの時刻を使うことは許されないし、その逆も許されない。 -- 特に、ログファイルの先頭に日付だけがあるのは、解析に充分ではなく、各行になければならない。マイクロソフト社のサーバソフトは、先頭行に日付だけが付いた拡張ログを生成する。しかしもしログファイルの途中で日付が変わっても、サーバソフトは、新しい日付行を書かない。このため、analog は安全にその様なログファイルを解析できない。役立つソフトのページ には、各行に日付をつけてくれる幾つかのプログラムがある。もしそのようなログファイルをあなたが扱っているなら、これらのプログラムの一つを使いたいかもしれない。しかし、これらのプログラムはログファイルの途中で日付が変わらないと仮定されており、従って、将来はより良い形式で、サーバソフトがログを取るようにする方が安全である。
拡張ログは、 http://www.w3.org/TR/WD-logfile.html に述べられている。 その先頭行は以下のようである。
#Fields: date time cs-uriログファイルの残りでは、項目は、空白かタブで区切られている。拡張形式については、マイクロソフトの試みがある。-- 残念なことに、この試みでは、仕様を読まないので、ブラウザや参照元を引用符で括らない、ブラウザ名中の空白を + で置き換え、そして時間を秒の代わりにミリ秒で計ったリクエストを提供する。拡張ログは、常に時刻を GMT で記録しているため、あなたの地域時間帯に変換するために、多分 LOGTIMEOFFSET コマンドを使う必要があるだろう。
WebSTAR 形式は、http://www.starnine.com/webstar/docs/ws4manual.3f.html に述べられている。 その先頭行は以下のようである。
!!LOG_FORMAT DATE TIME RESULT URL BYTES_SENT HOSTNAMEログファイルの残りでは、項目はタブで区切られている。WebSTAR サーバは、また時刻を GMT で記録しているため、あなたの地域時間帯に変換するために、再び LOGTIMEOFFSET コマンドを使う必要があるだろう。いくつかの他の Mac サーバも WebSTAR か、それに似たものを使う。analog はこれらも理解する。
最後に、Netscape の先頭行は、以下のようである。
format=%Ses->client.ip% [%SYSDATE%] "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%