プログラムの主な目標でビートエラーログは重要な手がかりとより良いトラブルシューティングのためのガイダンスを提供し、問題を解決することです。しかし、その意味は不明である演奏の練習中にエラーが多様な内容と形式をログ、エラーが不完全な可能性があり、何の背景には、問題を解決するための調査を行うことは非常に不便や時間のかかる操作になりません。

実際には、慎重に少しプログラミング時間あれば、それは問題を解決するために無駄な労力を削減します。エラーが発生したかを理解するための効果的なエラーログを作成する方法を説明するには、それは非常に重要です。

作る方法エラー

現在のシステムでは、3ヶ所の導入によって生成されたエラー：

1.不正パラメータレベルシステムが導入されました。 違法なパラメータエラーの概要については、エラーがインターセプトにチェックし、パラメータの前提条件を確認することができます。

生成された基本的なシステムエラー2.相互作用。 そして、根本的な相互作用によって発生したエラーは、2つあります：

下部システムプロセスが成功したが、通信エラー、これはサブシステム間のデータの矛盾につながります。

この場合、タイムアウトは、使用補償機構、以前に後続のデータ修正上にスケジュールされたタスクによって記録されたタスクであってもよいです。

何より良いデザイン、あなたがメッセージを残すことができます。

B.成功した通信が、より低いエラー処理。

この場合には、基礎となる必要性は、開発者と通信サブシステム間の相互作用を調整します。

適切な処置は、合理的なメッセージまたはエラー・コードとエラーの説明低いリターンを与えるために行われる必要があります。

いずれの場合も、我々は一般的な、優れた設計上の考慮事項エラーで基本となるシステムの信頼性ということを仮定しなければなりません。

3.エラーを処理層システム。

これは、層システムエラーを生成しました：

一つの理由： 過失。 過失はプログラマに完全にこのようなエラーを回避するための能力を指しますが、実際にそれをしませんでした。ノックなどが可能＆&&、= ==をノックなる;境界エラー、複合エラー論理的な判断。座ってプログラムを書きながら過失またはプログラマは、残業すべての夜は、そのような疲労の状態のように、集中を欠いていた。急いいずれかのアカウントに、プログラムの堅牢性などを服用しないで、機能を実現します。

改善点：効果的に問題を回避することができますユニットテストでコードの静的解析ツール、ラインカバレッジを使用。

二つの理由： エラーと例外処理による徹底した十分に。 例えば、入力の問題。オーバーフローを計算考えるだけでなく、不正入力の場合を考慮するだけでなく、一緒に2つの数値を計算します。かつてのために、おそらく理解し、経験やミスによって回避することができ、後者のために、そのような不正な入力をフィルタリングするために正規表現を使用して、制御することができます私たちの知性の範囲内になるように制限しなければなりません。正規表現のためにテストする必要があります。違法な入力の場合は、可能な限り、簡単に理解するために、詳細な優しいメッセージ、原因を与え、ソリューションをお勧めします。

改善点：考え込むよう、さまざまなエラー条件と例外を検討してください。 メインフローの実現後に、追加のステップ：可能エラーと例外の種々の注意深い精査、合理的な戻りエラーコード及びエラーの説明。各インタフェースモジュールが有効であるか、効果的に複雑な相互作用のシナリオに起因するバグを回避することができ、自分のエラーと例外を処理します。

たとえば、ビジネスユースケースのシナリオは、ABCの相互作用によって行われます。AB実際の実行が成功し、Cは失敗し、その後、BとメッセージとリターンロールバックA妥当コードメッセージへと、リターンB Aのロールバックによれば、クライアントに戻る妥当に係る妥当コード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 /メモリ/ネットワークの重要な指標です。

システムで発生する一般的なエラー：

エンティティは、エンティティまたはエンティティの識別子を指定する必要があります存在しないデータベースに記録します。
エンティティが正しく設定されていない、あなたは適切な構成がどうあるべきか、どの構成問題を指定する必要があります。
物理リソースが基準を満たしていない、あなたは資源が必要とされているものを、現在のリソースが何であるかを指定する必要があります。
エンティティの動作の前提条件は、現在の状態が何であるかを満たす必要があるが、指定する必要がありますどのような前提条件、満たされていません。
エンティティセットのキャリブレーション動作が満たされていない後、後のチェックは、現在の状態が何であるかを、満たすために必要なものを示さなければなりません。
パフォーマンスの問題は、パフォーマンス問題の原因を示す必要があり、タイムアウトを引き起こし、どのように最適化するためのフォローアップ。
双方向コミュニケーション複数のサブシステム間で一貫性のないデータのエラー状況または結果？

エラーを見つけることが一般的に困難な比較的低レベルの場所で発生します。根本的には、特定のビジネスシナリオを予測することはできませんので、指定されたエラーメッセージは比較的一般的です。

