log を整形して情報をまとめる logwatch

log を整形して情報をまとめる

Ubuntu の場合
ｌｏｇ整形ツールの logwatch を使うことで
ログを集計し
結果を比較的見やすい状態に加工してレポートできる

また、期間
表示するレポートの種類指定も可能

期間と種類を指定すれば
トラブル時に必要な情報だけ絞り込んでレポートを表示できる

Ubuntu での インストールは
sudo apt-get install logwatch

途中でダイアログが出て、インストールするタイプを聞かれるので、今回はローカルのみを選択

まず、
sudo logwatch
を実行

デフォルトでは
logwatch は標準出力に、昨日のログを集計した
レポートを出力する

sudo ログのセクションをみると
sudo コマンドを使って root 権限で
どのコマンドを何回実行したのか確認できる

レポート作成期間、ログの種類の絞り込みは
logwatch のオプションを使う

レポート作成期間は、
--range オプションで指定
今日のログのレポートにするなら

sudo logwatch --range today

昨日のログレポートなら
sudo logwatch --range yesterday

２日前のログレポートなら
sudo logwatch --range '-2 days'
というように、-の後に何日前か指定

日付を指定するなら
sudo logwatch --range 2013/07/20
というように、直接指定でOK

取得できる全ての期間にしたいのなら
sudo logwatch --range all

3日前から今日まで、としたいのなら
sudo logwatch --range 'since -3 days'
というように、
since -遡りたい日数 days

詳細な日数などの指定については
sudo logwatch --range help
で確認できる

logwatch のレポートの見方に関しては
Logwatchのレポートの見方
http://ameblo.jp/itboy/entry-10051133432.html
を参考にさせていただきました

logwatch では、取得できるログの種類を
サービス単位で扱う

サービスの種類は
ll /usr/share/logwatch/scripts/services/
で確認可能

ここにあるファイル名がサービス名になる

logwatch で過去１週間の
pam_unix
sshd
のログレポートを表示するなら

logwatch --Service pam_unix --Service sshd --range 'since -7 days'

というようになる

有用なログをみつけるポイント

有用なログをみつけるポイント

まず、ログを絞り込むために使う情報は
ログの日時と出力元

トラブルあが発生した時間帯
問題のあるプログラム
ホストに検討がついているのなら、これらの情報で
ログを絞り込める

次に扱う情報が
ログのプライオリティ


プライオリティの種類は
debug
デバッグ情報

info
正常な状態で出力される情報

notice
正常だけど、重要な情報

warn
警告

err
エラー

crit
致命的エラー

alert
緊急に対応が必要なエラー

emerg
システムを使用不能

となる

err 以上のプライオリティのログの場合
トラブル原因に関係している可能性が高い
emerg > alert > crit > err >warn > notice > info > debug
という順番になり
一番深刻なのが
emerg

デフォルトでプライオリティが表示されるログファイル
そして
設定を変更してプライオリティを表示する設定にしたログファイルを使って、プライオリティで絞り込むことができる

そして、msg の情報からでも推測ができる

トラブルが発生している場合
msg の部分にもエラーメッセージが出力されることがある
error
fail(failure, faied) などのキーワードで
ログを絞り込むとエラー関連ログを絞り込みやすくなる

ログをキーワードで絞り込むには
エディタの機能を使うと便利

/　で検索してもいいけど
view コマンドでなら
:g/キーワード/
とすることで
キーワードに一致する行だけを表示することができる

もし、error というメッセージがある行だけを表示したいのなら
view /var/log/auth.log
で開いている場合、
:g/error/
とすれば、 error のある行だけ表示されるので見やすくなる
たくさんある場合、qを押すと元の画面に戻れる

ログの種類と書式について

ログの種類と書式について

トラブル発生時にログから情報を取得する手助けになるのは

ログファイルの種類

ログの書式変更

ログファイルから有用なログをみつけるポイント

これらを把握していることがより効率的な原因究明につながる

まず、ログファイルの種類

linux では、ログは
/var/log の下に出力される

Ubuntu なら
/var/log/
の下にたくさんあるので
ls /var/log/
で調べると、どんなファイルがあるのか確認できる

種類がたくさんあるので、その中の一部を紹介すると

syslog
システムの動作状態に関するログ

dmesg
カーネルのメッセージバッファのログ
OS起動時、動作時のカーネルメッセージが出力される

auth.log
認証関係のログ

boot.log
OS起動時のサービスメッセージのログ

dpkg.log
パッケージマネジャーの dpkg のログ

apt
パッケージ管理ツールのAPT のログが出力されるディレクトリ

wtmp
ユーザのログイン履歴ログ
who コマンドを使って開く

lastlog
ユーザが最後にログインした日時のログ
lastlogコマンドで確認

この中で、トラブル遭遇時に確認することが多いのが
syslog

ログを確認する時に注意することは
書き込み権限のあるユーザの場合なら
viewコマンド
http://www.linuxlic.com/command/view.html
とか
tail
less
などのコマンドを使い、読み込み専用で開くこと

これは、間違えてログの変更や削除をしてしまわないため

今回は
view コマンドで 認証関連ログファイル auth.log をみる
view /var/log/auth.log
で内容を確認


このときに出てくる書式が
ログ管理デーモンになるrsyslog の
RSYSLOG_TraditionalFileFormat
という書式

これは、
/etc/syslog.conf で

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

と定義されている

syslog 形式のログは
TIMESTAMP
HOSTNAME
といった、いくつかのプロパティから構成される

例えば view /var/log/auth.log
で見てみると
Jul 21 10:17:01 snowpool-Prime-Series CRON[5106]: pam_unix(cron:session): session closed for user root
というログがあり

Jul 21 10:17:01
の部分がTIMESTAMPで
ログが出力された日時

snowpool-Prime-Series
が
HOSTNAMEで、ホスト名

CRON[5106]:
は
syslogtag で、ログメッセージの出力元
プログラム名の表示
今回なら、
プロセスID 5106 の cronデーモンがログを出力している

pam_unix(cron:session): session closed for user root
はmsg で、ログの内容になる

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
にコマンドが載っていました