日志的分类
首先往大的来说,日志分2种
①业务日志: 即业务系统需要查看的日志, 常见的比如谁什么时候修改了什么.
②参数日志: 一般是开发人员遇到问题的时候定位用的, 一般不需要再业务系统里展示.
对于业务日志, 我们现在基本确定” 业务日志是业务” 这么个准则, 即业务日志应该跟随着业务表走.
比如你一个订单的操作日志, 那么订单表再哪它就应该在哪, 业务日志应该要跟着你的业务操作同生共死(事务性), 基于上述理念所以业务日志我们不会用table存
对于参数日志, 我觉得这个说是后端开发人员的撕逼生命线毫不为过, 但是同时由于参数日志其实并不属于业务的一部分(完全没有这玩意,业务也是能跑的转,业务系统也不会显示这些信息)
所以很多时候除开发人员之外的其它利益相关方其实并不在意是否有这个参数日志, 甚至不少入门级开发人员也无法理解其重要性.
而且参数日志拥有单位价值低, 但是总量却及其庞大的特点, 也因为这个特点导致数据库那边的人(比如DBA)一般也挺抗拒这个的.
而我们用Table最主要就是解决参数日志的问题.
日志存储体系设计理论
首先一个大原则是我们希望业务日志和参数日志是能串通起来, 比如你进行了这个业务操作并且有了这个业务日志, 那么我要能回溯到执行这次业务操作的相关参数.
常规的想法是参数日志里存一个业务主键
但是订单表的话你存订单号, 用户表的话你存用户Id, 然后再来个别的业务又要存一个别的主键, 其实这挺不好扩展的, 然后参数日志就会变得乱七八糟, 另外你就算存了订单号你也没法和业务日志能直接的join出来(一般会匹配下2个日志的操作时间人肉来看)
而我们用Application Insights来作为主力监控, 我们发现它能够把一个请求/依赖项/异常等信息串联在一个列表里 参见： 统一的跨组件事务诊断
我们就很好奇它是怎么做到的，然后特地扒了一下它的SDK
发现在不同年代AppInsights通过不同的机制生产了一个在当前请求操作内的Id，然后用于各个操作之间进行关联，分别是通过：
1.早期的AppInsights里（Net 4.6之前）是通过CallContext
2.Net 4.6以后是通过AsyncLocal
3.现在NetCore年代则通过Activity
然后它Id分3个，一个是Id自身，一个是ParentId，一个是RootId
这个属于分布式追踪的内容，里面包含相对较多知识点这里就不展开太多了，具体可以看Github上微软对于Activity的用户手册里有详细描述 Activity User Guide
AppInsights这个算是给了我较大的启示，于是乎我就在想，如果我的业务日志也存下它的那个Id，然后我的参数日志也存这个Id
那么我就拥有了一个和业务无关的统一关联Id（而不是存各个业务表的业务主键），同时我甚至能实现类似它的那个“事务诊断”那样的体验，我通过一个业务日志的数据能迅速关联到我的参数日志的记录
扯了那么多，具体怎么做
首先对于如何记录参数日志这件事，比较笨的办法可能是如下这样
厉害点的人可能会把这个步骤放到Filter里
但是，拜托，都2021年了，我们来点稍微主流靠谱点的技术吧。
我们是使用了abp的，我觉得里面的Audit（审计日志）特性就蛮不错，我们就是通过这个来记录日志。
参考文档 审计日志
我们只需要重写一下它的 IAuditingStore（里面只有个SaveAsync方法）
然后在需要的地方打上[Audited]即可
Abp的审计日志本质是基于Castle的动态代理（DynamicProxy）来实现了AOP，然后它能获取到一个方法调用的入参/出参/执行时间/异常信息/方法名等各种信息，我们只要重写下告诉ABP怎么存就可以了
所以记录日志的时候只需要打一个特性（而且和Filter不同的是我这个特性可以打在任何基于接口获取的Public的方法里，而不局限于Controller里）
规范业务日志表
为了配套参数日志，我们也规范了业务日志表的存储。
业务日志一般会有2种比较常见的存储模式
①新值旧值得存储
②完全拷贝修改前的记录进行完全存储
我这边的业务日志一般是： 原始业务表的数据Copy + 日志创建时间 + 操作人 + 操作Id + （可选）操作类型（一般是一个枚举）
至于怎么Copy原始业务表，AutoMapper映射下不要太简单
然后结合下上面的理论篇，我们这里需要获取到一个操作Id用于接下来和参数日志关联。
在现在Core的年代下直接用Activity即可
在你请求进来的时候它默认就已经构造了，并且能确保当前请求内是唯一，Activity生成的Id也是符合opentelemetry规范的分布式追踪Id
其他一些APM工具（比如我用的AppInsights）现在它内部的追踪Id也都是基于这套来进行运作
如何存参数日志
首先结合之前说到参数日志的特点，量大，单位价值低
之前我们没更好的存储介质的时候也是直接存数据库里，然后DBA就经常跟我们说这个太大了，要定期清理下，然后我们大概是3周一清
如果一个问题潜伏3周以上对我们就是个麻烦事了
而且也因此导致我们对存储参数日志也比较谨慎（稍微量上去了就会叫）
所以我们认清了如下几个基本事实：
①关系型数据库是属于昂贵存储，它应该存储的是价值高的昂贵数据
②数据必须分层，高价值的和低价值的分开
在结合下前面我们提到的基于一个分布式追踪Id的日志设计体系，所以还要提供不低于1个索引能力的查询支持
后面我们就用上了Azure Table Storage
具体Table是什么我之前有一篇文章有简单介绍 Azure Table Storage 简单介绍
我们把分布式追踪Id作为PartitionKey，其他abp里能提供的数据统统塞Table里
最后的代码大概是这样
里面折叠的那个FillAudit方法
经过上述设计，我们整个日志现在基本就玩的比较转，一旦有什么问题，我们先查询业务日志，然后可以通过任意一条业务日志在关联到参数日志定位到当时是什么参数进来的，由此提升排查问题的速度
Note：可能有些眼尖的人会发现我的Async的方法没await，经过测试证明Table那边的调用可以FireAndForgot的，而且基本上也不会丢数据，So这不是Bug或者疏忽，是故意的，反而那个Catch可能是一句无效代码
多说几句
上面我重写Audit的是每次来一个请求我就往Table存一条记录，如果是面向高并发接口（比如查询类的接口）
上面我所说的这个做法会让你死得很惨
正确做法应该是：
将数据先在本地内存缓存一段时间后，当达到某个时间阈值或者数据量累计到一定程度再发送
这个做法背后还是蛮复杂的，不过当年我们再琢磨这个东西的时候发觉我们用的AppInsights的SDK里也有这个玩意，我们直接拿出来稍微定制了下后发觉还真能用。
有兴趣可以看看appInsights相关的代码 传送门
你只要想办法重写下它的Send方法，那么它就能为你所用了。