驚訝！我定的日誌規範被CTO在全公司推廣了

時間 2019-12-25

原文原文鏈接

打印日誌是一門藝術，但長期被開發同窗所忽視。日誌就像車輛保險，沒人願意爲保險付錢，可是一旦出了問題都又想有保險可用。咱們打印日誌的時候都很隨意，但是用的時候會吐槽各類 SB 包括本身！寫好每一條日誌吧，與君共勉！html

日誌

日誌是什麼？

日誌，維基百科的定義是記錄服務器等電腦設備或軟件的運做。java

日誌文件提供精確的系統記錄，根據日誌最終定位到錯誤詳情和根源。日誌的特色是，它描述一些離散的（不連續的）事件。例如：應用經過一個滾動的文件輸出 INFO 或 ERROR 信息，並經過日誌收集系統，存儲到一些存儲引擎（Elasticsearch）中方便查詢。git

日誌有什麼用？

在上文中咱們解釋了日誌的做用是提供精準的系統記錄方便根因分析。那麼具體在哪些具體方面它能夠發揮做用？github
打印調試：便可以用日誌來記錄變量或者某一段邏輯。記錄程序運行的流程，即程序運行了哪些代碼，方便排查邏輯問題。
問題定位：程序出異常或者出故障時快速的定位問題，方便後期解決問題。由於線上生產環境沒法 debug，在測試環境去模擬一套生產環境，費時費力。因此依靠日誌記錄的信息定位問題，這點很是重要。還能夠記錄流量，後期能夠經過 ELK（包括 EFK 進行流量統計）。
用戶行爲日誌：記錄用戶的操做行爲，用於大數據分析，好比監控、風控、推薦等等。這種日誌，通常是給其餘團隊分析使用，並且多是多個團隊，所以通常會有必定的格式要求，開發者應該按照這個格式來記錄，便於其餘團隊的使用。固然，要記錄哪些行爲、操做，通常也是約定好的，所以，開發者主要是執行的角色。
根因分析（甩鍋必備）：即在關鍵地方記錄日誌。方便在和各個終端定位問題時，別人說時你的程序問題，你能夠義正詞嚴的拿出你的日誌說，看，我這裏運行了，狀態也是對的。這樣，對方就會乖乖去定位他的代碼，而不是互相推脫。spring

何時記錄日誌？

上文說了日誌的重要性，那麼何時須要記錄日誌。數據庫

系統初始化：系統或者服務的啓動參數。核心模塊或者組件初始化過程當中每每依賴一些關鍵配置，根據參數不一樣會提供不同的服務。務必在這裏記錄 INFO 日誌，打印出參數以及啓動完成態服務表述。
編程語言提示異常：現在各種主流的編程語言都包括異常機制，業務相關的流行框架有完整的異常模塊。這類捕獲的異常是系統告知開發人員須要加以關注的，是質量很是高的報錯。應當適當記錄日誌，根據實際結合業務的狀況使用 WARN 或者 ERROR 級別。
業務流程預期不符：除開平臺以及編程語言異常以外，項目代碼中結果與指望不符時也是日誌場景之一，簡單來講全部流程分支均可以加入考慮。取決於開發人員判斷可否容忍情形發生。常見的合適場景包括外部參數不正確，數據處理問題致使返回碼不在合理範圍內等等。
系統核心角色，組件關鍵動做：系統中核心角色觸發的業務動做是須要多加關注的，是衡量系統正常運行的重要指標，建議記錄 INFO 級別日誌，好比電商系統用戶從登陸到下單的整個流程；微服務各服務節點交互；核心數據表增刪改；核心組件運行等等，若是日誌頻度高或者打印量特別大，能夠提煉關鍵點 INFO 記錄，其他酌情考慮 DEBUG 級別。
第三方服務遠程調用：微服務架構體系中有一個重要的點就是第三方永遠不可信，對於第三方服務遠程調用建議打印請求和響應的參數，方便在和各個終端定位問題，不會由於第三方服務日誌的缺失變得手足無措。

日誌打印

Slf4j & Logback

