LogicMonitorは、私が知る限り、最も自動化されています ネットワーク監視システム そこに。 しかし、私たちがあまり提供していない領域が XNUMX つあります。 オートメーション、よく聞かれるのは、アラートに応答する自動化されたスクリプトです。 そうしない理由はいくつかありますが、これは重要な本番データセンターを運用した経験から導き出されたものです。
- 自動リカバリを望まない場合が多くあります。人間が障害の原因を特定し、リカバリが安全に行われるようにする必要があります。 たとえば、マスターデータベースがクラッシュした後、多くのDBAは、原因、トランザクションをバックアウトする必要があるかどうか、スレーブがまだ有効なレプリカであるかどうかなどを特定せずにデータベースを再起動することを望んでいません。
- システムが自動リカバリを必要とするほど重要である場合、それを行う正しい方法は、スタンバイシステムをクラスター化するか、その他の方法で使用できるようにすることです。 たとえば、ロードバランサーの背後にある複数のWebサーバー。 マスター-マスターデータベース; 高速スパニングツリーを備えたスイッチ。 急速に収束するIGP（OSPF、EIGRP）を備えたルータ。
- サービスまたはプロセスをホストで自動的に再起動する必要がある場合、監視システムはほぼ確実にそれを行う正しい方法ではありません。 Linuxではdaemon-toolsまたはinitを使用するか、Windowsの[サービス]コントロールパネルで再起動するようにサービスを構成します。 監視システムを使用してこれを修正しようとすると、必然的にOSレベルのツールよりも脆弱なシステムになります。
- 監視対象のメトリックの状態に応じて強制終了して再起動する必要があるプロセスがある場合（メモリリークが発生して大きくなりすぎる場合）、たとえば（私はあなたを見ています、雑種犬）、そのために設計されたツールを使用します– monit、いう。
これらすべての場合において、監視を使用して、回復メカニズムではなく、回復メカニズムが機能しているかどうかを通知します。 雑種犬のプロセスのメモリ使用量を監視し、メモリ消費量が予想よりも多い場合にのみ警告します。たとえば、monitがその仕事をしている場合よりも長く警告します。
もちろん、LogicMonitor できる アラートに応じて自動スクリプトアクションをトリガーする–データセンター内のエージェントを設定して、すべてのアラートをプルし、スクリプトに送信することができます。これにより、スクリプトで実行できることは何でも実行できます。 そして、それが適切な場合もあります。 しかし、最初の手段としてそれに飛びつく前に、アーキテクチャと設計についてよく考えておく必要があります。