nDiki : アクセスログ

[ WiKicker ] WiKicker で Log::Log4perl を採用

他のプロジェクトでも使用していて「WiKicker でも使いたいのだけれど、これ以上依存するモジュールを増やすのものぁ」というものの一つであった Log::Log4perl をやはり採用する事に。

Perl 5.005_03 でもギリギリOKのようである。

Debugログおよび、アクセスログ等もすべてこの上にのせていくつもり。

AWStats 6.0

www.naney.org のアクセスログをローカルにもってきて統計解析をするのに、今回は analog ではなく AWStats を使うことに。

以前 www.naney.org に入れてみた時より、随分使いやすくなった感じ。

セットアップ

Debian パッケージを入れた後、awstats.naney.org というバーチャルドメインをローカルのApacheに用意(/var/www/awstats.naney.org)。

 Alias /icon/ "/usr/share/awstats/icon/"

も設定に追加しておく。

ファイルレイアウト:

 /var/www/awstats.naney.org/
  |
  +-- .htaccess
  |
  +-- awstats.conf  <-- 作成
  |
  +-- awstats.pl    <-- コピーしてきて一部修正
  |
  +-- cache         <-- DNSキャッシュ用 (まだ未使用)
  |
  +-- data          <-- データを保存
  |
  +-- plugins       <-- プラグイン
       |
       +-- wikicker.pm <-- /wiki/(.*).html を $1 で表示するプラグイン(自作)

awstats.pl はパッケージのものをコピー。DecodeEncodedString の中で Jcode.pm を使って文字列を UTF-8 に変換するように修正。

ローカル用なのであまり気にせず DocumentRoot の下にもりっとファイルを置いておく。

awstats.conf はこんな感じ。

 LogFile="/path/to/downloaded-log/access.log"
 LogType=W
 LogFormat=1
 LogSeparator=" "
 DNSLookup=2
 DirData="./data"
 SiteDomain="www.naney.org"
 HostAliases="localhost"
 DNSStaticCacheFile="cache/dnscache.txt"
 DNSLastUpdateCacheFile="cache/dnscachelastupdate.txt"
 URLWithQuery=1
 URLReferrerWithQuery=1
 LevelForWormsDetection=2
 ShowWormsStats=1
 LoadPlugin="wikicker"
 ValidHTTPCodes="200 304 -"

ValidHTTPCodes の '-' というのは、本来不要。自前のSSIで似非 Combined Log を生成する際に '-' を出力する事があるので追加。

日本語もきちんと出るしいい感じ。 指定した月ではなく、指定した日のログを見れるといいのだが設定すればできるようにならないかな。

analog と違ってプラグインが使えるのが良い。 Perlスクリプトだから、その気になれば簡単に awstats.pl 自体を変更する事もできるし。

今回は ShowInfoURL 用プラグインを書いて、/wiki 以下のURLの際は unescape して PageName を表示するようにしてみた。

その他いろいろ遊べそう。

mixi に登録

ちょっと落ちついたので、2日ほど前に招待されていたmixiに登録してみる。 そういえばorkutは(予想通り)最近ほったらかし。

チェックしてみると mixi は日記に関して外部のものを(RSS)を通して使えるようなので、ちょっと興味が出てきた。

mixi のシステムから送られてくるメールは、行末に ^M がつくのでちょっと嫌。

で登録。

RSS を設定

nDiki (DiKicker) はまだ RSS を生成しないので、かわりに NaneyOrgWiki (WiKicker) の RSS を指定してみる。 フォームに入力して、送信。

 Internal Server Error

そうですか。die を捕捉してませんか。 こちらのサイトのアクセスログを見るとRSSは取得していっているので、解析以降でこけているらしい。

いろいろチェックしてみると一つは日付表示の問題らしい。 mixi の要求する dc:date 要素はあるのだが、WiKicker で生成している YYYY-MM-DDThh:mm:ssZ (W3CDTFの一つ)では駄目らしい。

