JAVA微服务场景下分布式日志收集排查问题实战

问题产生的根由？不同服务的日志存在哪里？我们怎么去排查线上问题？

问题场景：我们部署的java服务可能有几十个，不同的项目里面他是看不到别的服务的日志，只有服务的返回msg消息，相比传统的单体服务来说，排查问题和解决问题的原因相对比较复杂和麻烦，我们传统的单体项目的日志存txt文本，log文件，但是项目日志的文件太大了，几个G，十几个G的时候去打开日志特别慢，很不方便。

那么处理这种日志应该怎么做和设计一个日志搜索呢？

传统的解决办法，数据库记录错误日志，es索引写入，页面搜索，写硬盘定时清理，但是日志不仅仅分系统日志，服务日志，还有业务逻辑操作日志，系统日志等，从而加大了我们存储日志的内存空间和复杂度。

下面给大家讲解微服务下日志怎么使用，怎么查问题。

日志方案：

方案一：分布式日志搜集：ELK+kafka 或者ELK 这是最传统的方式。

方案二：filebeta+logstatsh+ES+web  这钟方式处理的日志一般是网络处理，filebeta支持大量批量文件读取和操作，从而大大加快文件写入，因为filebeta不存在数据会丢失的情况。

方案三：微服务网关拦截：统一请求分发，每一个请求抓取服务的日志返回和信息，写入硬盘或者表中，定时数据清洗。当然实际开发当中没有这么用，这种方式不推荐。

方案四：阿里云日志搜集：日志服务 SLS (我相信很多企业目前都是在用阿里的sls，因为用起来比较方便，我们只关心服务的部署，阿里云帮我们做日志搜集，其实日志和ELK类似都是走索引写入查询)

方案一和方案二 和方案三是目前企业用的比较多的，当然一个是花钱一个是自己搭建的，花钱的肯定用起来方便。

我们今天就实践操作讲解一下阿里云的日志服务 SLS怎么使用和查日志。

看这个图 来说这个是目前我们生产环境的sls日志服务查询出来一个月的日志量，那一般企业的日志量我相信过亿就不错了，这个是目前12百个服务部署到阿里云k8s容器上面。所以日志量很大。

下面我们来看sls日志如何使用操作？

搜索方式支持和数据库一样的操作，可以模糊查询和精确查询日志，不是等值查询，或和且的方式都可以。

 阿里云日志查询语法：

查询语法 (aliyun.com)（可以参考阿里云的语法使用）

我们按照服务名称或者ip + id编号，筛选时间或者搜索指定打印指定的日志名称。

服务名称 + 后台日志搜索  

这里由于有敏感数据就不贴出来了，搜索方式是这样，如果你想要统计分组也是可以的。

服务名称 + 后台日志+ 日志关键词+like+ 分组

服务名称 and api auth-center  response  or LIKE memberId GROUP unionId 

基于这种查询就能查到具体的日志输出了，如果你要聚合统计，你可以添加预查询

 预查询的方式就是message: returnMessage  这样

上下文浏览：

 上下文浏览代表是程序从上往下执行，那么0的下标代表当前位置，负数代表程序上面，正数代表程序还在往下面执行，排查问题的时候每一步都会有记录，这个很关键。也是能够快速排查到问题原因的。

当然还有一些日志统计，报表的，都可以通过控制台去处理筛选查看：

 日志聚类：

 

日志智能聚类（LogReduce）功能能将相似度高的数据聚合在一起，提取共同日志Pattern（模式），快速掌握日志全貌

主要功能和特性：

• 支持任意格式日志：Log4J、Json、单行（syslog）
• 亿级数据，秒级出结果
• 日志经任意条件过滤后再Reduce
• 对Reduce后Pattern，根据signature反查原始数据
• 不同时间段Pattern比较
• 动态调整Reduce精度

主要应用场景：

• DevOps（问题定位、异常检测、版本回归等）
• 安全、入侵检测

计费标准：

开启“日志聚类”功能后，索引总量会增加原始日志大小的10%

其实开启过后就是增加指定日志的聚合并且持久化操作，反正费用是不能少的

监听事件查询：

监听索引字段的事件查询，主要是以阿里云的字段

 

 

当然还有数据加工的我就不演示了。

下面我们讲重点：其实sls服务也有查询不到问题的时候，那是必然的，你说你日志看到了但是没有看到别的服务的调用链路，这是关键，每一条执行日志都有一个 tid,tid是什么？tid就是链路调用的tranceid和spanId ，微服务分布式调用链路追踪请求服务的时候会传一个tranceid 从而帮助我们排查问题。

我们可以通过Sleuth + Zipkin 追踪日志记录。

我们这里采用Skywaking 。

 

https://github.com/apache/skywalking

感兴趣的可以去看看

搜索某一个错误的日志 

 

 

原理也是通过tranceId去查询调用链路，服务的链路。 从而判断这个服务的接口是否成功，这样我们整个链路就可以知道哪里出了问题了。 Zipkin也是通过tranceId去查询日志。原理都是一样的。

 当然也可以java服务集成日志写入到es里面进行查询，通过服务名称，渠道，时间，log日志级别做成web页面查询也是可以的。

 ————没有与生俱来的天赋，都是后天的努力拼搏（我是小杨，谢谢你的关注和支持）