共计 893 个字符，预计需要花费 3 分钟才能阅读完成。
作用
以前都是登陆到每个机器去看日志，特地是一个服务有多个机器集群部署，还要下载多个机器的日志 (运维下载日志，而后给开发排查问题)，当初 elk 是集中式日志零碎，所有的我的项目和我的项目集群都在一个日志零碎里，而且能够搜寻。
界面
组成
L 是收集日志，还有解析日志
E 是搜索引擎，就是 ElasticSearch
K 就是界面
流程
原始日志 (L 的客户端)——收集和解析日志 (L 的服务器端)——搜索引擎 (E)——界面展现 (K)
解释
1. 收集日志和解析日志
收集日志就是客户端到服务器，就是把 L 客户端装置到部署我的项目的机器，而后读原始日志文件，再写到 L 的服务器端。这是收集日志，就是：原始日志文件——L 的客户端——L 的服务器。
L 的服务器还要解析日志，次要是解析为固定的几个字段，比方工夫、IP(哪个机器的日志)、日志自身的内容、我的项目名字 (哪个我的项目的日志)。这几个固定字段是搜索引擎须要的字段。
2. 搜索引擎
方才解析之后的字段，再写给搜索引擎。
3. 界面
filebeat
为什么要用 filebeat，因为 L 的客户端性能不好，影响部署我的项目的机器，所以换了 filebeat 作为 L 的客户端，作用和 L 的客户端一样，都是收集日志，实质就是先读原始日志文件，而后再写到 L 的服务器。这就是 filebeat 的作用，对部署我的项目的机器无影响。
kafka
为什么要用 kafka，因为日志产生和日志生产的速度不匹配，还有因为网络起因，可能会导致数据失落，所以才要加消息中间件，因为消息中间件能够缓存海量数据，并且数据不会失落 (失落可能性极小，不会大量失落数据)。
架构图的演变
只有 ELK
L 的客户端没有应用 filebeat。
换了 filebeat
L 的客户端换成了 filebeat。
加了消息中间件
双层 L
从左往右看
从右往左看
第一层 L 作用只是分流，第二层 L 作用是解析为固定几个字段。
参考
https://mp.weixin.qq.com/s/F8…
https://www.cnblogs.com/wangx…
https://blog.qiniu.com/archiv…
https://jusene.github.io/2018…
