blog

異常を正しく分析する:良いハンドを作るには ログ

なぜログが重要なのですか?オンラインプロジェクトではデバッグができないため、Logを通してしか問題を分析することができません。このとき、Logをうまく書くことの重要性は、コードをうまく書くことに劣りま...

Apr 25, 2025 · 4 min. read
シェア

もし、そのプロジェクトが進行中であるなら、ログがいかに重要であるかはご存知のはずです。

なぜログが重要なのですか?なぜなら、オンラインプロジェクトではデバッグができないからです。このとき、Logをうまく書くことの重要性は、コードをうまく書くことに劣りません。プロジェクトで何か問題が発生したとき、自分の担当部分に問題がないことを証明するログを作成できなければなりませんし、自分の担当部分に問題がある場合は、ログからエラーの原因を素早く突き止めなければなりません。ログからエラーの原因がわからなければ、特にそのバグが再現しにくいものであれば、それはとても悲しいことに違いありません。それは大声で叫んでいるのと同じです。

I. ログレベル

最も一般的なLogのレベルはDEBUG、INFO、WARN、ERRORで、その他はほとんど使われません。どのようにログの適切なレベルを使用することも非常に重要ですが、ERROR ERRORの場所で使用しないでください、あなたに余分なトラブルをもたらす可能性があります。以下は、それぞれ自分の習慣によると、様々なレベルの私の理解。

1.ERROR:

ERRORはエラーの意味ですが、例外が発生した場所をERRORと打つという意味ではありません。 ERRORはプログラムの正しい動作に対して相対的なものだと思います。ERRORがあるということは、何かが間違っているということであり、開発者はその原因を突き止めなければなりません。プログラムの問題かもしれませんし、環境の問題かもしれませんし、理論上エラーが発生するはずのない場所かもしれません。要するに、どこかに解決すべき問題があると思えばERRORを押し、解決する必要がなければERRORを押さないということです。

例えば、インターフェイスがある場合。呼び出し元が許容範囲外のパラメータを渡した場合、どの値を渡すかはユーザー次第であり、プログラムの正しい動作には影響しないため、この場合はERRORを押すことはできません。サーバーにERRORやWARNを検出したときに警告を出す監視プログラムがあり、パラメータのエラーに対してERRORを押したとします。

トランシーバーを作って音声パケットの解析にミスがあった場合、ERRORを押すべきです。理論的にミスをしてはいけないのはここだけで、解析コードに何か問題があるか、音声パケットをつなぎ合わせる開発者に問題があるかのどちらかです。ですから、ERRORを押すべきです。

2.警告

WARNは、プログラムの正常な動作には影響しない問題です。WARNが頻繁に発生したり、何度も発生したりする場合は、プログラム、環境、または依存プログラムが本当に故障しているかどうかを確認する必要があることを意味します。

インターフェイスにアクセスし、タイムアウトを設定し、タイムアウトが例外をスローした場合、あなたはそれを無視するためにINFOをヒットしないようにトライブロック内のERRORをヒットしてはいけません、その後、あなたはWARNをヒットする必要があります、タイトな警告、タイムアウトがあまりにも多い場合は、それをチェックアウトする必要があります、インターフェイスの反対側に問題があるか、ネットワーク環境の問題ではありません。

3.INFOとDEBUG:

ERRORとWARNは問題を指し、INFOとDEBUGは一般的な情報を指します。プログラムの問題では、このログが問題の分析やプログラムの動作のチェックに役立つなら、INFOを再生する必要があります。パラメータが誤って渡されていることを伝えることができます。

II.遊び方

1.必要な情報を記録

それぞれのログに、時間、クラス名、関数名、そして、javaのlog4jのように行番号も表示できるのであれば、それは良いことです。

2.関数の開始と終了

重要な関数の終わりの先頭にログに入力する必要がありますので、ログを見ると、より直感的になるときに開始するときに終了が明確になる、プログラムの途中で例外が発生した場合に終了するだけでなく、どの関数を知っている突然の中断。同じことが重要なロジックブロックの開始と終了にも適用されます。

3.リターン結果

重要な関数やウェブインターフェースのすべての戻り分岐で、戻り結果を出力してみてください。例外の悪い分析の場合には、詳細から、このタイムログが便利になります。データ内のパートナーとの紛争がある場合も、タイムリーな証拠とすることができます。

4.例外キャッチの追加

コード内で何らかの例外をキャッチする場合、実行時例外がプログラムを中断させる場合に備えて、tryブロックの後にExceptionのcatchを追加します。

5.スタック情報を必ず印刷してください。

例外をキャッチするコードでは、必ずスタック情報をプリントアウトしてください。

6.マルチスレッドログ

マルチスレッドのプログラムでは、ログ***はthredIdでタグ付けされなければなりません。そうしないと、どのスレッドの仕事かわからなくなり、スレッドの整理されたビューを得ることができません。

7.成功と失敗の指標

関数は、より重要なことを行うには、この事は成功したか、ログを印刷するために失敗した場合、それ以外の重要なイベントの結果は、どのように言葉の証拠を得ることができない実行すると、本当に説得力がありません。

8.フロントログとバックログの関係

ウェブアプリケーションやインターフェイスの場合、ログは意図した順序で表示されず、複数のレスポンスからのログが散在している可能性があります。コード内にいくつかのログがあり、それが何らかのデータ関係を持つ場合、同じレスポンスに対するものであることを 確認するために、これらのログの相関情報をタイプアウトする必要があります。明確な表示がない場合、後のログが前のログと同じ応答であるとか、同じデータの一部に対するものであると言うことは困難です。

9.時間消費について

10.音量について

データベースへの照会や、ファイルの一括コピー、アップロード、ダウンロード、一括フォーマット変換など、数量を印刷することを前提としたバッチ操作など、数量を含む操作はログを印刷する必要があります。

要するに、ログを入力する目的は、エラーのトラブルシューティングを素早く行うため、あるいは、論争になった場合に自分自身を証明する証拠を作成するためです。この目的に基づけば、自分に有利な情報をすべてつかみさえすれば、ログは大したものではありません。

他にも思いついたらどんどん追加していくので、背中をポンと叩いて気軽に追加してください。

私はあまり教養がないので、皆さんのご指導のためにこの記事を書いています。 この記事があなたのお役に立てれば幸いです。

Read next

Red HatがOpenStackを発表 クラウドサービスの革新に注力

先日ボストンで年次 Red Hat Summit が開催され、Red Hat は今回、オープンソースのソリューション全体としてオープンハイブリッドクラウドに焦点を当てました。他の IT ベンダーと同様、Red Hat もクラウド・サービスへの移行が IT 業界における次の成長の波を先取りすることにつながると期待していますが、周知のように IT は予測不可能であり、次の変化では勝者よりも敗者の方が多くなるでしょう。

Apr 24, 2025 · 4 min read