近年来，业务系统逐渐往云化架构发展。
云化后，业务系统的复杂性与日俱增，服务器数量大幅度增长，出现故障的几率也不断增加，服务器上面临着以下诸多问题：
这些痛点具体表现为：
孤
跨业务系统日志、流水号、订单号、无法进行关联分析；
散
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
技术架构
我们再了解一下它的技术架构：
广东移动通过搭建统一日志平台实现日志搜集、过滤、传输、储存，对海量系统和组件日志进行集中管理和实时搜索、分析，使用搜索、监控、事件消息和报表等简单易用的功能，帮助运维人员进行线上业务的实时监控、业务异常及时定位原因、排除故障，深度挖掘日志的数据价值。
从“被动到主动”、“单维到多维”、“事后到事前”、“片面到全局”的转变，日志数据分析经历了一系列的“蜕变”。
海量日志数据的价值挖掘对业务系统“生产运维、研发测试”相关决策中发挥着重要作用，将会越来越受到人们的重视。
相信未来实时日志分析将会有更蓬勃的发展，更多的成熟解决方案会涌现和落地！