でどうやら YYYY-MM-DDThh:mm:ss+09:00 でないと駄目らしい (YYYY-MM-DDThh:mm:ss+00:00 でも駄目)。 まあこれもW3CDTFの形式ではあるけれど、もうちょっと許容してくれてもいいのになと思う。 いや駄目でもいいけど、 Internal Server Error はよろしくないんじゃないか。

とにかく RSS は設定できた。 がうまく表示されない。

がくり。

追記

mixi の dc:date について誤認。 いろいろ試してみたところタイムゾーン指定は Z でもOKだった。

(2004年11月21日追記)

[ Naney と mixi ]

トラッックフィード: 他のサイトからリンクが張られたことを瞬時に RSS でお知らせ

生成したスクリプトをHPに貼るだけで、他のサイトからリンクが張られたことを瞬時にRSSでお知らせします。-- http://trackfeed.com/

自前でアクセスログ解析をしなくてもリンク元を RSS で確認できることができるようになるサービス。素晴しい。

Tor で hidden service

Tor: An anonymous Internet communication system を試してみる。 Torは匿名接続を提供するシステム。 アプリケーションで Tor クライアント(あるいはサーバ)をSOCKSサーバとして指定すると、いくつかの Tor サーバを経由して目的のサービスに接続されるようになる。 途中の経路は時間とともにどんどん変わっていく(らしい)。

インストール

Debian パッケージになっているので apt-get。

Privoxy と連携させて Web閲覧

もともと普段から使用している Privoxy の config に、

 forward-socks4a / localhost:9050 .

という設定を追加して再起動。Privoxy がローカルサーバで動いている Tor 経由で接続するようになる。

 Firefox -> Privoxy(localhost:8118) -> Tor(localhost:9050)
         -> Tor server -> ... -> Tor server -> Web サーバ

という感じに複数の Tor サーバを経由して目的にサーバに接続されるようになる。

Web サーバのアクセスログを見ながら何度かHTTPアクセスをしてみると、IP アドレス(経路の最後の Tor server)が変わっていくのがわかる。

使用感

かなりレスポンスが悪くなる。 現状では常時設定しておくのは辛い感じ。

Tor では名乗りを上げない限り(待ち受けポートを開けた上で、ディレクトリサーバに登録する)サーバにはならない。 このため、Tor server が絶対的に足りていないのかもしれない。

hidden service

Tor の面白い機能の一つに匿名サービスを提供する機能がある。 Web サーバやSSHサーバなどを匿名で晒すことができる。

この時動かす tor は Tor サーバである必要はなく Tor クライアントでかまわない。

/etc/tor/torrc に

 HiddenServerDir /var/lib/tor/hidden_http_service/
 HiddenServicePort 80 127.0.0.1:80

を追加して、tor を再起動。

/var/lib/tor/hiden_http_service/hostname というファイルに ****************.onion というホスト名が書かれているので、Tor + Privoxy 経由で http://****************.onion/ にアクセスすると、先ほどの tor が動いているサーバの Web サーバのページが見える。 hidden service を提供している tor は NAT の中にいてもOK(のようだ)。

閲覧者側に Tor (とPrivoxyなど)がインストールしてあれば、ダイナミックDNSに登録したりしなくても好きなタイミングで Web サーバにアクセスしてもらえるようになる。 面白い。

ローカルの Apache に 「ServerAlias *.onion」な Virtual Host の設定を追加して、Tor 経由専用のWebサイトも実験的に準備しておいてみた(例によって Wiki)。

Web 解析サービス Google Analytics を申し込む

昨年無料サービス開始時には申し込みが殺到して新規登録を一時中止したという経緯があった Google Analytics、当時はそのうち試してみたいと思っていたのだが気がつけばもうすぐ1年だ。

