音声データを配信しているVPSのサーバーをやむなくSSL化した。
すると、そこからWebalaizer（アクスセス解析機能）に正しくログが取れていない状態だった。
気がついたのは約2ヶ月後（笑）普段あまり見ていないので。
とはいえ、Podcasterにとってアクセスログは非常に大事なデータなので、修正する事に。
1人ではちんぷんかんぷんだったのでリスナーのfukaさんに大いに協力してもらう。fukaさんありがとう。
分かった事は以下の通り。
原因はログファイル名
ssl化すると、httpdフォルダ内にssl.confという設定ファイルが生まれました。
ここでsslつまりhttpsへのアクセスに対するログファイル名や記録する内容について設定している様です。
という事はhttpへのアクセスとhttpsのアクセスに関するログは、出発点から違うって事ですね。
因みに、私の環境では以下の通りとなっていました。
httpに対するアクセスログ名：access_log
httpsに対するアクセスログ名：ssl_access_log
Webalaizerが食べるログ名は？
Webalizerは分析に使用するファイル名をWebalizer.confの中で指定していました。私の場合access_logというファイル名を指定しています。
ログローテーションの機能でaccess_logは一日ごとに日付の付いたファイル名に変換されて保存されています。
例えばaccess_log-20200426というファイル名に一日ごとに保存されていきます。
ローテーション後のファイルは保管されているだけで、Webalizerの集計にも表示にも影響していませんでした。
なので、ssl_access_logというhttpsのアクセスログはそもそもWebalizer君は興味が無かったという事です（笑）
じゃあ、もう一回食べさせよう。
再集計、再実行、再分析、色々表現の仕方があるようですが、とにかくWebalizer君にもう一度アクセスログを食べさせて、分析結果の欠損を保管したい。という事で、その作業を進めていきます。
各ファイルの場所（私の場合）
/etc/httpd/conf/httpd.conf
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf.d/webalizer.conf
/etc/webalizer.conf
/var/lib/webalizer/webalizer.hist
/var/lib/webalizer/webalizer.current
/var/log/httpd/access_log
/var/log/httpd/ssl_access_logSTEP1：再集計したい月の分析結果を削除する。
Webalizerで再集計したいときはまず、Webalizerで生成済みの関連ファイル（Webalizerの分析ページで見れる内容）を削除します。
Webalizerで集計すると私の場合/var/www/usageというディレクトリにhtmlファイルが生成されます。既に存在するとhtmlファイルやpngファイルがあると、上手く再集計できない場合があります。
バックアップを取ってから関連ファイルを削除しましょう。
今回は2020年02月を再集計したいので、202002と付いているファイルを全て削除します。
logsもバックアップ
今回の作業ではaccess_logに影響が出ることはありませんが、良い機会なのでバックアップしておきましょう。
私の場合はvar/log/httpd/にlogファイルがあります。
STEP2:ログファイルを単月に切り分ける
access_logとssl_access_logの中身ですが、1日に一回ローテーションされていますが実際にローテーションが行われるタイミングはまちまちです。
たまに、1日飛ばされたりします。
ただし、これはローテーションだけの問題で、ログは正しく記録されているはずです。
注意が必要なのは、
ファイル名の日付（例えば20200204）とログの内容は一致していない
と言うことです。
試しにaccess_log-20200201を開いてみると、1月31日と2月1日のログが含まれて言いました。
今回は2月のデータを再集計したいので、20200131、20200201、と20200229、20200301のアクセスログをチェックし、2月のデータがあるかを確認し、2月以外のデータを削除しなくてはなりません。
20200131のログ、20200301のログにも2月のデータが入っている可能性があるので、漏れなくチェック。
それぞれaccess_log-20200201-b、access_log-20200229-b等のファイル名でコピーしました。
コピーしたファイルをエディターで開いて、不要な日付のデータをバッサリカットします。
※ssl_access_logとaccess_logの内容とリダイレクト
私はssl化とほぼ同時に.htaccessによりhttpからのアクセスを全てhttpdへリダイレクトするようにしました。
なので、httpにアクセスがあったものは全てhttpsにリダイレクトされているはずです。
同じ日付でssl_access_logとaccess_logがある場合、二つのファイルを比較して、access_logにあるIPアドレス及びアクセス時間がssl_access_logに記載がある事が確認出来ると思います。
この条件であれば、Webalizerの欠損を補うための再集計ではaccess_logは無視して構わないと思いました。
場合に寄っては二つのlogファイルを一つにまとめる（コピペする）などして読み込ませる必要があるかも知れませんね。
STEP3：Webalizer.histを確認
私の環境では/var/lib/webalizer/にあります。
Webalizer.histは、これまでの集計結果の大枠（月別）がずーっと記録されているファイルです。おそらく削除しなくても良いと思うのですが、再集計したい月（の行）を消すことになります。
行頭に2020 02 xxx xxxxx…となっているので、見れば直ぐ分かります。
バッサリカット。
※カットしなくても問題無いかも。必要性を確認出来ていません。
STEP:4 Webalizer.currentを確認
Webalizer.currentは現在の集計状況（日別）のデータが一時的に保管されています。
どうやら2ヶ月分位を持っている様で、この後の再集計実行の際もこのcurrentファイルが更新されていきます。
currentファイルにデータがある場合、その上手く集計できない場合があります。
念の為、現在のWebalizer.currentの名前を変更しておきます。（事実上ファイルを削除した状態）
例えばWebalizer.current-backにしました。
※ファイルを改名する（削除する）必要があるかどうかを確認出来ていません。
STEP：5 Webalizerにログを食べさせる。
さて、いよいよログを食べさせる時間です。
動作確認の為に、まずはWebalizerの分析結果を表示させます。
数字をメモしておくと変化が分かるので便利です。
コマンドを入力していくので、ターミナル（っていうんでしたっけ？コマンドプロンプト的なやつ）を開くと便利です。
Webalizerは実行にオプションとソースファイルを指定することができます。
Webalizer -f access_log-20200201-b
Webalizer -f access_log-20200202
Webalizer -f access_log-20200203
.
.
.
Webalizer -f access_log-20200229
Webalizer -f access_log-20200229-bという様にターミナルから1行ずつ実行していきます。
「-f」というオプションは時系列の不整合を無視するという機能です。
Webalizerはデフォルトでは時系列が乱れていると「おかしいんじゃね？」とエラーを吐き出すらしいのですが、「今回は目をつぶってね」というお願いです。
※「-f」の必要性についての確認は出来ていません。
私が参考にしたのはこちらのウェブサイト
上手くいっていれば、2月分のデータを食べさせる度にWebalizerの分析画面の変化します。（ブラウザの画面は更新してください。）
STEP6: Webalizer.currentを元に戻す。
作業が終わったら、新しいWebalizer.currentが出来ているので、こいつを削除します。
そして、Webalizer.current-backとしておいた元々のファイル名から-backを外します。
この作業も必要性が確認出来ていません。
今後のaccess_logとssl_access_logをどうするか？
ここまでで、欠損したログを再集計することは出来ました。
ただし、今回の出発点はそもそもaccess_logがaccess_logとssl_access_logに分かれてしまった事が原因です。
解決方法を調べると、「二つのファイルを一つにして読み込ませれば良い」とか出てきますが、そんな高度なことは私にはできません。
乱暴だけど、httpもhttpsも同じログに書いちゃえ！
そこで、ssl.confのログの書き出し先に注目しました。
ssl.confでは「ssl_access_logに書き出しなさいよ」と指示があります。
結論、これをaccess_logに変更しちゃいました。
「※ファイルサイズが大きくなる可能性があるので推奨しない」と書かれている記事もありましたが私の場合はアクセスが多くないので大丈夫だろうと判断しました。
というか、そもそも一つだったものが分かれただけなので、元に戻しても問題無かろうと。
元のssl.conf
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn修正後のssl.conf
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
#ErrorLog logs/ssl_error_log
ErrorLog logs/error_log
# access_logと同等のログを出力するために追記
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %{HTTPS}e"
#TransferLog logs/ssl_access_log
TransferLog logs/access_log
LogLevel warnErrorlog ssl_error_log からerror_logへ変更
TransferLog ssl_access_logからaccess_logへ変更
combinedを実現するLogFormatについて
httpd.confの中を見ると、access_logに記録する情報について書かれています。
CustomLog logs/access_log combinedssl.confで記録する情報もこのcombinedと同じ内容に合わせておきたいですよね。
そこで、ssl.confにはLogFormatという一行を追加しています。
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %{HTTPS}e"これがその内容です。
これで、httpとhttpsの記録情報が統一されます。
とここで、一つ。{HTTPS}eという記載について。
これは今回独自に追加した項目です。
httpsからのアクセスの時は行末に「on」と表記され、httpからのアクセスの時には行末に「-」が表記されます。
こうすることでhttpとhttpsが混在するログの中でもhttps経由のアクセスであることが一目瞭然になります。
リダイレクトがきちんと出来ているので、そもそもaccess_log(httpからのアクセスのログ）を読ませる必要があるのか？と言われるとあまり必要性は高くないのかも知れません。
ミスや誤認があるようでしたらご指摘頂けますと幸いです。
あくまでも自己責任で作業を行ってください。
私の場合はしっかり欠損を補えて、一安心しました。
0コメント