雑文発散

追記
過去の日記

2014-10-25 [長年日記]

[] 富士山へ紅葉を観に行った

先週読んだ「富士山へ紅葉を観に行った(が少し早かった)」という日記に「来週以降がいいんじゃないかと思う」と書かれていたので、アドバイスに従ってオレも富士山へ行ってきた。

中央道が混む前に行こうと思って、朝6時ころ家を出たのに八王子手前で事故渋滞に巻き込まれて、相模湖辺りまでノロノロ。結局、富士スカイラインの入口に付いたのは8時半くらい。

富士山の周辺へは何度も行っているけど、富士スバルラインを自分のクルマで走るのは初めてなので、今日の紅葉がピークなのかどうか分からないのだけど、いろんな色が混ざり合っていて綺麗だった。

五合目の駐車場状況とかも全く知らないので、途中の駐車場には寄らずに一気に五合目へ。駐車場にはまだ余裕うがあったけど、既にバスで来た観光客がたくさんいて(特に中国系の人が多かった)、付近はなかなかの混み具合だった。

多くの人が撮影しているスキマで写真を撮ったり。

富士山

「富士山メロンパン」ってのがあったので食べてみたり。思ったよりも外側がパリパリで美味しかった。

富士山

おみやげ屋さんをウロウロしてたら、レストランに「噴火カレー」ってメニューがあったので、食べてみた。たいしてお腹も空いてなかったんだけど、この名前を見たら食わずにはいられなかった(笑)

富士山

五合目からの帰り、途中の駐車場がガラガラだったので、パンダを停めて紅葉と一緒に撮影。

富士山

別の角度から。

富士山

富士スカイラインを降りてしばらく行ったところで、モミジと白樺が一緒にあったのでパチリ。

富士山

そのまま道志みちを使って帰ってきたんだけど、山中湖から道の駅どうしあたりまで、ずっと白いプントと縦走してきた。たまたま山中湖で前後に並んだんだけど、並んだ直後に向こうが一瞬ハザードを付けたので、こっちがフィアット車だってことは認識してた様子。

思いがけずツーリング状態になって楽しかった。一定の距離で追いかけてたつもりだったんだけど、あちらの期待する距離ではなかったようで、途中で道を譲られてしまった。

なんか悪いことしちゃったなー。


2014-10-24 [長年日記]

[Fluentd][Elasticsearch] Fluentd + Elasticsearch + Kibana での解析のログ収集部分を考える

昨日の日記「Fluentd + Elasticsearch + Kibana での解析の構成を考える」からの続き。

今日はログ収集側、つまり第三tDiary.Net側の仕込みをする。

Fluentd 公式ドキュメントの「Installing Fluentd Using deb Package」に従ってインストールをする。あ、そうそう第三tDiary.Netは Debian wheezy の上で動いている。

Fluentd (td-agent) のインストール

公式ドキュメントには apt のリポジトリ登録と td-agent のインストールを一括して実行してくれるシェルスクリプトの紹介があるので、そのままコピペ。

% curl -L http://toolbelt.treasuredata.com/sh/install-debian-wheezy-td-agent2.sh | sh

最近は、このようにリモートのシェルスクリプトを実行するパターンのインストーラーも多いけど、本当はいきなり実行せずに中身を確認すべきだよね。

http://toolbelt.treasuredata.com/sh/install-debian-wheezy-td-agent2.sh

スクリプト内でやっていることはこんな感じ。

  • sudo で実行
  • apt 用の GPG-KEY の取得と登録
  • /etc/apt/sources.list.d にリポジトリ情報を追加
  • apt-get update
  • apt-get install td-agent

問題になりそうなことはやっていない。

まぁ、メジャーなプロジェクトだったら、大抵の場合は心配せずとも良い気がするんだけど、何も考えずに root 権限で実行するとヤバイ場合もあることだけは意識しておくべき。オレも含めて。

あと今回使うもの、まだ使わないものも含めて Fluentd のプラグインをインストールしておく。これもどこかのサイトを参考にさせて貰ったんだけど、、、元サイトを見つけられず。

% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-tail-asis
% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-parser
% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-grepcounter
% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-file-alternative
% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-elasticsearch
% sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-geoip

fluent-plugin-elasticsearch のインストール時に curl のライブラリが必要だと言われるかもしれない。状況によるとは思うけど、下記のどちらかをインストールすれば良いと思う。

% sudo apt-get install libcurl4-openssl-dev
% sudo apt-get install libcurl4-gnutls-dev

また、fluent-plugin-geoip では、geoip のライブラリが要求されるので、インストールしていなければ libgeoip-dev もインストールする。

% sudo apt-get install libgeoip-dev

Fluentd (td-agent) の設定

