バックアップなどを監視し、そのデータから統計をトレンド化するための最適なツール[終了]

私はnagios、opennms、およびzenossについていくつかの調査を行いましたが、探しているものが見つかったことを確信していません。

今の私の主な原動力は、バックアップを監視できることです。これには、mysql、mssql、および最終的にいくつかのファイルシステムバックアップが含まれます。

これらのさまざまなシステムのバックアッププロセスをラップし、統計を収集するツールがあります。したがって、次のようなアイテム：

• バックアップされたデータベースの数
• dbバックアップファイルのサイズ
• 圧縮されたdbバックアップファイルのサイズ
• バックアップを作成する時間
• ファイルを圧縮する時間

A）ジョブがスケジュールに従って実行されない場合に通知を受け取ることができるようにしたいB）通知をトリガーする統計にしきい値を設定できるようにするC）統計を傾向およびグラフ化できるようにしたい

この情報をHTTP POSTを介して監視アプリケーションに送信することを計画しています。または、監視アプリケーションがログファイルからそれをプルすることもできます。

ただし、他の「監視」の観点から（監視システムの観点から）「静的」な他のプロセスがあるため、柔軟性が非常に重要です。

1つまたは複数のツールは、ネットワークインターフェイス、サーバー負荷などの一般的な監視と傾向分析も実行できる必要があります。バックアップ監視を実施したら、これらの項目も含める必要があります。

ありがとう。

フォローアップ：

私は次のことをこの順序で試すことにしました。

• Zabbix：他のものより「ワンストップショップ」のように見え、Ubuntu Lucid RCに簡単にインストールできました
• opsview
• Nagios w / nagvis、pnp4nagios、nagiosgraph
• npcプラグイン付きサボテン
• ムニン：シンプルさを少し傷つけたが、これは長い目で見れば祝福になるかもしれない

私が決定したらポストバックします、それが起こるまでにはしばらくかかるかもしれません。

独自の監視ソリューションを作成するのではなく、既存のツールを使用して、すべての基本的な監視およびアラート機能が既に実装されていることを強くお勧めします。Nagiosを選択すると、サーバーとネットワークリソースの基本的な監視が無料で得られます。次のプラグインは、必要な残りのほとんどの機能を提供します。

check_file_ages_in_dirsは、バックアップファイルが存在するかどうかを通知します。これが私がいくつかの基本的な例を使って書いたブログ投稿です。

check_fileは、ファイルのサイズと内容を（正規表現を使用して）監視できるため、バックアップ統計をファイルに出力して監視できます。

Nagiosから得られないことの1つは、トレンド分析とグラフ化です。設定は簡単で、Nagiosのように、提供されたプラグインのスタックがあるので、Muninを参照することをお勧めします。

これは、zabbixを使用して設定するのがかなり簡単なはずです。

カスタム（および非常に強力な）しきい値の設定は簡単です。好きな式を記述できるため、「これら5つのサーバーのうち3つ以上が正常にバックアップされなかった場合に通知する」のようなことが可能です。6つの異なる重大度レベルとエスカレーションを使用して、柔軟な通知とアラートを実現することもできます。

zabbixにはデータストレージと視覚化機能がバンドルされています。すべてのデータはデータベースに保存され、単一のメトリックをグラフ化するために構成は必要ありません。「無料」でグラフを取得するだけです。長期保存とトレンドの1時間の平均が計算されます。

バックアップに関するデータをzabbixに取り込むことに関しては、いくつかの可能性があります。ファイルから読み取ったり、カスタムコマンドを起動したり、コマンドラインユーティリティzabbix_senderを使用して監視対象のマシンからプッシュしたりできます。

拡張は簡単です。データを返すカスタムコマンドを使用して、そのデータを収集、保存、視覚化できます。

もちろん、オペレーティングシステム、アプリケーション、snmpおよびipmiデバイスなどの一般的な監視も可能です。

