Access Log

30 views
Skip to first unread message

K F

unread,
Sep 13, 2013, 2:52:14 PM9/13/13
to hyec-...@googlegroups.com
みなさま、アクセスのログ解析はどうやっていますか?
よい方法があれば、教えてください。

やりたいことは、お決まりのパターンで、
日々のアクセスの推移やアクセス元などが見られればよいです。

ぱっと思いつくの以下です。

- Google Analyticsを使う。
- 自分で適当な cgi を拾ってくる→基本cgiベースで処理する。
- 同じく適当な cgi を拾ってくる、ただし→直接 apacheのログを分析処理する。

以前使っていたサイトでは、webalizerというツールが入っていて、
それをそのまま使っていました。
こちらでは何か標準的なツールがあったりしますか?特に、特殊なニーズはないので、
あれば、それをそのまま使ってみるつもりです。

よろしくお願いします。


318

unread,
Sep 19, 2013, 3:42:23 AM9/19/13
to hyec-...@googlegroups.com
これ!ってのはココではないですね…このCGIはどうでしょうか?
※KENTさん作、【ACCESS REPORT】
 
ただ、1時間ごとのアクセス数ってだけで、1日合計のアクセス数は表示されないみたいです…。
アクセスのログも残らないみたいですし…回答になっていないですね、すみません。

318

unread,
Sep 19, 2013, 3:45:08 AM9/19/13
to hyec-...@googlegroups.com
【追記】 
あ、CGIを使うならって話で、【Google Analytics】を使った方がいいと思います。
参考までに…では。

Yuta Hayakawa

unread,
Sep 19, 2013, 9:23:51 PM9/19/13
to hyec-...@googlegroups.com
HYEC.ORGの早川です

すでに回答が付いているようですが、一応。


みなさま、アクセスのログ解析はどうやっていますか?
よい方法があれば、教えてください。

やりたいことは、お決まりのパターンで、
日々のアクセスの推移やアクセス元などが見られればよいです。
このレベルで特に凝ったことをしようとしないのであれば、 

- Google Analyticsを使う。

が鯖管的には推奨です。
Googleが嫌だとかなら、忍者ツールズさんところの忍者アナライズとか。

- 自分で適当な cgi を拾ってくる→基本cgiベースで処理する。
- 同じく適当な cgi を拾ってくる、ただし→直接 apacheのログを分析処理する。
 ちなみにCGIベースで何かやる場合は、独自のログをCGIで記録する程度ならいいのですが、
それをWebalizerみたいにサーバ側でゴリゴリ処理する……ってのはご遠慮いただきたいです。
(サーバ負荷的な意味で)

あと、SSHアクセスが許可されている方の場合、権限上あちこち見られたりしますが、
基本的には自分のホームディレクトリ外へのアクセスは許容していないので、
「Apacheのログをゲットして処理」的なこともご遠慮いただきたいです。



以下、特定個人に向けた話ではなく、
基本的にこの手のネタで悩んだときの判断基準的なメモです。

基本、HYEC.ORGサーバは紳士協定的な部分が結構あって、
よく言えば柔軟な、平たく言えばいろいろ「ゆるーい」感じで皆様にお届けしています。

ので、「できる ≠ してもいい」の原則をベースに常識的に考えていただき、
サーバに負荷がかからない(サーバを使わない)方式を第一に検討いただけると助かります。

どうしてもサーバ側でやりたい(やって欲しい)ことがある場合、
セキュリティに関すること以外はこちらに投げていただければ最低限検討はします。

ちなみにCronにジョブを設定する程度ならいちいち言わなくてもいいですが、
あまりにサーバに負荷がかかっているようなら強権発動します。
不安なら事前に相談してください。

K F

unread,
Sep 20, 2013, 11:47:31 AM9/20/13
to hyec-...@googlegroups.com
早川様

適宜、こちらでも判断しつつ使うようにしています。
(善意で利用させてもらっているので、その善意に
 反するようなことはしないように注意しています。)

たとえば、特にcgiのinternal server errorは
error logを見れば、perl scriptの何行目でエラーが起きているかだとか
エラーの原因を特定できます。

つまり、この場合は、scriptの問題で、ユーザ側で対応すべきことがわかります。
一方、エラーが見えないと、どこでエラーが起きているかわからず、
いちいちサーバ管理者に対応をお願いしなくてはいけなくなります。
これは、スケールしないと思います。(ユーザ数が増えると、サーバ管理者が
対応できなくなる。)

極力、サーバ管理者の負荷を下げるべく、エラーの原因は明確にしたうえで、
サーバ設定などが必要な場合に相談するようにしています。

一般論として:
また、ご懸念のサーバ負荷・処理時間なども考慮するようにします。
実際に試した上で、時間がかかる処理がある場合は相談いたします。


今回も返信ありがとうございました。



2013年9月20日金曜日 3時23分51秒 UTC+2 Yuta Hayakawa:
Reply all
Reply to author
Forward
0 new messages