CN106844171A - 一种海量运维的实现方法 - Google Patents

Abstract

本发明提供一种海量运维的实现方法，属于产品全生命周期运维技术领域，本发明以整个业务***为视角整体业务***关联的主机、数据库、中间件、业务***的日志信息，通过大数据分析海量日志，分析信息***在软件、硬件环境下可能出现的功能和性能问题。有效监控到信息***甚至具体业务功能在硬件、软件、服务层面的问题，增强服务能力，控制运维风险整体，提高运维效率。

Description

一种海量运维的实现方法

技术领域

本发明涉及产品全生命周期运维技术，尤其涉及一种海量运维的实现方法。

背景技术

大型研发团队通常会面临从开发、测试到生产再到后期运维各个环节麻烦不断的问题，每个环节出现的问题因为不能及时发现，导致一个点被放大到最终用户的使用，严重的会影响用户满意度，进而影响到收益。

此时需要建立一种机制来提供产品全生命周期过程中的运维机制，研发人员的代码需要及时知道程序中的BUG，测试人员除了功能测试之外还需要清楚不同版本之间的性能差异，需要有一定的数据累积和数据比对方法，生产***发布新功能之后是否产生大量的错误，功能异常是否增多，这些影响最终用户体验的信息都应该被及时了解，并对问题进行及时的预警及时处理，日常运维也会牵扯到基础环境主机、中间件、数据库、网络层面是否健康良好。

如何保证开发环节的问题及时发现，测试中的潜在的版本问题被及时发现，以及生产***运行环境的监控状况，后期运维数据增长、功能响应时间的变化等能及时发现，这些都需要数据的日常观察，以及提供对性能缺陷的数据分析挖掘功能才能做到，而传统的运维方式会比较困难，这主要在于数据的采集比较分散，牵扯到服务器、网络、应用、中间件、数据库等多个层面的数据，采集技术也比较麻烦，而且这么大数据量的存储查询也面临极大的挑战，更不用说能及时的产生告警了。

一般信息***的管理方法往往在信息***问题出现后才会查看和分析日志，并且***中的日志存放过于分散，没有站在信息***的整体角度统一管理。从是指分散程度主要包括web中间件日志，例如：apache、http、nginx等；app中间件日志，例如：WebSphere、weblogic、tomcat等；主机的日志，包括：性能日志、***日志等；网络接口性能数据；数据库日志，例如：DB2、Oracle、Mysql等；应用日志，例如：log4j等；这些数据日志格式各不相同，传统方式运维起来非常麻烦，也比较孤立，很难有一种手段全方位分析，或者做到历史大数据分析都很困难。

发明内容

为了解决该问题，本发明提出了一种海量运维的实现方法。通过大数据相关技术改变传统运维不能实现的产品的全生命周期监控，并通过数据模型对性能进行分析提供一定的方法，进而建立业务功能层面的性能优化策略。

本发明运用大数据技术将传统无法实现的运维功能进行实现，同时通过大数据技术的运用好多潜在的功能问题、性能问题得以发现，及时预警。

本发明以整个业务***为视角整体业务***关联的主机、数据库、中间件、业务***的日志信息，通过大数据分析海量日志，分析信息***在软件、硬件环境下可能出现的功能和性能问题。

主要包括，

1）日志收集代理

Filebeat是一个日志收集器，以代理的方式部署在被监控服务器上，通过监控服务器上的日志目录或日志文件，收集日志文件中新增的日志内容，将日志经过logstash进一步处理后发送到elasticsearch上。

当启动Filebeat的时候，Filebeat会启动一个以上的harvester来监视所配置的日志文件，每个harvester读取一个单独的日志文件的内容。Filebeat会根据预先设置的收集周期去检查被监视的日志文件是否有新日志的增加，并收集新增加的日志内容。

2）日志处理和传输

Logstash是一个用于收集、分析和存储日志的工具；Logstash收集从Filebeat传输过来的日志，对日志进行过滤和处理，进一步将日志发送到elasticsearch上存储。

LogStash服务部署完成后，需要配置 Logstash 以指明从哪里读取数据，向哪里输出数据；这个过程称之为定义 Logstash 管道；一个管道需要包括必须的输入，输出，和一个可选项目 filter。

输入中配置了Beats端口，用来接收Filebeat的连接；输出中配置elasticsearch主机和端口，用于传输日志到目标elasticsearch集群；filter配置过滤条件和处理语句。

3）日志存储

Elasticsearch是一个开源的高扩展的分布式全文检索引擎，通过设置节点的名字和集群的名字，就能自动的组织相同集群名字的节点加入到集群中。

