近年来，业务系统逐渐往云化架构发展。

云化后，业务系统的复杂性与日俱增，服务器数量大幅度增长，出现故障的几率也不断增加，服务器上面临着以下诸多问题：

这些痛点具体表现为：

孤

跨业务系统日志、流水号、订单号、无法进行关联分析；

散

GB~TB级，分布在数百服务器，无法统一管理；

繁

精通awk/sed/sort/uniq，分别登录主机，重定向文件，多次加工；

慢

无实时日志监控告警，出现问题发现不及时，排查耗时；

难

业务系统众多，日志量级逐年增加，系统内部复杂、外部关联复杂；

险

操作风险、敏感信息泄露等安全隐患。

今天IT妹邀请IT小哥为大家讲讲：云化后面临的这些令人头大的难题，该怎么解决？

话不多说，小板凳搬过来！跟着IT小哥涨知识啦！

解决思路：转变

日志数据分析思路转变

——从事件触发向数据驱动

传统的运维方式对日志的处理是：

客户报障

发现问题

被动、逐个查日志

如上的处理流程是事后的排查故障，无法做到全面的核查，且需每台主机进行日志查询过滤，处理效率低下。

为了解决上述问题，广东移动转换思路，研究成熟的实时日志分析平台，实现从“被动到主动”、“单维到多维”、“事后到事前”、“片面到全局”的转变。

实时日志分析平台整合了共享日志信息碎片，利用数据分析判定运行趋势，提前发现问题隐患，对于常见故障精确定位并自动处理。

解决方案：分析、实施

根据上述思路，为了实现我们业务日志的智能化目标，我们分析了两类解决方案，分别是方案A和方案B。

一、 解决方案A

01

方案A采用ELK架构

ELK主要由Elasticsearch、Logstash和Kibana三部分组件组成，它提供了一整套解决方案。ELK各组件之间互相配合使用，完美衔接，满足了很多场合的应用，是目前最主流的一种日志分析管理系统。

ELK可以将我们业务系统的各种日志进行收集、过滤、清洗，然后进行集中存放并用于实时的检索和分析。

ELK三款软件通常是配合使用的，目前都已经归于http://Elastic.co公司名下，故又被简称为ELK Stack，基础组成如下所示。

02

ELK各组件功能介绍

ELK中，Elasticsearch、Logstash和Kibana三部分组件具有不同的功能：

1、Elasticsearch

Elasticsearch是一个实时的分布式搜索和分析引擎，可以用于全文搜索，结构化搜索以及分析。其主要特点是：

✍实时搜索，实时分析

✍分布式的架构、实时文件存储，可以将每一个字段都编入索引

✍文档导向，所有的对象都是文档

✍高可用性，容易扩展，支持集群、分片和复制等方式

2、Logstash

Logstash是一款轻量级的日志收集处理框架，它可以很方便把分散的、多样化的日志搜索起来，并进行自定义过滤分析处理，然后传输到指定的位置。它的主要特点是：

✍几乎可以访问任何数据

✍可以和多种外部应用整合

✍支持动态、弹性扩展

从功能上来讲，虽然Logstash只做如下三件事情，但通过组合输入和输出，可以变幻出多种架构实现不同的需求。

✍Input:数据收集

✍Filter：数据加工，如过滤、改写等

✍Output：数据输出

Logstash的逻辑架构如下图所示：

其中，每个部分的含义如下：

✍Shipper：主要用来收集日志数据，负责监控本地日志文件的变化，及时把日志文件的最新内容收集起来，然后经过加工、过滤，输出到Broker。

✍Broker：用来连接多个Shipper和多个Indexer。推荐使用Kafka作为Broker，这个Broker起数据缓存的作用。

✍Indexer：从Broker读取文本，经过加工、过滤，输出到指定的位置中。

3、Kibana

Kibana是数据分析可视化平台。使用Kibana可以Logstash 和 ElasticSearch提供的日志数据进行高效的搜索、可视化汇总和多维度的分析。Kibana拥有强大的数据可视化功能，灵活的报表制作、丰富的代表盘让日志信息一目了然。

03

ELK的工作流程

在需要收集日志的应用服务器上部署Logstash，Logstash Shipper用于监控并收集、过滤日志。接着将过滤后的日志发送给Broker。然后，Logstash Indexer将存放在Broker中的数据再写入到Elasticsearch集群中，Elasticsearch集群将这些数据创建索引，最后由Kibana对其进行各种分析并进行图表的形式展示处理。

ELK的工作流程如下图所示：

04

