记微服务架构下日志聚合服务的优化

项目背景：现项目主要是做关于机器人的调度系统，涉及到web端、移动端、小程序及服务端和实体机器人端；

迭代背景：微服务架构，每个功能模块单独一个服务，该架构下日志查询

记录方向：微服务架构下日志聚合优化；

记录时间：20200201

====================================================================

1、环境介绍：

现项目使用的微服务架构，编排工具使用的K8s，集群调度，集群可视化管理工具为：rancher；现项目有两个集群环境：

a、主要是开发工具集群环境；

• 日志服务：fluent-bit+loki+grafana；
• 开发工具依赖工具：ldap（轻型目录访问协议）、rancher（可视化集群管理工具）、zookeeper（负载均衡）
• 各种代理：nginx等服务、mongodb复制集主备处理（以前策略是主从模式，官方不推荐）；
• 各种系统服务：
• 各种开发工具：yapi、nexus（maven私服）；

b、环境集群：dev、sit、uat；

• 每个环境部署业务服务：每个服务为一个微服务，服务与服务之间采用服务调用；

2、问题：

在微服务架构下，每个服务模块一个服务，在这种架构下，每个微服务的日志是独立的，一旦出现问题需要查原因的时候只能去每个微服务下查询日志，排查效率低下，无法快速

定位到问题出在哪一个微服务下；尽管项目架构中做了一个网关服务，所有的服务调用都要经过网关服务，部分问题会上报在网关服务中，在网关服务模块可以查询到相关日志，但是一些

内部报错是无法上报在网关服务中的，也无法查询到所有的日志报错信息。

3、方案

基于此，后端准备搭建一套日志聚合服务，将所有服务的日志统一收集统一展示；

=================================================================

日志聚合服务实现

1、实现方案：fluent-bit+loki+grafana，属于轻量级的日志聚合框架；自己在查看的时候看到一个ELK的框架（Elasticsearch，Logstash和Kibana），后端说该框架占用系统资源过多，现目前项目的集群框架就只有

6台服务器集群在一起的，无法支持该ELK，就选取了轻量级的fluent-bit+loki+grafana框架；

2、fluent-bit+loki+grafana框架部署

 目前没有对这套框架进行模拟搭建，只是了解了整个框架的结构以及部署方案；

2.1、fluent-bit安装方式：https://mp.weixin.qq.com/s?__biz=MzI3NTEwOTA4OQ%3D%3D&chksm=f31a59bac46dd0ac040f75d4851ac1890d0ed9f18b95756eb93bce0405fb6b968f241fc08ddc&idx=1&mid=2649177140&scene=21&sn=dc0ce9c007aaacadd8a66e3f5bc907bb#wechat_redirect

2.2、loki+grafana安装：https://blog.51cto.com/anfishr/2511063

备注：该套框架后续使用自己的云服务器来进行搭建；