カテゴリー: log について

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 で、ログの内容になる

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

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

性能解析につかわれるログ
/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でシステムリソース情報を取得するには？
を参考にさせていただきました

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

dhclient のログは
タグにプロセスIDの記載がなく
dhclient というプログラム名だけを記録する
DHCPREQUEST はIP要求
DHCPACK は確認応答
remewall はIP更新を意味する