アクセス解析を見るのは結構楽しいもので、周期的に見たいという衝動がくる。 analog やら AWStats やら自作やらで過去にもいろいろ解析してみた経験がある。

会社でも最近アクセスログ解析が話題になっているし、www.naney.org 用に Google Analytics に申し込んでみた。

解析を取りたいページの最後に JavaScript を埋め込むタイプの解析で、404 であったりその他のリソースのアクセス数のチェックには向かないものの、その分 Web サーバのアクセスログ解析では得られない統計を得ることができる。

レポートの種類は豊富で、最初は「あのレポートは、どれだっけ?」と何度もいろいろ見直したりしなければならないぐらい。

アクセス傾向が分かるようになるので、重点的に内容を充実させるべきページを把握してサイトを改良していきたい。

Google Analytics のデータからよく検索されるキーワードを表示するようにした

Google Analytics から1日1回キーワードのレポートを TSV 形式でメールで配信するように設定している。 このデータをもとに「よく検索されるキーワード」を抽出して、nDiki の下の方に表示するようにした。

処理の流れ

1. メールで配信された TSV 形式データをファイルに保存する。
2. 検索質問とセッション数の組のデータを抽出する。
3. 1ワード単位でセッション数を集計する。
4. 上位のワードについて、nDiki のキーワードリストにあるか照合する。
   1. 完全一致するものがあれば、それを参照キーワードとする。
   2. 大文字小文字一致するものがあれば、それを参照キーワードとする。
   3. ワードを含むキーワードがあれば、その中で文字数の差が少ないものを参照キーワードとする。
   4. ワードで記事を grep 検索してマッチするものがあれば、それを(nDiki 内で検索して見つかる)キーワードとする。
   5. でなければ関連キーワード無しのワードとする。
5. 各ワードについて、対応するリンクを設定してフッタ埋め込み用の HTML フラグメントを生成しファイルを生成する。
6. ファイルをサーバにアップロードし、サーバ側でフッタにインクルードする。

1日1回の作業なので、メールからスクリプトにかける部分とアップロードする部分は手動で。

そこそこの処理なので、そこそこの精度なのだけれど傾向は何となくわかる感じだ。

実際にはアクセスログの対象となっているのは nDiki 以外の www.naney.org 内のアクセスも含まれているけれどもまあいいであろう。

キーワードの処理

キーワードの処理は細かいことをいうと結構面倒だったりする。

• 複合語の処理: 検索ワード側も、nDiki キーワード側も複合語を含むので空白で区切られた語の扱いが大変。特に検索ワード側は語順が正しいとは限らないし、各語が個別の語を表しているのか否かの判断が難しい。
• 曖昧一致処理: 検索ワード(や nDiki キーワード)が正確な語とは限らないので、曖昧一致させる必要がある。検索エンジン側で曖昧一致させて検索結果に上がっている可能性があるのでその辺りも考慮する必要がある。

などなど。

この辺りは精度を上げようとするといろいろ工夫の余地がって楽しそうではあるな。

位置情報とアクセス解析「なかのひと」

2007年4月20日にベータ版が開始され話題になってから随分たつが、nDiki に「なかのひと」を昨晩からつけてみた。 なかのひとは、

「どんな組織からアクセスがあったか」に特化したサービス

である。地図表示付きなどその他の機能もあるが、組織名がわかるのが一番面白い点。

基本的にはアクセスログ解析でアクセス元の IP アドレスから組織がわかるのだが、実際のところ対応表をメンテナンスするのって面倒なので、こういったサービス便利である。

優れている点

• タグクラウド形式のアクセス一覧が刺激的な表示で見やすい。
• あしあと表示で、ちょっと前までのアクセスが見られるのがライブ感があって良い。「激レア!!」等をゲットすると、なぜかちょぴり嬉しい。

別にどうといったことではないんだけれど、メジャーな組織名があると「おっ」と思ってしまうし、どの組織の人にどんな目的で見られているんだろうと考えると想像するだけで楽しくなってくる。

