日志系统架构介绍（非原创）
文章大纲
一、日志系统概念介绍
二、ELK日志系统介绍
三、互联网行业日志处理方案介绍
四、参考文章
一、日志系统概念介绍
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用户感兴趣商品。
二、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天生就是分布式的消息队列系统。
三、互联网行业日志处理方案介绍
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集群中。
任何解决方案都不是十全十美的，具体采用哪些技术要深入了解自己的应用场景。就目前日志处理领域的开源组件来说，在以下几个方面还比较欠缺：
