日志问题总结

举报
小强聊it 发表于 2024/04/06 00:21:47 2024/04/06
【摘要】 ​ 记录应用系统日志主要有三个原因:记录操作轨迹、监控系统运行状况、回溯系统故障。 记录操作轨迹:可以数据化分析用户偏好,有助于优化系统业务逻辑,为用户提供个性化服务。如:通过access.log记录用户的操作频率和跳转链接,有助于分析用户后续行为。监控系统运行状况:全面有效的日志系统有助于建立完善的应用监控体系。通过应用监控体系,可以实时监控系统运行状况,及时预警,避免故障发送。系统运行状...

 记录应用系统日志主要有三个原因:记录操作轨迹、监控系统运行状况、回溯系统故障。 记录操作轨迹:可以数据化分析用户偏好,有助于优化系统业务逻辑,为用户提供个性化服务。如:通过access.log记录用户的操作频率和跳转链接,有助于分析用户后续行为。监控系统运行状况:全面有效的日志系统有助于建立完善的应用监控体系。通过应用监控体系,可以实时监控系统运行状况,及时预警,避免故障发送。系统运行状况是指服务器的运行状态,如内存、CPU等使用情况;应用运行状况,如接口RT(响应时间)、QPS等。应用错误信息,如NPE、SQL异常、数据转换失败等。回溯系统故障:完整的现场日志方便快速定位问题,并迅速处理

一、日志的记录点要求

在程序执行过程中,以下5类日志记录点必须记录日志:

本系统接受到外部请求时(本地入口);

本系统调用其他模块或系统时(调用其他);

本系统调用其他模块或系统结束时(调用结束);

本系统处理结束时(本地出口);

本系统捕捉到错误时(出错时);

初始化参数时

初始化参数在各种框架里面可以看到一些内容,而在自己开发的业务中则使用打印业务参数阅读相关内容 系统核心角色,组件关键动作 :主要是核心业务的触发动作,但是需要避免非常高频率的打印,同时对于日志进行提炼 上述日志记录点,除出错时,均应该按[INFO]级别登记

二、日志的记录内容规则

应用程序日志原则上使用UTF-8字符编码,以便于将来的日志文件分析。 不要使用系统输出记录日志,如System.out.print, printStackTrace。不能将应用日志写入生产环境基础系统的日志。(如SystemErr.log、SystemOut.log); 日志记录应及时、完整,日志应该符合安全规范,不要在日志信息里包含安全敏感信息,敏感信息主要有客户身份信息如客户账号、名称、证件号、交易核心信息如交易金额、交易备注、安全控制信息如安全认证方式、密码。

1.日志输出不允许影响系统正常运行。

2.日志输出需符合安全审计要求,不允许产生安全问题,不允许输出敏感信息,支持保密机制。

3.日志输出格式严格按照要求、合理的打印信息,如对于交易日志,必须记录,对于程序调试中非关键节点的日志交付前进行删除,无需记录

4.日志输出内容能够提供开发和运维人员快速定位到故障问题原因。

5.日志按照一定的策略支持备份,如日期、时间等。

6.最小10M,缺省情况下,每个日志文件的大小限制为100M,超过限制,则必须写入到另一个带新序号的日志文件中

7.一定要控制日志输出量,以免出现磁盘空间不足。同时要为日志设置合理的生命周期,及时清理过期日志。避免重复打印,务必在日志配置文件中设置additivity=false

三、日志的性能要求

1、输出日志记录不能过于频繁。一般情况下10毫秒内不能输出3条以上日志信息;

2、输出的日志内容不能过长。一般情况下每行日志信息原则上不能超过2K字节,一条日志输出代码产生的日志内容不能超过40行;

3、输出日志信息的函数代码不能包含复杂的CPU计算,导致产生过多的CPU。

4.不建议打印查询list,尤其没有分页的

5.控制日志输出的长度在一定范围内,比如请求参数,避免打印大量的业务日志 如日志layout中 msg配置为 %.-4096msg,输出日志长度最长为4096字节,多余的将从后面截断不打印;

6.【建议】在循环,响应式编程中谨慎log

7.【建议】批量任务,大量mq,不建议每行均打印

8.【建议】gateway等网关中log需谨慎, gateway默认线程数很少,等你打印io线程消耗性能,遇到上传文件+报文解密+打印日志的时候,并发能力下降到2位数

9.【建议】报文加/解密 前后打印log,没必要 和第三方交互时,入参、出参可能是需要加密和解密,如果报文体积较大,明文和密文都打印没有意义,算法测试成功后,个人认为加解密成功的情况下打印明文,计算失败时异常中打印原文即可

10.【建议】如果开源jar包日志需要特别注意 如shardingsphere-jdbc等,需要关闭日志 如无法关闭,可以设置独立的logger,和其他应用日志分开 mybatis,eureka心跳等日志建议分开打印,不要和业务日志混在一起 日志按用途划分,避免业务日志,框架日志,混合,业务日志也应分模块打印: https://www.jb51.net/article/247048.htm,且日志使用rolling进行分割

11.在tps有高要求的场景应该异步打印,参考:https://www.cnblogs.com/yangyongjie/p/16230247.html

四、日志的等级分类

DEBUG 细粒度的、对出错(debug)、以及系统调试时候输出的信息、事件。

