目前最流行的集中式日志解决方案，实时日志的收集、存储、展示:
FileBeat + Kafka + LogStash + ElasticSearch + Kibana
FileBeat 是一款轻量级的数据收集引擎，他可以代替LogStash成为应用服务器端的日志收集引擎。
LogStash 是开源的服务端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到任意“存储库”中，进行数据的收集、分析、过滤。一般采用C/S架构，Client端安装在需要收集日志的主机上，Server端负责对收到的各个节点上的日志进行过滤、修改等再一并发往ElasticSearch；
ElasticSearch 是一个分布式、RESTful风格的搜索、数据分析引擎，能够解决不断涌现的各种用例。主要提供搜索、分析、存储数据三大功能。它的特点有分布式、零配置、自动发现、索引自动分片、索引副本机制、RESTful接口风格、多数据源、自动搜索负载等。
Kibana 可以对ElasticSearch进行可视化，还可以再ElasticStack中进行导航，从跟踪查询负载到理解请求如何流经整个应用，对汇总、分析和搜索重要数据日志有非常重要的作用。
一、为什么要用ELK
ELK对于可观察性有着非常重要的作用。
随着业务量的增长，每天业务服务器都会产生上亿条日志，单个日志文件所占内存达到多个G。
此时使用Linux自带工具 cat/grep/awk 分析会越来越难。
而且除了服务器日志，还有程序报错日志，这些日志分布在不同服务器，查阅烦琐。
在较大规模的场景下，此方法效率低下，面临的问题包括：
- 日志太大、种类太多、不好归档
- cat/grep/awk 文本搜索太慢
- 多维度查询
- 日志分布在不同服务器上，业务故障需要一台一台查看日志。
因此需要集中化的日志管理，将所有服务器上的日志收集汇总。
ELK提供了一整套的解决方案、其中所用到的都是开源软件，通过软件间的相互配合、完美衔接，高效满足了很多场合的应用，故成为主流的集中式日志解决方案。
ELK支持如下5个主要功能：
- 收集：能够采集多种来源的日志数据
- 传输：能够稳定地把日志数据传输到中央系统
- 存储：存储日志数据
- 分析：支持UI分析
- 告警：能够提供错误报告，拥有监控机制
二、基础架构
如图所示:
- 在各服务器端各部署一个LogStash组件，该组件作为日志收集器；
- LogStash收集到的数据经过过滤、分析、格式化处理后会发送至ElasticSearch进行存储；
- 最后使用Kibana进行可视化展示。
这种架构的不足之处：
- LogStash在应用服务器上读取、过滤、输出Log，势必会造成服务器上占用系统资源较高，增加应用服务器的负载压力。因此可能需要通过拆分来提升性能。
- 在高并发情况下，日志传输峰值比较大。如果直接写入ElasticSearch，会因为ElasticSearch的HTTP API处理能力有限，在日志写入频繁的情况下会出现写入超时、数据丢失等问题，所以需要一个缓冲中间件。
- 这种架构也会给运维调优带来巨大的成本。比如还没有接入全公司的业务，就可能发生ElasticSearch索引数据量比较大的情况，查询时会报CPU负载过高等问题。
这种架构的优化思路：
- 架构层面： 日志收集采用 FileBeat、增加Kafka代理缓存
- ElasticSearch层面：很多卡死的原因是日志导致索引过大，故除了提升ES系统性能以外，索引也需要进行调优（比如自定义templates，非必要的字段不存储），模板中设置_ttl过期时间(30天过期)
- 缓存层面：使用Kafka作为缓存，将Partition分成不同的topic，不同的业务日志写入不同的topic中
另外的一些思路：
- 缓冲中间件的选择： 早期的博客推荐都是Redis，但是经过证明Kafka更优秀，原因如下：
- Redis无法保证消息可靠性，但是Kafka可以做到。
- Kafka的吞吐量和集群模式都比Redis优秀
- Redis受限于机器内存，当内存达到阈值，数据就会被抛弃。
- 性能的问题：
- LogStash要处理大量数据，同时ES要存储和索引大量数据，服务器压力会比较大，往往需要配置为集群模式，否则会出现性能瓶颈。
- 相比于LogStash，FileBeat会是更轻量级的日志采集组件。
- 系统可靠性问题：上述架构如果部署成为集群，所有业务放在一个大集群中会出现相互影响的情况。一个业务系统出问题了，可能会拖垮整个日志系统。
三、改良架构
我们基于上一段的架构及思考，得到了一个新的架构： FileBeat + Kafka + LogStash + ElasticSearch + Kibana
该架构已经足够一般的小公司使用。
这套架构的特点是：
- FileBeat日志收集，相比于LogStash对业务系统资源消耗更少。
- LogStash 和 ElasticSearch 采用集群搭建
- 相比之前： 架构性能更优，采集速度更快，搜索速度更快，也更加稳定。
四、拓展思路
其实就是结语了，上述架构满足小公司的使用，但是咱们还是要有梦想，万一公司上市了呢。
- 针对业务使用不同的ES集群。
- 引入TribeNode，作为一个特殊的客户端，它可以在所有ES集群上执行搜索操作。
- 对ES数据进行7天的冷热分离。