日志系统架构介绍（非原创）

文章大纲

1、日志系统概念介绍
2、ELK日志系统介绍
3、互联网行业日志处理方案介绍
4、参考文章

 

1、日志系统概念介绍

1. 简介

日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员能够经过日志了解服务器软硬件信息、检查配置过程当中的错误及错误发生的缘由。常常分析日志能够了解服务器的负荷，性能安全性，从而及时采起措施纠正错误。
一般，日志被分散在储存不一样的设备上。若是你管理数十上百台服务器，你还在使用依次登陆每台机器的传统方法查阅日志。这样是否是感受很繁琐和效率低下。当务之急咱们使用集中化的日志管理，例如：开源的syslog，将全部服务器上的日志收集汇总。
集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，通常咱们使用grep、awk和wc等Linux命令能实现检索和统计，可是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法不免有点力不从心。
大数据时代，随着数据量不断增加，存储与计算集群的规模也逐渐扩大，几百上千台的云计算环境已不鲜见。如今的集群所须要解决的问题不只仅是高性能、高可靠性、高可扩展性，还须要面对易维护性以及数据平台内部的数据共享性等诸多挑战。优秀的系统运维平台既能实现数据平台各组件的集中式管理、方便系统运维人员平常监测、提高运维效率，又能反馈系统运行状态给系统开发人员。例如采集数据仓库的日志能够按照时间序列查看各数据库实例各类级别的日志数量与占比，采集DB2表空间数据分析可获得数据库集群健康状态，分析应用服务器的日志能够查看出错最多的模块、下载最多的文件、使用最多的功能等。大数据时代的业务与运维将紧密的结合在一块儿。

2. 日志分类

日志是带时间戳的基于时间序列的机器数据，包括IT系统信息（服务器、网络设备、操做系统、应用软件）、物联网各类传感器信息。日志能够反映用户行为，是真实数据。
日志处理方案经历的版本迭代

 

日志处理v1.0
日志没有集中式处理；只作过后追查，黑客入侵后删除日志没法察觉；使用数据库存储日志，没法胜任复琐事务处理。

日志处理v2.0
使用Hadoop平台实现日志离线批处理，缺点是实时性差；使用Storm流处理框架、Spark内存计算框架处理日志，但Hadoop/Storm/Spark都是编程框架，并非拿来即用的平台。

日志处理v3.0
使用日志实时搜索引擎分析日志，特色：第一是快，日志从产生到搜索分析出结果只有数秒延时；第二是大，天天处理TB日志量；第三是灵活，可搜索分析任何日志。做为表明的解决方案有Splunk、ELK、SILK。

3. 日志实时性分析

 

实时
通常适用于咱们常说的一级应用，如：直接面向用户的应用。咱们能够自定义各种关键字，以方便在出现各类 error 或 exception 时，相关业务人员可以在第一时间被通知到。

准实时
通常适用于一些项目管理的平台，如：在须要填写工时的时候出现了宕机，但这并不影响工资的发放。

平台在几分钟后完成重启，咱们能够再登陆填写，该状况并不形成原则性的影响。所以，咱们能够将其列为准实时的级别。

除了直接采集错误与异常，咱们还须要进行分析。例如：仅知道某人的体重是没什么意义的，可是若是增长了性别和身高两个指标，那么咱们就能够判断出此人的体重是否为标准体重。

也就是说：若是能给出多个指标，就能够对庞大的数据进行去噪，而后经过回归分析，让采集到的数据更有意义。

此外，咱们还要不断地去还原数字的真实性。特别是对于实时的一级应用，咱们要能快速地让用户明白他们所碰到现象的真实含义。

例如：商家在上架时错把商品的价格标签 100 元标成了 10 元。这会致使商品立刻被抢购一空。

可是这种现象并不是是业务的问题，很难被发现，所以咱们只能经过日志数据进行逻辑分析，及时反馈以保证在几十秒以后将库存修改成零，从而有效地解决此问题。可见，在此应用场景中，实时分析就显得很是有用。

最后是追溯，咱们须要在获取历史信息的同时，实现跨时间维度的对比与总结，那么追溯就可以在各类应用中发挥其关联性做用了。

