浅显地聊一聊中小公司的日志系统与Tracing（中）

嗨，大家好，我是谢顶道人 --- 老李。

我发现了一个过于牛逼的事实，那就是距离本篇文章的（上）已经过去一年多了：

所以今天本人火急火燎提着裤腰带火速赶稿，但是今天这篇如果要写，我就不得不提一下我的前老板 --- 原上草，他比较牛逼或者说过于牛逼。今天这个中篇，就是我和原上草不得不说的故事。

今天主要是由原上草主演，我打个配合。大家应该还记得，很久之前大约在几年前的一篇文章里我提过原上草，当时他跟我聊关于进化的事儿，他的理论大概意思就是：因为外星生物一般都是高等生物，而高等生物形象往往都没有头发，而他也碰巧认为头发是没有用的，并且他自己也碰巧没有头发，所以他自认为他是一个提前完成进化的高等生物。

同时原上草还有另外一个推论：因为头发或者毛发类等物质并不能留下化石证据，同时他又认为恐龙四肢发达头脑简单，不是高等生物，最终他大胆地猜测恐龙有很大概率是长头发的。

经过了这几年的深思熟虑后，我现在对于原上草的这个推论是不置可否的，甚至有些嗤之以鼻：难道说根据「三人行必有我师」和「一日为师终身为父」两条就能叠加推理出「三人行则必有我爹」？

但是对于某些领域，我是认可原上草的或者非常跟随认同的，毕竟是我前老板，对我而言犹如启蒙恩师。就比如说，他就对「系统可观测性」这个领域有着较高水平的认识。

我们差距在哪儿呢，在于我就知道一个TraceID和Log，别的就不行了，而他长年沉浸于Log + Trace + Metric所组成的「系统可观测性」领域中。他曾经有过几句名言对我影响颇深：

一、Log是查某一个非常非常具体的问题用的有力工具

二、Trace是可以在众多纷乱的服务中理出拎出一串链路的有力工具

三、Metric是反映某项问题整体变化趋势的有力工具（比如上线后某个接口499率曲线猛增）

但他对我影响最深的那句话是：这三项数据是支撑「系统可观测性」的支柱面，但你要用割裂的眼光去看待他们，那就不如不要搞得这么复杂。如果某一次上线后通过Metric（典型如普罗米修斯）观察发现某个接口的可用性（就是开始出错了）开始降低，然后怎么办呢，开始查日志Log吧，那查到的这些Log是引发这些错误的真正原因吗？那查一下错误的Trace吧，好不容易查到错误的Trace了，那这些错误的Log和这些Trace能对应上吗？...

只有用发展的眼光看问题，才能得到一个有深度的结论，原上草对我最大的影响就是：他试图告诉我当把这三个维度的数据buff叠加到一块儿的时候，才能发挥出一个最狠毒的效果，1+1+1 > 3，而TraceID是这三个buffer叠加起来后的唯一交集。

正确的、符合人性的做法应该是：从某个波动的Metric曲线（有些人叫做尖刺）中直接确定其中的某一条TraceID，然后基于该条TraceID直接查看在链路跟踪Trace系统中所有的Trace元信息（主要是就是包括耗时、Event等等），最后利用TraceID从日志系统中将请求历经的所有系统的日志一次性全部捞出来，此时系统的一切问题将无所遁形，你就是「系统可观测性界」的「瞄人缝」！在部分一线大厂的日志搜索平台中，一条traceid甚至可以直接搜出链路信息+系统日志+业务日志所有元素，并且有序的、按照大小子集方式呈现出来。

说到这里，也就是说我们进行工程设计的时候，要遵循的第一个大的原则就是Trace组件一定要对外暴露获取traceid和spanid的接口；第二个大的原则就是traceid和spanid同时要被注入到上下游系统中，而且需要横跨http、gRPC、Thrift甚至是原生TCP服务，同时还要具备从每次请求中获取traceid与spanid的方法；第三个大的原则就是Log组件需要具备将traceid与spanid注入到日志的能力，包括系统日志与业务日志（这两个定义的详情参考上篇）；最后一个原则就是重要的Metric指标中，Metric组件要具备将traceid注入到其中的能力，同时与span之间通过tag去关联。

简单总结一下，做到上述要求需要涉及到的工程组件有：

1、一个对外暴露获取traceid与spanid的Trace组件

2、一个横跨多语言多协议的网络请求组件与解析组件，这个组件需要具备向下游发起请求时注入trace信息的能力，同时下游服务收到请求后需要具备从请求中解析出trace信息的能力。举个例子，上游为php-fpm，下游为golang Gin，那么需要php中的http client组件需要具备注入Trace信息的能力，而在golang Gin中，需要具备解析Trace信息的能力

3、一个可以将trace信息注入到所有日志中的Log组件

4、一个可以将trace信息注入到metric信息中的Metric组件

好了，文章到这里，符合人性的用法、工程复杂程度与实现综合成本已经一目了然了，下面还有几点faq或者常见不合理想法：

1、有了Trace组件就不需要用Log组件了，把日志往trace里灌就行。这个想法是美好的，可惜Trace组件是要设置采样率的，不可能每次请求都会采样，采样100%你这业务系统就啥也别干了，专注采样一百年就行了。

2、Log组件与Trace组件割裂用。简单说就是各玩各的，原来有一套日志组件，每天哐哐哐堆一坨日志收集到日志系统中；然后后来脑门一拍又搞了一套Trace组件，然后各用各的。查完日志再去搜Trace，就这还不一定把两边查询到的数据串联到一块儿去。这是目前最典型的错误用法，不如不用。

系统可观测性，想说爱你并不是很容易的事。

在这里，我还是想多说几句，对于所有中小规模公司而言，其实重要性优先级应该是：Log > Trace > Metric。如果你阅读过（上）篇，就应该知道首先很多公司的日志系统压根可能就没有利用好，渣一样的日志没有任何意义，查询也很渣。我的意思其实是如果能单纯把日志系统利用充分了，乱七八糟的Trace/Metric对于中小公司而言可能是可有可无的事情。所以说建设优先级上说，如果贵公司日志系统都没有做好用好，就先不用火急火燎引入Trace/Metric，引入这些是为了更快速更高效更彻底解决业务系统问题的，如果不能达到上述目标，就是捣乱。

在这里还是再友情提示一下，关于一个完善的日志系统中，最恶心其实不是Log组件，也不是向日志种注入trace信息，更不是日志信息格式化，而是日志的存储与查询。很多小公司会选择自建ELK，不过在这里我要提醒一下各位可以考虑下各家云服务商的日志托管服务，没准你会发现成本会远远低于自建ELK，而且查询效率非常高。

话说回来，假如我们百人研发团队级别就一定要上全了这种三位一体，不可以吗？

虽然这玩意复杂、成本高，那就不搞了吗？此时老李就价值就来了，老李就最擅长从以前大厂偷经验后改造削减后搞适合中小公司的野鸡方案，毕竟是过过草地、上过雪山、背行军锅的男人。老李攒出来的这种野鸡方案就像德三儿二战时期的犀牛反坦克炮，浑身上下都是东拼西凑，但是凑出来的玩意还是是个王者。犀牛反坦克的核心就是德三儿的88毫米反一切炮，那老李这个野鸡方案中的88毫米炮是什么呢？终于可以请出来我们今天的主角了：Opentelemetry。

但是想必有很多朋友可能直接阅读这篇突然就幡然醒悟了，踏马的没想到成本这么高，现在只想好好地改造一下现有的日志系统，那么请挖坟去年的《浅显地聊一聊中小公司的日志系统与Tracing（上）》。

今天不写了，顶不住了。