基于filebeat+kafka+ELK的大数据日志收集系统
目录
-
- 日志收集系统简介
- 常用的日志收集系统对比
- 日志收集系统架构
- 架构设计考虑
-
- 可用性
-
- filebeat死掉
- kafka死掉
- logstash死掉
- es和hdfs正常关闭
- es和hdfs异常停机或不可访问
- logstash变慢
- hdfs变慢
- 可靠性
- 可扩展性
-
- filebeat层
- kafka层
- logstash、es、hdfs层
- 系统监控
-
- 发送速度，拥堵情况，写入速度
- 日志大小监控
- 异常日志监控
日志收集系统简介
日志收集是大数据的基石。
许多公司的业务平台每天都会产生大量的日志数据。收集业务日志数据，供离线和在线的分析系统使用，正是日志收集系统的要做的事情。高可用性，高可靠性和可扩展性是日志收集系统所具有的基本特征。
常用的日志收集系统对比
| Flume | Logstash | Filebeat | |
|---|---|---|---|
| 内存 | 大 | 大 | 小 |
| cpu | 小 | 大 | 小 |
| 背压敏感协议 | 否 | 否 | 是 |
| 插件 | 需要额外支持 | 多 | 多 |
| 功能 | 支持多种输入、多种输出 | 支持多种输入、多种输出，支持数据转换，支持实时解析 | 支持多种输入、多种输出 |
| 轻重 | 重量级 | 重量级 | 轻量级 |
| 过滤能力 | 可以支持分区、拦截器 | 过滤能力强大 | 过滤能力弱 |
| 稳定性 | 一台服务器支持多个进程，挂掉后需要手动启动 | 一台服务器只能有一个进程，挂掉后需要手动启动 | 非常稳定 |
| 集群 | 分布式 | 集群 | 单节点 |
| 二次开发 | 一般 | 难 | 易 |
背压敏感协议：当接收端繁忙时,会通知收集端降低传输速率,并在正常后恢复速度
日志收集系统架构
- 应用程序产生日志信息，通过
log4j2输出到磁盘上的两个日志文件中（app-log-服务名.log和error-log-服务名.log） filebeat会监听这个两个日志文件，日志中的新数据会被整合打包推送到kafka中kafka作为一个负载缓冲和临时存储的作用，将数据推送到logstash中logstash用来做日志的筛选和过滤，把需要日志推送到``elasticsearch和hdfs`中elasticsearch存放3个月内的日志信息，并为数据可视化提供数据来源hdfs存放所有的日志信息- 使用
kibana进行数据可视化
架构设计考虑
将从可用性，可靠性，可扩展性和兼容性等方面，对上述的架构做细致的解析
可用性
对日志收集系统来说，可用性指固定周期内系统无故障运行总时间。要想提高系统的可用性，就需要消除系统的单点，提高系统的冗余度。下面来看看在可用性方面的考虑。
filebeat死掉
filebeat死掉分为两种情况：机器死机或者filebeat进程死掉。
对于机器死机的情况来说，由于产生日志的进程也同样会死掉，所以不会再产生新的日志，不存在不提供服务的情况。
对于filebeat进程死掉的情况来说，确实会降低系统的可用性。对此，我们有下面三种方式来提高系统的可用性。
- 所有的
filebeat都被keepalived监控，如果进程死掉会被立即重启，以提供服务。 - 其次对于无法重启的
filebeat，keepalived在多次尝试后会发出报警，短信或者邮件的形式提醒人工处理。 - 日志是直接通过
log4j2直接输入到磁盘上的，保证不会丢失。
kafka死掉
由于kafka提供的是对等的且无差别的服务，并且kafka以集群部署。所以当某个kafka无法提供服务时，数据发送到其它可用的kafka上面。所以整个服务不受影响。
logstash死掉
同上
es和hdfs正常关闭
出于维护等原因，es和hdfs可能会临时关闭，logstash可以随时修改过滤、筛选方式和输出方式，以停止对es或hdfs的访问
es和hdfs异常停机或不可访问
假如es和hdfs异常停机或不可访问，此时logstash无法继续写入。由于我们使用了kafka，数据会临时保存在kafka中，继续提供服务。当es和hdfs恢复服务以后，再发送到es和hdfs上。可以提供较好的容错性。
logstash变慢
如果logstash处理速度变慢（比如机器load过高）或者filebeat和kafka之间的网络变慢，可能导致日志发往logstash的速度变慢。对于这种情况并无关系，filebeat是从磁盘上提取数据，数据不会丢失，logstash前有kafka做削峰和缓存，避免logstash压力过大
hdfs变慢
当Hadoop上的任务较多且有大量的读写操作时，Hdfs的读写数据往往变的很慢。由于每天，每周都有高峰使用期，所以这种情况非常普遍。同样的，hdfs变慢后，logstash也会变慢，由kafka进行削峰
可靠性
对日志收集系统来说，可靠性是指在数据流的传输过程中，保证日志的可靠传递，最终被持久化到指定位置
对于这套系统来说，日志一开始就持久化在硬盘上，filebeat会保证每条日志都进入kafka，kafka集群通过设置多副本，使topic可以进行复制副本，某一个节点宕机后不会影响整体的生产和消费。同时kafka的确认机制保证在Logstash处理失败的时候，数据不会被消费或者丢失，最终持久化到es和hdfs中。
同时我们也可以在log4j2中将重要的日志单独输出到一个log文件中，如果系统出现重大故障时，可以方便的进行人工核对。
可扩展性
对日志收集系统来说，可扩展性是指系统能够线性扩展。当日志量增大时，系统能够以简单的增加机器来达到线性扩容的目的。
需要在设计的每一层，都可以做到线性扩展地提供服务。下面将对每一层的可扩展性做相应的说明。
filebeat层
对于filebeat这一层来说，每个机器部署一个filebeat，可以水平扩展，不受限制。一个方面，filebeat收集日志的能力受限于机器的性能，正常情况下一个filebeat可以为单机提供足够服务。另一方面，如果机器比较多，可能受限于下游提供的服务。
kafka层
kafka的性能极佳，不会成为系统的性能瓶颈，并且可以通过集群水平扩展。
logstash、es、hdfs层
logstash、es和hdfs都是分布式系统，可以做到线性扩展
系统监控
发送速度，拥堵情况，写入速度
通过kafka的监控，就可以直观的看到日志写入量和写出量，通过kafka队列的堆积可以直观的反应出拥堵情况
日志大小监控
对于重要的日志，每个小时都监控日志大小周同比是否有较大波动，并给予提醒，这个报警可以有效的发现异常的日志，及时给予了对方反馈，帮助他们及早修复自身系统的异常。
异常日志监控
通过kibana的x-pack插件中watcher功能，对日志实现监控，并提供警报的能力。
同时kibana还可以提供图形展示、报表统计、安全认证、监控跟踪
