一体化监控各个厂家、不同类别的监控就像一座座孤岛占满了我们的监控屏。由于各种监控就像铁路警察各管一段，有些复杂的故障问题或性能问题的定位就变的很复杂，影响了问题的快速定位和故障处置。

 

如何构建一个一体化监控体系（或者整体监控体系），让IT运维人员掌控系统的整体运行情况和运行效能，预知未来系统运行的趋势，确保系统的安全稳定、高效运行，成为一个愈来愈紧迫的问题。

 

本文内容选自该领域专家曹贝及AIX专家俱乐部社区会员的精彩观点。

 

专家介绍

  

曹贝，北京邮电大学计算机硕士，多年的互联网研发设计及管理经验，擅长海量业务基础架构的构建，尤其在分分布式、云计算、自动化运维方面经验丰富。曾先后在某搜索引擎公司担任基础架构研发经理，国内某大型cdn公司（排名前二）担任云平台研发总监，现从事云计算与监控方面的创业。

 

1请谈谈在证券行业一体化监控实践过程中，遇到的坑及解决思路？

 

>>>> 

曹贝：

 

坑1：监控业务种类及其繁杂，比如：网络庞大，有众多的交换机、路由器、防火墙等；机房分布广，有主机房、备份机房、灾备中心及众多的营业网点；系统繁多，有集中交易、融资融券、网交系统、客户服务中心、个股期权、互联网中心等系统；技术和设备种类繁多，有数据库技术、虚拟化技术、大数据、私有云等等。造成大量的信息孤岛。

 

解决思路：标准化。

 

基于此，要大力推广标准化，形成企业为主的泰式，企业指定监控系统接入标准，供应商匹配企业标准，打破信息孤岛，实现信息互通。主要从以下几方面进行标准制定：

 

• 调用接口标准

  接入监控系统的接口标准化，例如：必须支持API/SDK之类的调用种类，参数设置及结果返回等

• 协议标准

  监控平台和供应商的服务进行通信时需要按照一定的协议标准，比如：必须支持snmp/tcp/http等数据通信协议，必须支持ssl等安全协议。

• 数据标准

  数据格式的标准化，比如：必须支持json/xml格式的数据返回等

 

坑2：由于监控种类太多，造成有些复杂的故障问题或性能问题的定位就变的很复杂，影响了问题的快速定位和故障处置。

 

解决思路：

 

证券行业监控需求的另一大痛点是业务复杂，彼此关联甚多，从而导致监控信息淹没，给问题的定位和排查造成巨大的困难

因此，要求一体化监控系统必须具备智能化的分析功能。从以下几方面加强：

 

• 建立系统关联，强化智能分析

具体来讲，依据整体的监控项，构建图数据模型，将所有监控的内在关联信息存储起来，在进行告警分析时按图索骥，即可快速实现问题定位。

 

例如：系统内部存在A->B->C->D的监控依赖数据，在传统监控体系中，一旦B出现故障，则会同时发出B、C、D三个告警，给问题排查造成困难；而在一体化监控平台中，只会发出B告警，同时告知受影响的业务C,D，排除干扰，实现问题快速定位。

 

• 趋势分析

由于采用大数据分析，可以支持业务的趋势监控，即可以根据历史数据情况，对未来的故障可能进行预警。

 

例如：针对存储设备的运行情况分析，预知其故障的可能性，从而提前预警，维护人员可快速接入处理。

 

2一体化监控的架构设计要点有哪些？

 

>>>> 

曹贝：

 

1、一体化监控系统定义

 

顾名思义，一体化监控系统就是提供一套完整的监控体系，为企业提供全方位、无死角、精准及时的监控服务，从而保证企业业务的稳定运行。

 

所谓一体化，包含了几个概念：

• 统一：用户在统一平台上即可完成从机房、设备到业务的监控诉求；

• 兼容性：能够兼容不同的监控需求、标准，实现监控的根本性抽象

• 智能化：系统自带关联分析功能，尤其在设备种类、数量增多的情况下，协助企业实现故障快速、清晰的定位。

 

2、设计准则

 

一体化监控平台需要秉承以下几个设计理念：

 

1)框架化

系统是框架清晰的，主要包括两大部分，监控体系核心框架和监控项目实现。