使用路由功能只在一个分片上执行查询命令，提高***吞吐量；

在启动Elasticsearch之前要设置好http.port端口，并在Logstash的输出配置中设置分发到Elasticsearch集群中各个节点的IP和http.port端口；Logstash就会把从Filebeat中收集到的日志内容分发存储到Elasticsearch集群中。

4）日志分析和展示

Kibana是一个为ElasticSearch提供的日志分析和展示平台，使用它对存储在ElasticSearch中的日志进行搜索、可视化、分析操作。

Kibana所有的属性都是在kibana.yml文件中设置，通过在此配置文件中设置elasticsearch.url属性为ElasticSearch集群中节点的IP和http.port端口即可；Kibana自身对外服务的端口通过server.port在kibana.yml配置文件中设置，此端口默认值是5601。

5)数据分析

通过三个分析思路,选取不同时间段代表业务周期的两条曲线进行总结：

5.1）、曲线平滑：故障是对近期趋势的一个破坏，视觉上来说就是不平滑；

5.2）、绝对值的时间周期性：两条曲线几乎重合；

5.3）、波动的时间周期性：假设两个曲线不重合，在相同时间点的波动趋势和振幅也是类似的。

本发明要实现信息***日志的集中管控，以信息***为视角以具体功能为视角，集中管理和分析信息***相关的主机信息、数据库服务、中间件服务、业务应用的日志信息。

以整个业务***为视角整体业务***关联的主机、数据库、中间件、业务***的日志信息，通过大数据分析海量日志，分析信息***在软件、硬件环境下可能出现的功能和性能问题。

本发明的有益效果是

采用该方法可以有效监控到信息***甚至具体业务功能在硬件、软件、服务层面的问题，增强服务能力，控制运维风险整体，提高运维效率。

以业务***以及业务***的具体功能为视角整体监控关联的资源，将不同方面的运维数据包括主机、中间件、数据库和应用***所涵盖的全方位数据进行手机，并能按照日志级别分类，覆盖产品全生命周期的运维分析；

采用大数据的分析工具，根据解决传统方式无法解决的数据存储以及数据查询的问题，并且采用轻量级的日志收集代理，占用***资源小，能够在不影响具体业务的情况下实时预警；

***日志监测自动化，产生日志实时收集；因网络原因造成日志传输失败，网络恢复后日志续传；

分布式日志数据集中式查询和管理，对海量***和组件日志进行集中管理和准实时搜索、监控、分析；

通过大数据的分析手段能够结合几种常用的性能问题分析手段从而及时对***进行异常检测，实现传统静态阈值无法实现的功能。

附图说明

图1是本发明的技术实现示意图。

具体实施方式

下面对本发明的内容进行更加详细的阐述：

技术实现示意图如图1所示。技术实现方案如下：

(一)日志收集代理

Filebeat是一个日志收集器，以代理的方式部署在被监控服务器上，通过监控服务器上的日志目录或日志文件，收集日志文件中新增的日志内容，将日志经过logstash进一步处理后发送到elasticsearch上。Filebeat是轻量级的代理程序，占用***资源非常小，并且提供不同平台的安装包，解压可用，简化了在不同平台部署和配置的复杂度。通过合理的设置，Filebeat支持几乎任何类型的日志，包括***日志、错误日志和自定义应用程序日志。

当启动Filebeat的时候，Filebeat会启动一个或多个harvester来监视我们所配置的日志文件，每个harvester读取一个单独的日志文件的内容。Filebeat会根据预先设置的收集周期去检查被监视的日志文件是否有新日志的增加，并收集新增加的日志内容。

(二)日志处理和传输

Logstash是一个用于收集、分析和存储日志的工具。Logstash收集从Filebeat传输过来的日志，对日志进行过滤和处理，进一步将日志发送到elasticsearch上存储。

LogStash架构专为收集、分析和存储日志所设计，是一个具有实时渠道能力的数据收集引擎。LogStash服务部署完成后，我们需要配置 Logstash 以指明从哪里读取数据，向哪里输出数据。这个过程我们称之为定义 Logstash 管道（Logstash Pipeline）。通常一个管道需要包括必须的输入（input），输出（output），和一个可选项目 filter。input中配置了Beats端口，用来接收Filebeat的连接；output中配置elasticsearch主机和端口，用于传输日志到目标elasticsearch集群；filter配置过滤条件和处理语句，Logstash的filter有广泛的插件，满足各种对日志内容处理的需求。