Slf4j 英文全稱爲「 Simple Logging Facade for Java 」，爲 Java 提供的簡單日誌門面。Facade 門面，更底層一點說就是接口。它容許用戶以本身的喜愛，在工程中經過 Slf4j 接入不一樣的日誌系統。編程

Logback 是 Slf4j 的原生實現框架，一樣也是出自 Log4j 一我的之手，但擁有比 Log4j 更多的優勢、特性和更作強的性能，Logback 相對於 Log4j 擁有更快的執行速度。基於咱們先前在 Log4j 上的工做，Logback 重寫了內部的實現，在某些特定的場景上面，甚至能夠比以前的速度快上 10 倍。在保證 Logback 的組件更加快速的同時，同時所需的內存更加少。json

日誌文件

日誌文件放置於固定的目錄中，按照必定的模板進行命名，推薦的日誌文件名稱：安全

當前正在寫入的日誌文件名：<應用名>[-<功能名>].log
如：example-server-book-service-access.log
已經滾入歷史的日誌文件名：<應用名>[-<功能名>].yyyy-MM-dd-hh.[滾動號].log

如：example-server-book-service-access.2019-12-01-10.1.log服務器

日誌變量定義

推薦使用 lombok（代碼生成器）註解 @lombok.extern.slf4j.Slf4j 來生成日誌變量實例。

<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.10</version>
    <scope>provided</scope>
</dependency>

代碼示例

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class LogTest {

    public static void main(String[] args) {
        log.info("this is log test");
    }
    
}

日誌配置

日誌記錄採用分級記錄，級別與日誌文件名相對應，不一樣級別的日誌信息記錄到不一樣的日誌文件中。若有特殊格式日誌，如 access log，單獨使用一個文件，請注意避免重複打印（可以使用 additivity="false" 避免）。

參數佔位格式

使用參數化形式 {} 佔位，[] 進行參數隔離，這樣的好處是可讀性更高，並且只有真正準備打印的時候纔會處理參數。

// 正確示例，必須使用參數化信息的方式
log.debug("order is paying with userId:[{}] and orderId : [{}]",userId, orderId);
// 錯誤示例，不要進行字符串拼接,那樣會產生不少 String 對象，佔用空間，影響性能。及日誌級別高於此級別也會進行字符串拼接邏輯。
log.debug("order is paying with userId: " + userId + " and orderId: " + orderId);

日誌的基本格式

日誌時間

做爲日誌產生的日期和時間，這個數據很是重要，通常精確到毫秒。

yyyy-MM-dd HH:mm:ss.SSS

日誌級別

日誌的輸出都是分級別的，不一樣的設置不一樣的場合打印不一樣的日誌。

主要使用以下的四個級別：

DEBUG：DEUBG 級別的主要輸出調試性質的內容，該級別日誌主要用於在開發、測試階段輸出。該級別的日誌應儘量地詳盡，開發人員能夠將各種詳細信息記錄到 DEBUG 裏，起到調試的做用，包括參數信息，調試細節信息，返回值信息等等，便於在開發、測試階段出現問題或者異常時，對其進行分析。
INFO：INFO 級別的主要記錄系統關鍵信息，旨在保留系統正常工做期間關鍵運行指標，開發人員能夠將初始化系統配置、業務狀態變化信息，或者用戶業務流程中的核心處理記錄到INFO日誌中，方便平常運維工做以及錯誤回溯時上下文場景復現。建議在項目完成後，在測試環境將日誌級別調成 INFO，而後經過 INFO 級別的信息看看是否能瞭解這個應用的運用狀況，若是出現問題後是否這些日誌可否提供有用的排查問題的信息。
WARN：WARN 級別的主要輸出警告性質的內容，這些內容是能夠預知且是有規劃的，好比，某個方法入參爲空或者該參數的值不知足運行該方法的條件時。在 WARN 級別的時應輸出較爲詳盡的信息，以便於過後對日誌進行分析。
ERROR：ERROR 級別主要針對於一些不可預知的信息，諸如：錯誤、異常等，好比，在 catch 塊中抓獲的網絡通訊、數據庫鏈接等異常，若異常對系統的整個流程影響不大，可使用 WARN 級別日誌輸出。在輸出 ERROR 級別的日誌時，儘可能多地輸出方法入參數、方法執行過程當中產生的對象等數據，在帶有錯誤、異常對象的數據時，須要將該對象一併輸出。

