文章目录
- 我们为什么要搭建日志系统？
- 相关组件介绍
- Flume
- Logstash
- FileBeat
- Elasticsearch
- Kibana
- Kafka
- 市场上的几种日志系统架构
- 原有ELK架构
- 引入消息队列架构
- 轻量级的日志采集架构
- 百亿级日志系统架构
- 总结
我们为什么要搭建日志系统？
日志系统已经成为目前互联网行业的必备项目，用户行为分析，用户画像，包括事件的异常分析，统计分析等等都要依赖于日志。
随着大数据的快速发展，近些年来日志被越来越多的公司所重视，以前我们数据量不大，日志都是写在服务器上，一般查看日志都是直接登陆服务器上直接查看，随着我们数据量不断增加，一台甚至几台服务器根本满足不了我们需求，我们甚至可能部署了上千台服务器。这个时候我们查看日志难道还要登陆到不同机器上吗。先不说我们如何知道我们想要查看的日志在哪一台机器上，即使我们能够精准的知道日志在哪，查看起来也是非常的不方便。
日志的量级其实是非常大的，因为日志越多意味着你能解析分析的数据就越多。而且面对如此海量的数据，又是分布在各个不同地方，如果我们需要去查找一些相关的日志，难道还是使用传统的方法，去登陆到一台台机器上查看？可以看出传统的工具和方法已经显得非常笨拙和低效了。所以有一个集中管理日志系统非常必要。
一个完整的集中式日志系统，主要有以下几个特点：
- 日志采集，能够采集多种来源的日志数据；
- 日志传输，能够稳定的把日志数据传输到*系统；
- 日志存储，如何存储日志数据；
- 日志分析，支持UI页面分析
- 日志监控，对一些日志异常进行监控报警
相关组件介绍
Flume
参考官网：http://flume.apache.org/
Flume作为上一代日志采集工具，可以说是风靡一时，现在还有很多公司在使用。最开始是cloudera 开发的实时日志收集系统，后来纳入Apache Flume。Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。主要有三个部分：Source、Sink、Channel。
- Source：负责数据的写入并推入Channel，可以同时是多个；
- Channel：缓存数据，等待sink成功返回后删除；
- Sink：数据输出，可以是Source，也可以是外部数据源；
Flume支持很多数据输入输出源，这里我们只讨论日志文本文件作为输入源。
优点：
- 集群高可用性，并且拥有Channel机制，在确保sink端成功接收数据后，Channel才会删除数据；
- 数据吞吐极大，适合大型互联网日志系统，如美团等。
缺点：
- 只限于传输，对数据处理非常弱
- 因为Channel机制的存在，并且Source、Sink都是独立封装的，所以Source并不会等待Sink的输出，而是一直写入Channel。
- Channel保存数据主要有两种，一种是MemoryChannel一种是FileChannel，MemoryChannel性能好但不安全，FileChannel性能较差。
Flume性能上是没得说，我们早期也是使用Flume，即使是现在也在使用Flume做日志持久化到hdfs。不过总会出现丢数据的情况，所以业务上被弃用了。
Logstash
参考官网：/guide/en/logstash/current/
Elastic公司旗下，ELK组件其中的L（Elastic在版本之后已经对ELK的版本进行统一化）。Logstash是一个支持日志采集、处理、转发的框架，开发语言是JRuby。类似框架可以参照Flume。Logstash在很多方面都是优于Flume的，尤其是在日志解析处理这块，Flume是没有数据处理功能的。
优点：
- 作为ELK组件之一，与Elasticsearch交互简单方便；
- 对日志处理功能强大，基本需求都可以实现；
- Logstash中自带很多插件，支持各种类型的输入输出源，用起来非常方便，节省了很多开发成本；
- 拥有检查点记录机制，记录采集日志的位置；
- 输出阻塞；
缺点：
- 支持自定义插件，但由于是用Ruby写的，对于非Ruby工程师开发还有有一定难度；
- 还是由于JRuby开发，会占用大量JVM，比较耗费资源；
FileBeat
参考官网：/guide/en/beats/filebeat/current/
FileBeat是Elastic旗下Beats家族的一份子，主要用来收集数据源是文件的数据，比如常见的系统日志、应用日志、网站日志等等。FIleBeat思路来自Logstash-forwarder，Beats团队加入之后重构改写而成，解决的就是Logstash作为Agent采集时占用太多被收集系统资源的问题，Beats家族都是Golang编写，效率高，占用内存和CPU比较少，非常适合作为agent跑着服务器上。版本上已与ELK统一。
优点：
- 专门的数据采集工具，轻量级，占用资源较小；
- 支持断点续传；
- 同样作为elastic旗下重点项目，对接ELK都非常方便；
- 5.3 版本以后支持动态载入外部配置；
Elasticsearch
参考官网：/guide/en/elasticsearch/reference/current/
Elasticsearch不用多说，目前最火的搜索引擎。全文检索，文本检索最强利器。在日志系统中主要用来提供日志检索和简单的统计分析。
Elastic公司已经在美国上市，可以买一些，希望大家早日财务*。
Kibana
参考官网：/guide/en/kibana/current/
Elastic旗下，作为Elasticsearch的数据可视化工具，可以实现Elasticsearch中的数据各种图表化转换。同时可以管理和监控Elasticsearch。
Kafka
参考官网：/
Apache kafka是目前最火的流式的消息处理的之一，主要用于日志处理的分布式消息队列，是一种高并发高吞吐量的发布订阅消息系统。它最初由linkedin开发，之后成为了Apache 的项目。
市场上的几种日志系统架构
目前市场上主流的就是基于ELK的日志系统架构，并且由ELK衍生出几种不同场景下的架构，下面会逐个简单介绍。
原有ELK架构
ELK是elastic最初设计出来的日志系统的架构。
这种架构相对简单了，优点是搭建简单，易于上手。缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议初学者和小型日志系统使用。
使用logstash既作为数据采集，又作为数据清洗，并将采集清洗的数据发送到Elasticsearch中，最终通过kibana进行图形化展示。
引入消息队列架构
在原有ELK基础之上，引入消息队列机制，通过logstash采集数据发送给kafka或redis（高并发一般使用kafka），kafka的数据输出到logstash进行解析，这里通过logstash消费kafka还有一个好处就是可以实现分布式并发消费，并且支持容错容灾，单个logstash挂掉不会影响这个业务。将解析后的结果输出到Elasticsearch提供检索，kibana用来数据可视化展示。
这种架构适合大规模的日志系统，T级以上的增量没什么问题，但是采集端过多的logstash部署势必要占用业务服务器的资源，增加服务器负担从而导致业务环境压力过大。
轻量级的日志采集架构
由于Logstash相当耗费资源，所以能不能找一个替代品？一开始是使用Logstash-forwarder，这个只支持数据采集。并不支持数据处理，并且更轻量化。后来由Logstash-forwarder衍生出了filebeat，filebeat可以完全取代Logstash中的数据采集功能，更加轻量和灵活性。
这种架构是由filebeat代替了Logstash的数据采集功能，因为filebeat使用Golang语言编写，性能上更加轻量级，可以减少应用服务器的负担。但是filebeat无法进行日志数据的解析，数据解析仍然还是使用Logstash来处理，但是这里的Logstash可以集中处理filebeat采集上来的日志而不必像第一种架构那样在采集端就进行日志清洗。
百亿级日志系统架构
上诉介绍了使用更轻量级的filebeat可以更好的减轻资源的负担，不过多的占用业务资源。但在目前互联网模式下，高并发高吞吐的日志动则TB级，那么用上面的架构显然太单薄了，所以我们还要引入目前很火的消息队列神器----kafka。
kafka具有高并发高吞吐的特性，非常受互联网企业的青睐，并且具备缓存机制，可以保存7天数据（默认值）。
这种架构使用filebeat作为采集工具，一般在每台服务器上部署一个filebeat服务来采集这台服务器上的日志。filebeat采集到的日志一般需要经过简单的处理，比如时间格式转换，报错日志的合并行等等，这些filebeat都可以做。
经过简单处理后的日志我们输出到kafka，每一个filebeat可以看作是一个producer。本身kafka是高并发高吞吐的存在，所以即使我们上千个filebeats同时发送数据，kafka依然可以实时接收。这里我们可以选择不同类型的日志，发送到kafka的不同topic上，这样可以把不同种类的日志隔离出来，同时制定不同的策略。
发送到kafka上的日志，我们使用Logstash集群作为消费者来消费kafka中的数据。如果kafka机器资源富裕的话，建议把Logstash集群部署在kafka集群上，这样可以减少网络开销。Logstash这里作为数据解析，是整个日志系统中的重中之重。在这里我们可以对日志进行关键词提取、日志字段解析、分类，以及报错日志的告警等等。
解析处理后的日志，我们使用output-elasticsearch来把解析后的日志发送到Elasticsearch，Elasticsearch提供日志的分析和检索功能。Elasticsearch可以做一些简单的统计分析，像分组聚合统计。比如：查看张三今天问了哪些问题？根据问题进行分类，哪类问题问得多？这些只要输入张三关键词就可以查询出来。
最后就是一个根据Elasticsearch的数据进行一个图形化页面展示。kibana是一个很好的数据可视化工具，可以将数据转换成各种土图表。我们也可以自己开发一个日志系统查询UI，提供日志检索功能（kibana查看日志页面并好看）。
对于应用日志的跟踪和问题的跟踪，这个需要我们自己开发一个页面来展示。
总结
本篇文章咱们讨论了一些日志系统的技术架构选型和优缺点，针对不同的场景可以选择不同的架构方式。现在最主流的还是ELK+filebeat+kafka组合，能够实现百亿级日志系统。后续会申请出一个达人课，从0开始，手把手教如何搭建ELK+filebeat+kafka组合的百亿级日志系统。现filebeat部分已经写完，最近比较忙，空闲下来会继续写，肯定会尽量完成它。
更多文章关注公众号