ELK 常见架构介绍

与业务系统架构类似，ELK架构也在不断演进变化。那么ELK在各个阶段的架构都有什么特点呢？

1、最简单的ELK架构

下图为最简单的ELK架构：

步骤说明：

(1)Logstash部署在应用服务器上搜集相关的日志数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。

(2)Elasticsearch再将数据以分片的形式进行压缩存储，并提供多种API供使用者查询、操作。

(3)用户可以通过Kibana Web直观对日志进行查询，并根据需求生成数据报表。

此种架构的优缺点：

✍ 优点：部署简单，容易上手

✍ 缺点：Logstash将日志读出、过滤、输出都是在应用服务器上进行的，这势必会造成服务器上占用系统资源较高，性能不佳。同时，在大并发情况下，日志传输峰值比较大，如果直接写入Elasticsearch，Elasticsearch的HTTP API处理能力有限，在日志写入频繁的情况下可能会超时、丢失，所以需要一个缓冲中间件。

2、典型的ELK架构

为保证ELK收集日志数据的安全性和稳定性，此架构引入了消息队列机制，下图是典型的ELK架构。

典型的ELK架构主要是引入了消息队列机制，步骤如下：

a) 部署在应用服务器上的一级Logstash Agent先将数据传输给消息队列Kafka。

b) 二级Logstash Server将格式化的数据传递给Elasticsearch集群进行存储。

c) Kibana将日志和数据呈现给用户。

此架构的优缺点：

✍ 优点：引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性。

✍ 缺点：依然存在Logstash占用系统资源过多的问题，在海量的数据场景下，会出现性能瓶颈。

3、ELK集群架构

ELK集群架构是在典型的ELK架构基础上演进而来的，主要是将应用服务器上收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群的模式进行部署。ELK集群架构如下图所示：

ELK的集群架构适合大型集群、海量数据的业务场景，将应用服务器的数据采集组件更换为Filebeat，有效降低了收集日志对业务系统资源的消耗。

同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端的Logstash和Elasticsearch均采用集群模式部署，从而整体上提高了ELK系统的高效性、扩展性和吞吐量。

二、 解决方案B

01

方案B简介

方案B是一款文本日志搜索引擎，通过功能强大日志分析功能，帮助用户及时发现问题。

方案B为企业提供一个日志集中管理平台，配置简单、功能强大、容易使用的日志管理工具，通过对日志进行集中采集和准实时索引，提供搜索、分析、可视化和监控告警等功能，帮助企业进行线上业务实时监控、业务异常原因定位、业务日志数据统计分析及安全与合规审计。

02

功能架构

03

各组件功能介绍

组件

功能

Collector

日志数据汇聚层，agent等数据源的数据，做转换后存入消息队列Kafka。

Kafka

分布式消息队列

Logriver

数据流式处理层，预处理

beaver

搜索引擎,日志索引存储层，提供数据存储等

Splserver

在线分析引擎,数据查询用于处理用户提交SPL查询语句

Yottaweb

日志展示层，Web模块

Frontend

用于Agent心跳监听同时也是beavver前端，用于连接yottaweb和beaver，对beaver的结果做处理

Mysqld

数据库，用于存储规则、人员、告警等配置信息。

Zookeeper

用于存储很重要的配置信息，以及模块选举

Nginx

负载均衡模块

Heka

服务端agent

04

方案B功能优势

1、全方位海量数据源采集

以无侵害agent为主，通过多种方式全方位海量数据的采集，且采用web界面化操作采集：

2、智能流式日志解析

日志流式解析，平台内嵌大量规则，提供正则划选辅肋，通过图形界面配置，简易配置，快速上手。

3、分散日志集中查询

通过对分布式系统日志的集中检索，辅助运维人员分析定位问题。

05

技术架构

我们再了解一下它的技术架构：

广东移动通过搭建统一日志平台实现日志搜集、过滤、传输、储存，对海量系统和组件日志进行集中管理和实时搜索、分析，使用搜索、监控、事件消息和报表等简单易用的功能，帮助运维人员进行线上业务的实时监控、业务异常及时定位原因、排除故障，深度挖掘日志的数据价值。

从“被动到主动”、“单维到多维”、“事后到事前”、“片面到全局”的转变，日志数据分析经历了一系列的“蜕变”。

海量日志数据的价值挖掘对业务系统“生产运维、研发测试”相关决策中发挥着重要作用，将会越来越受到人们的重视。

相信未来实时日志分析将会有更蓬勃的发展，更多的成熟解决方案会涌现和落地！