DEBUG / INFO 的選擇

DEBUG 級別比 INFO 低，包含調試時更詳細的瞭解系統運行狀態的東西，好比變量的值等等，均可以輸出到 DEBUG 日誌裏。 INFO 是在線日誌默認的輸出級別，反饋系統的當前狀態給最終用戶看的。輸出的信息，應該對最終用戶具備實際意義的。從功能角度上說，INFO 輸出的信息能夠看做是軟件產品的一部分，因此須要謹慎對待，不可隨便輸出。若是這條日誌會被頻繁打印或者大部分時間對於糾錯起不到做用，就應當考慮下調爲 DEBUG 級別。

因爲 DEBUG 日誌打印量遠大於 INFO，出於前文日誌性能的考慮，若是代碼爲核心代碼，執行頻率很是高，務必推敲日誌設計是否合理，是否須要下調爲 DEBUG 級別日誌。
注意日誌的可讀性，不妨在寫完代碼 review 這條日誌是否通順，可否提供真正有意義的信息。
日誌輸出是多線程公用的，若是有另一個線程正在輸出日誌，上面的記錄就會被打斷，最終顯示輸出和預想的就會不一致。

WARN / ERROR 的選擇

當方法或者功能處理過程當中產生不符合預期結果或者有框架報錯時能夠考慮使用，常見問題處理方法包括：

增長判斷處理邏輯，嘗試本地解決：增長邏輯判斷吞掉報警永遠是最優選擇拋出異常，交給上層邏輯解決
拋出異常，交給上層邏輯解決
記錄日誌，報警提醒
使用返回碼包裝錯誤作返回

通常來講，WARN 級別不會短信報警，ERROR 級別則會短信報警甚至電話報警，ERROR 級別的日誌意味着系統中發生了很是嚴重的問題，必須有人立刻處理，好比數據庫不可用，系統的關鍵業務流程走不下去等等。錯誤的使用反而帶來嚴重的後果，不區分問題的重要程度，只要有問題就error記錄下來，其實這樣是很是不負責任的，由於對於成熟的系統，都會有一套完整的報錯機制，那這個錯誤信息何時須要發出來，不少都是依據單位時間內 ERROR 日誌的數量來肯定的。

強調ERROR報警

ERROR 級別的日誌打印一般伴隨報警通知。ERROR的報出應該伴隨着業務功能受損，即上面提到的系統中發生了很是嚴重的問題，必須有人立刻處理。

ERROR日誌目標

給處理者直接準確的信息：ERROR 信息造成自身閉環。

問題定位：

發生了什麼問題，哪些功能受到影響
獲取幫助信息：直接幫助信息或幫助信息的存儲位置
經過報警知道解決方案或者找何人解決

線程名稱

輸出該日誌的線程名稱，通常在一個應用中一個同步請求由同一線程完成，輸出線程名稱能夠在各個請求產生的日誌中進行分類，便於分清當前請求上下文的日誌。

opentracing 標識

在分佈式應用中，用戶的一個請求會調用若干個服務完成，這些服務可能仍是嵌套調用的，所以完成一個請求的日誌並不在一個應用的日誌文件，而是分散在不一樣服務器上不一樣應用節點的日誌文件中。該標識是爲了串聯一個請求在整個系統中的調用日誌。

惟一字符串（trace id）
調用層級（span id）

經過搜索 trace id 就能夠查到這個 trace id 標識的請求在整個系統中流轉（處理）過程當中產生的全部日誌。

biz 標識

在業務開發中，咱們的日誌都是和業務相關聯的，有時候是須要根據用戶或者業務作聚類的，所以一次請求若是能夠經過某項標識作聚類的時候，能夠將聚類標識打印到日誌中。

用戶標識（user id）
業務標識（biz id）

日誌記錄器名稱