サイト運営の清涼剤になるな。

今日のさえずり - そうかあれネズミか

• 09:21 9:00 過ぎにシャープのサービスから電話があった。今日の冷蔵庫の出張修理は 12:00 から 14:00 とのこと。[mb]
• 11:17 アクセスログ見て「なんで『トッポ・ジージョ』でこんなに検索されているんだろう」と年末から思っていたが、そうかあれネズミか。
• 12:05 サービスマンきた。[mb]
• 12:14 冷凍室内分解中。[mb]
• 12:17 サイクル故障(コンプレッサー故障)の可能性大らしい。[mb]
• 12:31 コンプレッサー交換だと5万円ぐらいかかるとのこと。ひえー。買い換えるにしても修理するにしても痛い出費だ。

Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon

LINE株式会社で開催された Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon 「秋のPlack/PSGI祭り」に参加してきた。今回は YAPC::Asia Tokyo でもよくトークされている masartz 氏とご一緒させていただいた。ここの会場にくるのは「第3.5回 データ構造と情報検索と言語処理勉強会」「PerlCasual #05」に続き3回目。

• http://atnd.org/events/45276

開催を知った時には定員60人すでに埋まっていて補欠だったんだけれど、その後定員80人に増やしてくれたようで参加できるようになった。当日時点ではキャンセル等で定員切っていてきたい人はこれるようになってたよ。

普通に使う Plack/PSGI Server @fujiwara 氏

会場アンケートをとりつつ、必須な/便利なモジュールや Plack::Middleware の紹介。

• だいたい Starlet か Sterman を使っている。
• リバースプロキシ使っている時には Plack::Middleware::ReverseProxy が便利。
• Server::Starter の start_server では plackup を実行するシェルスクリプトを作ってそれを指定するようにするとパラメータ変更できるのでいいよ。
• Devel::NYTProf する時には if $$ % 11 == 0 などで一部のプロセスだけでプロファイリングするようにすると不運な人は遅くなるけど、全体の影響抑えつつできるよ。

『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3 を受けての話題 @kazeburo 氏

YAPC::Asia Tokyo 2013 の発表の続き。

Plack/PSGI のパフォーマンス向上の取り組みが進めば Perl の適用領域を広がるし(リアルタイムな広告系とか)、Perl 使いの仕事も増えるよ。

Plack::BodyParser の話 @tokuhirom 氏

• 最近のサーバーサイドの開発は JSON API の開発と管理画面の開発だよね。
• HTTP ステータスコードの使い方をシンプルに。アクセス自体が成功したら 200 を返して、API の結果の方に API 処理自体のステータスを入れる方がシンプルだし、アクセスログ処理なども楽だよと。
• JSON API のボディ内で返すステータスも HTTP ステータスコードと同じにしたら覚えることが少なくて楽。
• URI の /v1/ とか入れたりするけど /v2/ とか出たためしがない。

など。プラクティカルなトーク。

Plack::Request with Encoding @moznion 氏

リクエスト中のパラメータの decode を Plack で一箇所でやってしまう話。

Mojolicious の知りたい 10 のコト @yusukebe 氏

• morbo と hypnotoad。それほどパフォーマンス悪くない。
• Mojo::Base は使わなくていい。それほど機能無いし、Web 系以外では Mojo に依存したくないし。

「YAPC::Asia 2014 やります!」とのことです。

LT

@bayashi 氏の plackup -e でちょっとしたこといろいろできて便利だよという話や、@azumakuniyuki 氏の Haineko の話や、 @hkoba 氏のコントローラを書く人がいないプロジェクト向けのテンプレートエンジンの話や、@songmu 氏の .psgi からの卒業の話とか、@tasukuchan 氏のきまぐれオレンジ☆ロードについてのラジオみたいなビデオ LT とか。

空気を読まない(読めない)一方通行なビデオ LT は新しく。