β

谈服务运行日志记录(10.26)

人月神话的BLOG 9 阅读
对应服务运行日志记录,在前面曾经谈过相关的文章,即给出了服务运行日志,注意包括了服务运行实例和服务运行实例详细输入和输出包括两个方面的内容。因此对于日志记录实际上就涉及到这方面内容如何处理。对于服务运行详细的输入和输出,其中输入本身有包括了我们约定的标准的MsgHeader消息头和详细的业务系统XSD数据结构。对于这个XSD数据结构本身又可能包括了多层结构。

如果从日志记录的完整可配置性来说,最优的方式是可以针对每一个服务单独配置究竟记录哪些内容,即实例日志是否记录?对于输入是否记录,输出是否记录,对于输入和输出中的多层结构本身又记录到那层Segment元素上面。这个一个最理想的实现方案。

服务实例头日志的记录

首先对于服务日志实例头,这个实例我们会记录每次服务调用的消费方,消费方IP,调用开始时间,结束时间,调用的报文量,提供服务的OSB集群节点等关键信息。而我们常说的不记录日志,是指对服务运行详细日志不记录,而对于服务运行实例头日志都记录。

但是最近服务运行监控发现,有个别实时大并发量调用服务,一个服务本身一天的调用量就好几百万次,而其它服务运行次数只有不到10万次。在这种场景下将使整个服务实例头表数据量增长极快。即使现在我们对服务实例头表采用的是按天的分区表记录,但是仍然会发现该表数据增长量极大。估计不到3个月就达上亿条记录。

为了解决该问题有两种方式来处理,即:

1. 可以灵活的配置,实例头也不记录日志

2. 可以针对服务独立配置,对调用量超大的服务,启用独立的实例头记录表,即分表存储

对于第一种情况,如果实例头都不记录日志,基本服务实例就在OSB总线上面存代理调用,我们也无法观察到服务一天调用的详情和次数,如果要统计次数也只有看access.log记录。但是对于这种情况如果有失败和异常调用还是会记录日志。比较好的情况是对于这种情况需要记录下一天调用的总数情况,或者记录下每分钟调用的一个总次数情况。

对于第二种情况,需要独立建新的数据表(也可以是分区表)进行日志记录,因此对于这类特殊情况在服务部署的时候需要将日志信息重定向到一个独立的分区表里面。同时在服务日志查询的时候需要默认不查询这部分日志,如果需要查询大并发服务调用日志,单独启用一个菜单进行查询。

详细输入和输出报文日志记录

对于服务的消息头MsgHeader记录,由于服务规范是统一的,因此这个MsgHeader消息头也是统一的,因此我们可以灵活的配置是否记录这个消息头。但是这个消息头本身信息量并不大,比如只有消费方系统,编码,路由代码,安全校验token等关键信息,而没有具体的业务字段类信息。

对于输入和输出,需要实现能够灵活配置分开记录的功能。

即对于查询类服务,往往都是输入数据量很小,但是输出数据量很大,当查询类服务响应缓慢的时候,如果输入和输出都没有记录日志,那就很难对响应缓慢的服务进行优化和分析,而必须要联系消费端业务系统。因此对于这类服务可以配置为只记录服务输入,而不记录输出。而对于导入类服务正好相反,即为了后续的问题分析排查,可以只记录输出,不记录输入。

但是对于导入类服务的输入信息,如果全部不记录日志,那么在导入出现异常的时候问题排查也相对困难,因此就可以考虑前面提到的可以灵活的配置记录到输入结构的哪层上面。比如对于采购订单导入的四层结构,我们可以配置对于订单头表进行日志记录,而剩余的三层不记录日志。当然要实现这个处理起来会比较麻烦,也会影响到日志分析和记录的性能。

在服务日志记录的时候,如果一个服务调用出现异常,对于这种情况应该是不管是否配置了日志记录,都应该对输入输出报文,实例头日志进行全部记录,以方面后续进行问题分析和排查。

对于Solr全文检索日志记录

对于服务运行实例报文的全文检索记录,也需要做到可以灵活的配置,即针对某个服务是否记录Solr查询日志并建立索引,同时对于特定的服务也需要能够记录,可以灵活的选择输入是否记录,输出是否记录。

如果对于服务异常调用出现,对于该异常调用类情况,为了方便后续的问题排查,最好的方式也是不论针对该服务是否配置了建立索引,都统一记录索引信息。创建全文检索的索引文件相对的耗费存储空间,最怕的就是服务出现某种大并发异常调用,这些调用都是同样的请求大并发反复调用,如果配置了记录索引就会导致索引文件快速增长,而且后续无法针对该服务单独进行清理。

作者:人月神话的BLOG
原文地址:谈服务运行日志记录(10.26), 感谢原作者分享。

发表评论