実行

バックアップはbackupninjaによって調整されます。私はそれを私のbashスクリプトのラッパーとして使用します-単一のバックアップログを持ちます。各スクリプトは次で始まります

 function handle {
         echo Error
         error problem occured
 }
 set -e
 trap handle ERR

そのため、コマンド[mysqldumpやrsyncなど]のいずれかが失敗すると、ログにエラーが記録されます。

すべてのバックアップはrdiffリポジトリで終了するため、n日間の増分があります。

すべてのバックアップは、rsyncを使用して中央ストレージサーバーに送信されます。

ストレージサーバーでは、すべてのバックアップが毎日検証され、ローカルディスク上のデータの検証が成功した後、それらは外部USBドライブにコピーされます。

検証

すべてのサーバーのbackupninja.logはnagiosによって監視されます。DEBUGおよびINFOメッセージのみが含まれているかどうかを確認します。それ以外はアラートをトリガーします。

すべてのバックアップはテストファイルに「触れ」、その存在と鮮度はnagiosを使用して中央バックアップリポジトリサーバーで監視されます。

さらに、より重要なSQLダンプのサイズ（新鮮さだけでなく）と完全性（たとえば、mysqlダンプの最後に、最新のタイムスタンプが期待される）がチェックされます

-ダンプは2010-04-22 23:21:02に完了しました

すべてのrdiffアーカイブは、データがUSBドライブに同期される前に毎日検証され、同期後に再び検証されます。したがって、夜間の転送が中断された場合でも、USBディスク上にのみ一貫したリポジトリがあります。チェックの結果はファイルに記録され、nagiosによってコンテンツと鮮度がチェックされます。

USBディスクは毎週ローテーションされ、念のためオフラインで保存されます。これは、大量のデータに対してはやり過ぎかもしれませんが、ゆっくりと変化するファイル/ダンプの約300GBに対しては正常に機能します。

トレンド

シンプルなカスタムmuninプラグインを使用して、各rdiffリポジトリのdiff / dataのサイズをプロットします。

実行にかかる時間は、backupninjaログで確認できますが、今のところは気にしません。

nagiosはトレンド分析を実行できますが、プラグインでperfdata（http://nagios.sourceforge.net/docs/1_0/perfdata.html）を出力する必要があります。pnp4nagios http://docs.pnp4nagios.org/pnp-0.4/startを使用すると、すべてがグラフ化されます。

opsview http://www.opsview.org/を使用すると、nagiosおよびpnp4nagiosを構成するよりもはるかに簡単であることがわかりました。特にあなたが仕事で唯一のLinuxに精通した管理者である場合。Opsviewは、Webブラウザーからほぼすべてのアクションを実行できる優れたWebUIを備えたnagiosです。nagiosですので、これまで使用してきたすべてのnagiosプラグインを使用できます。素晴らしいツール。

アラート用のNagios、グラフ作成用のCactiに加えて、いくつかのシェルまたはperlスクリプトは、まさに望みどおりの動作をします。それらを組み合わせることで、あなたが入れようとする努力の量に応じて、ほとんど何でもすることができます。

OpenNMSをお勧めします。パッケージは完全にオープンソースであり、積極的にサポートされ、定期的に強化されています。参考までに、Symantec Backup Execを監視するための Wiki構成情報を見つけました。

彼らのウェブサイトから..

OpenNMSは、オープンソースモデルに基づいて開発された世界初のエンタープライズグレードのネットワーク管理プラットフォームです。コミュニティでサポートされているオープンソースプロジェクトと、商用サービス、トレーニング、サポート組織で構成されています。

開示：私はここでは商業的な関心はありませんが、上記の「営利サービス、トレーニング、サポート組織」であるThe OpenNMS Groupの所有者は私の友人です。

これは、Circonus（http://circonus.com/）で簡単に実行できます。このようなメトリックをResmon XML DTDで定期的にインポートします。