业务日志输出规范
日志文件规范
1.1. 日志文件命名
日志文件名格式：logName_YY-MM-dd_hh.[ roll count].log
示例：sdk_2020-09-03_11.0.log
1.2. 日志滚动大小
日志文件大小等于100M，须日志滚动
由于Linux对于小文件存在Inodes限制，所以对于日志量较大，开启INFO等较低级别日志，若日志大小设置较低，将会产生大量【roll count】，造成Inodes报警。
1.3. 日志文件存放
日志文件统一保存在业务软件服务器的数据盘目录下的logs目录中。
示例：
sdk服务的服务器数据盘符为/data，则日志将存放在/data/logs/{appid或域名}目录中。
同机器nginx日志将会放置在/data/logs/nginx
好处，统一日志存放路径非常有利与后续运维自动化，否则每个程序日志采集端都要自定义不同的日志路径，非常不利于运维自动化的体系建设
日志内容规范
2.1. 组件编码(appID)
组件编码为业务软件标识，用于ELK系统搜索指定业务模块日志使用，该值全局唯一。
2.2. 时间戳(@timestamp)
日志产生的时间，推荐使用时间标准：Time_ISO8601。其中，yyyy代表四位数年份，MM代表两位数月份，dd代表两位数日期，HH代表两位数小时时间，mm代表两位数分钟时间，ss代表两位数秒时间，Time_zone代表时区。
@timestamp=“yyyy-MM-ddTHH:mm:ss+Time_zone”
示例：@timestamp=“2020-09-03T14:34:15+08:00”
2.3. 日志级别(level)(极其建议遵守)
日志级别
级别描述
信息类别
FATAL
业务软件发生严重错误，服务被终止或者重启，需要立即被处理。
错误日志信息日志
ERROR
业务软件发生错误，后续流程还能继续进行，但也已经影响了用户的正常访问。该级别的错误也需要马上被处理。
错误信息日志
WARN
有潜在风险的、不会造成大危害的错误，需要开发人员给予足够关注，往往表示有参数校验问题或者程序逻辑缺陷。
错误信息日志
INFO
在正常运行状态中，粗粒度的、关键流程/事件、业务软件重要的配置和参数信息，可用来表示业务软件健康度的信息
一般信息日志
DEBUG
对调试(debug)有帮助的信息、事件，默认情况下不打开日志记录。
调试信息日志
2.4. 日志字段
由于新的ELK架构建立字段时采用json格式，所以须统一指定日志内容字段格式，以实现ELK接收日志方案的统一化。
{"@timestamp": "2020-09-03T14:34:15+08:00", "appID": "sdk", "level": "INFO", ....}
2.5. 必要字段
每条业务日志须包含以下字段：组件ID(appID)、时间戳(@timestamp)、日志级别(level)。
研发注意事项
时间戳字段名必须为@timestamp，时间输出规范为time_iso8601。举例："@timestamp": "$time_iso8601"
整体日志输出每一条必须json可以直接转化，统一日志输出日志名，统一日志存放路径，统一日志字段格式。
日志等级(level)要逐渐有严格的等级评估意识，科学使用WARN，INFO等级别，后续可以针对针对日志级别出现次数进行统计监控预警，以及时优化代码，非常有利于提升程序健壮性，以免长期出现问题不能发现积累酿成灾难事件
