Apache2のログ監視はanalogをインストールし既に行ってました。
また、サーバーの各ステータスもMrtg+RRDTOOLで監視を行っていました。
そこで今回はsyslogなどの実際のログを監視して自動でメールを送信してくれるlogwatchをいうアプリをインストールします。
※このアプリを動かすためにはmailutils、exim4などのメール送信に必用なパッケージをインストールしmailコマンドでメール送信が出来るように設定する必要があります。

まずインストールですがこれは非常に簡単です。
apt-get install logwatch

インストールされたらlogwatchの設定を変更します。
vi /usr/share/logwatch/default.conf/logwatch.conf

変更点は以下の点になります。

変更前：MailTo = root
変更後：MailTo = your_address@your_host.com
↑送信したいメールアドレスに書き換えます。（mailコマンドで送信できるアドレスであることが前提）

変更前：#Archives = No
変更後：Archives = Yes
↑logがlotateされた場合を想定

変更前：Detail = Low
変更後：Detail = Med
↑好みのログレベルに設定してください。（文字列ではなく数値で指定も可能です）

設定が完了したらテストで実行してみましょう。
/usr/sbin/logwatch

実際に設定したアドレスにメールが送信されてくれば設定は完了です。

ちなみにcronにはインストール時に自動で登録されています。
(１日１回自動実行されてメールが送られてきます)
debianでのcronへの自動登録はdailyに登録されるのでAM6:25に実行されます。
時間などを変更したい場合はcron.dailyから削除しcrontabに自分で登録してください。

送られてくる内容で注意すべきなのは
pam_unix、SSHD、Disk Space、kernelの項目でしょうか。(kernelはエラー出ないと送られてこないようです)

pam_unixはLinuxのpam認証を表示しています。

SSHDはその名の通りsshへの接続を示しています。
許可していないユーザーでのログインがあれば不正アクセスの可能性もありますので注意が必要です。

Disk Spaceは一杯になる前にどうにかしましょう（笑）

kernel項目に関しては出力されていれば解析、調査が必要ですね。

最後に
　logwatchを導入すると毎日定期でlogの結果が送信されてきます。
誰しも最初は注意深く見るのですが平和な日々が続きますと次第に見なくなったり軽く読み飛ばしたりするようになりがちです。
しかし、それではlogwatchを導入した意味は全くありません。
mrtgの様にグラフでの傾向は示してくれませんが毎日logに目を通すことで障害を未然に防げたり
発生した障害による被害を広げないことも可能になります。
このツールの本当の真価はlogをチェックする人の対応力に尽きると思います。

LinkStationの抜け殻を使ってLinkStationを再生します。
※新品HDDを組み込んだだけでは起動してくれないARM系のLinkStationを対象にしています。

通常はLinuxにHDDを繋いで必要なファイルを書き込んでHDDをLinkStationに戻しますが
今回はお手軽に再生する方法を紹介します。

お手軽にということでシリアルコンソールも使用せずに再生したいと思います。
LinkStationに新品HDDを取り付けて起動するとbootディレクトリ(必要なファイルも)が存在しないのでLinkStationは内部的にはtftp経由で起動しようとします。

そこでｔｆｔｐを使ってbootイメージをLlinkStationに転送しEMモード(復旧モード)で起動し
そこからファームウェアのアップデートでHDD内に必要なファイルを作成します。
使用するソフトはTFTPサーバー Poor TFTP Server for WIN32というソフトです。
Windows上で起動することでｔｆｔｐサーバーとして動作するソフトです。
※既にリンク先のサイトはなくなっているようです

ｔｆｔｐで転送する為のboot用ファイルをまずは用意します。
Buffaloのサイトから該当するLinkStationのファームウェアをDLしてきます。
転送に必要なファイルは　initrd.buffalo　uImage.buffalo　の二つです。
これらのファイルはファームの中に圧縮ファイルとして存在するので解凍して取り出します。
initrd.imgを解凍するとinitrd.buffaloが取り出せますがZIPのPASSを求められるので下のどれかを入れてください。

1NIf_2yUOlRDpYZUVNqboRpMBoZwT4PzoUvOPUp6l
aAhvlM1Yp7_2VSm6BhgkmTOrCN1JyE0C5Q6cB3oBB
YvSInIQopeipx66t_DCdfEvfP47qeVPhNhAuSYmA4
IeY8omJwGlGkIbJm2FH_MV4fLsXE8ieu0gNYwE6Ty

二つのファイルをtftpのディレクトリに置けば準備完了です。
LinkStationのtftp起動時はLlinkStationのIPは192.168.11.XXXとなっており
192.168.11.1のtftpサーバーに接続しようとします。
ですのでtftpサーバーを起動するPCのIPを192.168.11.1に変更してからtftpソフトを起動してください。
tftpサーバーソフトを起動させたらLinkStationの電源をONにしてtftp起動させます。
※同じハブなどにPCとLinkStationをLANで接続してから行ってください。

ｔｆｔｐでｂｏｏｔイメージが転送されるとtftpサーバーソフトに転送されたメッセージが出て
LinkStationのLEDがオレンジ色に光り起動するはずです。
この状態がEMモードとなります。