これは、上のビジネスにできるだけ豊富な手掛かりを提供する必要になります。間違っては層スタックの原因に前提条件を満たしていない相互作用または複数のシステムの特定のレベルです。プログラミングする場合、スタックの各層は、ビジネス層が傍受内のすべての前提条件は、可能性のあるエラー限り、下に渡された間違ったパラメータを避けるために、可能な限り満足されるように注意する必要があります。

ほとんどのエラーは、さまざまな理由を生成するために結合されています。 しかし、すべてのエラーが原因を持っている必要があります。 エラーを解決した後、エラーが発生したかを詳細に分析し、どのように再び起こって、それらを回避します。 努力は、しかし、成功することができます：進捗状況を反映させるために！

簡単に問題のトラブルシューティングにエラーログを書き込む方法

ビート・エラー・ログの基本原則：

できるだけ完全として。 エラーログの各完全な説明は、次のとおりです。何をどのようなシナリオの下で間違っていたことは、その理由（または何考えられる理由）、どのように解決する（または解決のヒント）するものです。
できるだけ具体的なとして。 例えば、NC不十分なリソースは、具体的には、プログラムから直接示すことができますどのようなリソースを指し、何の欠如;などVMのNOT EXISTなどの一般的なエラー、現場で何が起こったかを示すために、フォローアップの統計情報の作業を容易にすることができます。
直接できるだけ。 最初の本能は、どのように解決するのではなく、本当の理由を見つけるために、いくつかの段階を通過する必要がし、原因を知っているでエラーログは最高の人材でなければなりません。
経験は、システムに直接統合されています。 すべての問題は解決し、システムに統合可能な限り友好的な方法での経験を持って、新しいスタッフとより良いヒントに、というよりも他の場所で埋められています。
レイアウトは清潔で整然とした、統一標準化された形式でなければなりません。 緻密で、エッセイ風のログは容易ではないトラブルシューティングするために、心配して、非常に非友好的に見えました。
複数のキーワードを使用して、一意の識別要求は、キーワードが強調表示された：時間、エンティティの識別（例えばVMNAME）、操作名。

問題をトラブルシューティングするための基本的な手順：

アプリケーションサーバにログオンします - >開くログファイルは - >エラー・ログのロケーションへナビゲート - >トラブルシューティングするために、指導の手がかりのエラーログによると、問題を特定し、問題を解決します。

どこで：

着陸からログファイルを開きます。 複数のアプリケーションサーバので、それを見るために1枚ずつ上がるにログオンすることは便利ではありません。AGビュー上のツールのすべてのサーバがAGに直接ログインする、あるいは直接、必要に応じて、エラー・ログを遮蔽を記述する必要があります。
エラーログの場所を探します。 現在、エラー・ログにナビゲートしやすい高密度のレイアウトを記録します。一般的な場所の前面付近エラーログを見つけ、その後、エラーログエンティティキーワード/名前の組み合わせのロック操作を使用するには、「時間」の最初の使用ができます。より多くの伝統が、最初のfind requestIdに沿ったものの、エラーログrequestIdを見つけるためによると、説明ではありません。これは、直接時間/コンテンツキーワードに基づいて、エラー・ログのロケーションを見つけることが最善です。
エラーログを分析します。 エラー・ログの内容は、より簡単であることが最善であり、問題は明らかに現在の調査の特性を同定し、一貫して重要な手がかりを与えることです。

に持っている、あなたは、コードの状況を離れると、言われている内容を正確に把握することは困難であり、一般的に、問題のアプリケーションエラーログは、ログの内容は、現在のコードのコンテキストを理解することですシンプルに見えますが、常に書き込み不完全、ハーフ英語フォーマットは、人々が考えるか、ログと言うの意味が何であるかを理解するために、コードを見て。これは、自分の罪にないのですか？

例えば：

if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)
                && (zone.hasStorageType(StorageType.io3) || zone.hasStorageType(StorageType.io4))) {
// 进入dfs1 和dfs2 在io3 io4 存储。
} else {
      log.info("zone storage type not support, zone: " + zone.getZoneId() + ", storageType: "
+ storageType.name());
      thrownew BizException(DeviceErrorCode.ZONE_STORAGE_TYPE_NOT_SUPPORT);
}

どのようなストレージ・タイプのサポートへのゾーンが正しいのですか？ドゥないようにしましょう私は考えて！

エラー・ログには、実行する必要があります。 でも、コンテキストでコードを残し、かつ明確に何が起こったのかを説明することができます。

また、あなたはより多くのエネルギーを節約することができ検査を行うには、ログイン、エラー・ログに直接明確な理由を説明することができます。ある意味では、エラーログにも非常に便利なドキュメント、ユースケースの不正な操作のすべての種類の記録することができます。

現時点では、エラー・ログの内容は、次のような問題ことがあります

