一.搭建日志收集分析平台的原因
说法1. 通常来说，日志被分散的存储在各自的不同的设备上，如果说需要管理上百台机器，那么就需要使用传统的方法依次登录这上百台机器进行日志的查阅，这样会使得工作效率即繁琐且效率低下。所以就引出了把日志集中化的管理方法
说法2. 一般我们需要进行日志分析场景：直接在应用系统服务后台的日志文件路径下 通过 grep、awk 等查找命令就可以获得自己想要的信息。但是我们都知道，在生产环境中经常会遇到很多异常，报错信息，需要查看日志信息排查错误。现在的系统大多比较复杂，即使是一个服务背后也是一个集群的机器在运行，如果逐台机器去查看日志显然是很费力的，也不现实。如果能把日志全部收集到一个平台，然后统一管理，就会非常省事。所以常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。一般现在的应用服务系统工程、大型系统都是一个分布式部署的架构。不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块。构建一套集中式日志系统，可以提高定位问题的效率。
二.对ELK的了解
ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana （现在也有人提出了ELKF的概念，那就是在ELK的基础之上，加上了Filebeat）
ELK概念解析
- Elasticsearch
Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
- Logstash
Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。其实Logstash的理念很简单，只做三件事情：
- Input：数据输入
- Filter：数据加工，例如：过滤、改写等
- output：数据输出
- Kibana
Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。 - Filebeat
Filebeat隶属于Beats。目前Beats包含四种工具：
①Packetbeat（搜集网络流量数据）
②Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
③Filebeat（搜集文件数据）
④Winlogbeat（搜集 Windows 事件日志数据）
ELK常见的架构：
- Logstash+ES+Kibana
（1）将日志进行集中化管理
（2）将日志格式化（Logstash）并且输出到Elasticsearch
（3）对格式化后的数据进行索引和存储（Elasticsearch）
（4）前端数据的展示（Kibana）
虽然官网中介绍的是这种架构，但是在实际生产中好像很少使用这种方式，因为logstash消耗的资源比较大，运行占用的CPU和内存高，而且没有消息队列缓存，存在数据丢失隐患
- Filebeat+Logstash+ES+Kibana
这种架构是ELKF，但是也有缺点，如果Logstash出现故障，会导致日志丢失
- Elasticsearch + Logstash + filebeat + redis(也可以是其他中间件，比如kafka（集群化）) + Kibana
这种架构是上面那个架构的完善版，通过增加中间件，来避免数据的丢失。当Logstash出现故障，日志还是存在中间件中，当Logstash再次启动，则会读取中间件中积压的日志。
在生产环境中，由于logstash消耗资源过多，我们一般采用filebeat轻量级日志收集代理，让logstash专注于日志格式化，又由于生产环境中日志量过大，logstash一旦故障，会导致日志的丢失，所以要在filebeat与logstash中增加一个中间件redis或kafka来起一个缓存汇聚作用
ELK和我的项目的区别点
我这个基于kafka的nginx日志收集分析平台跟ELK的第三种架构有点像，都是使用filebeat收集数据，然后kafka作为消息中间件存储数据，但是我这个项目后面是直接使用python编写的一个程序将需要的日志存入了数据库，而ELK则是使用logstash对数据进行格式化处理，然后再放到elasticsearch上，可以用来存储数据，也可以用来对数据进行搜索，最后再由kibana作前端展示。
如果想要了解我的项目或者filebeat和kafka的更多内容，可以查看此篇文章：基于Kafka的nginx日志收集分析平台
三.常见的消息中间件
消息中间件：就是在分布式系统中完成消息的发送和接收的基础软件，又可以称为消息队列。
目前比较流行的消息中间件有：ActiveMQ、ZeroMQ、RocketMQ、RabbitMQ、Kafka，其中流行最广泛的是RocketMQ、RabbitMQ、Kafka
如何选择消息中间件：
1.产品应该是开源的，这样如果在使用的过程中遇到了BUG可以很快的修改，不用等着开发者进行更新。
2.产品应该是近几年比较流行的，这样如果遇到了什么问题，也可以在网上比较快速的找到解决方案，并且比较流行也说明着产品的bug比较少。
3.然后，作为消息队列应该具备以下几个特性：
- 消息传输的可靠性：保证消息不会丢失。
- 支持集群，包括横向扩展，单点故障都可以解决。
- 性能要好，要能够满足业务的性能需求
RabbitMQ
RabbitMQ 开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。
优点：
- 轻量级，快速，部署使用方便
- 支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。
- RabbitMQ的客户端支持大多数的编程语言。
缺点：
- 如果有大量消息堆积在队列中，性能会急剧下降
- RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应用要求高的性能，不要选择RabbitMQ。
- RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。
RocketMQ
RocketMQ 是一个开源的消息队列，使用 java 实现。借鉴了 Kafka 的设计并做了很多改进。
优点：
- RocketMQ 主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。
- RocketMQ 几乎具备了消息队列应该具备的所有特性和功能。
- java 开发，阅读源代码、扩展、二次开发很方便。
- 对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时间，可以使用RocketMQ。
- 性能比RabbitMQ高一个数量级，每秒处理几十万的消息。
缺点：
- 跟周边系统的整合和兼容不是很好。
Kafka
Kafka的可靠性，稳定性和功能特性基本满足大多数的应用场景。跟周边系统的兼容性是数一数二的，尤其是大数据和流计算领域，几乎所有相关的开源软件都支持Kafka。Kafka是Scala和Java开发的，对批处理和异步处理做了大量的设计，因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是三个中最好的，但是跟RocketMQ拉不开数量级，每秒处理几十万的消息。如果是异步消息，并且开启了压缩，Kafka最终可以达到每秒处理2000w消息的级别。
优点：
- 支持多个生产者和消费者
- 支持broker的横向拓展
- 副本集机制，实现数据冗余，保证数据不丢失
- 通过topic将数据进行分类
- 通过分批发送压缩数据的方式，减少数据传输开销，提高吞高量
- 支持多种模式的消息
- 基于磁盘实现数据的持久化
- 高性能的处理信息，在大数据的情况下，可以保证亚秒级的消息延迟
- 一个消费者可以支持多种topic的消息
- 对CPU和内存的消耗比较小
- 对网络开销也比较小
- 支持跨数据中心的数据复制
- 支持镜像集群
缺点：
- 由于是批量发送，所以数据达不到真正的实时
- 对于mqtt协议不支持
- 不支持物联网传感数据直接接入
- 只能支持统一分区内消息有序，无法实现全局消息有序
- 监控不完善，需要安装插件
- 需要配合zookeeper进行元数据管理
- 会丢失数据，并且不支持事务
- 可能会重复消费数据，消息会乱序，可用保证一个固定的partition内部的消息是有序的，但是一个topic有多个partition的话，就不能保证有序了，需要zookeeper的支持，topic一般需要人工创建，部署和维护一般都比mq高
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
