1

わかりました、ここに私の混乱/問題があります:

  1. 私はローカルホストで開発し、そこで例外を発生させ、コマンドラインでログを簡単に見ることができました.
  2. 次に、テスト サーバー、ステージ サーバー、および運用サーバーにコードをデプロイします。ここから問題が発生します。ログを確認したり、エラーや例外をデバッグしたりするのは簡単ではありません。通常のエラーの場合、django-toolbar を有効にできると思いますが、クラッシュしないサイレント例外がいくつか発生しますが、そのためにプロセスが操作されて失敗します。たとえば、私は支払いの統合を行っており、数日前に私たちのサイトで支払いがリターン (コールバック) で失敗していましたが、何もクラッシュしていませんでした。支払いプロセスが失敗したというメッセージだけが来ていましたが、支払いゲートウェイベンダーは正常に動作していました。この問題につながる可能性のあるいくつかの障害インスタンスを探す必要があり、変数がそこになかったため、1 つのデータベース保存操作が保存されていないことがわかりました。

さて、私の質問は、Sentry ( https://github.com/getsentry/sentry ) がその答えですか? または、これには他のオプションがありますか?

私の要件についてさらに説明が必要かどうか尋ねてください.

4

1 に答える 1

1

Sentry はオプションですが、正直なところ制限がありすぎます (1 か月ほど前に試しました)。これは例外を追跡することを目的としていますが、現実の世界では重要な情報やイベントも追跡する必要があります。アプリケーションのログ記録を設定していない場合は、この例に従って設定することをお勧めします。

私のアプリでは、さまざまな目的のためにいくつかのロガーを定義しました。辞書 (Django で使用されるもの) を介した Python ロギング構成は非常に強力であり、ログの記録方法を完全に制御できます。たとえば、ログをファイルに書き込むことができます。 、データベースへの送信、電子メールの送信、サードパーティの API の呼び出しなど。アプリが負荷分散された環境で実行されている場合 (複数のマシンでアプリを実行している場合)、Logglyなどのサービスを使用して、インスタンスからのログを 1 か所に集約できます ( RSYSLOGを使用するため、集約するだけでなく、 Django アプリのログだけでなく、基盤となる OS のすべてのログも含まれます)。New Relicも使用することをお勧めします、実行されたクエリと時間、テンプレートの読み込み時間、エラー、その他の多くの有用な統計など、多くのものを自動的に追跡します。

于 2014-04-04T12:59:08.813 に答える