安定性の監視とグレーリリースの監視にエラーを使用する方法は？
1。完全性
。2。煩わしさが少ない。3。
差別化可能性
。1。フィルターによるフィルター
。2 。ログ構成とエンコーダーメカニズムによる実現。3 。
キー名（％c小文字） c、大文字の％C、推奨されない、時間がかかる、％methodは推奨されない、時間がかかる）+
（ログバックレイアウトのhttp://logback.qos.ch/manual/layouts。html）1。
エンコーダーを追加します元のpatternEnCoderを置き換えます。1.1rootExceptionクラスとreasonを追加します。1.2元のloggerName1.3 callerClass;
2.2。
悪いケース
<appender name = "STDOUT" class = "ch.qos.logback.core.ConsoleAppender">
<layout class = "ch.qos.logback.classic.PatternLayout">
<pattern>％date [caller =％replace（％caller {1}）{"\ n"、 ""}] [rootEx =％replace（％rEx {0}）{"\ n"、 ""}]] [％level] [％c {0}。％method] [$ {lippi_meetingroom_current_environment}] m =％X {EAGLEEYE_RPC_METHOD}％msg t =％X {EAGLEEYE_TRACE_ID}％n </ pattern>
</ layout>
</ appender>
保護されたロガーロガー= LoggerFactory.getLogger（this.getClass（））;
@Test public void testError（）{logger.error（ "123 {}"、3、new RuntimeException（））; LoggerUtils.error（logger、this.getClass（）、 "test"、 ""、new RuntimeException（））; }
2020-05-02 19：36：47,982 [caller = Caller + 0 atcom.dingtalk.meetingroom.mocktest.manager.meeting。BookingManagerMockTest。testError（BookingManagerMockTest.java:60）] [rootEx = java.lang。RuntimeException：null]] [ERROR] [ BookingManagerMockTest。testError ] [lippi_meetingroom_current_environment_IS_UNDEFINED] m = 123 3 t = java.lang.RuntimeException：null
2020-05-02 19：36：48,015 [caller = Caller + 0 atcom.dingtalk.common.log。LoggerUtils。エラー（LoggerUtils.java:48）]} [rootEx = java.lang。RuntimeException：null]] [ERROR] [ BookingManagerMockTest。エラー] [lippi_meetingroom_current_environment_IS_UNDEFINED] m = [DT_Monitor_V1] result = false、category = BookingManagerMockTest_test、reason =、traceId =、description =、t =
java.lang.RuntimeException：null