最近想把之前做过的日志项目及个人的思考梳理一下,于是有了本文。
我们这边应用部署的环境比较复杂,主要有以下几种:
部署环境不统一,导致查看应用日志很不方便。
与部署环境对应,对于日志收集需求分为以下几类:
具体业务需求可以拆分为:
需求已经明确了,下面看一下业界方案。
上图的架构是业界比较通用的一种架构,对于各种场景都考虑的比较全。
既然业界的架构已经这么完备,那么我们是否就直接采用呢?
对于我们而言,有以下几个问题:
选择组件,我们这边主要是从以下几个方面进行考量的:
Agent
一提到日志收集方案,大家第一个想到的肯定是ELK(Elasticsearch、Logstash、Kibana ),但Logstash依赖于JVM不管是性能还是简洁性,都不是日志收集agent的首选。
个人感觉一个好的agent应该是资源占用少,性能好,不依赖别的组件,可以独立部署。而Logstash明显不符合这几点要求,也许正是基于这些考虑elastic推出了Filebeat。
Collector、MQ
Elasticsearch集群在部署的时候,一般都是提前估计好容量、机器、shard等信息,因为Elasticsearch集群运行后,再水平拓展,比较麻烦,而我们这边由于业务及成本限制无法很好的预估容量,所以就结合公司实际要求:使用日志服务的业务方自带机器,也就是业务方会有独立的Elasticsearch集群。
每个业务方都使用自己的Elasticsearch集群,所以集群压力不会很大,从而Collector、MQ这两个组件对于我们的作用也就很小了。
ETL
因为Elasticsearch Ingest Node完全可以满足我们的解析需求,所以就没有必要再引入Logstash等相关组件了。
到这里,基本可以看出我们的架构如下:
架构设计的几个原则:
基于需求及EFK套件,梳理我们场景中特有的东西:
具体规则及解析见下图(实例部分处理暂未标注):
推荐写日志到文本文件中,使用标准输出就好。
到这里可以发现我们选择Filebeat来作为日志的收集端,Elasticsearch来存储日志并提供检索能力。
那么,日志的清洗在哪里做呢?
日志的清洗一般有两种方式:
对于,我们的场景而言,我们需要清洗数据的要求比较简单,主要是应用、实例名称的截取还有文本日志中日志时间的处理(@timestamp重置,时区处理),所以我们选择了方案2。
在我们的方案中,并没有提供Kibana 的界面直接给用户用,而是我们自己根据公司业务独立开发的。
前端界面为什么不采用Kibana,而需要自己开发?
log-search提供的功能可以参见github:github.com/jiankunking…
如果日志需要清洗的比较多,可以采用方案1,或者先不清洗,先把数据落到Elasticsearch,然后在查询的时候,进行处理。比如在我们的场景中,可以先把日志落到Elasticsearch中,然后在需要检索应用名称的时候,通过代码来处理并获取App名字。
其实基于日志可以做很多事情,比如:
具体思路,可以参见下图:
前提:能要求使用方,按照某种规则打印日志。 监控发展:监控基本就是先打通链路trace,然后再在上报信息或者日志信息中,加强业务方面标识,即给监控添加业务维度方面的视角。
DaemonSet
以DaemonSet方式部署Filebeat来收集日志,其实收集也是宿主机/var/lib/docker/containers目录下的日志。 Running Filebeat on Kubernetes
Sidecar
一个POD中运行一个sidecar的日志agent容器,用于采集该POD主容器产生的日志。
莫名想起了istio。
Filebeat可以以sidecar模式来进行容器日志的收集,也就是filebeat和具体的服务容器部署在同一个pod内,指定收集日志的路径或文件,> 即可将日志发送到指定位置或Elasticsearch这类的搜索引擎。 每个pod内部署filebeat的模式,好处是和具体的应用服务低耦合,可扩展性强,不过需要在yaml进行额外配置。