日誌記錄器名稱通常使用類名，日誌文件中能夠輸出簡單的類名便可，看實際狀況是否須要使用包名和行號等信息。主要用於看到日誌後到哪一個類中去找這個日誌輸出，便於定位問題所在。

日誌內容

禁用 System.out.println 和 System.err.println

變參替換日誌拼接

輸出日誌的對象，應在其類中實現快速的 toString 方法，以便於在日誌輸出時僅輸出這個對象類名和 hashCode

預防空指針:不要在日誌中調用對象的方法獲取值，除非確保該對象確定不爲 null，不然頗有可能會由於日誌的問題而致使應用產生空指針異常。

異常堆棧

異常堆棧通常會出如今 ERROR 或者 WARN 級別的日誌中，異常堆棧含有方法調用鏈的系統，以及異常產生的根源。異常堆棧的日誌屬於上一行日誌的，在日誌收集時須要將其劃至上一行中。

最佳實踐

日誌格式

2019-12-01 00:00:00.000|pid|log-level|[svc-name,trace-id,span-id,user-id,biz-id]|thread-name|package-name.class-name : log message

時間
pid，pid
log-level，日誌級別
svc-name，應用名稱
trace-id，調用鏈標識
span-id，調用層級標識
user-id，用戶標識
biz-id，業務標識
thread-name，線程名稱
package-name.class-name，日誌記錄器名稱
log message，日誌消息體

日誌模塊擴展

日誌模塊是基於如下技術點作擴展的。

Slf4j MDC 實現原理（暫不開展詳解，若有興趣私下溝通）
Opentracing Scope 原理（暫不開展詳解，若有興趣私下溝通）

在每一個 tracing 鏈路中，將 Opentracing Scope 中的上下文信息放置 MDC 中，根據 Spring Boot Logging 擴展接口擴展的取值邏輯 logging.pattern.level 的取值邏輯。

相關源碼參考

Spring Cloud Sleuth

[Spring Cloud Sleuth][https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/log/Slf4jCurrentTraceContext.java](https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/log/Slf4jCurrentTraceContext.java)

修改 logback 配置文件中每一個 appender 的 pattern 爲如下默認值便可實現標準化。

%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}|${PID:- }|%level|${LOG_LEVEL_PATTERN:-%5p}|%t|%-40.40logger{39}: %msg%n

logback.xml 節選

<configuration>
<property name="LOG_PATH"
          value="${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}}"/>

<springProperty scope="context" name="APP_NAME"
                source="spring.application.name" defaultValue="spring-boot-fusion"/>
<!-- 全局統一 pattern -->
<property name="LOG_PATTERN"
          value="%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}|${PID:- }|%level|${LOG_LEVEL_PATTERN:-%5p}|%t|%-40.40logger{39}: %msg%n"/>
<!-- 輸出模式 file,滾動記錄文件，先將日誌文件指定到文件，當符合某個條件時，將日誌記錄到其餘文件 -->
<appender name="fileInfo" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <!--被寫入的文件名，能夠是相對目錄，也能夠是絕對目錄，若是上級目錄不存在會自動建立，沒有默認值。-->
    <file>${LOG_PATH}/${APP_NAME}-info.log</file>
    <!--滾動策略  基於時間的分包策略 -->
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <!-- yyyy-MM-dd 時間策略則爲一天一個文件 -->
        <FileNamePattern>${LOG_PATH}/${APP_NAME}-info.%d{yyyy-MM-dd-HH}.%i.log</FileNamePattern>
        <!--日誌文件保留小時數-->
        <MaxHistory>48</MaxHistory>
        <maxFileSize>1GB</maxFileSize>
        <totalSizeCap>20GB</totalSizeCap>
    </rollingPolicy>
    <!--  layout 負責把事件轉換成字符串，格式化的日誌信息的輸出 -->
    <layout class="ch.qos.logback.classic.PatternLayout">
        <pattern>${LOG_PATTERN}</pattern>
    </layout>
    <!--級別過濾器，根據日誌級別進行過濾。若是日誌級別等於配置級別，過濾器會根據onMath 和 onMismatch接收或拒絕日誌-->
    <filter class="ch.qos.logback.classic.filter.LevelFilter">
        <!--設置過濾級別-->
        <level>INFO</level>
        <!--用於配置符合過濾條件的操做-->
        <onMatch>ACCEPT</onMatch>
        <!--用於配置不符合過濾條件的操做-->
        <onMismatch>DENY</onMismatch>
    </filter>
