日志收集系统规划
背景
目前生产集群机器数量持续增多，各个服务日志均分散存储在本地，对于线上日志排查问题十分不便。因此需要一套日志实时收集系统，对线上服务器上各类型的日志进行分类收集，集中存储，以便实现日志的快速检索，后期可以针对于日志实现日志级别的告警。
名词解释
ES: ElasticSearch
设计目标
实现功能
- 实现日志统一集中存储。
- 实现web端日志快速检索，图表分析。
- 基于日志系统的告警，提高系统稳定性。
系统环境
整套组件统一运行与centos7.4系统上，kafka运行于java8虚拟机，ELK出于稳定行考虑运行于ELK官方自带的JDK软件包。
相关软件及硬件
-
软件版本
|
软件名称
|
版本号
|
|kafka
|
2.2.2
|
|filebeat
|
7.6.1
|
|logstash
|
7.6.1
|
|elasticsearch
|
7.6.1
|
|kibana
|
<pre> </pre>
- 硬件配置
由于ES集群对于机器的配置较高，为节省成本，先少量的购买机器部署，等集群数据量到一定规模后，再适时扩容。
|
服务类型
|
机器配置
|
数量
|
备注
|
|
kafka
|
大数据网络增强型den1 8H32G5500*4HDD
|
3
| |
|
logstash
|
计算型C6 8H16G 500G云盘
|
2
| |
|
ES 热数据服务器
|
通用型G6 16H64G2048G*4ESSD
|
3
|
Hot节点
|
|
ES 冷数据服务器
|
大数据网络增强型16H64G 8*5.5THDD
|
3
|
Cold 节点
|
|
ES协调节点/master节点
|
通用型G6 16H32G 1024G高效云盘
|
3
| |
|
kibana展示
|
4H8G 500G高效云盘
|
1
| |
数据规模预估
当前实际存储的日志量为1.5T/天，三个月的数据量为：135T,数据作为磁盘存储的70%，剩余的30%用于存储索引以及其他数据，副本集设定为2副本，合计使用的存储容量为400T。
设计思路
数据采集层：使用filebeat进行采集，filebeat为ELK集群专为日志收集开发的轻量级服务，对于机器的新能消耗较低，配置简单。
数据缓冲层：当前的日志总量高，考虑到当前的日志总量大且存在峰值，使用kafka来作为日志数据缓冲层，避免峰值数据写入ES引发集群故障。
数据转换层：使用ELK中的Logstash来作为数据[图片上传中...(image-65a147-1614391361379-1)]
的转换和转发，其对数据需要做大量的处理，比较消耗CPU，需选择CPU密集型的服务器，其作为kafka的消费端，可以很方便扩缩容。
数据存储层：使用ES作为日志的存储服务。ES与mongodb类似，有master(config),data(rs),coordinate(mongos)节点，考虑到ES后期存储的数据量会越来越大，同时也越来越重要，在集群设计时，应充分考虑各个角色的高可用性和可扩展性，各个角色的都应该至少部署3节点，数据应该至少具备2副本。但同时ES本身对资源的消耗比较高，为节省成本将数据节点，采取冷热分离方式，根据目前日常的日志查询主要集中在7天内，因此7天内的数据作为热数据，存储在hot node上(ESSD硬盘)，7天后的数据存储在cold node上（HDD裸盘)。
数据展示层：使用Kibana，其具有丰富的展示功能以及实时查询。
安全层面：ES7.x版本，开放了x-pack的部分安全功能，包括集群间加密通讯，kibana密码认证等功能，能够满足当前我们的需求。
系统架构图
[图片上传中...(image-742104-1614391361379-0)]
规划：
该项目分为三个阶段：
第一阶段(预计需要20天)：
- 服务器的购买，基础服务搭建，以及监控系统搭建(3天)。
- 业务服务日志收集，转化，存储(12天)。
- 搭建、配置、使用文档输出(5天)。
第二阶段(10天)：
- 基础服务日志、数据库慢日志、系统日志收集，转化，存储（7天）。
- 配置、使用文档输出（3天）。
第三阶段(长期)：
1. 根据日志的存储量，适时进行扩容。
2. 日志告警，优化。
3. 日志转储。
