現在、嵐でコードレベル、されているキャッチ例外は唯一の仕事は抗チェックサーバーの問題分析に行きます、最終的な原因は明白な状況をログに記録する、開発者に通知するのは初めてではないので、フォローアップは、コードと例外処理を最適化するために、不利。
しかし、それはまた、以下のスキームによって解決することができます
1.書き込みInfluxdb方法を監視することで埋設した後、Grafanaによってアラームが、アプリケーションとデータベースは、多くの圧力の原因となります
2.電子メール警告を直接SMTPAppenderのlog4j2を通じて、この方法は、あなたが直接設定を変更することができ、比較的簡単ですが、比較的単純なアラームモードでは、それは、可能な場合オフフックメールボックスのエラーの数が多いです
3.私たちも助けKafkaAppenderカフカへの非同期書き込みをログに記録することができ、カフカを入力した後、我々は零細企業のレベルに応じてその他のニュース多様化警報SMS、電話、メール、消費、他方では、要約階ストレージをログに記録することができます（たとえば、 ES）、以降の処理を容易にします。このアプローチは、アクセス、他のアプリケーションのエンド消費者側の統一治療への取り組みが必要です
第三の実施形態増加に直接配置log4j2 / work.xmlファイル
<アペンダ>
<カフカ名= "kafkaLog" トピック= "トピック" ignoreExceptions = "false" に>
<PatternLayoutはパターン= "アプリケーション名_ | _ [％P] _ | _％のlogger_ | _％のD {YYYY-MM-DD HH：MM：SS、SSS} _ | _％M％N" />
<プロパティ名= "bootstrap.servers">カフカ地址</プロパティ>
<プロパティ名= "max.block.ms"> 2000 </プロパティ>
</カフカ>
<RollingFile名= "failoverKafkaLog" fileNameに= "/データ/ログ/ストーム/ failoverKafka / request.log" filePattern = "/データ/ログ/ストーム/ failoverKafka /要求％D {YYYY-MM-DD} .logに">
<ThresholdFilterレベル= "INFO" onMatch = "ACCEPT" onMismatch = "DENY" />
<PatternLayoutは>
<パターン> storm_ | _ [％P] _ | _％のlogger_ | _％のD {YYYY-MM-DD HH：MM：SS、SSS} _ | _％M％N </パターン>
</ PatternLayoutは>
<ポリシー>
<TimeBasedTriggeringPolicy />
</ポリシー>
</ RollingFile>
<フェイルオーバ名= "フェイルオーバー" 主= "kafkaLog" retryIntervalSeconds = "60">
<フェイルオーバー>
<AppenderRef REF = "failoverKafkaLog" />
</フェイルオーバー>
</フェイルオーバー>
</アペンダ>
<ロガー>
<AsyncLogger名= "com.xxx" レベル= "INFO" 加法= "false" に>
<アペンダ-REF REF = "フェイルオーバー" />
</ AsyncLogger>
<ルートレベルは= "警告"> <！ - 私たちはすべてをログ - >
<アペンダ-REF REF = "kafkaLog" />
</ルート>
</ロガー>
テスト環境：
1.ライティングプログラムの嵐、受信したメッセージを直接出力するログ
2.クライアントがメッセージのビンを生成/ kafka-console-producer.sh --brokerリストXX.XX.XX.XX：9092 --topic運河テスト
3.クライアント消費ログトピックビン/ kafka-console-consumer.sh --bootstrapサーバXX.XX.XX.XX：9092 --topic stormlog
参考住所：http://logging.apache.org/log4j/2.x/manual/appenders.html#KafkaAppender