</appender>
</configuration>

代碼使用示例：

@Override
public Result<PagingObject<SimpleResponse>> page(@RequestParam(value = "page-num", defaultValue = "1") int pageNum,
                                                 @RequestParam(value = "page-size", defaultValue = "10") int pageSize) {
    LogStandardUtils.putUserId("userId123");
    LogStandardUtils.putBizId("bizId321");
    producerService.sendMsg("xxx");
    simpleClient.page(pageNum, pageSize);
    return new Result<>(simpleService.page(pageNum, pageSize));
}

日誌記錄

2019-12-04 16:29:08.223|43546|INFO|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.n.u.concurrent.ShutdownEnabledTimer   : Shutdown hook installed for: NFLoadBalancer-PingTimer-example-server-order-service
2019-12-04 16:29:08.224|43546|INFO|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.netflix.loadbalancer.BaseLoadBalancer : Client: example-server-order-service instantiated a LoadBalancer: DynamicServerListLoadBalancer:{NFLoadBalancer:name=example-server-order-service,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:null
2019-12-04 16:29:08.234|43546|INFO|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.n.l.DynamicServerListLoadBalancer     : Using serverListUpdater PollingServerListUpdater
2019-12-04 16:29:08.247|43546|INFO|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.n.l.DynamicServerListLoadBalancer     : DynamicServerListLoadBalancer for client example-server-order-service initialized: DynamicServerListLoadBalancer:{NFLoadBalancer:name=example-server-order-service,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:ConsulServerList{serviceId='example-server-order-service', tag=null}
2019-12-04 16:29:08.329|43546|WARN|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.p.f.l.ctl.common.rule.StrategyRule    : No up servers available from load balancer: DynamicServerListLoadBalancer:{NFLoadBalancer:name=example-server-order-service,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:ConsulServerList{serviceId='example-server-order-service', tag=null}
2019-12-04 16:29:08.334|43546|WARN|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.p.f.l.ctl.common.rule.StrategyRule    : No up servers available from load balancer: DynamicServerListLoadBalancer:{NFLoadBalancer:name=example-server-order-service,current list of Servers=[],Load balancer stats=Zone stats: {},Server stats: []}ServerList:ConsulServerList{serviceId='example-server-order-service', tag=null}
2019-12-04 16:29:08.342|43546|ERROR|[example-server-book-service,ac613cff04bac8b1,4a9adc10fdf0eb5,userId123,bizId321]|XNIO-1 task-4|c.p.f.w.c.advice.ExceptionHandlerAdvice : 當前程序進入到異常捕獲器，出錯的 url 爲：[ http://127.0.0.1:10011/simples ]，出錯的參數爲：[ {"querystring":"{}","payload":""} ]
java.lang.RuntimeException: com.netflix.client.ClientException: Load balancer does not have available server for client: example-server-order-service

日誌服務

SLS 阿里雲日誌服務

阿里雲日誌服務（簡稱 SLS）是針對日誌類數據的一站式服務，在阿里巴巴集團經歷大量大數據場景錘鍊而成。您無需開發就能快捷完成日誌數據採集、消費、投遞以及查詢分析等功能，提高運維、運營效率，創建 DT 時代海量日誌處理能力。

project

項目、管理日誌基礎單元，服務日誌建議一個環境建爲一個 Project，這樣日誌記錄是總體一個閉環，日誌記錄隨整個環境內的服務調用產生。

logstore

日誌庫，日誌庫建議按照日誌類型分爲不一樣的，如特定格式的 access 日誌，以及 info / warn / error 日誌，特定格式能夠配置更爲方面的索引以及告警設置。

注意：請勿按照應用服務區分爲不一樣的 logstore，在微服務架構中，一次請求交叉了多個應用服務，日誌是散落在各個應用服務中的，按照服務區分 logstore，須要開發同窗十分了解應用運行情況和調用拓撲圖，這點每每是不具有的。

實時採集與消費

功能：

經過ECS、容器、移動端、開源軟件、JS等接入實時日誌數據（例如Metric、Event、BinLog、TextLog、Click等）。
提供實時消費接口，與實時計算及服務對接。

用途：數據清洗（ETL）、流計算（Stream Compute）、監控與報警、機器學習與迭代計算。

查詢分析

實時索引、查詢分析數據。

查詢：關鍵詞、模糊、上下文、範圍。
統計：SQL聚合等豐富查詢手段。
可視化：Dashboard + 報表功能。
對接：Grafana、JDBC/SQL92。

用途：DevOps / 線上運維，日誌實時數據分析，安全診斷與分析，運營與客服系統。

消費投遞

穩定可靠的日誌投遞。將日誌中樞數據投遞至存儲類服務進行存儲。支持壓縮、自定義Partition、以及行列等各類存儲方式。

用途：數據倉庫 + 數據分析、審計、推薦系統與用戶畫像。

告警

日誌服務的告警功能基於儀表盤中的查詢圖表實現。在日誌服務控制檯查詢頁面或儀表盤頁面設置告警規則，並指定告警規則的配置、檢查條件和通知方式。設置告警後，日誌服務按期對儀表盤的查詢結果進行檢查，檢查結果知足預設條件時發送告警通知，實現實時的服務狀態監控。

最佳實踐

阿里雲的日誌服務功能至關強大，想用好日誌服務能夠參看：

https://help.aliyun.com/document_detail/29090.html?spm=a2c4g.11186623.6.1079.4edd3aabvs50OW

ELK 通用日誌解決方案

ELK 是 Elasticsearch、Logstash、Kibana 三大開源框架首字母大寫簡稱。市面上也被成爲 Elastic Stack。其中 Elasticsearch 是一個基於 Lucene、分佈式、經過 Restful 方式進行交互的近實時搜索平臺框架。像相似百度、谷歌這種大數據全文搜索引擎的場景均可以使用 Elasticsearch 做爲底層支持框架，可見 Elasticsearch 提供的搜索能力確實強大，市面上不少時候咱們簡稱 Elasticsearch 爲 es。Logstash 是 ELK 的中央數據流引擎，用於從不一樣目標（文件/數據存儲/MQ）收集的不一樣格式數據，通過過濾後支持輸出到不一樣目的地（文件/ MQ / Redis / Elasticsearch / Kafka 等）。Kibana 能夠將 Elasticsearch 的數據經過友好的頁面展現出來，提供實時分析的功能。

實踐說明

普通格式日誌

2019-11-26 15:01:03.332|1543|INFO|[example-server-book-service,28f019d57b8336ab,630697c7f34ca4fa,105,45982043|XNIO-1 task-42]|c.p.f.w.pay.PayServiceImpl     : order is paying with userId: 105 and orderId: 45982043

普通日誌前綴是固定的，能夠固定分詞索引，方便更快的查詢分析。

特定格式日誌

以 access 日誌爲例

2019-11-26 15:01:03.332|1543|INFO|[example-server-book-service,28f019d57b8336ab,630697c7f34ca4fa,105,45982043|XNIO-1 task-42]|c.p.f.w.logging.AccessLoggingFilter     : 
> url: http://liweichao.com:10011/actuator/health
> http-method: GET
> request-header: [Accept:"text/plain, text/*, */*", Connection:"close", User-Agent:"Consul Health Check", Host:"liweichao.com:10011", Accept-Encoding:"gzip"]
> request-time: 2019-11-26 15:01:03.309
> querystring: -
> payload: -
> extra-param: -

< response-time: 2019-11-26 15:01:03.332
< take-time: 23
< http-status: 200
< response-header: [content-type:"application/vnd.spring-boot.actuator.v2+json;charset=UTF-8", content-size:"15"]
< response-data: {"status":"UP"}

特定格式日誌可按格式建立索引更方便聚焦查詢分析和告警，如根據 take-time，http-status，biz-code 等值。