原标题：软件开发中日志的使用
一、 谁需要日志?
开发者
通过日志能够方便的帮助我们排查和定位问题。
其次线上问题很难重放，用户基本都不懂技术，往往表述一般都会失真。
定时任务日志，能够提醒我们任务的运行状态。
运维人员
整个系统大部分时间都是运维人员来维护，日志可以帮助运维人员来了解系统运行状态，运维人员发现日志有异常信息也可以及时通知开发来排查
运营人员
电商的转化率、视频网站的完播率、普通PV数据等都可以通过日志进行数据统计分析。
安全人员
虽然大多数企业不重视安全，但是安全也可以通过日志来进行预警，比如某个用户突然大额转账、再比如数据库突然出现大量无条件分页查库(拖库)等等。
异常的网络请求，非法参数的请求探测等，都可能通过一定的风控规则，即使告知安全组或者研发岗位。
二、日志有几种?
调试日志 用于开发人员开发或者线上回溯问题。
诊断日志 一般用于运维人员监控系统与安全人员分析预警。
埋点日志 一般用于运营决策分析，也有用作微服务调用链路追踪的(运维、调试)。
审计日志 与诊断日志类似，诊断日志偏向运维，审计日志偏向安全。
三、日志打印的8种级别
OFF | 关闭：最高级别，不打印日志。
FATAL | 致命：指明非常严重的可能会导致应用终止执行错误事件。
ERROR | 错误：指明错误事件，但应用可能还能继续运行。
WARN | 警告：指明可能潜在的危险状况。
INFO | 信息：指明描述信息，从粗粒度上描述了应用运行过程。
DEBUG | 调试：指明细致的事件信息，对调试应用最有用。
TRACE | 跟踪：指明程序运行轨迹，比DEBUG级别的粒度更细。
ALL | 所有：所有日志级别，包括定制级别。
所以，日志优先级别标准顺序为：
ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF
四、最佳实践
1 合理地记录信息，不要滥用日志。
大量无用的内容都记录到日志中，使得日志文件的体积越来越大甚至撑爆磁盘，所以我们要针对性的使用日志，例如错误异常日志，请求日志，三方系统对接的发送和回传日志等。
对于那些像SQL执行日志，调试日志，在特殊场景下，可以临时开启。 但不建议长期开启，高并发的系统中，会很快打满磁盘空间。
对于外部系统调用需要记录任务请求前包括入参信息，请求成功后返回成功的信息，请求失败或者异常后重点要记录异常堆栈信息或者失败信息。
2 结构化
日志不能太随意，否则在大量的数据记录里检索想要的数据如同大海捞针。每行记录的数据要使用同一个固定结构。例如自定义标准的文本结构。或者采用约定好的Json结构。固定接口可以很方便的进行解析和数据分析，让检索变得有效而且容易些。
日志记录要高效且有效。有些数据建议必填，例如时间点(业务点)，发生时间，发生结果(执行结果)，以及上下文信息(例如订单号，机构码，详情简述或者关联点)等。
简要异常推送示例：
运行环境：{?}
项目名称：{?}
报警时间：{?}
当前客户：{?}
客户编号：{?}
访问路由：{?}
请求参数：{?}
文件路径：{?}
错误行号：{?}
错误信息：{?}
错误追踪：{?}
业务日志可选字段示例
trace_id 跟踪Id
[app_name] 业务线或者模块(根据架构设计决定)
Host,server_ip
service_name或者url
request_params
request_time
request_body
response_params
response_time
response_body
form_string 参数可以是get，post或者文件流方式
context_message
3.不要影响系统性能
尽可能地用异步方式记录日志，日志甚至能直接写入本地日志文件或使用日志传输工具传输至你所选择的日志服务。
使用队列也可以作为记录日志的选项，但请记住，在查看日志时可能存在延迟。
日志记录频率越高，越影响系统性能。
4 日志的分析
简单的日志可以通过程序进行分析，存储，将结果展现出来。
复杂的日志可以采用一些开源系统进行处理。例如elk , loki。
5 日志监控。
1 防止日志过大，导致磁盘空间不足影响其他业务。
2 如果采用队列中转日志的话，要监控日志的消费速度，防止大量堆积，影响关键业务。
参考：
https://blog.csdn.net/qf2019/article/details/104245782
http://jalan.space/weekly-translation/other/follow-these-logging-best-practices-to-get-the-most-out-of-application-level-logging-slides.html