springboot日志管理（springboot日志管理保存到数据库）

日志技术-SpringBoot使用日志

tips：Ctrl + F快速拿亏定位所需内容阅读吧。

注意： SpringBoot默认的日志门面是slf4j-api，日志实现是logback-core，是 SLF4J 加 Logback 的组合。

1、快速入门

1、自定义logger对象日志级别

2、指定控制台输出消息格式

[%-5level] %d{yyyy-MM-dd HH:mm:ss} %c [%thread]=== %m%n

[左对齐5：日志级别] 日期：年-月-日 时:分:秒 类信息 [线程信息]=== 日志信息 换行

3、指定存放日志文件的具体路径

Ⅰ 指定路径及文件名形式： logging.file.name=/logs/springboot.log；

Ⅱ 指定日志存放路径，使用默认文件名spring.log： logging.file.path=/logs/

4、指定配置

给类路径下放上每个日志框架自己的配置文件，SpringBoot就不使用默认配置。

此处我们已Logback为例，如下：

可以看到，此时控制台输出的日志为红色，日期格式也多了毫秒，符合logback.xml配置，如下：

5、使用SpringBoot解析日志配置（灵活切换环境配置）

非常关键的一点，需要使用 logback-spring.xml 、 log4j2-spring.xml 命名的配置文件才能生效。

以下案例我们以logback-spring.xml为例，如下：

在appender内的encoder属性中我们配置了 springProfile 相关的喊顷内容。

如消渗神何我们dev的配置 [%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} %c %M %L [%thread]--- %m%n" ，如下：

6、将日志切换为log4j2（经常使用）

Ⅰ 排除 Logback 的日志实现： spring-boot-starter-logging ；

Ⅱ 使用 log4j2 的日志启动器： spring-boot-starter-log4j2 。

以上即为SpringBoot使用日志的全部内容，感谢阅读。

springboot标签体系怎么建立

Spring Boot的标签体系可以根据不同的业务需求建立。以下是一些建议：

1. 技术类型标签：将标签按照技术类型划分，比如“数据库”、“web框架”、“缓存”等等。这样，用户可以根据技术类型快速找到自己需要的标签。

2. 功能类型标签：将标签按照功能类型划分，比如“安全认证”、“日志管理”、“任务调度”等等。这样，用户可以根据自己的功能需求找到需要的标签。

3. 适用场景标签：将标签按照适用场景划分，比如“移动端”手嫌、“Web端”、“微服务”等等。这样，用户可以根据自己的业务场景找到需要的标签。

4. 版本标签：将标签按照版本划分，例运薯中如Spring Boot 2.0、Spring Boot 1.5等等。这样，用户可以根据版本找到自己需要的标签。

5. 热门标签：将标签旁山按照热度排序，将热门的标签展示在前面，方便用户快速找到最常用的标签。

建立标签体系时需要根据业务需求和用户体验来考虑，同时也需要不断进行优化和调整，以提高标签的查询效率和用户体验。

Spring Boot配置保存日志文件

springboot日志配置：

名称只要是一 logback开头就行，测试使用log.xml并不会生成日志。合法名称：logback.xml 、logback-spring.xml

备注：要配置logback-spring.xml，springboot会默认加载此文件，为什么不配置logback.xml,因为logback.xml会先application.properties加载，而logback-spring.xml会后于application.properties加载，这样我们在application.properties文中设置日志文件名称和文件路径才能生效

2、编写xml文件内容：

上述配置的编码中，对应符号的含义如下

在当前文件夹下会创建一个【poslog/2020-10/22】的文件夹，里面会按天生成日志：【2020-10-22.log】，例如：

备注：发现使用这个默认不用配置pom依赖，最新的spring-boot-starter-web中已经集成了。

总结：启动一个项目源备，直接将logback-spring.xml文件复制到resources目录下就可以实现液洞日志文件记录。非常方便。

分类logback.xml配置：

日志配置到d盘了

还可以在application.yml中配置

配置info就只有info以上日志才会输出

如果配置 com.example: debug ，那么雹埋毁我们项目com.example包里面debug以上的日志也会输出。

springboot 动态日志管理（actuator）

引入依赖

配置文件添加

management.endpoints.web.exposure.include= loggers

之后访问

即可看或搭到每个文件的日志级别

