转转发布系统问题排查实战

排查分布式系统问题用的最多的手段就是查看系统日志，但是目前分布式系统都是部署在多台机器上且多数调用链路比较长，因此日常工作过程中经常出现研发人员同时登录多台机器切换各个终端查询日志的场景。我们希望搭建一个日志收集及查询系统，方便定位问题。

针对转转发布系统，搭建日志系统的主要原因包括：

• 目前公司内部分布式链路跟踪系统仅支持java服务，但是发布系统部署服务涉及java开发的发布系统后端服务和go语言开发的发布代理服务，因此采集全量的全链路的日志数据存在困难。
• 分布式服务部署在多台机器上，有的大流量服务甚至需要部署在几十台服务器上，目前公司共运维数千台机器，日常查询每台机器的部署日志都需要单独申请权限后登录机器查询，整个查询流程比较长，操作比较繁琐。

本文以转转发布系统的服务上线部署过程为例，介绍原始问题排查的复杂度以及现在的解决方案。

转转发布系统的springboot服务上线部署过程为例，部署服务的过程分为备份旧版本服务、下载新版本程序包、解压程序包、初始化机器环境、下线部署机器的nginx配置、部署启动新版本服务、上线部署机器的nginx共7个步骤，其中每个步骤的处理过程需要发布系统向代理服务发布命令，代理服务接到命令后运行机器上相应脚本完成操作后通知发布服务处理结果，发布服务根据处理结果确定是否继续发布流程。如果线上部署某个步骤出现问题，需要登录发布服务机器和部署目标机器分别查询日志。为了解决这个问题，我们调研了业界的日志系统方案，搭建了一套日志收集和查询系统。

日志系统搭建及接入

日志对于开发和运维同事排查定位问题来说至关重要，能够及时有效地搜索是日志系统的核心要求，业界各种商业和开源的日志解决方案有很多，在开源领域中ELK Stack可以说是一枝独秀，ELK中的E指的就是Elasticsearch，Elasticsearch是一个可伸缩的开源分布式实时搜索与分析引擎，它基于Apache Lucene之上提供了全文搜索能力、多语言支持、强大灵活的查询语言以及RESTful API等功能，结合实际需求我们搭建了一套以es为核心的近实时日志系统。java开发的发布服务通过client上报数据到日志系统，go开发的代理服务通过http接口方式上报数据，完成全链路的数据收集并通过kibana检索展示还原整个部署过程。

应用实践

数据索引字段及主要含义如下：

GET zzdeploylog/_mapping

下图展示了通过任务唯一id查询单个服务部署上线的整个流程，展示了每个步骤执行的命令参数及处理结果等相应数据，简化了以前登录各个机器查日志的流程，可以方便快捷的定位问题。

结语

目前发布系统问题排查效率已得到较大提升，后续考虑将docker机器部署的日志也收集到日志系统方便更加全面的查询。此外es集群稳定性、集群运维以及索引数据归档等方面仍然需要日常人为干预，期待公司统一运维的集群早日上线，后续其他业务系统可以统一接入，不断提高工作效率。最后，欢迎各位提出宝贵的意见和建议。