日志服务架构设计( 二 ) _架构设计

docker日志的场景比较单一，都是通过之前一个产品A发布部署的，其docker命名规则比较统一，可以通过截取docker.container.name来获取应用名字；同时在部署的时候，可以知道部署目标机器的ip，这样就可以通过应用+ip来作为实例名称。
k8s场景也比较统一，都是通过之前一个产品B发布部署的，其pod命名规则比较统一，可以通过截取kubernetes.pod.name来获取应用名字（但需要通过namespaces关联到tenant，再通过tenant与项目一一对应）；k8s中的pod.name就是唯一的，以此来作为实例名称即可。
文本日志：因为文本日志主要的场景是已经裸机部署的应用，这种场景下，不存在应用自动迁移的情况，所以文本日志的应用名称、实例名称可以在部署的时候打上标签即可。

【日志服务架构设计】具体规则及解析见下图（实例部分处理暂未标注）：

文章插图

推荐写日志到文本文件中，使用标准输出就好。

到这里可以发现我们选择Filebeat来作为日志的收集端，Elasticsearch来存储日志并提供检索能力。
那么，日志的清洗在哪里做呢？
日志的清洗一般有两种方式：

先把日志收集到kafka，再通过Logstash消费kafka的数据，来清洗数据
直接通过Elasticsearch的[Ingest Node]来清洗数据，因为Ingest Node也支持Grok表达式

对于，我们的场景而言，我们需要清洗数据的要求比较简单，主要是应用、实例名称的截取还有文本日志中日志时间的处理（@timestamp重置，时区处理），所以我们选择了方案2 。
在我们的方案中，并没有提供Kibana 的界面直接给用户用，而是我们自己根据公司业务独立开发的。
前端界面为什么不采用Kibana，而需要自己开发？

kibana对于业务开发人员有一定的学习成本
kibana界面没有很好的将日志内容与业务意义关联起来（界面选择总比一次次的输入要好，这也是我们将日志的项目、应用、实例等业务信息解析出来的原因）
log-search支持Query String，因此对于熟悉kibana的开发人员来说，在我们自己开发的前端界面检索效果是一样的。

log-search提供的功能可以参见github：github.com/jiankunking…

如果日志需要清洗的比较多，可以采用方案1，或者先不清洗，先把数据落到Elasticsearch，然后在查询的时候，进行处理。比如在我们的场景中，可以先把日志落到Elasticsearch中，然后在需要检索应用名称的时候，通过代码来处理并获取App名字。

监控、告警其实基于日志可以做很多事情，比如：

基于日志做监控（google Dapper）
基于日志做告警
基于日志做machine Learning

具体思路，可以参见下图：

文章插图

前提：能要求使用方，按照某种规则打印日志。监控发展：监控基本就是先打通链路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进行额外配置。