(三)日志存储

Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。Elasticsearch通过设置节点的名字和集群的名字，就能自动的组织相同集群名字的节点加入到集群中，并使很多的技术对用户透明化，分布式集群搭建非常简单。

为集群选择合适的分片(shard)和分片副本(replica)的数量，合理的使用路由对ElasticSearch分布式集群性能的提升至关重要。关于索引分片，要求尽量少的分片，避免过度分片以提高查询速度。使用路由功能可以只在一个分片上执行查询命令，作为提高***吞吐量的一种解决方案。

在启动Elasticsearch之前要设置好http.port端口，并在Logstash的输出配置中设置分发到Elasticsearch集群中各个节点的IP和http.port端口。Logstash就会把从Filebeat中收集到的日志内容分发存储到Elasticsearch集群中。

(四)日志分析和展示

Kibana是一个为ElasticSearch提供的日志分析和展示平台，可使用它对存储在ElasticSearch中的日志进行高效的搜索、可视化、分析等各种操作。Kibana可以简便的读取大量的ElasticSearch中的日志数据，它简易的基于浏览器的交互方式可以实时的检测到ElasticSearch中数据的变化。

Kibana所有的属性都是在kibana.yml文件中设置，通过在此配置文件中设置elasticsearch.url属性为ElasticSearch集群中节点的IP和http.port端口即可。Kibana自身对外服务的端口通过server.port在kibana.yml配置文件中设置，此端口默认值是5601。

(五)数据分析的几个思路

通过大数据的比对的方法提供三个分析思路,选取不同时间段代表一定业务周期的两条曲线进行总结：

1、曲线平滑：故障一般是对近期趋势的一个破坏，视觉上来说就是不平滑

2、绝对值的时间周期性：两条曲线几乎重合

3、波动的时间周期性：假设两个曲线不重合，在相同时间点的波动趋势和振幅也是类似的

具体的分析方法如下：

曲线平滑的分析方法

这种检测的根据是在一个最近的时间窗口，比如1个小时。曲线会遵循某种趋势，而新的数据点打破了这种趋势，使得曲线不光滑了。也就是说，这种检测利用的是时间序列的时间依赖，T对于T-1有很强的趋势依赖性。业务逻辑上来说，10:00 有很多人登陆，10:01 也有很多人来登陆的概率是很高的，因为吸引人来登陆的因素是有很强的惯性的。但是10月11日很多人来登陆，11月11日也有很多人来登陆的惯性就要差很多。

绝对值的时间周期性分析方法

很多监控曲线都有这样以一天为周期的周期性（凌晨3、4点最低，上午9、10点最高之类的）。一种利用时间周期性的最简单的算法

min(7 days history) * 0.6

对历史7天的曲线取最小值。怎么个取最小值的方法。对于8:05分，有7天对应的点，取最小值。对于8:06分，有7天对应的点，取最小值。这样可以得出一条一天的曲线。然后对这个曲线整体乘以0.6。如果几天的曲线低于这条参考线则告警。

这其实是一种静态阈值告警的升级版，动态阈值告警。过去静态阈值是一个根据历史经验拍脑袋的产物。用这个算法，其实是把同时间点的历史值做为依据，计算出一个最不可能的下界。同时阈值不是唯一的一个，而是每个时间点有一个。如果1分钟一个点，一天中就有1440个下界阈值。

实际使用中0.6当然还是要酌情调整的。而且一个严重的问题是如果7天历史中有停机发布或者故障，那么最小值会受到影响。也就是说不能把历史当成正常，而是要把历史剔除掉异常值之后再进行计算。一个务实的近似的做法是取第二小的值。

为了让告警更加精确，可以累积计算实际曲线和参考曲线的差值之和。也就是相对于参考曲线下跌的面积。这个面积超过一定的值则告警。对于深度下跌，则累积几个点就可以告警。对于浅度下跌，那么多累几个点也可以告警出来。翻译成人话就是，一下在跌了很多，则很有可能是故障了。或者连续好久都偏离正常值，那么也很有可能是出问题了。

振幅的时间周期性分析方法

有些时候曲线是有周期性，但是两个周期的曲线相叠加是不重合的。两个周期的曲线一叠加，一个会比另外一个高出一头。对于这种情况，利用绝对值告警就会有问题。

比如今天是10.1日，放假第一天。过去7天的历史曲线必然会比今天的曲线低很多。那么今天出了一个小故障，曲线下跌了，相对于过去7天的曲线仍然是高很多的。这样的故障如何能够检测得出来。一个直觉的说法是，两个曲线虽然不一样高，但是“长得差不多”。那么怎么利用这种“长得差不多”呢。那就是振幅了。