EMモードになったらtftpを起動したPCで通常と同じようにファームのアップデートを行ってください。
HDDのパーティション設定やフォーマットまでやるのでそれなりの時間が掛かります。
これで新品のHDDからLlinkStaionの再生は完了です。

どうしてももエラーになる場合などは内部的に何が起こっているのか全く分からないので
どうしてもシリアルコンソールが必要になります。
何台も再生させる人や色々とイジリ倒したい人は素直にシリアルコンソールを取り付けましょう（笑）

HDDの温度監視に続いて不良セクタの監視を行います。
HDD温度と同じようにsmartctrlコマンドを利用して不良セクタ情報を取得します。
監視項目は以下の二つです。

Reallocated_Sector_Ct　　　不良セクタを予備セクタと置き換えた数
Current_Pending_Sector　　置き換えることが出来なかった不良セクタの数

Reallocated_Sector_Ctに関しては置き換えが成功しているので一般的に数個までなら大丈夫といわれています。
しかし大事なデータやシステム領域のセクタを失うと致命傷になる可能性はあります。
Current_Pending_Sectorは１個でも出るとかなり危険です。
データを退避してHDDを入れ替えた方がいいかもしれません。

個人的な設定としてはReallocated_Sector_Ctは１０、Current_Pending_Sectorは１でメールが送信されるように設定しました。
グラフを表示しても基本的には０なので面白くはないですが重要なグラフには違いないです。

HDDの温度のスクリプトを少し改造すればこれらの情報を取得するスクリプトはすぐに完成しますね。

Reallocated_Sector_Ct.pl
－－－－－－－－－－－－－－－－－－－
#!/usr/bin/perl —

$count = readpipe(‘smartctl -d marvell -a /dev/sda -s on | grep -i Reallocated_Sector_Ct | awk ‘{print $10}”);

print $count;

exit $count;
－－－－－－－－－－－－－－－－－－－

Current_Pending_Sector.pl
－－－－－－－－－－－－－－－－－－－
#!/usr/bin/perl —

$count = readpipe(‘smartctl -d marvell -a /dev/sda -s on | grep -i Reallocated_Sector_Ct | awk ‘{print $10}”);

print $count;

exit $count;
－－－－－－－－－－－－－－－－－－－

※スクリプトのsnmp登録方法や利用方法、閾値を超えた場合のメールの送信方法は以前の記事を参考にして下さい。

MRTGでCPU使用率というと殆どのページでLoadAverageの設定が書かれています。
LoadAverageの表示には％で書かれている事が多いと思います。
そもそもLoadAverageとはなんなのか？
UNIX処方箋：「load average」によるCPU負荷の確認 – ITmedia エンタープライズ

つまりCPUの負荷を表すものであるがWindowsのプロセスマネージャーやtopコマンドで表示される
おなじみのCPU使用率とは意味合いが少し違うということになりますね。（ほぼ比例しますが）
また本来は％ではなく１.00表記の方が感覚的に正しいのかもしれません。
（1.00=100%なので意味は同じなのですが100%を超える場合もあるということです）

LoadAverageは1を超える可能性があるのでMRTGの設定でUnscaled[xxxx]: dwmyを指定している方は外した方がいいでしょう。
MaxBytes[xxx]:の項目も100以上の値を指定しないとLoadAverageが1を超えた場合にグラフの値がｒｒｄファイルに書き込まれません。
重たい処理を行う時は１を超えることがしばしばありますので大き目の500などを指定しておけば問題ないと思います。
CPUがマルチなシステムの場合は普通に1を超えるようです。

ではお馴染みのtopコマンドと同じCPU使用率はsnmpで取得出来ないのでしょうか？
答えは「取得可能です」

Target[xxxx]: .1.3.6.1.4.1.2021.11.50.0&.1.3.6.1.4.1.2021.11.52.0:public@localhost

ユーザー使用の使用率：.1.3.6.1.4.1.2021.11.50.0
システム使用の使用率：.1.3.6.1.4.1.2021.11.52.0
※最後の0は何番目のCPUかを表します。マルチCPUであれば1を指定で２番目のCPUの値が取れます。
　　他にもidle時間なんかも取れます。

但し取得してくる値はLoadAverageとは違うのでOptions[xxxx]:の部分に gauge, absoluteは指定しないで下さい。
参考サイト：MRTG: Net-SNMPでLinuxのCPU使用率をプロットするには
※既にリンク先のサイトはなくなっているようです

ということで私の場合はLoadAverageとCPU使用率の両方をRRDTOOL経由で記録して表示することにしました。
※５分の平均なのでCPU使用率がしばしば100%になっててもMAX値は記録されません。
　　あくまでも平均としての目安で参考程度にした方が良いでしょう。

以下rrdcgiのサンプルです。
※cpu2.rrdがCPU使用率でcpu.rrdがLoadAverageになります。
　　グラフの便宜上LoadAverageも百分率で表示しています。

－－－－－－－－－－－－－－－－－－
#!/usr/bin/rrdcgi

CPU Use & Load Average for LS-GLDEB

System: localhost

Maintainer: Root

Ip: 192.168.x.x

The statistics were last updated .

－－－－－－－－－－－－－－－－－－