1

私は、数日前に ApplicationPool をクラッシュさせた asp.net アプリケーションの何が問題なのかをデバッグ/発見する責任を突然負っています。設定した 5 分間のフェイルセーフで 5 つのエラーが発生したため、停止しました。問題は、まだページが提供されていたため、一部の訪問者に対して 503 が返されたことです。悲しいことに、アプリケーションのロギングが不十分であり、ファーム内のサーバーの 1 つだけで発生することはめったにないため、何が問題なのかを突き止めるのは困難です。

それでは質問です。私は管理者ではなく、IIS7 と Server2008 の両方に慣れていないので、自分の可能性を探っているだけです。私が知っていることと持っていること:

  • httperr ログ ファイル。
  • 別のディスクに保存されている wc3 形式のサイト固有のログは、アクセス ログのように見えますか?
  • イベントビューア

失敗したリクエストのトレースを設定する可能性もありますが、パフォーマンスが向上する可能性があることは理解しています。

ログに記録されている、またはログに記録できるものを見逃していませんか? アプリケーションが正常に動作していることをサーバーでチェックする方法に関する一般的なヒントはありますか?

LogParser を学ぶ必要があるように思えますが、何かヒントはありますか?

編集:マシンの状態のログにも興味があります。cpu-load、メモリなどのように。可能性はありますか?

4

3 に答える 3

1

Tess Ferrandez の「壊れている場合は修正する必要があります」というブログを確認してください。これは、本番用の asp.net アプリケーションをデバッグするための、私が知っている最高のリソースです。おそらく、すべてのログが十分に役立つわけではありません。ほとんどの場合、クラッシュの原因となっているアプリケーション コードです。

于 2008-12-01T22:27:06.760 に答える
0

私たちの Web アプリでは、HttpApplication エラー イベントを介してすべての未処理の例外をキャッチし、必要なすべての補助データと共にそれらをデータベースに記録します。そのロギングが失敗した場合は、Windows EventLog に頼ります。次に、ログとサイトを定期的にチェックし、スケジュールに従って更新をメールで送信する別のマシンでサービスを実行しています。

于 2008-12-01T17:14:46.360 に答える
0

特に冒険したい場合は、IIS のクラッシュ ダンプを作成して分析する方法があります。

http://support.microsoft.com/kb/892277

これを利用して、クラッシュポイントでのコールスタックを見つけることができます。

于 2008-12-01T17:15:15.113 に答える