其实理解起来比较简单，类似于我们平时一直在使用的logback、log4j这种的日志框架的其中一个功能部分，minbox-logging分布式日志框架目前独立于api-boot-plugins，已经加入了minbox-projects开源组织，之前博客有一系列的文章来讲解了ApiBoot Logging（内部是集成的minbox-logging）日志组件的使用以及极简的配置方式，可以访问ApiBoot 组件系列文章使用汇总了解日志组件的使用详情。
ApiBoot Logging Admin支持界面可视化查看请求日志信息，初期版本支持查看上报日志的服务列表、最新的链路日志等功能，还可以整合Spring Security配置用户名、密码
在上一篇文章【{% post_link apiboot-logging-using-openfeign-transparent-traceid %}】中我们详细的讲解了ApiBoot Logging整合SpringCloud通过Openfeign进行透传链路信息，包括traceId（链路编号）、parentSpanId（上级单元编号）等信息。
ApiBoot Logging不仅仅可以使用Openfeign传递链路信息，还支持RestTemplate方式，本篇文章来详细的讲解下具体的使用方式。
ApiBoot Logging可以无缝整合SpringCloud来采集请求日志，目前支持RestTemplate、Openfeign两种方式，我们本章来讲解下在使用Openfeign完成服务之间请求相互调用的一条链路请求日志是否可以都采集到。
ApiBoot Logging支持整合服务注册中心（Eureka、Consul、Nacos Discovery、Zookeeper...）进行上报请求日志，Logging Client会从服务注册中心内找到指定ServiceID的Logging Admin具体可用实例，通过SpringCloud Discovery内部的负载均衡策略返回Logging Admin的部署服务器IP以及端口号，这样Logging Client就可以完成请求日志的上报流程。
ApiBoot Logging在上报日志时虽然是一般通过内网的形式部署，不过安全方面还是主要依赖于服务器的安全策略（防火墙），为了提高日志上报的安全性，ApiBoot Logging支持了整合Spring Security来使用Basic Auth的形式上传日志信息。
ApiBoot Logging会为每一个请求都对应创建链路编号（TraceID）以及单元编号（SpanID），用于归类每一次请求日志，通过一个链路下日志单元的Parent SpanID可以进行上下级关系的梳理。
通过ApiBoot Logging可以将每一条请求的详细信息获取到，在分布式部署方式中，一个请求可能会经过多个服务，如果是每个服务都独立保存请求日志信息，我们没有办法做到统一的控制，而且还会存在日志数据库与业务数据库不一致的情况出现（可能会用到多数据源配置），正因为这个问题ApiBoot Logging提供了一个Admin的概念，将客户端采集到的的每一条日志都进行上报到Admin，由Admin进行分析、保存等操作。
ApiBoot Logging通过集成minbox-logging来进行管理每一次请求的日志信息，包含头信息、参数、主体内容、路径、发生的服务器相关信息等，根据接口的响应状态还可以记录响应的头信息、响应的内容以及发生异常时的堆栈信息。