与其用x(t)的值，不如用x(t) – x(t-1)的值，也就是把绝对值变成变化速度。可以直接利用这个速度值，也可以是 x(t) – x(t-1) 再除以 x(t-1)，也就是一个速度相对于绝对值的比率。比如t时刻的在线900人，t-1时刻的在线是1000人，那么可以计算出掉线人数是10%。这个掉线比率在历史同时刻是高还是低。那么就和前面一样处理了。

实际使用中有两个技巧：可以是x(t) – x(t-1），也可以是x(t) – x(t-5）等值。跨度越大，越可以检测出一些缓慢下降的情况。

另外一个技巧是可以计算x(t) -x(t-2)，以及x(t+1) – x(t-1)，如果两个值都异常则认为是真的异常，可以避免一个点的数据缺陷问题。

运用大数据分析工具解决了传统运维无法解决的海量数据如何采集以及分析的问题，解决了大型研发团队全生命周期，包括开发、测试、生产、运维全生命周期的运维数据存储以及挖掘问题。

本发明采用大数据分析手段，该方案保证数据能够全领域涵盖，同时数据运用分布式存储以及查询技术，能够快速查询快速分析，进而实现告警的及时性，解决传统静态阈值告警无法发现的潜在问题。

Claims (7)

1.一种海量运维的实现方法，其特征在于，以整个业务***为视角整体业务***关联的主机、数据库、中间件、业务***的日志信息，通过大数据分析海量日志，分析信息***在软件、硬件环境下出现的功能和性能问题。

2.根据权利要求1所述的方法，其特征在于，

主要包括，

1）日志收集代理

Filebeat是一个日志收集器，以代理的方式部署在被监控服务器上，通过监控服务器上的日志目录或日志文件，收集日志文件中新增的日志内容，将日志经过logstash进一步处理后发送到elasticsearch上；

2）日志处理和传输

Logstash是一个用于收集、分析和存储日志的工具；Logstash收集从Filebeat传输过来的日志，对日志进行过滤和处理，进一步将日志发送到elasticsearch上存储；

3）日志存储

Elasticsearch是一个开源的高扩展的分布式全文检索引擎，通过设置节点的名字和集群的名字，就能自动的组织相同集群名字的节点加入到集群中；

4）日志分析和展示

Kibana是一个为ElasticSearch提供的日志分析和展示平台，使用它对存储在ElasticSearch中的日志进行搜索、可视化、分析操作；

5)数据分析

通过三个分析思路,选取不同时间段代表业务周期的两条曲线进行总结：

5.1）、曲线平滑：故障是对近期趋势的一个破坏，视觉上来说就是不平滑；

5.2）、绝对值的时间周期性：两条曲线几乎重合；

5.3）、波动的时间周期性：假设两个曲线不重合，在相同时间点的波动趋势和振幅也是类似的。

3.根据权利要求2所述的方法，其特征在于，

当启动Filebeat的时候，Filebeat会启动一个以上的harvester来监视所配置的日志文件，每个harvester读取一个单独的日志文件的内容；Filebeat会根据预先设置的收集周期去检查被监视的日志文件是否有新日志的增加，并收集新增加的日志内容。

4.根据权利要求2所述的方法，其特征在于，

LogStash服务部署完成后，需要配置 Logstash 以指明从哪里读取数据，向哪里输出数据；这个过程称之为定义 Logstash 管道；一个管道需要包括输入，输出，和一个可选项目 filter。

5.根据权利要求4所述的方法，其特征在于，

输入中配置了Beats端口，用来接收Filebeat的连接；输出中配置elasticsearch主机和端口，用于传输日志到目标elasticsearch集群；filter配置过滤条件和处理语句。

6.根据权利要求2所述的方法，其特征在于，

使用路由功能只在一个分片上执行查询命令，提高***吞吐量；

在启动Elasticsearch之前要设置好http.port端口，并在Logstash的输出配置中设置分发到Elasticsearch集群中各个节点的IP和http.port端口；Logstash就会把从Filebeat中收集到的日志内容分发存储到Elasticsearch集群中。

7.根据权利要求2所述的方法，其特征在于，

Kibana所有的属性都是在kibana.yml文件中设置，通过在此配置文件中设置elasticsearch.url属性为ElasticSearch集群中节点的IP和http.port端口即可；Kibana自身对外服务的端口通过server.port在kibana.yml配置文件中设置，此端口默认值是5601。