Webアプリケーション監視のベストプラクティス
Webアプリケーションを完成させ、展開を計画しています。運用環境への展開で非常に重要な側面は、システムの状態を監視することです。開発者/サポートの小さなチームを持つことは、私たちが 早期通知 潜在的な問題を特定し、ユーザーに影響が及ぶ前に解決します。
Nagiosシームを使用するのは良いオプションですが、Webアプリケーション全般、特にDjangoアプリ）に最適な監視ツール/プラクティスは何かについてもっと意見を求めたかったのですが、明らかなCPU、メモリ、ディスク容量、データベース接続以外に監視されます。
私たちのwebアプリはDjangoで書かれており、Apache + Fast CGIの下でLinux（Ubuntu）上で実行され、PostgreSQLデータベースを使用しています。
編集 Linodeの下に完全に仮想化された環境があります。
編集 私たちはDjango-loggingを使用しているため、情報、エラー、重大な問題などを分離する方法があります。
Nagiosは良いです。システムテスト（Selenium）を定期的に実行するのは良いことです。
編集： Hyperic および Groundwork も興味深いように見えます。
多分あなたのためにすべてを圧力テストし続けることができるテストスイートシステムがあるでしょう。頭の上の名前を思い出せません。誰かが以下の名前を言うかもしれません。
私がしたい他のこと：
インフラストラクチャの最良のモットーは、常に修正、検出、修復です。それを起こし、その根本に到達し、可能であればそれを治療/予防します。
システムは多くのレベルで存在するため、多くのレベルでテストする必要があります。
編集：すべてのエラーや警告をメールでケースマネージャーに直接投稿します。これにより、発生箇所を1か所で追跡できます。
1）Connection：サーバーと外部からのインターネット接続を監視します。これをどこかに記録する
2）Server：実行する必要があるすべてのプロセスを監視し、サーバーが固定されていないことを確認します。 HPサーバー、またはBIOSレベルから実行できるハードウェア障害通知を備えた同等のものを使用してください。通知がある場合はログに記録してください。
3）Software：常に実行する必要がある主要なソフトウェアを特定します。パフォーマンスレベルを設定し、監視します。 Nagiosはこれを手助けできるはずです。 Windowsの場合は、これが少し増えることがあります。例外が発生すると、そこからスクリプトを実行してプロセスを自動的に再起動できるはずです。私の夢のシステムでは、SMSを介してサーバーとやり取りできるようにしています。これは、サーバーが許可する必要がある例外、またはSMSでキャンセルしない限り自動的に発生する例外と見なされる場合です。1日..
4）リモート電源：リモート電源リセット機能が手元にあることを確認します。何かにWindowsを使用する場合は、毎週の再起動をスケジュールすることをお勧めします。
5）ビジネスロジックテスト：システムのワークフローをテストするスクリプトを定期的に実行します。 Seleniumはおそらくこれのいくつかを達成できますが、結果をログに記録して、この時点で実行され、これらのファイルにエラーがあったと言うことも好きです。可能であれば、スクリプトを使用してシステムに自身を監視させます。
6）Backups：設定して忘れることのできるバックアップを作成します。物事を仮想マシンに取り込むことができれば、インフラストラクチャのあらゆる部分をどこにでも拡張、移動、または展開できるため、理想的です。停止したサーバーをラップトップに移動した例があります。問題を修正している間、サーバーをvmwareで実行させてください。
Webサーバーとデータベースへの接続数を監視することも、追跡するのに適した方法です。可能性としては、屋根を突き抜けて、リソースが不足してサイトがダウンする可能性があります。
また、システムの妥当なエンドツーエンドのテストであるURLに対する定期的なリクエストがあることを確認してください。サイトが検索をサポートしている場合は、nagiosに検索を実行してもらいます。これにより、検索インデックス、Webサーバー、データベースサーバーが正常であることを確認できます。
また、ユーザーがエラーを確認したときや、未処理の例外があるときは、必ずアプリケーションからメールが送信されるようにしてください。そうすれば、アプリケーションがフィールドでどのように失敗するかを知ることができます。
1つのタイプのテストを選択する必要がある場合は、システムのエンドユーザー機能をテストすることになります。考慮すべき重要なことはユーザーです。データベースの可用性、サーバーの稼働時間などのテストはすべて重要ですが、リモートUIテストシステムを介してシステムを介してワークフローをテストすることで、これらすべてのベースをカバーできます。システムの重要な部分がエンドユーザーに利用可能であることがわかっていれば、システムは大丈夫だとわかります。
- システムの重要なワークフローを特定します。たとえば、eコマースサイトを作成した場合、「製品を検索し、製品をショッピングカートに入れ、製品を購入する」というワークフローを特定できます。 。
- ワークフローを優先し、優先度の高いテストを最初に作成します。運用環境にロールアウトした後は、いつでもテストを追加できます。
- 利用可能なUIテストフレームワークの1つを使用してUIテストを作成します。自動化された方法で実行できる無料の商用UIテストフレームワークがいくつかあります。最初に、重要なワークフローに対応するコアテストセットを作成します。
- テストを実行する少なくとも1つのリモートロケーションをセットアップします。システムのすべての側面をテストする必要があります。つまり、リモートでテストします。インターネット接続は確立していますか？ Webサーバーは稼働していますか？データベースサーバーへの接続は機能していますか？など、リモートでテストする場合は、システムが外部から利用できることを確認してください。つまり、エンドツーエンドで動作している可能性が高いです。これらのテストは内部で実行することもできますが、外部で実行することが重要だと思います。
- ソリューションにレポートと通知の両方が含まれていることを確認してください。重要なワークフローテストの1つが失敗した場合は、だれかにそれを知らせて、問題をできるだけ早く修正してください。重要ではないタスクが失敗した場合は、おそらく、帯域外の問題を修正できるようにレポートすることだけが必要です。
このエンドユーザーテストでは、データセンター内のシステムの監視が排除されるべきではありませんが、エンドユーザーテストは、Webアプリケーションに対して実行できる最も重要なタイプのテストであることを繰り返し述べたいと思います。
ああ、モニタリング。午前3時のあなたとあなたの波動が大好きです。
本質的には、特定の瞬間だけでなく、一定期間にわたるアプリケーションの内部状態を検査する方法が必要です（後者は、問題が発生する前に検出するために非常に重要です）。もう1つの考え方は、栄光の単体テストです。
独自の（非常に素晴らしい）監視システムがあるため、Nagiosや他のアプリについてコメントすることはできません。私たちのユースケースはあなたのものと似ています（Apacheのcgiアプリ）。
- 情報をディスクに記録するlogging.monitor（）タイプのメソッドを追加します。これは少なくとも、単純な数と数の口述のログをサポートするはずです（key => valueの関連付けは非常に便利です）。
- モニタリングログをスクレイピングしてデータベースに保存するプロセスがあります。
- データベース情報を取得し、ルールと照合してチェックし、アラートを送信するプロセスがあります。フレーク状のものがあることに注意してください。 404 onceを取得したからといって、アプリがダウンしているわけではありません。
- アラートをミュートする方法があります（メンテナンスやメールを読むのに非常に役立ちます）。
それはすべてかなり高いレベルです。重要なことは、アプリケーションの状態の履歴があることです。これから、「おそらく1秒あたりのクエリが2倍になった場合は、SlashDottedアラートを送信する」、または「応答の50％が404の場合は、警告」。また、アップ、ダウン、高速、低速のいずれについてもコメントを定量化できるため、管理が煩雑になります。
監視する項目には、以下のものが含まれます（他の人もこれらに言及している可能性があります）：httpステータス、ポートアクセス可能、httpロード、データベースロード、オープン接続、クエリ遅延、サーバーアクセス可能性（ssh、ping）、1秒あたりのクエリ、ワーカープロセス数、エラー率、エラー率。
単純なエンドツーエンドのテストも非常に便利ですが、壊れやすい場合もあります。それらをシンプルに保つのが最善ですが、アプリのコア部分（キャッシュ、データベース、認証）に触れようとするものが必要です。
内部のログ記録は問題なくうまくいきますが、アプリ全体がダウンしたり、box/enviroがクラッシュしたりする場合は、外部チェックも必要です。 http://www.pingdom.com/ は私にとって非常に信頼できるものでした。
私の他のアドバイスは、これに時間をかけすぎないことです。私の最高の例はTwitterです。彼らは、ハードウェアの投入やスケールアウトに時間とエネルギーを費やすだけでなく、システムがどれだけのエネルギーを費やしてハーフダイを実現できるかを考えました。
おそらくあなたを倒すことになる可能性があります。とにかく、あなたの伐採と健康システムは見落としているでしょう。
オンラインサイトを監視する最も重要な方法は、外部から監視することです。目標は、ユーザーがサイトをどのように使用しているかを最も正確に反映する方法でサイトを監視することです。 99％のケースでは、サイトが外部でダウンしていることがわかったらすぐに、根本的な原因を見つけるのは比較的簡単です。最も重要なことは、顧客がサイトをロードできないことをできるだけ早く知ることです。
これは通常、外部パフォーマンス監視サービスを使用することを意味します。非常にローエンド（mon.itor.us、pingdom）からハイエンド（Webmetrics、Gomez、Keynote）まで。そしていつものように、あなたはあなたが支払うものを手に入れます。監視サービスを購入する際に注意すべき点は次のとおりです。
- 監視ネットワークの規模と分布
- 監視ソリューションが実際のブラウザを使用してサイトを監視できるかどうか（そうでない場合、実際のユーザーのようにサイトをテストしていない）
- スクリプト言語（サイトに対するトランザクションをスクリプト化するため）
- サポート部門は、途中であなたを助け、正しく監視する方法に関する専門知識を提供します
幸運を！
IP Patrol または SiteSentry によるWeb監視は私たちにとって有用でした。 2つ目は、サイトの信頼度に少し似ていますが、少しきれいです（笑）。
すでに回答済みの監視対象を除いて、使用しているシステムが何であっても、エラーの通知oneのみを受け取ることを確認する必要があります。これは、リクエストごとに複数回発生します。または、受信トレイでメモリが不足します:)さらに、それは非常に迷惑です...
スタンバイシフトをサポート/開発チーム間で分割することで、毎晩1人が待機する必要がなくなります。それは人々を疲れさせます。監視は良いことですが、誰もがたまに人生を過ごす機会を得る必要があります。午前2時に数晩携帯電話が鳴り響くと、すぐに非常に古くなります。また、すべての開発者が24時間年中無休のサポートに慣れているわけではないため、監視の使用と監視の乱用のバランスを見つける必要があります。
基本的に、異なるエスカレーションレベルを設定し、空が落ちない場合は、小さなエスカレーションレベルが出ないように、夜に " serenity now "ウィンドウを定義します。
機能の監視についても考えましたか？ （PerlやPytonなどのスクリプト言語で、または WebTest などのツールを使用して）スクリプトで、アプリケーションと通信し、ログイン、購入などの重要な手順を実行することは非常に便利です。 。
私はNagios + CruiseControl + Seleniumを使用して、ミッションクリティカルなWebアプリケーションで高レベルのテストを実行しています。ユーザーがオンラインのサインアップフォームを処理するのを妨げる単純なjqueryエラーでかなり焦げました。
http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/
AlertGrid をご覧ください。このWebアプリケーションを使用すると、アラートをフィルタリングしてチーム（世界中）に転送できます。何かが起こらなかったかどうかを監視する素晴らしい機能もあります。
システムテスト（Selenium）を定期的に実行することは良いことです。
=> 100％ACK。これには http://www.alertfox.com を使用します。 PRO2アカウントを使用すると、1時間ごとに回帰テストを実行できます。無料のアカウントでもこれを行うことができますが、トランザクションセンサーは1つに制限されています。
Richard Levasseurを言い換えると、ああ、監視ツール、あなたの欠点が私をいらだたせている。完璧なツールはないようです。 Nagiosの設定は非常に簡単ですが、UIは少し古臭く、監視対象の各サーバーでデーモンを実行する必要があります。 Zenoss は、リソース使用状況のトレンドグラフを含むはるかに優れたUIを備えていますが、SNMPを使用しているため、適切に機能させるためにはある程度の知識が必要であり、ドキュメントは最適ではありません。ページの数ですが、始めるために必要な情報だけを見つけるのは本当に難しいです。
私の友人も Cacti および Hyperic を推奨していますが、私はそれらについての個人的な経験はありません。
最後にもう1つ-他の回答の1つは、サイトに負荷をかけるツールを実行することを提案しました。誰もそれに当たらないときの信頼できる静かな期間がない限り、私はあなたのライブサイトでそれをすることはお勧めしません。それでも、予期せずそれをダウンさせる可能性があります。運用環境に変更を加える前に負荷テストを実行できるステージングサーバーを用意することをお勧めします。
過去のエラーの履歴とそれらを修正したことに基づいて、エラーの可能性をある程度予測できることを付け加えておきます。小規模な内部テストでは、この時点までに修正された問題の頻度と重大度をグラフ化すると、予測可能な新しい問題の概要がわかります。しばらくの間すべてがエラーなしで実行されている場合、問題の2つの原因は最近の変更またはスケーラビリティの問題です。
上記から、スケーラビリティはあなたの唯一の心配のように思えますが、私が常に行ってきたチームは常に最後のエラーが修正され、それ以上はないと思っているので、過去のエラーの頻度テストに言及します。あるまで。
私たちのクライアントの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