Fluentd (td-agent) の設定ファイルは `/etc/td-agent/td-agent.conf' になる。ここにログの入力設定と出力設定を書くイメージなるようだ。

まず入力部分のところ。これは Apache2 のアクセスログを対象とする。tail インプットプラグイン を使えば、既存のログ出力設定をいじらずに済むようなので、これを使う。

ログのフォーマット指定(format パラメータ)については、通常なら apache2 を設定するだけで良いようなのだが、第三tDiary.Netでは、ログのフォーマットをちょっとだけいじっているので、このままではパースできそうもなかったので、正規表現を自前で書いてみた。

ちなみにログのフォーマットはこんな感じ。複数の日記が稼働しているので、ログの中にホスト名を埋め込んでいる。

LogFormat "%h %l %u %t %{Host}i \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" tdiary

これに対応する td-agent の format 設定はこうしてみた。

これ、だいぶがんばって書いたんだけど、tail インプットプラグイン のドキュメントには apache2 フォーマットの正規表現の例が書いてあったんだね。これを参考にして改良すれば良かったのかも。

<match> の方で、stdout にしておくと、td-agent のログ(/var/log/td-agent/td-agent.log)に書かれるようなので、こいつを使ってデバッグ作業をした。

とりあえず今日のところはここまで。


2014-10-23 [長年日記]

[Fluentd][Elasticsearch] Fluentd + Elasticsearch + Kibana での解析の構成を考える

昨日の日記「DDD (DoS Driven Development) を始めよう」からの続き。

DoS への対策で Fluentd + Elasticsearch + Kibana を使ったアクセスログ解析を第三tDiary.Netの上で行おうと思い立ったのは事実なんだけど、実はそれ以前から Elasticsearch 関連は勉強し始めていたのであった。

その勉強を実地で活かす場として、第三tDiary.Netのアクセスログを利用する。その結果として DoS 避けができるようになれば、オレに取ってのメリットが大きくなる。

Elasticsearch 関連を勉強するにあたって、参考にしているサイトや書籍を先に上げておく。これらが無ければ先に進めなかったかも。

サイト

書籍

さて、ここで話を元に戻そう。

今回のシステム構成を考えた。まずサーバは2台構成。第三tDiary.Netが動いているサーバとは別に解析用のサーバを用意する。用意するとは言っても、借りているけど遊び気味な VPS が元々あるのでそれを流用するイメージ。

Kibana で画面を見るのは手元の MacBook Air なので、いちおう描き加える。Kibana 本体は「解析サーバ」の上に置くとは思うけど、ちょっと図の簡略化をしたらこうなった。

fluentd + elasticsearch 構成図

第三tDiary.Netは apache2 で動いていて、アクセスログは普通に書き出している。この部分は今回は変えない。基本的には現在稼働中の tDiary 部分には手を入れない方針でいく。

Fluentd (td-agent) で apache2 のアクセスログを読んで、解析サーバの Elasticsearch サーバへ直接送信する。この間の通信は iptables によってアクセス元を制限しておく。うまくいったら ssh トンネルなどで経路の暗号化もちょっと考えるけど、最初はシンプルな構成にする。

Kibana から Elasticsearch へアクセスするために、nginx のリバースプロキシ機能を使う。Kibana (Ver3) は JavaScript から Elasticsearch に接続する形になる。

つまり、ブラウザを開いた場所の IP アドレスからの接続になるため、先ほどの iptables によるアクセス元制限との共存がうまくいかない。そこで Kibana からは一度 nginx に繋いで、そこで BASIC 認証などでアクセス制限を行なう構成にしてみた。

こういう考え方もどこかのサイトを参考にしたんだけど、辿りつけなくなってしまった。。。メモ重要なのに。

ということで、今回も実践には辿り着かずにこの日記を終えるけど、裏側(?)ではインストールやら設定やらを進めていて、少しずつ形になりつつある。まだ実際に Kibana で見るところまではできてないけど、、、もう少しじゃないかな、希望的観測としては(笑)

サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)(養成読本編集部)

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)(Rafal Kuc (lにストローク符号、cにアクサン・テギュ付く)/Marek Rogozinski (nにアクサン・テギュ付く)/大岩 達也/大谷 純/兼山 元太/水戸 祐介/守谷 純之介/株式会社リクルートテクノロジーズ)



2014-10-22 [長年日記]

[Fluentd][Elasticsearch] DDD (DoS Driven Development) を始めよう

第三tDiary.Net への Dos が発生した時に「どこからだ?」と探すのに、grep とか awk とか sort とか使って、次のように IP アドレスを特定している。

% cat tdiary_access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10

これでアクセスが多い IP アドレスの上位10個が表示される。例えばこんな感じ。まぁ、いちおう IP アドレスの詳細は隠しておこう。

% cat access.log | awk '{print $1}' | sort | uniq -c | sort -n | tail -10
   7968 107.x.x.x
   9960 74.x.x.x
  15081 104.x.x.x
  15082 104.x.x.x
  15109 104.x.x.x
  15200 104.x.x.x
  15902 74.x.x.x
  17336 68.x.x.x
  17712 68.x.x.x
  17866 68.x.x.x

現在ほとんど更新されていない日記へのアクセスも多くて、それらの合計が15,000件をオーバーしているとか、明らかに異常な状態ではある。ちなみにこの例のログは weekly ローテーションの設定をしていて、まだローテーション前の状態(つまり、まだ、今週の合計値ではない)。

で、今は上記の方法で IP アドレスを特定し、iptables の REJECT に設定して BAN しているのだけど、そろそろそういう時代じゃないよな、という思いが募ってきた。

世の中では Fluentd + Elasticsearch + Kibana によるログ監視が流行ってたりするようだし、ちょっとその構成を作って、DoS アクセス元の特定をブラウザベースで行える環境を作ってみよう。

DoS から始まる開発、DoS Driven Development の始まりである。


2014-10-21 [長年日記]

[tDiary] IE6.0 を拒否した結果のサーバメトリクス

IE6.0 を拒否した後のメトリクスが安定していて笑えるレベル。元の状況がひどすぎたってのもあるとは思うけど。

tdiary3 server metrics

グラフが空白の部分は DoS によって死んでいたタイミング。

あ、ちなみにこれは Mackerel のグラフ。監視対象サーバにエージェントを入れるだけで、こんな綺麗なグラフがすぐ出てくるのは楽でいいね。mrtg.cfg とか nagios.cfg とか悩みながら書いていた頃が懐かしい(笑)