日志与我们日常的项目开发有着密切关系，日志是我们分析和排查问题的重要依据。今天就来简单总结下笔者个人对于项目中日志的一些经验。
日志文件名格式：logname_YY-MM-dd_hh.[roll-count].log
例子：api_2022-06-20_12.0.log
一般要限制每个日记文件的大小，需日志滚动。一般常设置文件大小为 100M。
Linux 对于小文件存在 Inodes 限制，所以当日志量大时，日志文件大小不宜设置的过小，否则将会产生大量日志滚动，造成日志文件过多，造成 Inodes 报警。并且最好定期清理过期的日志文件。
日志文件统一保存在服务器的目录中，这个目录在团队内部最好是固定的，且有一定规律。
例如日志的根目录均为 /data/logs，项目的日志可以放在/data/logs/app/order-service/ 目录下，nginx 的日志可以放在 /data/logs/service/nginx/ 目录下面。
统一的日志存放路径便于后续接入日志平台与运维自动化，否则日志采集程序需要定义不同的日志路径，这将是一件非常复杂且不利于维护的事情。
为每个模块或组件分配一个编号，即 app_id，该值需要全局唯一，便于在 ELK 等日志平台检索指定业务模块的日志。
日志产生的时间，建议使用 Time_ISO8601。其中，yyyy 代表四位数年份，MM 代表两位数月份，dd 代表两位数日期，HH 代表两位数小时时间，mm 代表两位数分钟时间，ss 代表两位数秒时间，Time_zone 代表时区。
1 | @timestamp="yyyy-MM-ddTHH:mm:ss+Time_zone" |
| 日志级别 | 描述 | 类别 |
|---|---|---|
| FATAL | 业务软件发生严重错误，服务被终止或重启，需立即被处理。 | 错误信息日志 |
| ERROR | 业务软件发生错误，后续流程还能继续进行，但已经影响用户正常访问。该级别错误也需要马上被处理。 | 错误信息日志 |
| WARN | 有潜在风险、不会造成大危害的错误，需开发人员关注，一般是程序逻辑缺陷。 | 错误信息日志 |
| INFO | 在正常运行状态中，粗粒度的、关键流程或事件、业务软件重要的配置和参数信息，可用来表示业务软件健康度的信息。 | 一般信息日志 |
| DEBUG | 对调试有帮助的信息或事件，默认情况下不打开日志记录。 | 调试信息日志 |
按照业务要求，打开合适级别的日志记录。同时在代码中记录日志时，level 也要评估好。禁止乱使用 level，无用的数据打入日志。
一般使用 json 格式，主流日志分析平台都支持，且各种程序语言对于 json 格式日志写入也都有很好的库支持。
每条业务日志必须包含的字段： app_id，@timestamp，level。
1 | {"@timestamp": "2022-06-20T03:01:15+08:00", "app_id": "DFNAKLPYH", "level": "INFO", ....} |
对于多系统间调用，还需要至少包含 trace_id 标识，一次完整的调用链路需要传递并记录唯一的 trace_id。
对可能含有敏感信息的文本打入日志要保持敬畏。同时对于进入日志中的敏感信息，要在日志采集器或者日志平台中进行脱敏处理，避免其出现在日志检索中。