核心框架实现监控数据的收集、存储及监控规则定制、告警判断及发出等功能。监控项目则实现具体的监控诉求。

 

2)层次化

一体化监控是分层次、多维度的，横向来讲，包括：用户可用性监控-》业务接口监控-》系统存活监控-》系统健康度监控；纵向来讲，包括：骨干网边缘监控-》机房监控-》网络和服务器监控-》操作系统监控-》业务监控。

 

3)标准化

强调接口的标准化，监控体系自带标准，其他企业级服务需参照标准接入一体化监控体系。

 

4)智能化

监控系统支持系统依赖与关联，支持告警判断，从而实现问题快速定位、监告警排重等功能。

 

3一体化监控的目的是什么，是为了跨领域的分析，还是主要为了使用方便避免监控系统烟囱化？

 

>>>> 

阳海超 IT顾问：

 

我的理解是指后者，能从系统，服务，应用三个维度的监控。

 

>>>> 

qq373793057 系统工程师：

 

补充一下，我认为应该是基础设施层、应用系统层、业务运行层三个维度来进行监视、管理、控制并有序的形成一个闭环的过程。

 

>>>> 

samssams 安信证券 系统架构师：

 

我理解两者都是重要需求。

 

>>>> 

yujin2010good 北京物美 系统工程师：

 

个人觉得还是当前互联网思维引领我们走向简单化，智能化方向，统一监控目的就是一个平台，简单，简洁，方便，能够实现趋势化分析，能够预知未来，在发生故障前就已经能判断出故障，这才是我们一体化监控的未来。

 

4企业有非常多的核心系统中，如何衡量监控系统的质量状况，大家是如何做的？

 

>>>> 

曹贝：

 

当然是指标啦，数字说明一切，常见的指标：

 

* 故障告警时延1分钟以内

* 误报率0.5%以下

* 准确率99.5%以上

* 漏报率0.1%以下

* 监控系统平台化，支持业务自定义监控，具有自助服务平台

* 支持趋势监控

* 监控可视化

* 可自定义粒度

* 易用性

 

5如何定义监控系统的误报率、准确率、漏报率这几个KPI？

 

>>>> 

曹贝：

 

误报率  =  误报次数/总告警次数

漏报率 = 漏报次数/总告警次数

准确率 = (总告警次数 - 误报次数 - 漏报次数 ) /总告警次数

 

至于误报次数、漏报次数，可以采用抽样 + 制度的方式进行统计

 

6如何看待监控系统的标准化？

 

>>>> 

曹贝：

 

证券行业监控诉求的一大痛点就是监控种类繁多，设备厂家繁多，彼此信息不通，形成信息孤岛，从而给监控系统带来大量问题。

 

基于此，要大力推广标准化，形成企业为主的泰式，企业指定监控系统接入标准，供应商匹配企业标准，打破信息孤岛，实现信息互通。主要从以下几方面进行标准制定：

 

• 调用接口标准

  接入监控系统的接口标准化，例如：必须支持API/SDK之类的调用种类，参数设置及结果返回等

• 协议标准

  监控平台和供应商的服务进行通信时需要按照一定的协议标准，比如：必须支持snmp/tcp/http等数据通信协议，必须支持ssl等安全协议

• 数据标准

  数据格式的标准化，比如：必须支持json/xml格式的数据返回等

 

7我这里有几十套不同的系统，上百个服务器，网络设备，虚机，目前用foglight搭建监控环境，请问诸位搭建运维监控系统时，通过什么视角比较合适？

 

1. 是按某个系统的拓扑图，建立混合监控环境，.还是按不同类型去搭建？

2. 当发生实际问题时，如何通过监控平台去 定位问题 ，是否有通用的套路

3. 当发现问题后，是先定位问题，再生成事件，通过ITSM分配任务；还是先把问题，生成任务，分配给一组人，对定位问题

4. 能否提供一个现实的案例，能清晰的表现出， 如何发现问题，如何定位问题，如何解决问题，如何预防问题，这一个完整流程。

 

>>>> 

rainbowlily CCB 项目经理：

 

1. 监控主要分为这样几个维度：资源监控（含操作系统、数据库、中间件、网络、存储、硬件以及环境）、应用监控（应用运行的状态，如进程、日志、状态等）、交易监控（如交易量、响应时间、成功率等），还可抽象到业务级监控。所以监控环境的搭建需要根据企业运维要求，按照不同纬度、不同层次进行监控。