4. 完整的日志系统包含内容

（1）收集－可以采集多种来源的日志数据
（2）传输－可以稳定的把日志数据传输到中央系统
（3）存储－如何存储日志数据
（4）分析－能够支持 UI 分析
（5）警告－可以提供错误报告，监控机制

ELK提供了一整套解决方案，而且都是开源软件，之间互相配合使用，完美衔接，高效的知足了不少场合的应用。目前主流的一种日志系统。

5. 完整的日志系统做用

（1）信息查找。经过检索日志信息，定位相应的bug，找出解决方案。
（2）服务诊断。经过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态，找出耗时请求进行优化等等。
（3）数据分析。若是是格式化的log，能够作进一步的数据分析，统计、聚合出有意义的信息，好比根据请求中的商品id，找出TOP10用户感兴趣商品。

2、ELK日志系统介绍

1. ELK组成成分

ELK Stack是开源日志处理平台解决方案，背后的商业公司是elastic(https://www.elastic.co/)。它由日志采集解析工具Logstash、基于Lucene的全文搜索引擎Elasticsearch、分析可视化平台Kibana组成。目前ELK的用户有Adobe、Microsoft、Mozilla、Facebook、Stackoverflow、Cisco、ebay、Uber等诸多厂商。

2. ELK工做原理展现图

 

3. Elasticsearch介绍

Elasticsearch是基于Lucene的近实时搜索平台，它能在一秒内返回你要查找的且已经在Elasticsearch作了索引的文档。它默认基于Gossip路由算法的自动发现机制构建配置有相同cluster name的集群，可是有的时候这种机制并不可靠，会发生脑裂现象。鉴于主动发现机制的不稳定性，用户能够选择在每个节点上配置集群其余节点的主机名，在启动集群时进行被动发现。
Elasticsearch中的Index是一组具备类似特征的文档集合，相似于关系数据库模型中的数据库实例，Index中能够指定Type区分不一样的文档，相似于数据库实例中的关系表，Document是存储的基本单位，都是JSON格式，相似于关系表中行级对象。咱们处理后的JSON文档格式的日志都要在Elasticsearch中作索引，相应的Logstash有Elasticsearch output插件，对于用户是透明的。

4. Logstash介绍

Logstash事件处理有三个阶段：inputs → filters → outputs。是一个接收，处理，转发日志的工具。支持系统日志，webserver日志，错误日志，应用日志，总之包括全部能够抛出来的日志类型。
Logstash工做原理：

 

5. Kibana介绍

Kibana是专门设计用来与Elasticsearch协做的，能够自定义多种表格、柱状图、饼状图、折线图对存储在Elasticsearch中的数据进行深刻挖掘分析与可视化。下图定制的仪表盘能够动态监测数据库集群中每一个数据库实例产生的各类级别的日志。
实时监测DB2实例运行状态的动态仪表盘：

 

6. ELK总体方案

ELK中的三个系统分别扮演不一样的角色，组成了一个总体的解决方案。Logstash是一个ETL工具，负责从每台机器抓取日志数据，对数据进行格式转换和处理后，输出到Elasticsearch中存储。Elasticsearch是一个分布式搜索引擎和分析引擎，用于数据存储，可提供实时的数据查询。Kibana是一个数据可视化服务，根据用户的操做从Elasticsearch中查询数据，造成相应的分析结果，以图表的形式展示给用户。
ELK的安装很简单，能够按照"下载->修改配置文件->启动"方法分别部署三个系统，也可使用docker来快速部署。具体的安装方法这里不详细介绍，下面来看一个常见的部署方案，以下图所示，部署思路是：
（1）在每台生成日志文件的机器上，部署Logstash，做为Shipper的角色，负责从日志文件中提取数据，可是不作任何处理，直接将数据输出到Redis队列(list)中；
（2）须要一台机器部署Logstash，做为Indexer的角色，负责从Redis中取出数据，对数据进行格式化和相关处理后，输出到Elasticsearch中存储；
（3）部署Elasticsearch集群，固然取决于你的数据量了，数据量小的话可使用单台服务，若是作集群的话，最好是有3个以上节点，同时还须要部署相关的监控插件；
（4）部署Kibana服务，提供Web服务。

 

在前期部署阶段，主要工做是Logstash节点和Elasticsearch集群的部署，而在后期使用阶段，主要工做就是Elasticsearch集群的监控和使用Kibana来检索、分析日志数据了，固然也能够直接编写程序来消费Elasticsearch中的数据。

在上面的部署方案中，咱们将Logstash分为Shipper和Indexer两种角色来完成不一样的工做，中间经过Redis作数据管道，为何要这样作？为何不是直接在每台机器上使用Logstash提取数据、处理、存入Elasticsearch？

首先，采用这样的架构部署，有三点优点：第一，下降对日志所在机器的影响，这些机器上通常都部署着反向代理或应用服务，自己负载就很重了，因此尽量的在这些机器上少作事；第二，若是有不少台机器须要作日志收集，那么让每台机器都向Elasticsearch持续写入数据，必然会对Elasticsearch形成压力，所以须要对数据进行缓冲，同时，这样的缓冲也能够必定程度的保护数据不丢失；第三，将日志数据的格式化与处理放到Indexer中统一作，能够在一处修改代码、部署，避免须要到多台机器上去修改配置。

其次，咱们须要作的是将数据放入一个消息队列中进行缓冲，因此Redis只是其中一个选择，也能够是RabbitMQ、Kafka等等，在实际生产中，Redis与Kafka用的比较多。因为Redis集群通常都是经过key来作分片，没法对list类型作集群，在数据量大的时候必然不合适了，而Kafka天生就是分布式的消息队列系统。

 

3、互联网行业日志处理方案介绍

1. 新浪

新浪采用的技术架构是常见的Kafka整合ELK Stack方案。Kafka做为消息队列用来缓存用户日志；使用Logstash作日志解析，统一成JSON格式输出给Elasticsearch；使用Elasticsearch提供实时日志分析与强大的搜索和统计服务；Kibana用做数据可视化组件。该技术架构目前服务的用户包括微博、微盘、云存储、弹性计算平台等十多个部门的多个产品的日志搜索分析业务，天天处理约32亿条（2TB）日志。
新浪的日志处理平台团队对Elasticsearch作了大量优化（好比调整max open files等），而且开发了一个独立的Elasticsearch Index管理系统，负责索引平常维护任务（好比索引的建立、优化、删除、与分布式文件系统的数据交换等）的调度及执行。为Elasticsearch安装了国内中文分词插件elasticsearch-analysis-ik，知足微盘搜索对中文分词的需求。

2. 腾讯

腾讯蓝鲸数据平台告警系统的技术架构一样基于分布式消息队列和全文搜索引擎。但腾讯的告警平台不只限于此，它的复杂的指标数据统计任务经过使用Storm自定义流式计算任务的方法实现，异常检测的实现利用了曲线的时间周期性和相关曲线之间的相关性去定义动态的阈值，而且基于机器学习算法实现了复杂的日志自动分类（好比summo logic）。
告警平台把拨测（定时curl一下某个url，有问题就告警）、日志集中检索、日志告警（5分钟Error大于X次告警）、指标告警（cpu使用率大于X告警）整合进同一个数据管线，简化了总体的架构。

3. 七牛

七牛采用的技术架构为Flume＋Kafka＋Spark，混部在8台高配机器。根据七牛技术博客提供的数据，该日志处理平台天天处理500亿条数据，峰值80万TPS。
Flume相较于Logstash有更大的吞吐量，并且与HDFS整合的性能比Logstash强不少。七牛技术架构选型显然考虑了这一点，七牛云平台的日志数据到Kafka后，一路同步到HDFS，用于离线统计，另外一路用于使用Spark Streaming进行实时计算，计算结果保存在Mongodb集群中。
任何解决方案都不是十全十美的，具体采用哪些技术要深刻了解本身的应用场景。就目前日志处理领域的开源组件来讲，在如下几个方面还比较欠缺：

4、参考文章

1. https://blog.csdn.net/yunzhaji3762/article/details/82962291
2. https://blog.csdn.net/bigstar863/article/details/49099531
3. https://www.cnblogs.com/kevingrace/p/5919021.html