日志

关于日志

通常日志指的是系统日志和程序日志。

系统日志 是记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。用户可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。系统日志包括系统日志、应用程序日志和安全日志。

程序日志 是程序运行中产生的日志，通常由框架运行时或开发者提供的日志。包括请求日志，异常日志、审计日志、行为日志等。

日志作用

日志在调试，错误或者异常定位，数据分析中的作用是不言而喻的。

• 调试 在项目调试时，查看栈信息可以方便地知道当前程序的运行状态，输出的日志便于记录程序在之前的运行结果。

• 错误定位 不要以为项目能正确跑起来就可以高枕无忧，项目在运行一段时候后，可能由于数据问题，网络问题，内存问题等出现异常。这时日志可以帮助开发或者运维人员快速定位错误位置，提出解决方案。

• 数据分析 大数据的兴起，使得大量的日志分析成为可能，ELK 也让日志分析门槛降低了很多。日志中蕴含了大量的用户数据，包括点击行为，兴趣偏好等，用户画像对于公司下一步的战略方向有一定指引作用。

日志级别

级别	值	方法	描述
Trace（跟踪）	0	LogTrace	包含最详细的消息。 这些消息可能包含敏感的应用数据。 这些消息默认情况下处于禁用状态，并且不应在生产中启用。
Debug（调试）	1	LogDebug	用于调试和开发。 由于量大，请在生产中小心使用。
Information（信息）	2	LogInformation	跟踪应用的常规流。 可能具有长期值。
Warning（警告）	3	LogWarning	对于异常事件或意外事件。 通常包括不会导致应用失败的错误或情况。
Error（错误）	4	LogError	表示无法处理的错误和异常。 这些消息表示当前操作或请求失败，而不是整个应用失败。
Critical（严重）	5	LogCritical	需要立即关注的失败。 例如数据丢失、磁盘空间不足。

如何使用

• _logger.LogInformation("GET Pages.PrivacyModel called.");
• 懒人模式
• "简单日志".LogInformation(); "新增了一条记录".LogInformation(); "程序出现异常啦".LogError(); "这是自定义类别日志".SetCategory("类别").LogInformation();

审计日志

通常来说，我们审计日志更多指的是数据库的操作记录。

打印方式

• 本地化
• ELK、SkyWalking
• Console

打印方案

ELK 、SkyWalking 异常，自动本地化记录

日志层级

日志规格

1. 一天一个文件
2. 每个文件最大50MB，超出大小后在所有文件名后自动增加正整数重新命名
3. 超过30个文件后 自动删除之前的文件

日志格式

名称	类型	描述
id	String	日志的唯一id
dateTime	DateTime	当前时间
traceid	String	后文会讲到
spanid	String	后文会讲到
level	String	INFO、WAR、ERR
appName	String	应用名称
userid	String	用户名称
moduleid	String	模块标识(借出模块、归还模块)
threadName	String	线程名称
className	String	日志记录器名称
logMessage	logMessage	日志消息体

名称	类型	描述
action	String	该条日志处于什么动作（请求前、请求中、请求后）
message	String	手写信息
sysMessage	String	系统信息

• traceid 为什么需要traceid，为了查看完整的调用链，一旦调用过程中出现问题，可以第一时间定位到问题现场

整个调用链是一棵树形结构，traceid的传递涉及到主干与支干，进程内与进程外

• spanid

spanid 代表本次调用在整个调用链路树中的位置

哪个环节生成

• traceid 生成规则 产生规则是： 客户端、服务端 IP + UserID + 当前时间戳

比如：

0ad1348fC4836DA8B4214717B5C773E99802F8A91618385153

1. 前 8 位 0ad1348f 即产生 traceid 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143
2. C4836DA8B4214717B5C773E99802F8A9 为用户的GUID(UUID)去掉中横杠（-）
3. 1618385153 为时间戳

• spanid 生成规则

  假设一个业务系统A接收了一次请求（请求自带请求头spanid=0）

  那么在业务系统A的日志中，记录下的 spanid 是 0，如果需要通过 依次调用 B、C、D 三个系统，那么在 B、C、D 三个系统的服务端日志中，spanid 分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的客户端日志是 0.2.1 和 0.2.2，E、F 两个系统对应的服务端日志也是 0.2.1 和 0.2.2。

根据上面的描述可以知道，如果把一次调用中所有的 spanId 收集起来，可以组成一棵完整的链路树。