デバッグ情報をアプリケーションのデータベースに格納する必要があります

Question

VIPの背後にあるn個のホストでサービスを実行しています。特定の要求の呼び出しで何らかの障害が発生した場合、障害が発生した尊重されたホスト上のログを調べることによってその理由を知ることができます。要求がどのホストにも行き渡る可能性があるため、ログを追跡する際に、どのホストから障害が発生したかを知る必要があります。

解決方法の1つは、弊社サービスのデータベースにホスト名を他の情報とともに保存することです。 代わりに、ログを共通のストアにプッシュしてそこにトレースします。

私は、最初のアプローチでは、アプリケーションデータベースに多くのデバッグ関連の属性を追加して、それを汚染する可能性があると個人的に感じています。しかし、第2の選択肢も実装が容易ではなく、オーバーヘッドが発生します。さらに、どのホスト上で障害が発生したかは、ハードウェア固有の問題のために障害が発生した場合を除いて、あまり役に立ちません。

あなたは何をお勧めしますか？

Answer 1

インフラストラクチャについて詳しく知りませんが、正確ではありませんが、ここではいくつかの一般的な視点があります。

データベースを使用してアプリケーションログを格納するのが好きではありません。データベースが転倒した場合、ログに記録することはできません。実際にはリレーショナルデータでもないため、他のソリューションで使用できる監視ツールを手に入れることはできません。

オペレーティングシステムの組み込みイベントロギングソリューションを使用することをお勧めします。ほとんどのロギングフレームワークはこれをそのままの状態でサポートします。 Windowsでは、これがイベントログです。 on * nixにはsyslogシステムがあります。ロギングはすばやく、安く、弾丸でなければなりません。これはOSツールから得られるものです。

第2の問題は、トラブルシューティングと監視のためにこれらのログをどのように使用するかです。これを行うためのツールはたくさんありますが、主に開発者ではなくシステム管理者を対象としています。 MicrosoftにはMoMがあり、TivoliとBig Brotherがあります。また、オープンソースのツールもたくさんあります。私は、あなた自身のソリューションを構築するのではなく、それらを使うでしょう。

重要な点は、 - ロギングは高速で安価で堅牢でなければならないことです。分析と監視はアプリケーションロジック全体とは別のものにする必要があるため、複数のプロジェクトのツールとプロセスを再利用することができます。

Answer 2

ホスト名を格納するのはかなり安いはずです。あなたはDBにログを追加していると思いますか？ 複数のプロセスが同じホスト名で実行されている場合に役立つ、各プロセスのpidも格納できます。 hostname/pid/timestampの組み合わせは、プロセスを一意に識別できるようにします。