Web アプリケーションを完成させ、展開を計画しています。本番環境への展開の非常に重要な側面は、システムの状態を監視することです。開発者/サポートの小さなチームを持つことで、潜在的な問題を早期に通知し、ユーザーに影響が及ぶ前に解決することが非常に重要になります。
Nagios シームを使用することは良い選択肢のようですが、Web アプリケーション全般、特に Django アプリに最適な監視ツール/プラクティスについて、より多くの意見を求めたいですか? また、明らかな CPU、メモリ、ディスク容量、データベース接続以外に何を監視する必要があるかについての推奨事項も歓迎します。
私たちの Web アプリは Django で書かれており、Linux (Ubuntu) で Apache + Fast CGI と PostgreSQL データベースを使用して実行しています。
編集 Linodeの下に完全に仮想化された環境があります。
編集 django-loggingを使用しているため、情報、エラー、重大な問題などを分離する方法があります.
Nagiosは良いです、多分システムテスト（Selenium）を定期的に実行するのは良いことです。
編集：HypericとGroundworkも面白そうです。
おそらく、すべてを圧力テストし続けることができるテストスイートシステムがあります。頭のてっぺんから名前を思い出せないので、誰かが下に名前を挙げてくれるかもしれません。
私がしたい他のこと：
インフラストラクチャの最善のモットーは、常に修正、検出、修復です。それを立ち上げ、その根源に到達し、可能であればそれを治療/予防します。
システムは多くのレベルで存在するため、次の多くのレベルでテストする必要があります。
編集：すべてのエラーまたは警告をメールでケースマネージャーに直接投稿してもらいます。そうすれば、1か所で発生を追跡できます。
1）接続：サーバーおよび外部からインターネット接続を監視します。これをどこかに記録します
2）サーバー：サーバーを固定していないことを確認するために必要なすべてのプロセスを監視します。HPサーバーまたはBIOSレベルから実行できるハードウェア障害通知と同等のものを使用します。通知し、ログに記録します。
3）ソフトウェア：常に実行する必要がある主要なソフトウェアを特定します。パフォーマンスレベルがある場合は設定してから、それらを監視します。Nagiosはこれを支援できるはずです。Windowsでは、もう少し多くなる可能性があります。例外が発生した場合、そこからスクリプトを実行してプロセスを自動的に再起動できるはずです。私の夢のシステムでは、サーバーが許可する必要がある例外、またはSMSでキャンセルしない限り自動的に発生する例外と見なした場合に、SMSを介してサーバーと対話できるようにしています。いつか..
4）リモート電源：リモート電源リセット機能が手元にあることを確認します。Windowsを何かに使用する場合は、毎週の再起動をスケジュールすることをお勧めします。
5）ビジネスロジックテスト：システムのワークフローをテストするスクリプトを定期的に実行します。Seleniumはおそらくこれの一部を達成できますが、結果をログに記録することも好きです。これはこの時点で実行され、これらのファイルにはエラーがあったと言えます。可能であれば、どこでも、スクリプトを介してシステム自体を監視します。
6）バックアップ：設定して忘れることができるバックアップを作成します。インフラストラクチャの任意の部分をどこにでも拡張、移動、または展開できるため、仮想マシンに物事を取り込むことができれば理想的です。死んだサーバーをラップトップに移動し、問題を修正している間、それをvmwareで実行させた例があります。
Web サーバーとデータベースへの接続数を監視することも、追跡するのに適しています。屋根を突き破ると、何かがリソースを枯渇させ、サイトがダウンしようとしている可能性があります。
また、システムの合理的なエンド ツー エンド テストである URL の定期的な要求があることを確認してください。サイトが検索をサポートしている場合は、nagios に検索を実行させます。これにより、検索インデックス、Web サーバー、およびデータベース サーバーが正常であることを確認できます。
また、ユーザーがエラーを表示したり、未処理の例外が発生したりするたびに、アプリケーションから電子メールが送信されるようにしてください。そうすれば、アプリケーションが現場でどのように失敗しているかがわかります。
ああ、モニタリング。午前 3 時のあなたとあなたの振動をどれほど愛しているか。
基本的に、アプリケーションの内部状態を特定の瞬間と一定期間の両方で検査する方法が必要です (後者は、問題が発生する前に検出するために非常に重要です)。それを考える別の方法は、美化された単体テストです。
独自の (非常に優れた) 監視システムがあるため、Nagios や他のアプリについてコメントすることはできません。ただし、私たちのユースケースはあなたのものと似ています（Apacheのcgiアプリ）。
それはすべてかなり高いレベルです。重要なことは、時間の経過に伴うアプリケーションの状態の履歴を持っていることです。これから、「1 秒あたりのクエリが 2 倍になった場合、SlashDotted アラートを送信する」または「応答の 50% が 404 の場合、アラート」。また、アップ、ダウン、速い、遅いなどのコメントを数値化できるため、管理者を驚かせます。
監視する項目には次のものがあります (他の人もおそらくこれらについて言及しています): http ステータス、アクセス可能なポート、http の負荷、データベースの負荷、開いている接続、クエリの待機時間、サーバーのアクセシビリティ (ssh、ping)、1 秒あたりのクエリ、ワーカー プロセスの数、エラーの割合、エラー率。
簡単なエンド ツー エンド テストも非常に便利ですが、脆弱な場合があります。それらをシンプルに保つのが最善ですが、アプリのコア部分 (キャッシュ、データベース、認証) に触れようとするものを用意する必要があります。
内部ログは問題ありませんが、アプリ全体がダウンしたり、ボックス/環境がクラッシュした場合は、外部チェックも必要です. http://www.pingdom.com/は私にとって非常に信頼できるものです。
私の他の唯一のアドバイスは、これにあまり時間をかけないということです。私の最良の例はツイッターです。その時間とエネルギーをより多くのハードウェアの投入/スケールアウトに投資する代わりに、半分死ぬことができるシステムにどれだけのエネルギーを投入しましたか。
いずれにせよ、ロギングとヘルス システムが見逃している可能性があります。
オンライン サイトを監視する最も重要な方法は、外部から監視することです。目標は、ユーザーがサイトをどのように使用しているかを最も正確に反映する方法でサイトを監視することです。99% のケースで、サイトが外部的にダウンしていることがわかれば、根本原因を見つけるのは比較的簡単です。最も重要なことは、顧客がサイトを読み込めないことをできるだけ早く知ることです。
これは通常、外部のパフォーマンス監視サービスを使用することを意味します。それらは非常にローエンド (mon.itor.us、pingdom) からハイエンド (Webmetrics、Gomez、Keynote) まであります。そしていつものように、あなたはあなたが支払うものを手に入れます. 監視サービスを購入する際に探すべきことは次のとおりです。
幸運を！
IP PatrolまたはSiteSentryによる Web 監視は、私たちにとって役に立ちました。2つ目は、サイトの信頼に少し似ていますが、少しきれいです（笑）.
機能の監視についても考えましたか？アプリケーションと通信し、ログイン、購入などの重要な手順を実行するスクリプト（PerlやPytonなどのスクリプト言語またはWebTestなどのツールを使用）は非常に便利です。
私はNagios + CruiseControl + Seleniumを使用して、ミッション クリティカルな Web アプリケーションで高レベルのテストを実行しています。ユーザーがオンライン サインアップ フォームに進むのを妨げた単純な jquery エラーで、私はかなりの熱傷を負いました。
http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/
AlertGridをご覧ください。この Web アプリケーションを使用すると、アラートをフィルタリングしてチーム (世界中) に転送できます。何かが起こらなかったかどうかを監視する優れた機能もあります。
Richard Levasseur の言葉を言い換えると、ああ、監視ツール、あなたの不完全さがどれほど私を苛立たせているか。完璧なツールはないようです。Nagios のセットアップは非常に簡単ですが、UI はやや古臭く、監視対象の各サーバーでデーモンを実行する必要があります。 Zenossはリソース使用量のトレンド グラフを含むより優れた UI を備えていますが、SNMP を使用するため、適切に機能させるにはそれに慣れる必要があり、ドキュメントは最高ではありません - 何百ページもありますが、それを理解するのは非常に困難です始めるために必要な情報だけを見つけてください。
私の友人もCactiとHypericを推奨していますが、個人的な経験はありません。
最後にもう 1 つ - 他の回答の 1 つは、サイトに負荷をかけるツールを実行することを提案しました。誰もアクセスしていない信頼できる静かな期間がない限り、ライブサイトでそれを行うことはお勧めしません。それでも、予期せずダウンする可能性があります。本番環境に変更を加える前に、負荷テストを実行できるステージング サーバーを用意することをお勧めします。
当社のクライアントの 1 人が Techout (www.techout.com) を使用しており、このサービスに非常に満足しています。
アラートの種類や数に関係なく、アラートは無料で、電子メール、ボイスメール、SMS アラートを提供します。何か重大なことが起こった場合は、生きている人からの電話で助けてくれます。
それはすべてサービスに基づいています。ソフトウェアをインストールする必要はありません。お客様と協力してビジネスに最適なアプローチを決定するコンサルタントがいます。すべてを処理するため、最も便利な Web アプリケーション監視サービスの 1 つです。
行を少し変更すると、本当に便利だと思うことがあり、アプリを監視する方法が大きく変わり、javascript の例外をどこかに記録するようになりました。ユーザーのブラウザから Google Analytics に直接ログを記録する非常に優れた実装があります。これは Javascript 中心の Web アプリケーションには必須であり、ユーザーのブラウザーに直接基づいて結果を得ることができるため、非常に予期しないエラーが発生する可能性があります (iE およびモバイル ブラウザーは苦痛です)。
免責事項：以下の私の投稿
http://www.directperformance.com.br/en/javascript-debug-simples-com-google-analytics
過去のエラーの履歴とそれらを修正したことに基づいて、エラーの可能性をある程度予測できることを付け加えておきます。小規模な内部テストを使用して、この時点までに修正された問題の頻度と重大度をグラフにすると、予測可能な新しい問題の概要がわかります。しばらくの間、すべてがエラーなしで実行されている場合、問題の 2 つの原因は、最近の変更またはスケーラビリティの問題です。
以上のことから、スケーラビリティが唯一の懸念事項のように思えますが、過去のエラー頻度テストについて言及しただけです。なぜなら、私が参加したチームは常に、最後のエラーは修正され、それ以上はないと考えているからです。あるまで。
インターネットプレゼンスの監視については、私が取り組んでいるサービス、Sucuri NBIM (ネットワークベースの完全性監視) をお勧めします。
可用性と整合性のチェックを行い、インターネット プレゼンス (サイト、DNS、WHOIS、ヘッダーなど) の変化と接続の喪失を探します。これは無料で、ここで試すことができます。