查看配梁某个目录的日志级别

]( {目录名}

可以配置指定目录的衫卖拿日志级别

post请求修改指定目录日志级别：

{目录名}

请求提

再次查看此目录的日志级别发现已被修改

]( {目录名}

SpringBoot接入轻量级分布式日志框架（GrayLog）

在文章正式开始之前，我分享下我以前负责过的一个系统，它的架构如下：

每次当我查问题的时候，我都能把问题初步定位在 逻辑层 ，但为了能给业务方交代，我需要 给证据 业务方面（日志信息就是铁证）。

一个请求肯定是被这8台机器内的某一台处理，但具体是哪一台，我不知道。所以，我需要上每台机器上 grep 一把日志，然后才能找出对应的日志证明我的分析。

有的时候，可能 接入层 也需要一起参与进去，就排查一个问题，人都傻了了（翻看日志的时间占用了太久了）。

后来啊，看了同事的骚操作（在 item2 编写脚本： 快速登录堡垒机 （免去输入账号和密码信息），根据应用服务器数量来切割窗口并且切禅陵颤换到对应的日志目录）。说白了就是 一键登录 多台应用服务器。嗯，这查日志的速度比起以前又快了好多。

再后来，公司运维侧又主力推在 Web页面 上登录应用服务器（ 自动登录堡垒机 ），这能省去编写脚本（ 支持批量操作 ）。但从当时的体验上，没有问题 item2 访问得流畅（总感觉卡卡的）。

不过还有问题，因为我们在很多时候是不知道在 info / warn / error 哪个文件下。很多时候只能一个一个文件去查，虽然说可以直接查 通配符汪唤 一把查，如果日志过大，带来停顿时间也挺烦的。

系统一旦被问到业务问题，查日志的频率实在是太高了。于是我在某个Q规划的时候是想自己把日志信息写入到 搜索引擎 ，顺便学习下搜索引擎的知识。然后这个规划被组内的某个大佬看到了，在底下评论： 要不来试试Graylog ？

原来组内本身就在维护了一个 日志框架 ，只是我不知道...于是我接入了 Graylog 日志，工作效率杠杠提高了， 凭借这个事情吹了一个Q 。

自从接入了之后，我就没登录过应用服务器了，有次差点连 grep 都不会写了。

说起ELK，即便没用过肯定也听说过这玩意了，在后端是真的流行。这次austin接入一个比较轻量级的ELK框架： Graylog

这个框架我感觉蛮好用的，作为 使用方 接入起来 异常简单 （我估摸运维应该也挺简单的，很多用Graylog是直接发UDP到Server，不用在机器上装agent收集日志）

官方文档：

据我了解，有相当多的企业使用它来 查看日志和业务监控告警 ，这篇文章我就直接让你们体验体验吧。

老样子，直接上docker-compose，如果一直跟着我的步伐，应该对着不陌生贺败了。 docker-compose.yml 的内容其实我也是抄官网的，这里还是贴下吧（就不用你们翻了）

这个文件里唯一需要改动的就是 ip （本来的端口是 9000 的，我由于已经占用了 9000 端口了，所以我这里把端口改成了 9009 ，你们可以随意）

嗯，写完 docker-compose.yml 文件，直接 docker-compose up -d 它就启动起来咯。

启动以后，我们就可以通过 ip:port 访问对应的Graylog后台地址了，默认的账号和密码是 admin/admin

随后，我们配置下 inputs 的配置，找到 GELF UDP ，然后点击 Launch new input ，只需要填写 Title 字段，保存就完事了（其他不用动）。

嗯，到这里，我们的GrayLog设置就完成了。

还记得我们 austin 项目使用的日志框架吗？没错，就是logback。我们要把日志数据写入Graylog很简单，只需要两步：

1、引入依赖：

2、在 logback.xml 配置graylog相关的信息：

在这个配置信息里，唯一要改的也只是 ip 的地址，到这里接入就完毕了，我们再打开控制台，就能看到日志的信息啦。

懂点GrayLog查询语法：这块我日常来来去去其实就用几个，我来展示下我平时用的吧。如果觉得不够，再去官网文档捞一把就完事了：

1、根据字段精确查询： full_message:"13788888888"

2、查询错误日志信息： level_name:"ERROR"

3、组合多字段查询： level_name:"INFO" AND full_message:"13788888888"

在接入的时候，仔细的小伙伴可能会发现我这边在Input的时候选择的是 GELF ，然后在引入Maven依赖的时候也有 GELF 的字样。那 GELF 是啥意思呢？

这块在官网也有给出对应的解释： The Graylog Extended Log Format (GELF) is a log format that avoids the shortcomings of classic plain syslog

详细资料：

GELF 是一种日志格式，能避免传统意义上的 syslogs 的一些问题，而我们引入的Maven依赖则是把日志格式化成 GELF 格式然后append到GrayLog上。

前几天有个老哥在GitHub给我提了个 pull request 关于 swagger 的，我昨天把他 merge 了，也升级了下 swagger 的版本。

之前我没用过 swagger 类似的文档工具，就这次 pull request 我也去体验了下 swagger 。

在初次的体验感觉是不错的：它能把项目的所有接口的 文档信息 都能在一个页面上 统一管理 ，并且就能直接通过 样例参数 直接发送请求。通过注解的方式来进行编写文档，也不用担心代码改了然后忘了更新文档这事。

但是，后来我配置好对应的参数信息文档，再在 swagger-ui 体验了下， 发现是真滴丑 ，看到这 ui 我还是阶段性放弃吧。

swagger 的竞品还有好几个，我看 ui 貌似都要比 swagger 好看。不过，austin项目的 主要接口就只有一个 ，我作为熟练掌握的 markdown 工程师能轻松胜任文档工作，就没再继续体验别的竞品了。