最終更新日：2003年9月6日
【Homeへ】
WebalizerはWebサーバのログを解析するツールです。 解析結果を、静的なHTML形式のファイルとして出力することで、結果をWebブラウザで見ることができます。出力結果はグラフカルかつ簡単な操作で見ることができ、容易にログを解析する事が可能です。
Webalizerは、CLF（common log forma）形式のログをサポートしており、このフォーマットはNCSAを含め多くのWebサーバがサポートしています。 また、wu-ftpdの結果ログやProxyサーバのSquidのログ形式もサポートしています。
ログの記録結果にはGzipによる圧縮された形式（.gzで表されてことが多い）として保存されている場合がありますが、Webalizerではこの圧縮されたファイルを直接読む事が可能になっています。
Webalizerは、コマンドラインやCronで実行することを考慮してしてデザインされています。 このため、以下のようなコマンド形式で実行できるようになっています。
ｗｅｂａｌｉｚｅｒ [オプション......] [ログファイル名]
オプションは、１つまたはそれ以上が指定できます。 オプションに続いてログファイル名を指定できます。 ファイル名を指定しなかったり、マイナス(-)を指定した場合には、標準入力からのデータが解析されます。
実行するとおおよそ次のような処理が行われます。
Webalizer1.2.xから、増加のための機能が追加された。 これは、１つの大きなログファイルを解析する代わりに、バラバラになっている小さなログファイルを使って解析できるようになる。これが意味することは、あなたが望む時に随時、ログファイルのローテーションができるという事です。（それまでは、１月分のログを１つのログとしてまとめておく必要がありました）
Webalizerの増加処理の機能を使うためには、いくつか注意する点があります。 コンフィグレーションオプションは、一連の実行中で変更すると、ストアされるデータがおかしな結果になる事が考えられます。 たとえば、MangleAgentsのレベルを変えると、ユーザエージェントが異なる表現でストアされることになります。結果としてユーザエージェントセクションは意味のないレポートとなります。もし変更が必要なら、月の終わりまでは現在のままの設定でレポートを作成し、月の初めのデータから変更するようにしてください。また、同様に"'webalizer.current"を削除するか"IncrementalName"での指定を変更してください。
Webalizerは、記録データの重複を避けるために最後のレコードのタイムスタンプを使った処理が行なわれます。 このタイムスタンプより前に記録されたどんなレコードも無視されます。 これは、ログのローテーションが混乱してしまった場合に、再度解析を作り直す場合に、つねに年代順でログを処理しないといけない事を意味します。さもないと結果は予期しないものとなるでしょう。
Webalizerは各月の報告をhtmlでグラフィカルに作成します。 さらにサマリーは最大１２ヶ月間生み出されます。 これらの作成されるファイルは、コマンドラインオプションまたは設定ファイルで変更できます。
デフォルトのファイルの構成は：
報告は１２ヶ月間の統計としてレポートされます。 月次の報告にはどんなURLへどこからリンクしてきたかどが報告されます。報告の内容としては、
Webalizerでは、出力に関する多くのコマンドラインオプションがあります。 一方いくつかのものは設定ファイルに記述することで指定できます。
以下のオプションでは、引数として比較のための文字列を指定します。 IndexAlias
を除いて文字列にはワイルドカード(*)を使うこともできます。 複数の引数を指定する場合には次のように指定します。
例） "cgi/css"のページを「トップURL」のレポートから隠す場合：
-u "cgi" -u "css"
というオプションで指定する。
Webalizerへの指示を簡単にするために設定ファイルを利用できます。 設定ファイルの検索順は、カレントディレクトリに「webalizer.conf」があるか探し、なければ「/etc/webalizer.conf」を探すでしょう。 また、webalizerを起動時に"-c"オプションとともに明示的に設定ファイルを指示することもできます。 Webalizerでは、最初に設定ファイルの中で指示されたパラメータによる指示をデフォルトの指示として、さらにコマンドオプションで指示されたパラメータを優先して処理を行います。
例えば、基本的な設定を/etc/webalizer.confでしておき、Webalizerを利用するユーザ毎に違う設定に関してはコマンドラインオプションで設定するという使い方が考えられます。
設定ファイルのパラメータのうち幾つかは、コマンドラインオプションで書き換えることができないものがあります。 例えば、「Quiet
yes」は設定ファイルで指定できますが、コマンドラインオプションでは書き換えることはできません。 コマンドラインでは精々、"-q"による抑制だけです。
設定ファイルは、標準的なテキスト形式ファイルなので、一般的なエディタを使って編集ができます。 空行ならびに#マークで始まる行は無効です。
行は「キーワードと値」で記述しており、キーワード以後の値は、行の端までは値と見なされます。
サンプルのwebalizer.confには、参考になるいくつのも記述があるのでご覧ください。 構成ファイルを使わなくても、デフォルトの動作で殆どは問題ないと思われます。
これらのキーワードは、レポートの中の各種表から、指定したものを非表示にするために使われます。 キーワードへの値は80文字以内で指定してください。
Group Object Keywords
---------------------
The Group* keywords allow object grouping based on Site, URL, Referrer,
User Agent and Usernames. Combined with the Hide* keywords, you can
customize exactly what will be displayed in the 'Top' tables. For example,
to only display totals for a particular directory, use a GroupURL and
HideURL with the same value (ie: '/help/*'). Group processing is only
done after the individual record has been fully processed, so name mangling
and site total updates have already been performed. Because of this, groups
are not counted in the main site total (as that would cause duplication).
Groups can be displayed in bold and shaded as well. Grouped records are
not, by default, hidden from the report. This allows you to display a
grouped total, while still being able to see the individual records, even
if they are part of the group. If you want to hide the detail records,
follow the Group* directive with a Hide* one using the same value. There
are no command line switches for these keywords. The Group* keywords also
accept an optional label to be displayed instead of the actual value used.
This label should be separated from the value by at least one whitespace
character, such as a space or tab character. See the sample.conf file
for examples.
GroupReferrer Allows grouping Referrers. Can be handy for some of the
major search engines that have multiple host names a
referral could come from.
GroupURL This keyword allows grouping URL's. Useful for grouping
complete directory trees.
GroupSite This keywords allows grouping Sites. Most used for
grouping top level domains and unresolved IP address
for local dial-ups, etc...
GroupAgent Groups User Agents. A handy example of how you could use
this one is to use "Mozilla" and "MSIE" as the values for
GroupAgent and HideAgent keywords. Make sure you put the
"MSIE" one first.
GroupDomains Allows automatic grouping of domains. The numeric value
represents the level of grouping, and can be thought of
as 'the number of dots' to display. A 1 will display
second level domains only (xxx.xxx), a 2 will display
third level domains (xxx.xxx.xxx) etc... The default
value of 0 disables any domain grouping.
Command line argument: -g
GroupUser Allows grouping of usernames. Combined with a group
name, this can be handy for displaying statistics on
a particular group of users without displaying their
real usernames.
GroupShading Allows shading of table rows for groups. Value can be
'yes' or 'no', with the default being 'yes'.
GroupHighlight Allows bolding of table rows for groups. Value can be
'yes' or 'no', with the default being 'yes'.
Ignore/Include Object Keywords
----------------------
These keywords allow you to completely ignore log records when generating
statistics, or to force their inclusion regardless of ignore criteria.
Records can be ignored or included based on site, URL, user agent, referrer
and username. Be aware that by choosing to ignore records, the accuracy of
the generated statistics become skewed, making it impossible to produce
an accurate representation of load on the web server. These keywords
behave identical to the Hide* keywords above, where the value can have
a leading or trailing wildcard '*'. These keywords, like the Hide* ones,
have an absolute limit of 80 characters for their values. These keywords
do not have any command line switch counterparts, so they may only be
specified in a configuration file. It should also be pointed out that
using the Ignore/Include combination to selectively exclude an entire
site while including a particular 'chunk' is _extremely_ inefficient,
and should be avoided. Try grep'ing the records into a separate file
and process it instead.
IgnoreSite This allows specified sites to be completely ignored from
the generated statistics.
IgnoreURL This allows specified URL's to be completely ignored from
the generated statistics. One use for this keyword would
be to ignore all hits to a 'temporary' directory where
development work is being done, but is not accessible to
the outside world.
IgnoreReferrer This allows records to be ignored based on the referrer
field.
IgnoreAgent This allows specified User Agent records to be completely
ignored from the statistics. Maybe useful if you really
don't want to see all those hits from MSIE :)
IgnoreUser This allows specified username records to be completely
ignored from the statistics. Usernames can only be used
if you use http authentication on your server.
IncludeSite Force the record to be processed based on hostname. This
takes precedence over the Ignore* keywords.
IncludeURL Force the record to be processed based on URL. This takes
precedence over the Ignore* keywords.
IncludeReferrer Force the record to be processed based on referrer.
This takes precedence over the Ignore* keywords.
IncludeAgent Force the record to be processed based on user agent.
This takes precedence over the Ignore* keywords.
IncludeUser Force the record to be processed based on username.
Usernames are only available if you use http based
authentication on your server. This takes precedence over
the Ignore* keywords.
Dump Object Keywords
--------------------
The Dump* Keywords allow text files to be generated that can then be used
for import into most database, spreadsheet and other external programs.
The file is a standard tab delimited text file, meaning that each column
is separated by a tab (0x09) character. A header record may be included
if required, using the 'DumpHeader' keyword. Since these files contain
all records that have been processed, including normally hidden records,
an alternate location for the files can be specified using the 'DumpPath'
keyword, otherwise they will be located in the default output directory.
DumpPath Specifies an alternate location for the dump files. The
default output location will be used otherwise. The value
is the path portion to use, and normally should be an
absolute path (ie: has a leading '/' character), however
relative path names can be used as well, and will be
relative to the output directory location.
DumpExtension Allows the dump filename extensions to be specified. The
default extension is "tab", however may be changed with
this option.
DumpHeader Allows a header record to be written as the first record
of the file. Value can be either 'yes' or 'no', with
the default being 'no'.
DumpSites Dump tab delimited sites file. Value can be either 'yes'
or 'no', with the default being 'no'. The filename used
is site_YYYYMM.tab (YYYY=year, MM=month).
DumpURLs Dump tab delimited url file. Value can be either 'yes' or
'no', with the default being 'no'. The filename used is
url_YYYYMM.tab (YYYY=year, MM=month).
DumpReferrers Dump tab delimited referrer file. Value can be either
'yes' or 'no', with the default being 'no'. Filename
used is ref_YYYYMM.tab (YYYY=year, MM=month). Referrer
information is only available if present in the log
file (ie: combined web server log).
DumpAgents Dump tab delmited user agent file. Value can be either
'yes' or 'no', with the default being 'no'. Filename
used is agent_YYYYMM.tab (YYYY=year, MM=month). User
agent information is only available if present in the
log file (ie: combined web server log).
DumpUsers Dump tab delimited username file. Value can be either
'yes' or 'no', with the default being 'no'. FIlename
used is user_YYYYMM.tab (YYYY=year, MM=month). The
username data is only avilable if processing a wu-ftpd
xferlog or http authentication is used on the web server
and that information is present in the log.
DumpSearchStr Dump tab delimited search string file. Value can be
either 'yes' or 'no', with the default being 'no'.
Filename used is search_YYYYMM.tab (YYYY=year, MM=month).
the search string data is only available if referrer
information is present in the log being processed and
recognized search engines were found and processed.
HTML Generation Keywords
------------------------
These keywords allow you to customize the HTML code that The Webalizer
produces, such as adding a corporate logo or links to other web pages.
You can specify as many of these keywords as you like, and they will be
used in the order that they are found in the file. Values cannot exceed
80 characters in length, so you may have to break long lines up into two
or more lines. There are no command line counterparts to these keywords.
HTMLExtension Allows generated pages to use something other than the
default 'html' extension for the filenames. Do not
include the leading period ('.') when you specify the
extension.
Command line argument: -x
HTMLPre Allows code to be inserted at the very beginning of the
HTML files. Defaults to the standard HTML 3.2 DOCTYPE
record. Be careful not to include any HTML here, as it
is inserted _before_ the <HTML> tag in the file. Use it
for server-side scripting capabilities, such as php3, to
insert scripting files and other directives.
HTMLHead Allows you to insert HTML code between the <HEAD></HEAD>
block. There is no default. Useful for adding scripts
to the HTML page, such as Javascript or php3, or even
just for adding a few META tags to the document.
HTMLBody This keyword defines HTML code to be placed immediately
after the <HEAD> section of the report, just before the
title and "summary period/generated on" lines. If used,
the first HTMLHead line MUST include a <BODY> tag. Put
whatever else you want in subsequent lines, but keep in
mind the placement of this code in relation to the title
and other aspects of the web page. Some typical uses
are to change the page colors and possibly add a corporate
logo (graphic) in the top right. If not specified, a
default <BODY> tag is used that defines page color, text
color and link colors (see "sample.conf" file for example).
HTMLPost This keyword defines HTML code that is placed after the
title and "summary period/generated on" lines, just before
the initial horizontal rule <HR> tag. Normally this keyword
isn't needed, but is provided in case you included a large
graphic or some other weird formatting tag in the HTMLHead
section that needs to be cleaned up or terminated before the
main report section.
HTMLTail This keyword defines HTML code that is placed at the bottom
right side of the report. It is inserted in a <TABLE> section
between table data <TD>..</TD> tags, and is top and right
aligned within the table. Normally this keyword is used to
provide a link back to your home page or insert a small
graphic at the bottom right of the page.
HTMLEnd This allows insertion of closing code, at the very end of
the page. The default is to put the closing </BODY> and
</HTML> tags. If specified, you _must_ specify these tags
yourself.
--------------------------------------------------------------------------
Notes on Web Log Files
----------------------
The Webalizer supports CLF log formats, which should work for just
about everyone. If you want User Agent or Referrer information, you
need to make sure your web server supplies this information in it's
log file, and in a format that the Webalizer can understand. While
The Webalizer will try to handle many of the subtle variations in
log formats, some will not work at all. Most web servers output
CLF format logs by default. For Apache, in order to produce the
proper log format, add the following to the httpd.conf file:
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""
This instructs the Apache web server to produce a 'combined' log
that includes the referrer and user agent information on the end of
each record, enclosed in quotes (This is the standard recommended
by both Apache and NCSA). Netscape and other web servers have
similar capabilities to alter their log formats. (note: the above
works for apache servers up to V1.2. V1.3 and higher now have additional
ways to specify log formats... refer to included documentation).
Notes on FTP Log Files
----------------------
The Webalizer now supports ftp logs produced by wu-ftpd and others, as
a standard 'xferlog'. To process an ftp log, you must either use the
-Ff command line option or have "LogType ftp" in your configuration file.
Support for additional formats may be forthcoming, however a future
version of the Webalizer is in the works that will allow user defined
log formats, so this will become a non-issue. It is recommended that
you create a separate configuration file for ftp analysis, since the
values used for your web server will most likely not be suited for ftp
log analysis (ie: page types, hostname, etc.. should be different).
Because of the difference in web and ftp logs, there are a few limitations:
o Because there is no concept of a 'response code' in ftp world, response
codes are restricted to either 200 (OK) or 206 (Partial Content), based
on the completion status found in xferlog (for wu-ftpd, 'i'=incomplete
and will generate a 206, 'c'=complete and will generate a 200). If your
ftp server doesn't supply the completion status, all requests will be
assigned a response code of 200. This allows the usage graph to display
all transfer requests (hits), and how many of those completed in success
(files - ie: 200 response codes).
o Page totals won't accurately reflect reality, since there isn't really
the concept of a 'page' in regards to ftp services. I have found that
setting the PageType value to "README", "FIRST", etc... seems to work
fairly well however, and will give a pretty good indication of how
many 'non-binary' files were requested. Of course, the content of your
ftp site will be different, so your results may vary.
o Visit totals also won't accurately reflect reality, since visits are
triggered on PageType requests (see above). What you usually wind up
with is visits=sites in most cases.
o Entry/Exit pages will not be calculated for ftp logs.
o For obvious reasons, referrers and user agents are not supported.
o You _cannot_ analyze both web and ftp logs at the same time.. they must
be done separately in different runs.
Notes on Referrers
------------------
Referrers are weird critters... They take many shapes and forms, which makes
it much harder to analyze than a typical URL, which at least has some
standardization. What is contained in the referrer field of your log
files varies depending on many factors, such as what site did the referral,
what type of system it comes from and how the actual referral was generated.
Why is this? Well, because a user can get to your site in many ways... They
may have your site bookmarked in their browser, they may simply type your
sites URL field in their browser, they could have clicked on a link on some
remote web page or they may have found your site from one of the many search
engines and site indexes found on the web. The Webalizer attempts to deal
with all this variation in an intelligent way by doing certain things to
the referrer string which makes it easier to analyze. Of course, if your
web server doesn't provide referrer information, you probably don't really
care and are asking yourself why you are reading this section...
Most referrer's will take the form of "http://somesite.com/somepage.html",
which is what you will get if the user clicks on a link somewhere on the
web in order to get to your site. Some will be a variation of this, and
look something like "file:/some/such/sillyname", which is a reference from
a HTML document on the users local machine. Several variations of this can
be used, depending on what type of system the user has, if he/she is on
a local network, the type of network, etc... To complicate things even
more, dynamic HTML documents and HTML documents that are generated by
CGI scripts or external programs produce lots of extra information which
is tacked on to the end of the referrer string in an almost infinite number
of ways. If the user just typed your URL into their browser or clicked on
a bookmark, there won't be any information in the referrer field and will
take the form "-".
In order to handle all these variations, The Webalizer parses the referrer
field in a certain way. First, if the referrer string begins with "http",
it assumes it is a normal referral and converts the "http://" and following
hostname to lowercase in order to simplify hiding if desired. For example,
the referrer "HTTP://WWW.MyHost.Com/This/Is/A/HTML/Document.html" will become
"http://www.myhost.com/This/Is/A/HTML/Document.html". Notice that only the
"http://" and hostname are converted to lower case... The rest of the
referrer field is left alone. This follows standard convention, as the
actual method (HTTP) and hostname are always case insensitive, while the
document name portion is case sensitive.
Referrers that came from search engines, dynamic HTML documents, CGI
scripts and other external programs usually tack on additional information
that it used to create the page. A common example of this can be found
in referrals that come from search engines and site indexes common on the
web. Sometimes, these referrers URL's can be several hundred characters
long and include all the information that the user typed in to search for
your site. The Webalizer deals with this type of referrer by stripping
off all the query information, which starts with a question mark '?'.
The Referrer "http://search.yahoo.com/search?p=usa%26global%26link" will
be converted to just "http://search.yahoo.com/search".
When a user comes to your site by using one of their bookmarks or by
typing in your URL directly into their browser, the referrer field is
blank, and looks like "-". Most sites will get more of these referrals
than any other type. The Webalizer converts this type of referral into
the string "- (Direct Request)". This is done in order to make it easier
to hide via a command line option or configuration file option. This is
because the character "-" is a valid character elsewhere in a referrer
field, and if not turned into something unique, could not be hidden without
possibly hiding other referrers that shouldn't be.
Notes on Character Escaping
---------------------------
The HTTP protocol defines certain ways that URL's can look and behave. To
some extent, referrer fields follow most of the same conventions. Character
escaping is a technique by which non-printable or other non-ASCII (and even
some ASCII) characters can be used in a URL. This is done by placing the
Hexadecimal value of the character in the URL, preceeded by a percent sign '%'.
Since Hex values are made up of ASCII characters, any character can be
escaped to ensure only printable ASCII characters are present in the URL.
Some systems take this concept to the extreme and escape all sorts of stuff,
even characters that don't need to be escaped. To deal with this, The
Webalizer will un-escape URL's and referrers before being processed. For
Example, the URL "/www.mrunix.net/%7Ebrad/resume.html" is the same URL as
"/www.mrunix.net/~brad/resume.html", a very common form of a URL to access
users web pages. If the URL's were not un-escaped, they would be treated as
two separate documents, even though they are really one and the same.
Search String Analysis
----------------------
The Webalizer will do a minimal analysis on referrer strings that
it finds, looking for well known search string patterns. Most of
the major search engines are supported, such as Yahoo!, Altavista,
Lycos, etc... Unfortunately, search engines are always changing
their internal/CGI query formats, new search engines are coming on
line every day, and the ability to detect _all_ search strings is
nearly impossible. However, it should be accurate enough to give
a good indication of what users were searching for when they stumbled
across your site. Note: as of version 1.31, search engines can now
be specified within a configuration file. See the sample.conf file
for examples of how to specify additional search engines.
Notes on Visits/Entry/Exit Figures
----------------------------------
The majority of data analyzed and reported on by The Webalizer is
as accurate and correct as possible based on the input log file.
However, due to the limitation of the HTTP protocol, the use of
firewalls, proxy servers, multi-user systems, the rotation of your
log files, and a myriad of other conditions, some of these numbers
cannot, without absolute accuracy, be calculated. In particular,
Visits, Entry Pages and Exit Pages are suspect to random errors
due to the above and other conditions. The reason for this is
twofold, 1) Log files are finite in size and time interval, and
2) There is no way to distinguish multiple individual users apart
given only an IP address. Because log files are finite, they have
a beginning and ending, which can be represented as a fixed time
period. There is no way of knowing what happened previous to this
time period, nor is it possible to predict future events based on
it. Also, because it is impossible to distinguish individual users
apart, multiple users that have the same IP address all appear to
be a single user, and are treated as such. This is most common where
corporate users sit behind a proxy/firewall to the outside world,
and all requests appear to come from the same location (the address
of the proxy/firewall itself). Dynamic IP assignment (used with
dial-up internet accounts) also present a problem, since the same
user will appear as to come from multiple places.
For example, suppose two users visit your server from XYZ company,
which has their network connected to the Internet by a proxy server
'fw.xyz.com'. All requests from the network look as though they
originated from 'fw.xyz.com', even though they were really initiated
from two separate users on different PC's. The Webalizer would
see these requests as from the same location, and would record only
1 visit, when in reality, there were two. Because entry and exit
pages are calculated in conjunction with visits, this situation
would also only record 1 entry and 1 exit page, when in reality,
there should be 2.
As another example, say a single user at XYZ company is surfing
around your website.. They arrive at 11:52pm the last day of
the month, and continue surfing until 12:30am, which is now a
new day (in a new month). Since a common practice is to rotate
(save then clear) the server logs at the end of the month, you
now have the users visit logged in two different files (current
and previous months). Because of this (and the fact that the
Webalizer clears history between months), the first page the
user requests after midnight will be counted as an entry page.
This is unavoidable, since it is the first request seen by that
particular IP address in the new month.
For the most part, the numbers shown for visits, entry and exit
pages are pretty good 'guesses', even though they may not be 100%
accurate. They do provide a good indication of overall trends,
and shouldn't be that far off from the real numbers to count much.
You should probably consider them as the 'minimum' amount possible,
since the actual (real) values should always be equal or greater
in all cases.
Exporting Webalizer Data
------------------------
The Webalizer now has the ability to dump all object tables to tab
delimited ascii text files, which can then be imported into most
popular database and spreadsheet programs. The files are not normally
produced, as on some sites they could become quite large, and are only
enabled by the use of the Dump* configuration keywords. The filename
extensions default to '.tab' however may be changed using the
'DumpExtension' keyword. Since this data contains all items, even
those normally hidden, it may not be desirable to have them located
in the output directory where they may be visable to normal web users..
For this reason, the 'DumpPath' configuration keyword is available,
and allows the placement of these files somewhere outside the normal
web server document tree. An optional 'header' record may be written
to these files as well, and is useful when the data is to be imported
into a spreadsheet.. databases will not normally need the header. If
enabled, the header is simply the column names as the first record of
the file, tab separated.
Log files and The Webalizer
---------------------------
Most sites will choose to have The Webalizer run from cron at specified
intervals. Care should be taken to ensure that data is not lost as a
result of log file rotations. A suggested practice is to rotate your
web server logs at the end of each month as close to midnight as possible,
then have The Webalizer process the 'end of month' log file before running
statistics on the new, current log. On our systems, a shell script called
'rotate_logs' is run at midnight, the end of each month. This script file
looks like:
------------------------- file: rotate_logs ------------------------------
#!/bin/sh
# halt the server
kill `cat /var/lib/httpd/logs/httpd.pid`
# define backup names
OLD_ACCESS_LOG=/var/lib/httpd/logs/old/access_log.`date +%y%m%d-%H%M%S`
OLD_ERROR_LOG=/var/lib/httpd/logs/old/error_log.`date +%y%m%d-%H%M%S`
# make end of month copy for analyzer
cp /var/lib/httpd/logs/access_log /var/lib/httpd/logs/access_log.backup
# move files to archive directory
mv /var/lib/httpd/logs/access_log `echo $OLD_ACCESS_LOG`
mv /var/lib/httpd/logs/error_log `echo $OLD_ERROR_LOG`
# restart web server
/usr/sbin/httpd
# compress the archived files
/bin/gzip $OLD_ACCESS_LOG
/bin/gzip $OLD_ERROR_LOG
------------------------- end of file ------------------------------------
This script first stops the web server using a 'kill' command. Apache
keeps the PID of the server in the file httpd.pid, so we use it as the
argument for the kill. Next, it defines some names for the backup files,
which are basically the name of the files with the date and time appended
to the end of them. It then makes a copy of the log file, appended with
'.backup' in the log directory, moves the current log files to an archive
directory (/var/lib/httpd/logs/old) and restarts the server. This setup
allows the web server to be down for the minimum amount of time needed,
which is important for busy sites. If you don't want to stop the server,
you can remove the initial 'kill' command, and replace the '/usr/sbin/httpd'
line with "kill -1 `cat /var/lib/httpd/logs/httpd.pid`" command instead,
On most web servers, this will cause a restart of the server and create
the new log files in the process...
At this point, we have made copies of the previous months logs, the web
server is going about it's business as usual, and we have all the time in
the world to do any other additional processing we want. The last two
lines of the script compress the archived logs using the GNU zip program
(gzip). Remember, we still have a copy of the log which we can now run
The Webalizer on without having to do any further processing.
Next, we define two crontab entries. The first runs the above 'rotate_logs'
script at midnight at the end of the month. The second runs The Webalizer
on the '.backup' log file created above at 5 minutes after midnight. This
gives other end of month processing jobs a chance to run so we don't bog
the system down too much. If you have lots of end of month stuff going on,
you can change the timing to suit your needs. The crontab entries look
something like:
------------------------- crontab entries --------------------------------
# Rotate web server logs and run monthly analysis
0 0 1 * * /usr/local/adm/rotate_logs
5 0 1 * * /usr/bin/webalizer -Q /var/lib/httpd/logs/access_log.backup
------------------------- end of crontab ---------------------------------
As you can see, the log rotations occur at midnight, and the analysis
is done at 5 minutes after. Once you verify that The Webalizer ran
successfully, the access_log.backup file can be deleted as it isn't
needed any more. If you need to re-run the analysis, you still have
the compressed archive copy that the shell script created. In order
for the above analysis to work properly, you should have already
created an /etc/webalizer.conf configuration file suitable for your
site, or otherwise specify configuration options or a configuration
file on the crontab command line above.
If you want The Webalizer to be run more often than once a month, you
can specify additional crontab entries to do this as well. Care should
be taken however to ensure that The Webalizer is not running when the
end of month processing above occurs, or unpredictable results may
happen (such as an inability to rotate the logs due to a file lock).
The easiest way is to run it on the half hour with a crontab entry like:
30 * * * * /usr/bin/webalizer
Language Support
----------------
Version 1.0x of The Webalizer added language support. This
support is only provided at compile time in the form of an
include file containing all the strings used by The Webalizer.
The source distribution contains all language files that were
available at the time, with English being the default as
that is the only human language I speak fluently, and me
Espanol es muy malo. Several people have already indicated
the desire to do translations into various languages, and as
I receive the language files, will make them available via
ftp at ftp://ftp.mrunix.net/pub/webalizer/lang. Unless there
happens to be a binary distribution in the language you need,
you will need to grab the source distribution and compile the
program yourself. See the file INSTALL that comes in the source
distribution for information on how to use a language other than
English.
It should also be noted that the GD graphics library, used to
produce the in-line graphics in the output HTML, doesn't
support extended character sets, so if you are translating
the language file, you will no doubt encounter this problem.
New: You can now specify the language to use when you are building
program from source, using the configure script. Just add
--with-language=language_name , where 'language_name' is the
name of a valid language file in the /lang/ directory. For
example, --with-language=french will build using French as
the default language. You should consult the INSTALL file
for additional information on building the program from source.
Known Issues
------------
o Memory Usage. The Webalizer makes liberal use of memory for internal
data structures during analysis. Lack of real physical memory will
noticeably degrade performance by doing lots of swapping between memory
and disk. One user who had a rather large log file noticed that The
Webalizer took over 7 hours to run with only 16 Meg of memory. Once
memory was increased, the time was reduced to a few minutes.
o Performance. The Hide*, Group*, Ignore*, Include* and IndexAlias
configuration options can cause a performance decrease if lots of
them are used. The reason for this is that every log record must
be scanned for each item in each list. For example, if you are
Hiding 20 objects, Grouping 20 more, and Ignoring 5, each record
is scanned, at most, 46 times (20+20+5 + an IndexAlias scan).
On really large log files, this can have a profound impact. It
is recommended that you use the least amount of these configuration
options that you can, as it will greatly improve performance.
Final Notes
-----------
【Homeへ】
Copyright© 1998-2003 ROBATA.ORG