ヒント：いいえ公共の懸念：黒板には、卵を保存し、攻略、入力する必要がBATに25K +プログラマの月給を受け取ります！
プログラムの主な目標でエラーログを打つより良いトラブルシューティングのための重要な手がかりとガイダンスを提供し、問題を解決することです。実際には、エラーログの多様な内容と形式を再生し、エラーは、何の背景不完全ないかもしれない、その意味は不明である。しかし、この問題を解決するための調査を行うことは非常に不便や時間のかかる操作になります。実際には、慎重に少しプログラミング時間あれば、それは問題を解決するために無駄な労力を削減します。エラーが発生したかを理解するための効果的なエラーログを作成する方法を説明するには、それは非常に重要です。
作り方エラー
現在のシステムでは、エラーは3ヶ所の導入によって生成されました：
1.不正パラメータレベルシステムが導入されました。違法なパラメータエラーの概要については、エラーが傍受したパラメータの前提条件を確認するためにチェックすることができます。
2.生成された基本的なシステムエラーと対話します。そして、根本的な相互作用によって発生したエラーは、2つあります：
下部システムプロセスが成功したが、通信エラー、これはサブシステム間のデータの矛盾につながる、この場合、タイムアウト機構は、タイミングデータ修正タスクに後続することにより上、事前にタスクレコードを補償するために使用することができます。より良いデザイン？
B.成功した通信が、より低いエラー処理。この場合、開発者と通信するための基礎となる必要性、サブシステム間の相互作用を調整し、適切な処置を行うか、根底返さのエラーコード及び記述に基づいて、合理的なエラーメッセージを与える必要があります。
いずれの場合も、我々は一般的な、優れた設計上の考慮事項エラーで基本となるシステムの信頼性ということを仮定しなければなりません。
3層システム処理エラー。
これは、層システムエラーを生成しました：
一つの理由：過失
過失はプログラマに完全にこのようなエラーを回避するための能力を指しますが、実際にそれをしませんでした。ノックなどが可能＆&&、= ==ノックなる;境界エラー、複合エラー論理的な判断を。座ってプログラムを書きながら過失またはプログラマは、残業すべての夜は、そのような疲労の状態のように、集中を欠いていた。急いいずれかのアカウントにように、プログラムの堅牢性とを取らない、機能を実現します。
改善点：効果的に問題を回避することができますユニットテストでコードの静的解析ツール、ラインカバレッジを使用。
二つの理由：細心の注意の欠如にエラーと例外処理
例えば、入力の問題。、一緒に2つの数値を計算オーバーフローを計算考慮するだけでなく、不正入力の場合を考えます。かつてのために、おそらく理解を通じて、経験やミスを回避することができる、それが私たちの知性の範囲内であるが、制御できるように、後者のために、そのような不正な入力をフィルタリングするために正規表現を使用して、制限しなければなりません。正規表現のためにテストする必要があります。違法な入力の場合は、可能な限り、詳細な理解しやすい、優しいメッセージ、原因を与え、ソリューションをお勧めします。
改善点：として思慮深く、さまざまなエラー条件と例外を検討してください。メインフローの実現後に、追加のステップ：可能エラーと例外の種々の注意深い精査、合理的な戻りエラーコード及びエラーの説明。各インタフェースモジュールが有効であるか、自分のエラーや例外を処理、効果的に複雑な相互作用のシナリオによって引き起こされるバグを回避することができます。たとえば、ビジネスユースケースのシナリオは、ABCの相互作用によって行われます。AB実際の実行が成功し、CはBとメッセージ戻るロールバックに妥当なコードメッセージと、ロールバックB復帰に従って、クライアントに戻る妥当に係る妥当コードCを返す必要が次に、障害が発生しましたコードとメッセージ。これは、セグメント化されたロールバック・メカニズムは、ロールバックの例外を考慮しなければならない各場面で必要とされています。
三つの理由：密結合ロジック・リード
密結合ビジネス・ロジックとして、ソフトウェア製品の段階の開発バイステップで、論理的な関係のすべての種類は、予測できない問題が発生し、グローバルスコープを変更するには、ローカルの影響の広がりにつながる、世界の状況を見ることが難しく、複雑です。
改善：ショート機能とは、短い方法、各関数またはメソッド好ましくは50以上の行を書き込みます。書き込み関数とメソッドステートレス、読み取り専用のグローバルな状態、および出力が常に同じ結果のための前提条件である彼らの動作を変更し、外部の状態に依存しない、インターフェースおよびロジック部分の構造の合理的な定義は、間のインタフェースとなるよう可能直交相互作用、低いカップリング;界面に直交できるだけ簡単提供するサービス層と、連続的なリモデリング、モジュール性と疎結合アプリケーション、ソートロジックの依存関係を維持します。サービスインターフェイスの多数がお互いに影響を与えるため、ビジネス・ロジックのプロセス全体を最適化するために、インターフェイスと相互依存を配置する必要があり、状態のエンティティの多数のためだけでなく、状態を終え、サービス・インターフェースとの間の関連遷移を整理する必要があります関係。
4つの理由：アルゴリズムが不正につながりません
改善は：まず、このアルゴリズムは、アプリケーションから分離されています。複数のアルゴリズムが実装される場合、このような動作をソートように、クロスバリデーションユニットを試験することによって求めることができる。アルゴリズムの可逆的性質は、暗号化および復号化演算として可逆ユニットテストをチェックすることによって見つけることができる場合。
5つの理由：順序エラーに渡されたパラメータの同じタイプ
例えば、modifyFlow（INT RX、TX INT）、実際の呼び出しはmodifyFlow（TX、RX）であります
改善：タイプは、特定のオブジェクトタイプにオブジェクトのこの特定のタイプで、文字列に対して、文字列を浮動小数点では浮動小数点数で、できるだけ具体;パラメータと同じオフセットタイプを、上記のすべての場合満たすことができない、それはインタフェースをテストすることによって検証されなければならない、インタフェースパラメータの値が異なっている必要があります。
6つの理由：nullポインタ例外
nullポインタ例外は通常、オブジェクトが正しく初期化されていない場合、またはまったくオブジェクトは、オブジェクトを使用する前にテストを行うには非空ではありません。
改善点：それは正常に初期化されている場合、構成オブジェクトの場合、検出は、通常のオブジェクトに対して、空でないかどうかを検出するために使用する前に、エンティティオブジェクトを取得しました。
七つの理由：ネットワーク通信エラー
ネットワーク遅延、障害物や障壁が発生したため、通常は、間違ったネットワーク通信エラーが発生しました。ネットワーク通信エラーは通常、小さな確率イベントですが、小さな確率事象は、大面積の故障につながる可能性があり、バグを再現することは困難です。
改善：INFOログを再生した後、各サブシステムのフロントエンドポイントおよびサブシステムのエントリポイント。2間の時間差により、手掛かりを提供します。
理由8：トランザクションと同時実行エラー
一緒にトランザクションと同時に、見つけることは非常に難しいエラーになりやすいです。
共有変数および重要なステータス変更を伴う同時操作でプログラムの場合、およびINFOログを上げる：改良。より効果的なアプローチ？？？
理由ナイン：構成エラー
改善点：あなたは、アプリケーションを起動したり、適切なコンフィギュレーションを開始し、すべての設定項目を検出し、適切なINFOすべての設定が正常にロードされていることを確認するためにログを出力します。
理由10：なじみのない事業による誤差
大規模なシステムでは、ビジネスロジックとビジネスの相互作用の一部は、より複雑で、全体のビジネスロジックは、学生の複数の脳の発達に存在することができ、すべての人の理解が完全ではありません。これは、簡単にビジネスコーディングエラーにつながることができます。
改善点：議論とコミュニケーション以上には、ビジネスロジックの使用例を記述し、実装するための事業に応じて、適切なビジネスユースケースを設計、究極のビジネスロジックとビジネスユースケースは、完全なアーカイブでなければなりません。前提条件は、サービス・インターフェースでサービスを示し、トラフィックの変化が同期して更新コメントにサービスを提供する必要が;コードレビューを処理ロジック、および注意事項リアチェックサム。ビジネスノートには、重要なビジネス文書・インターフェースである、ビジネスはキャッシュを理解する上で重要な役割を果たしています。
理由XI：設計上の誤差が問題を引き起こしました
たとえば、パフォーマンス同期シリアルやり方があるだろう、応答が遅いの問題は、非同期および同時パフォーマンスは、応答が遅いという問題を解決することができるが、それはセキュリティ上、リスクの正確さをもたらすでしょう。非同期プログラミングモデルは、変化をもたらす新しいものを追加して、その上の非同期メッセージのプッシュとを受け取ることができます。私たちは、パフォーマンスを向上させるためにキャッシュを使用することができますが、問題のキャッシュの更新があります。
改善点：書き込みや設計文書を慎重に検討。、背景は、ニーズは、ビジネス目標が満たされている手の込んだ必要があり、全体的なデザインのアイデア、詳細なプログラムに影響を与える可能性のあるビジネス・パフォーマンス・メトリックを達成するための設計文書は、プログラムは、利点と欠点と可能性への影響を予測し、その変化を確実にするために、テストと受け入れを渡しますデザインは、ビジネス目標と業績評価指標を満たしています。
理由12：不明詳細に起因する誤差
このようなバッファオーバーフロー、SQLインジェクション攻撃など。機能的な観点から、そこに問題はありませんが、ビューの悪質なポイントの使用は、脆弱です。別の例では、新しいフィールドオブジェクトがエラーを解析引き起こす可能性があります場合は、デフォルトでは、ジャクソンライブラリJSON文字列の解析を行うことを選択します。オブジェクト上で適切に変化に対応するために@JsonIgnoreProperties（ignoreUnknown =真）注釈を追加する必要があります。あなたは他のJSONライブラリを選択した場合は、この問題は発生しません。
改善点：経験を通じて、一方で、他の一方で、成熟した厳密なテストライブラリを選択し、セキュリティの問題や例外を考慮してください。
理由サーティーン：バグの時間をかけて登場
過去にいくつかのソリューションは非常に良いように見えますが、それは、それは一般的なことですが、現在または将来のシナリオに厄介な、あるいは無駄になることがあります。過去の暗号化と復号化アルゴリズムは、完璧であるとみなすことができるなど、私たちは、休憩後に注意して使用する必要があります。
改善点：変更やバグ修正のニュース、日付コードの適時補正、図書館、行動に注意を払います。
理由14：ハードウェア関連のエラー
このようなメモリリーク、その上のストレージスペースの不足、OutOfMemoryErrorが発生し、など。
改善点：上昇、アプリケーションのパフォーマンス監視システムは、CPU /メモリ/ネットワークの重要な指標です。
システムで発生する一般的なエラー：
- データベース内のエンティティのレコードは、エンティティまたはエンティティの識別子を指定する必要があり、存在しません。
- エンティティが正しく設定されていない、あなたは適切な構成がどうあるべきか、どの構成問題を指定する必要があります。
- 物理リソースは、あなたが必要としている、どのような資源である、現在どのようなリソースを指定する必要があり、基準を満たしません。
- エンティティの動作の前提条件は、現在の状態が何であるかを満たすために必要性を、指定する必要がありますどのような前提条件、満たされていません。
- エンティティセットが満たされていないのキャリブレーション動作後、後のチェックは、現在の状態が何であるかを、満たすために必要なものを示さなければなりません。
- パフォーマンスの問題がタイムアウトを起こし、フォローアップを最適化する方法、パフォーマンスの問題の原因を示す必要があります。
- 双方向コミュニケーション複数のサブシステム間で一貫性のないデータのエラー状況または結果？
エラーを見つけることが一般的に困難な比較的低レベルの場所で発生します。根本的には、特定のビジネスシナリオを予測することはできませんので、指定されたエラーメッセージは比較的一般的です。
これは、上のビジネスにできるだけ豊富な手掛かりを提供する必要になります。間違った層スタックの原因の前提条件を満たしていない相互作用または複数のシステムの特定のレベルがあります。プログラミングする場合、スタック内の各レイヤは、すべての前提条件が傍受ビジネス層で可能なエラー限り、下に渡された間違ったパラメータを避けるためにできるだけ満足していることを保証するために注意する必要があります。
ほとんどのエラーは、さまざまな理由を生成するために結合されています。しかし、すべてのエラーが原因を持っている必要があります。エラーを解決した後、エラーが発生したかを詳細に分析し、どのように再び起こって、それらを回避します。努力は、しかし、成功することができます：進歩するために反映させます！
問題のトラブルシューティングを容易にエラーログを書き込む方法
エラーログの基本原則を破りました：
- できるだけ完全な。エラーログの各完全な説明は、次のとおりです。何が解決する（またはヒントを解決）する方法、理由（または可能性どのような理由）何で、どのようなシナリオの下で間違っていました。
- できるだけ具体的に。フォローアップの統計情報の作業を容易にすることができる、現場で何が起こったかを示すために、そのようなVMなどの一般的なエラーは、存在しませ;例えば、NC不十分なリソースは、特にどのようなリソースを参照するものの欠如は、プログラムから直接示すことができます。
- 直接できるだけ。最初の本能は、どのように解決するのではなく、本当の理由を見つけるために、いくつかの段階を通過する必要がし、原因を知っているでエラーログは最高の人材でなければなりません。
- 経験は、システムに直接統合されています。すべての問題は解決し、システムに統合可能な限り友好的な方法での経験を持って、新しいスタッフとより良いヒントに、というよりも他の場所で埋められています。
- レイアウトは清潔で整然とした、統一された標準化された形式でなければなりません。緻密で、エッセイスタイルのログは、心配にトラブルシューティングすることは容易ではない、非常に非友好的に見えました。
- 複数のキーワードを使用して、一意の識別要求は、キーワードが強調表示された：時間、エンティティの識別（例えばVMNAME）、操作名。
問題のトラブルシューティングを行うための基本的な手順
>開くログファイル - - アプリケーションサーバにログオンします>エラー・ログのロケーションに移動 - >、トラブルシューティングの問題を特定し、問題を解決するためのガイダンスキューのエラーログに応じました。
どこで：
- ログファイルを開くには、着陸から：複数のアプリケーションサーバので、それは便利ではありません見て一つずつ上がるためにログオンします。あなたは、すべてのサーバがAGに直接ログインする、あるいは直接、必要に応じて、エラー・ログを遮蔽AGビューでツールを記述する必要があります。
- エラーログの場所を探します。現在、エラー・ログにナビゲートしやすい、密なレイアウトをログに記録します。一般的には最初の場所の前面付近エラーログを検索するために「時間」を使用することができ、その後、エンティティのキーワード/名前の組み合わせのロック操作エラーログを使用しています。伝統に沿って、より多くの、しかし、最初requestIdを見つけ、そして記述はないが、エラーログrequestIdを見つけるためによります。これは、直接、時間/コンテンツのキーワードに基づいて、エラー・ログのロケーションを見つけることが最善です。
- エラーログを分析します。エラー・ログの内容は、より簡単であることが最善であり、問題は明らかに現在の調査の特徴は一貫して、重要な手がかりを与えることであると同定されました。
一般的に、問題のあるアプリケーションエラーログがログの内容は、現在のコードのコンテキストを理解することですシンプルに見えますが、常に不完全な記述であり、あなたは、コードの状況を離れると、言われている内容を正確に把握することは困難である、人々はについて考える必要がまたはログ言うの意味が何であるかを理解するために、コードを見て。これは、自分の罪にないのですか？
でもコンテキストでコードを残し、かつ明確に何が起こったのかを説明することができます。エラーログが行う必要があります。
エラー・ログに直接明確な理由を説明することができた場合に加えて、あなたはより多くのエネルギーを節約することができ検査を行うためにログインします。
ある意味では、エラーログにも非常に便利なドキュメント、ユースケースの不正な操作のすべての種類の記録することができます。
現時点では、エラー・ログの内容は、次のような問題ことがあります
1.エラー・ログには、エラー・パラメータと内容を示すものではありません
ソリューション：これは通常、対象DO toStringメソッドに読める書か必要です。
2.エラー・シーンは明らかではないが、
ソリューション：言葉と相まって、またはインターフェイス[名前]を追加すると、エラーメッセージは、理解するために知って、エラー・ログからの直接のエラーメッセージのシーンの前にエラーを示します。インタフェースの実行者を知ることが一般的に可能な[名前]、サービスに加えたときに単語を追加することができます。
3.内容は明らかではない、またはその意味不明
ソリューション：明確に適切にエラー内容を説明します。
4.トラブルシューティングガイドの内容は明らかではないが、
解決策：適切な背景知識や大手調査対策を追加します。
エラーが十分に具体的かつ詳細な内容ではありません
解決策：プログラムまたは特定の場所で明らかな違いとして、スキルを向上させることにより、操作する手動アラインメントを減らします。
要約します
エラーログには、問題を解決するための重要な手段です。機能をプログラミングする場合、通常、弊社ではさまざまなエラーを検討 - と、なぜそれが発生する可能性があります。
該当する理由をトラブルシューティングするために、我々は、キーの記述のいくつかの原因を突き止める必要があります。これは、トライアドを形成します：症状 - >エラーキー説明 - >エラーの究極の原因。
だから我々は原因とどのような対策や手順を採用するものによって、任意のシナリオの下で何が悪かったのか、できるだけ完全な具体的かつ直接的な命令として、対応するエラーの説明のように、各キーのエラーのためにプログラミングを提供する必要があります。
著者：Jingdongはシニアエンジニア - 梁松花江、セキュリティの安定性の深い理解、アジャイル開発、JAVAが進む、マイクロサービスアーキテクチャ
保存された卵の黒板、よりエキサイティングな取得：マイクロチャンネル公衆数に焦点を当てます！
