log server 構築

今回は ubuntu 11.10 server を使うため
http://releases.ubuntu.com/11.10/
から
64-bit PC (AMD64) server install CD
をダウンロードしてインストール
今回は web3層システムで行うということなので
ちょっとこの仕組みについて調べてみました
http://blog.livedoor.jp/del_yu/archives/591755.html
に解説が載っていました
まずは実験ということで、VMware Player で実験していきます
最初に PostgreSQL インストール
sudo apt-get update
sudo apt-get install postgresql
次に動作確認
sudo su – postgres
psql -l
これでDB一覧が表示されればOK
続いて、データ投入ユーザとDB作成
これは、日経Linux 2012 6月号の補足事項からダウンロードしたものを
使用します
http://itpro.nikkeibp.co.jp/article/MAG/20120507/394743/?ST=oss
からダウンロードできます
ファイルをダウンロードしたら
unzip toku3.zip で解凍し
この中にある
createDB.sql
を使って作成します
DB関連はSQLをまとめて sql ファイルにすれば効率がよくなります
ダウンロードしたファイルを転送して
cd /tmp
psql -f createDB.sql
でDBが作成されます
ついでにユーザも作成
createuser -s syslog
次にDB接続
psql syslog syslog
ログインできると
syslog=#
となるので、テーブル一覧をみたいので
\dt を実行
一覧の一番上にあるテーブル
systemevents の内容を確認するため
\d systemevents
を実行
これで
テーブルの項目名である Column
データのタイプである Type
が一覧表示される
確認できたら
\q
でDBを抜ける
続きはまた明日以降になります

log サーバーの永続性について

一般的なDBMSでは
一旦格納してコミットしたデータは
ディスク破壊などを除き、何があっても消失しないような仕組みになっている
この
コミットした結果を消失しないようにするには負荷が伴う
アクセスログのように消失が許容されるログ管理では
永続性を維持しないことで処理負荷をおさえられる
PostgreSQL では
テーブル作政治に
CREATE UNLOGGED TABLE コマンドを使うことで
永続性を維持するための
トランザクションログを特定のテーブルだけ書かないように指定できる
他のテーブルの永続化には影響しない
この状態でDBMSがクラッシュすると該当するテーブルデータが強制的にクリアされる
そ他割、更新処理はかなり高速になる

log を管理するDB設計について

DBに格納した log はいずれ削除することになる
ログを削除するときには
指定の時間より古いというような条件を指定して実行する
見かけはDELETE コマンドの実行
しかし
実際の処理は削除対象データを検索してから削除
こういった行単位の削除では検索処理をするので
削除対象が大量になるログで実行するとすさまじい時間になってしまう
また、ログ管理サーバーでは
新しいログデータ投入という、挿入処理
古いログデータ削除という、削除処理
これを繰り返すためデータの断片化が起こりやすく
検索性能が徐々に低下していく
これは windows をつかったことがあるとよく行う
デフラグしないと遅くなるというもの
このため、ログの格納の問題を解決するために
つかわれるのが
テーブルパーティショニング
日付情報をもちいた
レンジパーティショニングを施せば
削除単位がテーブルの一部
から
テーブルそのものになる
こうなれば
DROP コマンドや TRUNCATE コマンドが使えるので
ほぼ一瞬で処理可能
それに、テーブル単位のほうがアーカイブもしやすい
ちなみに、
DROP TRUCNCATE コマンドは
SQLなので、
SQLコマンド で検索するといろいろでてくる
今回は
PostgreSQLのコマンド
http://www.postgresql.jp/document/8.1/html/sql-commands.html
にコマンドが載っていました

sysstat のログ

性能解析につかわれるログ
/var/log/sysstat/
に格納されている
注意点としては、テキスト形式ではないので
参照するときに sar コマンドを使うということ
指定するオプションにより、様々な性能情報を得られる
Ubuntu ではデフォルトではインストールされていないため
sudo apt-get install sysstat
でインストールします
次に
sudo vim /etc/default/sysstat
で設定ファイルを開き
ENABLED=”false”

ENABLED=”true”
へ変更
sudo /etc/init.d/sysstat start
で起動します
sar コマンド導入には
Ubuntuでシステムリソース情報を取得するには?
を参考にさせていただきました

mail log

postfix などメール関連アプリが
/var/log/mail.log
に出力するログのこと
不正メールの監視、
メールの配送処理の解析など
用途はいろいろ
解析時には
エラーの記録を参照することがおおいけど
mail.log は非常に大量に記録されているので
エラーを調べるには
/var/log/mail.err
を調べる
cat /var/log/mail.err
でファイルをみたり、この中から grep で絞り込みかけるとよりやりやすくなります

認証ログ

linux 統合認証モジュールの
PAM
Pluggable
Authentication
Modules
のこと
を使っているアプリが出力するログ
syslog が扱うログだけど
認証ログだけはsyslog に出力されない
認証ログは監査で利用するログなので
解析用途のおおい syslog とは混在させないように設計されているのが理由
認証ということで
今回は
cat /var/log/auth.log
を実行してみました
書籍によれば
sshd のログで
authentication failure
なら認証失敗
の痕跡となるようです

Linux kenel log

linux のコアプログラムである
kernel が出力するログ
/var/log/kern.log
に蓄積される
kernel は様々なアプリを制御するため
ログにも様々なアプリの動作が記録される
特に活用するときは
故障時の記録で
システムトラブルの解析に利用される
解析対象を kernel に絞ったケースでは非常にみやすいログになる
これと同じログが syslog にも出力される
ちなみに、書籍にはサンプルが載っていたけど、自分でも確認したかったので
コマンドを実行してみました
Linux ファイルシステムは
EXT4 なので
cat /var/log/kern.log| grep EXT4
を実行することで確認できました

ログデータフォーマットは
サービスごとに異なる
Linux で出力できるログは
syslog サービスが出力するログ
アプリが個別に出力するログ
の2つ
まずは、syslog サービスが出力するログについて
syslogのログは
各種アプリが出力するログを処理する
syslog の出力ログは
一般的には
/var/log
にまとめて配置される
syslog が扱うすべてのログが集まるファイルが
syslog ファイル

/var/log/syslog
に記録されていく
今回は、日経Linux を参考に
cron コマンドのログを出してみました
今回は
cat /var/log/syslog | grep cron
を実行しました
以下は実行結果です
snowpool@snowpool-Prime-Series:~$ cat /var/log/syslog | grep cron
Nov 28 18:51:27 snowpool-Prime-Series anacron[1029]: Job `cron.daily’ terminated
Nov 28 18:51:27 snowpool-Prime-Series anacron[1029]: Normal exit (1 job run)
Nov 28 19:17:01 snowpool-Prime-Series CRON[6889]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
Nov 28 20:17:01 snowpool-Prime-Series CRON[7740]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
画像をつけると
Screenshot-2012-11-28 21:09:30
まず、ログの読み方ですが
基本的なフォーマットは
タイムスタンプ ホスト名 タグ: メッセージ本体
となります
今回のタイムスタンプなら
Nov 28 19:17:01
つまり11月28日 19:17のログ
です
ホスト名は
snowpool-Prime-Series
つまりマシンのホスト名
タグですが
ここにはプログラム名とプロセスIDになりますので
CRON[6889]:
なら
cron がプログラム
6889 はプロセスIDとなります
メッセージ本体は行ったことです
(root) CMD ( cd / && run-parts –report /etc/cron.hourly)
が実行されたということになります