2. 当发生问题的时候一定是监控平台发现故障，至于问题定位上简单故障（如硬件等）可直接定位，如复杂故障需要借助其它的分析方法

3. 发现问题后先根据事件级别生成事件单，运维人员保留现场恢复生产，然后有事件单专为问题单再详细分析根本原因，记录知识库。

 

>>>>

 

刘建清 中国建材 系统运维工程师：

 

个人建议：

 

1. 首先以公司核心业务系统为主，做尽量全方位的监控，远离IT服务价值为目标，只为建立监控系统而做的监控不过是耍流氓而已。所以可以对相关系统按重要性、系统类型、设备分类等多个维度进行监控分类。

2. 当实际问题发生时，监控系统的报表或监控日志将作为问题分析和排查的重要依据，如果还需要重新从最低层的日志进行分析的话，排查效率将会十分低下，如果加上企业IT运维管理人员的变更，将可能造成重大经济损失。

3. 当问题发生后，标准的ITSM流程应该是立即生成一个ticket请求，由服务台进行任务或事件分配，由相应的工程师解决问题后进行关闭请求，如果未解决将为失败关闭该请求，一直到有新的解决方案后，该问题将彻底关闭。

4. 建议去参加相关ITSM流程优化等方面的培训。

 

8监控本身是事后性，但是长期事后分析，是否可以进行趋势分析，提前预测硬件宕机情况？应用宕机等情况？

 

>>>> 

曹贝：

 

趋势分析是利用已有数据寻找某种统计指标的内在规律性，从而得到较为准确的指标未来预测值。对于监控系统来说，趋势分析即利用历史指标值对未来指标值进行计算，操作人员关心的是未来的指标值是否会越界（发生违例），以便在可能发生违例前对系统进行预先处理，提高系统的可用性。

 

采用大数据分析，可以支持业务的趋势监控，即可以根据历史数据情况，对未来的故障可能进行预警。例如：针对存储设备的运行情况分析，预知其故障的可能性，从而提前预警，维护人员可快速接入处理。

 

常见的趋势分析方法如下：

 

1. 采用线性回归算法分析平稳的趋势

2. 采用指数性回归算法分析变化剧烈的趋势

3. 采用三角函数算法分析周期性趋势变化

 

除了分析算法，也需要完善的分析平台和存储平台的支持，例如常见的基于 storm + hbase的分析平台等。

 

>>>> 

qq373793057 某银行 系统工程师：

 

监控系统中也是可以通过日志分析，提前预判出设备运行隐患；打个比方，通过网络设备的端口CRC和error就可以预判出链路的质量是否会有问题，可以在链路告警前提前处理，存储设备中的日志也可以在阵列中硬盘发生故障告警的前一两天左右就展现出来的，可以提前更换硬盘；主机中提前预测的方式就更多了，CPU繁忙，内存换页等等。

 

只不过，这些日志不一定能够满足我们监控系统中预先设定好的告警阈值，所以才会给用户感觉监控系统本身存在事后性的特点。

 

>>>> 

yujin2010good 北京物美 系统工程师：

 

楼上大师给的的却是个方法，但是我感觉作为运维人员对各种算法可能比较陌生，能否有具体简单的工具或者说是方法来说明清楚。比如elk等log收集工具，用他来收集log然后可否进行分析等等。

 

>>>> 

曹贝：

 

1. 日志收集：ELK可以做，集成整体的收集、存储和检索，都是支持该功能的；或者使用flume + scribe + hadoop来实现； 推荐ELK，支持完善的API接口。

2. 内部服务接口暴露： RESTFUL接口； etcd；zookeepr等

 

9目前金融领域，互联网运维方面流程管理工具哪些比较实用？

 

目前运维涉及的小事比较多，升级变更也比较频繁，硬件设备的记录也比较耗时间。

 

有什么工具是比较实用的？可以进行事件流程化管理的，而且最好不要有什么收费的。

 

>>>> 

galaxy1975 系统架构师 自动化运维专家：

 

1. 用什么工具去干活儿   这个工具还是比较多的，ansible、puppet、saltstack都可以，甚至自己写个远程的ssh工具也可以。