INFO 在正常运行状态中,粗粒度的、关于重要流程/事件的、可用来表示系统健康度的信息、事件。在INFO级别不允许把SQL语句、报文等这些作为日志内容输出。

WARN 有潜在风险的、不会造成大危害的错误(往往由应用外部因素造成,如不正确的输入数据)

ERROR 应用发生错误(包括业务错误和技术错误),但后续流程还能够继续进行 FATAL 应用发生严重错误(技术型异常),应用服务被终止。

五、日志的目录和文件名

1.应用日志输出至/app/logs目录下;

2.应用日志文件名以.log后缀结尾;

3.应用日志中每行以[LEVEL][yyyy-MM-dd HH:mm:ss,SSS]开头;

4.把不同类型的日志分离出去,应用中的扩展日志(如打点、临时监控、访问日志等)命名方式: appName_logType_logName.log。logType:日志类型,如 stats/monitor/access/error 等;logName:日志描述。这种命名的好处:通过文件名就可知道日志文件属于什么应用,什 么类型,什么目的,也有利于归类查找。说明:推荐对日志进行分类,如将错误日志和正常 日志分开存放,便于开发人员查看,也便于通过日志对系统进行及时监控。

六、日志的大小

日志文件的大小应该可以通过参数控制(log4j2 可配置),如果超过限制,则必须写入到另一个带新序号的日志文件中,且不能超过本次磁盘预警值: 参考:log4j2官网:Log4j – Log4j 2 Appenders 下面是一个示例配置,它使用滚动文件追加器,其时间和大小都基于时间 触发策略,将在同一天创建最多 100 个存档 (1-100) 存储在目录中 根据当前年份和月份,并将压缩每个 使用 gzip 存档,每小时滚动一次。 在每次翻转期间,此配置将删除与“/app-.log.gz”匹配的文件 并且出生 30 天或以上, 但保留最近的 100 GB 或最近的 10 个文件,以先到者为准 logback:官网:Chapter 4: Appenders 译文:第四章:Appenders - logback 中的maxHistory处 其他注意点:https://www.cnblogs.com/ZTPX/p/14090313.html

七、日志的清理

一般情况下,日志文件按照磁盘预警值和监控组对接需求定时清理一次,移出日志目录; 对于有审计需求的日志,按照审计规定对这些文件进行归档,归档数据转入存储服务器。

八、日志打印注意事项

1.记录异常时一定要输出异常堆栈。如下:logger.error("xxx"+e.getMessage(), e)

2.日志中如果输出对象实例,要确保实例类重写了toString方法,否则只会输出对象的hashCode值。 注:logger应被定义为static,与类绑定,防止浪费资源。 使用slf4j+日志库模式时,要防止日志库冲突,一旦发生则可能会出现日志打印功能失效问题

3.不要在打印日志时造成异常

4.日志框架选型 logback、log4j2 logback:推荐,Springboot默认的日志框架 log4j2:版本大于2.15.0

5.日志格式 日志输出基本格式(有任何需求按规范添加): •pid[级别] [时间][应用名称][调用链标识][调用层级标识][业务标识] [线程名] [线程上线映射变量] [类名] [行号] [日志内容] [换行] 即:[%-5p] [%d{yyyy-MM-dd HH:mm:ss,SSS}] [%t] [%-1X{变量名}] [%C:%L] [%m] %n

6.日志级别得支持动态修改,要么actuator通过post接口动态修改日志级别,要么放到配置中心来修改

7.链路追踪 通过 AOP 切面,日志框架 MDC 等技术结合,在日志中打印traceId,而后根据traceId可检索整个请求链路的日志

1)AOP切面结合MDC方式 ①、日志配置文件中配置traceId占位符 Gherkin <pattern>%date{yyyy-MM-dd HH:mm:ss.SSS}|%t|%-5level|%X{traceId}|%C{0}#%M:%L|%msg%n</pattern> ②、AOP切入要增强traceId的方法 ③、在增强类中往MDC中添加traceId字段,并赋值,并在finally块移除MDC中traceId字段

2)直接使用MDC方式

①、日志配置文件中配置traceId占位符,同上

②、在方法执行业务逻辑前往MDC中添加traceId字段,并赋值

③、在方法返回前移除MDC中的traceId字段

3)在线程池中没采取阿里ttl方式做mdc前线程池必须手动使用mdc打印,防止链路追踪失败

  1. 不要记录异常又抛出 记录之后抛出异常是非常危险的操作,因为外层可能会因为内层捕获异常之后不会再次处理,如果是自定义异常更是难以排查问题,此外这样做法会导致堆栈二次打印,非常浪费系统性能,

  2. 核心功能模块日志 如果是核心功能模块的日志,其实多打印一些内容是可以接受的,但是需要注意打印的日志必须要第一时间可以定位到问题所在。 监控系统集成:建议将日志和监控系统打通,将日志信息传递给监控系统,以便实时监控系统的运行状态和性能指标。

  3. 理想的日志中应该记录不多不少的信息 l 不要在日志中记录无用的信息,实践中常见到的无用的日志有: 1)能够放在一条日志里的东西,放在多条日志中输出; 2)预期会发生且能够被正常处理的异常,打印出一堆无用的堆栈; 3)开发人员在开发过程中为了调试方便而加入的“临时”日志 l 对于日志的使用者,能够从日志中得到所有需要的信息

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。