随笔分类
线上日志
概述
排查线上问题时,通过日志去定位问题是常使用、也是最有效的手段
线上服务出于高可用等目的,通常会引入多个节点进行部署,并且随着项目的庞大复杂起来,进而会转去使用微服务架构,而我们知道,一个请求进来,最终只会被一台线上机器所部署的服务消费,so,当去排查线上问题时,我们并不知道请求命中的是哪一个机器,我们只能注逐一去登陆机器,查看报错 log,这实际上是非常繁琐且低效的
因此,我们希望能够有一个统一的实时日志服务,能够去收集所有线上机器上的日志,并且能够去提供灵活高效的查询服务,一般而言,对于其的要求:
-
稳定、采集:
能够去采集多个来源的日志数据,并且能够将这些日志数据稳定传输到日志服务上去
-
存储:
能够去存储海量的日志数据
-
查询:
能够去提供灵活高效的日志查询服务,并且具有一定的分析能力
-
告警:
能够提供告警功能,即时通知开发和运维
为什么线上日志服务会与全文搜索引擎关联?其实很简单,服务所打印的日志,如果不通过全文搜索引擎去搜寻,我们搜索日志数据时的条件又该怎样?这种 case下,也只有全文搜索引擎能够满足我们的需求
目前,线上日志服务使用得最多的其实还是 ELK,ElasticSearch、LogStash、Kibana
再简单介绍下:ElasticSearch是一个全文搜索以及分析引擎,LogStash是一个服务器端数据处理管道,其会去采集来自多个源的日志数据,转换数据,然后将数据传输到诸如 ES等存储库中去,Kibana可以让用户在 ElasticSearch中使用图表对数据进行可视化
因此,在采集日志数据时,我们需要在服务器上安装一个 LogStash,但 LogShash本身是基于 JVM的重量级采集器,对系统的 cpu、内存、IO等资源占用比较高,这可能会影响到系统上其它应用的使用,因此可以考虑 Beats - 基于 Go的采集器,对系统资源的占用可以就忽略不计,Beat平台提供了集成了很多单一用途数据采集器,其能从成千上百机器、系统上收集数据并且向 LogStash、ElasticSearch上传输数据
待补充