日志处理方案

嗨咯沃得

已于 2022-10-13 10:05:53 修改

阅读量1.4k

点赞数

分类专栏：运维工具文章标签：搜索引擎 elasticsearch 大数据

于 2022-09-18 21:34:12 首次发布

本文链接：https://blog.csdn.net/m0_46673598/article/details/126923062

版权

运维工具专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、日志的作用

1、日志记录下了服务器各种行为信息，出现错误时可以通过日志可以排错

2、分析日志可以了解服务器的一些性能，也可以做一些数据分析统计，类似于大数据分析

二、日志处理版本迭代

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

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

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

三、完整的日志系统包含内容

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

四、日志处理系统的作用

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

五、elk+kafka日志处理方案

elk介绍：

它由日志采集解析工具Logstash、基于Lucene的全文搜索引擎Elasticsearch、分析可视化平台Kibana组成。ELK中的三个系统分别扮演不同的角色，组成了一个整体的解决方案。Logstash是一个ETL工具，负责从每台机器抓取日志数据，对数据进行格式转换和处理后，输出到Elasticsearch中存储。Elasticsearch是一个分布式搜索引擎和分析引擎，用于数据存储，可提供实时的数据查询。Kibana是一个数据可视化服务，根据用户的操作从Elasticsearch中查询数据，形成相应的分析结果，以图表的形式展现给用户。

Elasticsearch介绍

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

Logstash介绍

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

Kibana介绍

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

方案图

这里为什么要加入消息队列kakfa？

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

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

其次，我们需要做的是将数据放入一个消息队列中进行缓冲，所以Redis只是其中一个选择，也可以是RabbitMQ、Kafka等等，在实际生产中，Redis与Kafka用的比较多。由于Redis集群一般都是通过key来做分片，无法对list类型做集群，在数据量大的时候必然不合适了，而Kafka天生就是分布式的消息队列系统。

六、常见的存储中间件

redis +

消息队列：

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

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集群中。
任何解决方案都不是十全十美的，具体采用哪些技术要深入了解自己的应用场景。

参考：日志系统架构介绍（非原创） - 走看看 (zoukankan.com)