最近想把之前做过的日志项目及个人的思考梳理一下，于是有了本文。
要做一件事，先看看目前业界是怎么做的。
一、业界日志系统架构
- Collector的作用是：
- 清洗、汇聚数据，减少对于后端集群的压力。
- 安全，不允许Agent直连kafka等内部集群，保证一定的安全性，即使后端发生调整也能保证对于Agent连接、认证方式的稳定。
- MQ的作用是削峰填谷、解耦、多次消费。
上图的架构是业界比较通用的一种架构，比较适合用于：大数据量、运维能力强（团队人多）的公司或团队。
如果对于业务量没有那么大，人员也比较少的公司，应该怎么选择呢？
通用性的架构意味着，考虑的比较全，也就会比较重（比如：会引入很多组件），而这些组件对于你的场景有可能并不是不可或缺的，同时运维这些组件又会产生一定的成本，所以说通用架构对于你来说有可能并不一定是最好的。
共勉一句话：
在满足业务需求的前提下，代码、架构，越简单，越稳定。
二、组件选择
选择组件，我们这边主要是从以下几个方面进行考量的：
- 组件对应的开源生态完整、活跃度高
- 对应的技术栈是我们所熟悉的，我们这边语言技术栈主要是Java、Go，如果组件语言是C、Ruby，应该就被排除了。
- 运维成本
- 易部署、性能好
1、Agent
一提到日志收集方案，大家第一个想到的肯定是ELK(Elasticsearch、Logstash、Kibana )，但Logstash依赖于JVM不管是性能还是简洁性，都不是日志收集agent的首选。
个人感觉一个好的agent应该是资源占用少，性能好，不依赖别的组件，可以独立部署。而Logstash明显不符合这几点要求，也许正是基于这些考虑elastic推出了Filebeat。
2、Collector、MQ
elasticsearch集群在部署的时候，一般都是提前估计好容量、机器、shard等信息，因为elasticsearch集群运行后，再水平拓展，比较麻烦，而我们这边由于业务及成本限制无法很好的预估容量，所以就结合公司实际要求：使用日志服务的业务方自带机器，也就是业务方会有独立的elasticsearch集群。
每个业务方都使用自己的elasticsearch集群，所以集群压力不会很大，从而Collector、MQ这两个组件对于我们的作用也就很小了。
3、ETL
因为Elasticsearch Ingest Node完全可以满足我们的解析需求，所以就没有必要再引入Logstash等相关组件了。
到这里，基本可以看出我们的架构如下：
架构合适的，就是最好的。
三、业务需求
我们这边收集日志应对的场景主要是：文本日志、docker日志、k8s日志，恰恰这些EFK全家桶都支持。
我们希望日志收集产品可以满足以下几个需求：
- 按照项目、应用、实例维度检索日志并支持搜索关键字高亮（因为大家检索日志的时候，肯定是检索某个应用、某个实例的日志）
- 支持检索出某条想要的日志后，可以查看上下文（查看该日志所在日志文件的前后多少条）
- 支持日志下载（目前支持两种场景：搜索结果下载、上下文下载；支持两种方式：在线下载、离线下载）
- 支持Elasticsearch Query String查询
- 支持自动化批量部署、卸载Filebeat，部署、卸载过程可视化
- 单实例支持多elasticsearch集群
- 支持文本日志、docker日志、k8s日志并能与将日志与其业务意义对应上。（即不管是哪种日志形式、来源，最终都需要与业务意义上的项目、应用、实例对应起来，因为对于日志的使用者来说，查询日志的出发点肯定是查询某个项目、某个应用（可以不选）、某个实例（可以不选）、某段时间的日志。）
四、具体实现
基于需求及EFK套件，梳理我们场景中特有的东西：
- 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，而需要自己开发？
1、kibana对于业务开发人员有一定的学习成本
2、kibana界面没有很好的将日志内容与业务意义关联起来（界面选择总比一次次的输入要好，这也是我们将日志的项目、应用、实例等业务信息解析出来的原因）
3、log-search支持Query String，因此对于熟悉kibana的开发人员来说，在我们自己开发的前端界面检索效果是一样的。
log-search提供的功能可以参见github：log-search
https://github.com/jiankunking/log-search
如果日志需要清洗的比较多，可以采用方案1，或者先不清洗，先把数据落到Elasticsearch，然后在查询的时候，进行处理。比如在我们的场景中，可以先把日志落到Elasticsearch中，然后在需要检索应用名称的时候，通过代码来处理并获取app名字。
五、监控、告警
其实基于日志可以做很多事情，比如：
- 基于日志做监控（Google Dapper）
- 基于日志做告警
- 基于日志做Machine Learning
具体思路，可以参见下图：
前提：能要求使用方，按照某种规则打印日志。
监控发展：监控基本就是先打通链路trace，然后再在上报信息或者日志信息中，加强业务方面标识，即给监控添加业务维度方面的视角。
六、其它
1、DaemonSet
以DaemonSet方式部署Filebeat来收集日志，其实收集也是宿主机/var/lib/docker/containers目录下的日志。
Running Filebeat on Kubernetes
2、Sidecar
一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。
莫名想起了istio。
Filebeat可以以sidecar模式来进行容器日志的收集，也就是filebeat和具体的服务容器部署在同一个pod内，指定收集日志的路径或文件，即可将日志发送到指定位置或Elasticsearch这类的搜索引擎。
每个pod内部署filebeat的模式，好处是和具体的应用服务低耦合，可扩展性强，不过需要在yaml进行额外配置。
3、业界案例分享
- InfoQ运维大会日志处理专题演讲干货合集
- 曹林华-沪江网日志平台化之路
- 黎吾平-日志分析场景下的搜索引擎改进
- 林冰玉-QA 与Ops通力打造反脆弱的软件系统
- 周辉-新思路打造移动端个案综合日志分析系统
个人微信公众号：