1.エラー・ログには、エラー・パラメータと内容を示すものではありません。

catch(Exception ex){
      log.error("control ip insert failed", ex);
      returnnew ResultSet<AddControlIpResponse>(
ControlIpErrorCode.ERROR_CONTROL_IP_INSERT_FAILURE);
}

これは、コントロールの挿入が失敗したIPを指定しませんでした。私たちがコントロールipキーワードを追加すると、簡単にエラーを検索し、ロックします。

同様のがあります。

log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure.", e);

それは何かの余分な操作を行うためにそれらを識別するために、ことは注目に値するIPサブネットが、多少のパフォーマンスに影響を与える可能性があり、その下に指定しませんでした。この時間のトレードオフ性能およびデバッグ。

解決方法：String.Formatの（「ErrorObjにいくつかのメッセージ：％s」は、errobj）メソッドはエラーパラメータと内容を示しています。

これは通常、オブジェクトのtoStringメソッドDOの読みの準備が必要です。

2.エラーシナリオは明らかではありません。

log.error("nc has exist, nc ip" + request.getIp());

NCはすでにcreateNcでエラーを検出しました。しかし、現場にエラーログを指定しなかったNCは、エラーが存在すると報告されている理由は、人々は推測しています。

変更することができます

log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());
log.error("[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());

同様のがあります。

log.error("not all vm destroyed, nc id " + request.getNcId());

変更

log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s", vmNames, request.getNcId());

ソリューション：言葉と相まって、またはインターフェイス[名前]を追加すると、エラーメッセージは、理解するために知って、エラー・ログからの直接のエラーメッセージのシーンの前にエラーを示します。

一般的には、インタフェースの実行者は、[名前]を追加することができます知ることができるサービスを加えたときの言葉。

3.コンテンツは、その意味をクリア、または不明ではありません。

if(aliMonitorReporter == null) {
        log.error("aliMonitorReporter is null!");
} else {
       aliMonitorReporter.attach(new ThreadPoolMonitor(namePrefix, asynTaskThreadPool.getThreadPoolExecutor()));
}

読みます：

log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx.");

同様のがあります。

if (diskWbps == null && diskRbps == null && diskWiops == null    && diskRiops == null) {
      log.error("none of attribute is specified for modifying");
      thrownew BizException(DeviceErrorCode.NO_ATTRIBUTE_FOR_MODIFY);
}

変更

log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);

ソリューション：明確に適切にエラー内容を説明します。

4.トラブルシューティングガイドの内容は明らかではありません。

log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));

zkPath？どのようにこの問題を解決するには？私は誰に行くべき？どこより具体的な手がかりを見つけるには？

解決策：適切な背景知識や大手調査対策を追加します。

エラーが具体的かつ詳細な内容ではありません。

if (!ncResourceService.isNcResourceEnough(ncResourceDO,    vmResourceCondition)) {
      log.error("disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());
      thrownew BizException(ResourceErrorCode.ERROR_RESOURCE_NOT_ENOUGH);
}

正確に十分なリソースは何ではないのですか？どのくらいの経常黒字？どのように多くなりましたか？それは少しのパフォーマンスに影響を与える可能性があり、何かの余分な操作を行うためにそれらを識別するために、ことは注目に値します。この時間のトレードオフ性能およびデバッグ。

解決策：プログラムまたは特定の場所で明らかな違いとして、スキルを向上させることにより、操作する手動アラインメントを減らします。

読み取り6.半分英語の文は、一緒に作品完全な意味を考える必要性を理解するための明確で十分ではありません。

log.warn("cache status conflict, device id "+deviceDO.getId()+" db status "+deviceDO.getStatus() +", nc status "+ status);

読みます：

log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc.", deviceDO.getId(), deviceDO.getStatus(), status));

ソリューション：変更自然に読める英語の文。

要約すると、エラーログ形式が指定できます。

log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].");
log.error(String.format("[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].", params));

若しくは

log.error("[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].");
log.error(String.format("[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].", parameters));

[おそらく理由] [おそらく行う必要がある]は、いくつかのケースでは省略されてもよい。いくつかの重要な場面とのインタフェースに最もよく説明しています。

各エラー・ログには、独立している理由は、どのような施策や工程を採用することに何によって引き起こされ、任意のシナリオの下で何が悪かったのか、可能な具体的かつ直接的な命令と完全なように。

問題：

1.String.format性能が遊び、それをログに影響を与えるのだろうか？

一般的には、エラーログが比較的小さくすべきであり、使用String.Formatの頻度が高くなりすぎない、とアプリケーションログには影響しません。

2.開発時間は、言葉はあなたが裁量に時間を持って、非常に緊張しているのですか？

書式セットに標準化されたコンテンツのフォーマット、コンテンツを確立し、あなたは裁量の時間の単語を保存することができます。

3.場合は、情報を使用して警告、エラーには？