2. 事件流程化管理    这个属于任务管理范畴了，任何一个任务，提交后都放到任务列表中，不管工具还是人，把活儿干完后，从任务列表中标记任务已经完成。 这个功能我们在一个项目中自己写了一个，并不复杂。你们如果自己有开发团队，很快就写完了。

 

最后一个就是收费的概念，我们考虑的是TCO，这里面包含购买成本和使用成本， 开源软件基本上没有购买成本，但是附带的使用成本会比较高，例如为了自己的个性化需求进行的二次开发。

 

10如何进行大文件日志内容监控？

 

• 大文件日志或众多小日志如何进行实时的关键字匹配，实现业务监控？

• 远程实时抓取应用日志或数据库日志信息？（不安装agent）

 

>>>>

 

qq373793057 某银行 系统工程师：

 

1. 可以专门注定灵活、高效的数据分析语句，将日志内容进行细粒度的数据分析。也完全可以利用日志建立可编程的日志实时搜索平台，针对特定的关键字进行检索。

2. 不安装agent，可以通过特定的协议如snmp等，在监控平台上获取机器数据和通信数据，但是针对应用和数据库等的日志信息，我想到的是通过定时+shell的方式进行抓取。

 

对于应用日志和数据库日志，如果不是采用agent方式，我认为还是只能进行半自动的日志分析，可以在相关服务器上使用定时脚本将日志抓取到监控服务器端。然后利用监控平台的日志分析功能对应用和数据库的日志进行处理并进行告警等。

 

>>>> 

chenryn 日志易 产品总监：

 

不安装agent和实时需求之间是有一定权衡取舍的。

 

比如说scp、rsync这些命令，其实也算是一种agent（sshd和rsyncd）。用Perl之类服务器自带脚本语言写一个daemon实时传日志，这个daemon也是一种agent。所以在有实时需求的时候，关键还得看agent是不是真的耗用系统资源了。所以很多地方会选择日志输出给rsyslog再转发出去，就是因为反正你不用，rsyslogd这个agent也一定会在系统上跑的。

 

除此之外，还有一种方式，让应用直接给远端打日志过去。log4j是有socketappender的……这算是可以圆满达到目的，但是这就必须联系研发人员一块了。

 

>>>> 

刘建清 中国建材 系统运维工程师：

 

1. 大日志文件或小日志文件可以使用splunk进行分析和监控，对按规则提出数据可以生成非常漂亮的报表和展现形式。特别适合于HDFS海量小文件。如果是大日志其实也可以考虑对日志进行切片，可以提高大日志文件的读写效率。

2. 远程抓取日志，要么遵循通用的snmp、SSH、telnet等协议，要么采用如sync、通用转发器等轻agent进行。其实不用担心agent会出问题，都是轻量级的工具。一般不会造成系统资源消耗太大。

 

>>>>

 

yujin2010good  北京物美 系统工程师：

 

开源工具有很多，如果不允许用开源工具，可以按照这个样子去开发。

 

1. logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理，提供 Web 接口用于查询和统计。他可以对你的日志进行收集、分析，并将其存储供以后使用（如，搜索），您可以使用它。说到搜索，logstash带有一个web界面，搜索和展示所有日志。

2. Kibana 是一个为 Logstash 和 ElasticSearch 提供的日志分析的 Web 接口。可使用它对日志进行高效的搜索、可视化、分析等各种操作。kibana 也是一个开源和免费的工具，他可以帮助您汇总、分析和搜索重要数据日志并提供友好的web界面。他可以为 Logstash 和 ElasticSearch 提供的日志分析的 Web 界面。

3. RabbitMQ是一个受欢迎的消息代理，通常用于应用程序之间或者程序的不同组件之间通过消息来进行集成。本文简单介绍了如何使用 RabbitMQ，假定你已经配置好了rabbitmq服务器。

4. Apache Kafka是由Apache软件基金会开发的一个开源消息系统项目，由Scala写成。Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

 

等等，都可以用已log收集，检索。还有一些简单的工具如sync等也可以实现简单的log收集。

 

>>>>

 

云还是晕  VANGA：

 

可以对日志采用log file agent监控，使用正则表达式去匹配关键字，从而达到监控目的。速度快，效率高。

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-07-19