MinBox Logging
是由minbox-projects
開源組織推出的一款零侵入分佈式鏈路日誌組件,可用於微服務、RPC、單體應用使用。java
MinBox Logging
內存在兩個概念,分別是:Client
、Server
。git
Client數據庫
Client
咱們能夠理解爲日誌的採集端,也就是咱們的業務服務端,你的服務須要記錄日誌就能夠理解做爲Client
端。json
Serverapi
Server
是日誌的管理服務端點,提供日誌的存儲、閥值分析提醒(暫未發佈)、鏈路分析(暫未發佈)等功能,統一接收日誌採集端上報的請求日誌信息並作記錄,目前支持寫入數據庫、自定義存儲機制,下一步整合消息隊列
來處理大批量日誌的存儲問題。服務器
服務端經過整合
服務註冊中心
能夠完成負載均衡多節點部署。負載均衡
MinBox Logging
能夠用來記錄你的應用程序請求日誌信息,能夠將發起請求的IP
、頭信息
、URL參數
、請求主體參數
、耗時
、響應內容
、異常堆棧信息
等。curl
下面是MinBox Logging
能夠獲取到的基本信息,以下所示:分佈式
{
"endTime":1568252359448,
"httpStatus":200,
"requestBody":"",
"requestHeaders":{
"accept":"*/*",
"host":"localhost:40030",
"user-agent":"curl/7.54.0"
},
"requestIp":"10.180.98.120",
"requestMethod":"GET",
"requestParam":"{}",
"requestUri":"/open/system/time/current",
"responseBody":"{\"code\":\"SUCCESS\",\"data\":1568252359425,\"errorMsg\":\"\",\"success\":true,\"timestamp\":1568252359425}",
"responseHeaders":{},
"serviceId":"bff-open-api",
"serviceIp":"10.180.98.245",
"servicePort":"40030",
"spanId":"56aaa01c-cad5-41c6-bd46-bf94626d77bd",
"startTime":1568252359416,
"timeConsuming":32,
"traceId":"ad9ff32c-6195-4f75-adf2-1eb1ed98aaf9"
}
複製代碼
以上信息是由MinBox Logging
進行在控制檯格式化並打印輸出(前提:配置輸出日誌參數),咱們能夠經過MinBox Logging
提供的日誌通知接口來實現本身的業務邏輯,詳見org.minbox.framework.logging.client.notice.LoggingNotice
源碼。ide
Client
採集的每一條請求日誌都會攜帶產生的服務器IP
、應用程序名稱
、應用程序端口號
而且一併上傳到Server
,根據這些內容能夠直接定位到日誌的來源位置,可根據Client
上報的數量進行佔比分析,來決定服務請求分發負載均衡權重配置。
每一次請求都會產生耗時,而接口耗時過長,可能會致使接口阻塞(若是應用程序沒有加入熔斷機制),針對這個問題MinBox Logging
提供了計算耗時的方式,經過MinBoxLog#timeConsuming
字段獲取本次請求的耗時時間,單位是:毫秒
,根據本身的業務自定義一個耗時閥值來進行通知耗時過長的請求給指定郵箱
或者其餘途徑。
若是在用戶請求過程當中遇到了異常信息,而應用程序的控制檯日誌文件過大進行篩選異常信息時會耽誤必定的時間,針對這個問題MinBox Logging
提供獲取請求中遇到異常的堆棧信息
,經過異常信息能夠精準的定位出現異常的代碼位置。
用戶發送的請求參數,咱們沒法進行限制,不過咱們能夠進行參數監控,經過制定參數對應的參數值來進行分析、監控,將分析結果經過存儲或者通知方式告知。
與請求參數
一致,經過請求頭信息咱們一樣能作的事情有不少。
經過這個功能,咱們能夠記錄每個發起請求的IP地址
接口訪問量、訪問的頻率、峯值等信息。
等待發掘合適的業務.
日誌信息在Client
、Server
均可以獲取,拿到請求日誌信息後,能夠實現上面的擴展功能。
在Client
端能夠經過LoggingNotice
方式來獲取MinBoxLog
日誌對象,根據對象的字段值來進行處理分析等業務,可建立多個LoggingNotice
實現類來分析處理不一樣的業務,優先級根據LoggingNotice#getOrder
方法的返回值而定。
/** * 自定義日誌通知 * 當不上報日誌到`Logging Admin`時,可以使用{@link LoggingNotice}來進行本地處理日誌 * 上報日誌與本地處理不衝突,可並存 * * @author 恆宇少年 */
@Component
public class CustomerLoggingNotice implements LoggingNotice {
/** * 通知方法 * * @param minBoxLog ApiBoot Log */
@Override
public void notice(MinBoxLog minBoxLog) {
System.out.println(minBoxLog.getTraceId());
// MinBoxLog 對象即爲控制檯打印的json信息,能夠拿到裏面的所有字段內容
}
/** * 通知執行優先級 * {@link #getOrder()}方法返回值值越小優先級越高 * * @return */
@Override
public int getOrder() {
return 1;
}
}
複製代碼
經過
notice
方法的參數能夠直接獲取到MinBoxLog
對象,可根據參數值進行自定義業務判斷處理。
建議在Server
端進行日誌統一處理,雖然Client
能夠經過實現LoggingNotice
接口來擴展日誌處理,不過也是針對單個Client
應用程序,對於分佈式微服務應用程序來講卻顯得那麼的無力。
由於每一個Client
都會進行上報到Server
,因此在Server
進行日誌處理是最好的選擇。
Server
能夠經過監聽ReportLogEvent
事件來獲取Client
的基本信息以及上報的日誌列表
(若是Client
配置了延遲上報,每次可上報多條。),以下所示:
/** * 自定義上報日誌事件{@link ReportLogEvent}監聽 * * @author 恆宇少年 */
@Component
public class CustomerReportEventListener implements SmartApplicationListener {
/** * logger instance */
static Logger logger = LoggerFactory.getLogger(CustomerReportEventListener.class);
/** * 判斷事件類型爲{@link ReportLogEvent} * * @param eventType * @return */
@Override
public boolean supportsEventType(Class<? extends ApplicationEvent> eventType) {
return ReportLogEvent.class == eventType;
}
/** * 自定義處理業務 * Client一次可上報多條日誌{@link MinBoxLog}信息 * * @param event {@link ReportLogEvent} */
@Override
public void onApplicationEvent(ApplicationEvent event) {
ReportLogEvent reportLogEvent = (ReportLogEvent) event;
LoggingClientNotice loggingClientNotice = reportLogEvent.getLogClientNotice();
// MinBoxLog 日誌列表
List<MinBoxLog> logs = loggingClientNotice.getLoggers();
logger.debug("上報日誌服務:{},IP地址:{},端口號:{},日誌列表:", loggingClientNotice.getClientServiceId(),
loggingClientNotice.getClientServiceIp(),
loggingClientNotice.getClientServicePort(),
logs);
}
}
複製代碼
SmartApplicationListener
是Spring
提供的事件監聽接口,因爲該接口繼承了Ordered
因此擁有了#getOrder
方法,經過該方法能夠調整自定義日誌監聽
的執行優先級。
使用文檔地址:gitee.com/minbox-proj…
ApiBoot最佳集成實踐源碼:gitee.com/minbox-proj…
MinBox Logging Samples:gitee.com/minbox-proj…