日志分析平台建设方案.doc

v1.0可编辑可修改
v1.0可编辑可修改

v1.0可编辑可修改

日志分析平台建设方案

目录
TOC\o"1-3"\h\z\uHYPERLINK\l"_Toc256000000"一、 现状和需求 PAGEREF_Toc256000000\h2
HYPERLINK\l"_Toc256000001"(一) 现状与问题 PAGEREF_Toc256000001\h2
HYPERLINK\l"_Toc256000002"(二) 需求说明与分析 PAGEREF_Toc256000002\h2
HYPERLINK\l"_Toc256000003"二、 建设目标 PAGEREF_Toc256000003\h3
HYPERLINK\l"_Toc256000004"三、 系统设计 PAGEREF_Toc256000004\h3
HYPERLINK\l"_Toc256000005"(一) 技术选型 PAGEREF_Toc256000005\h3
HYPERLINK\l"_Toc256000006"(二) 系统架构 PAGEREF_Toc256000006\h3
HYPERLINK\l"_Toc256000007"1. 架构图 PAGEREF_Toc256000007\h3
HYPERLINK\l"_Toc256000008"2. 架构分析 PAGEREF_Toc256000008\h4
HYPERLINK\l"_Toc256000009"(三) 系统介绍 PAGEREF_Toc256000009\h4
HYPERLINK\l"_Toc256000010"四、 实施方案 PAGEREF_Toc256000010\h5
HYPERLINK\l"_Toc256000011"(一) 系统配置 PAGEREF_Toc256000011\h5
HYPERLINK\l"_Toc256000012"1. 软件 PAGEREF_Toc256000012\h5
HYPERLINK\l"_Toc256000013"2. 硬件 PAGEREF_Toc256000013\h5
HYPERLINK\l"_Toc256000014"(二) 系统搭建 PAGEREF_Toc256000014\h5


现状和需求
现状与问题
日志文件分散在各个应用服务器，开发人员必须远程登录才能查看日志，不利于服务器安全管控，加大生产服务器的风险；
服务器上各项目日志配置很随意，文件分布杂乱，没有统一的规范和管理；
日志文件占用服务器大量的硬盘空间，如不及时清理会发生硬盘占满，影响系统的正常运行；
对于超过百兆的日志文件根本没法打开和关键字搜索，不利于问题的快速定位和排查；
集群和分布式的系统需要查看多个服务器的日志
日志保存的时间不统一，不能长时间保存日志

需求说明与分析
不需要开发人员登录生产服务器就能查看日志；
统一规范日志的配置和输出格式；
实时的将日志文件从服务器中迁出；
提供日志的检索和统计分析的平台；

建设目标
搭建支持高并发高可靠的日志分析平台，方便开发人员快速的检索日志，排查问题，同时提供友好的分析和统计的界面。

系统设计
技术选型
针对这些问题，为了提供分布式的实时日志搜集和分析的监控系统，我们采用了业界通用的日志数据管理解决方案-它主要包括Elasticsearch、Logstash和Kibana三个系统。通常，业界把这套方案简称为ELK，取三个系统的首字母。调研了ELK技术栈，发现新一代的logstash-forward即Filebeat，使用了golang，性能超logstash，部署简单，占用资源少，可以很方便的和logstash和ES对接，作为日志文件采集组件。所以决定使用ELK+Filebeat的架构进行平台搭建。
为了支持日志的高并发和高可靠需要进了消息队列（MQ），这里选择了kafka，相对其他消息中间件，kafka有支持大并发，快速持久化等优点，而且ELK+Filebeat对kafka的兼容性也很好。

最终，我们采用Elasticsearch+Logstash+Kibana+Filebeat+Kafka+Zookeeper的架构搭建日志分析平台。

系统架构
架构图

架构分析
第一层、数据采集层
最左边的是业务服务器集群，上面安装了filebeat做日志采集，同时把采集的日志分别发送给两个logstash服务。

第二层、数据处理层，数据缓存层
logstash服务把接受到的日志经过格式处理，转存到本地的kafkab