网站内容更新监控(阿里云提供搜索引擎服务，错误统计功能基本能满足老板需求 )

　　网站内容更新监控(阿里云提供搜索引擎服务，错误统计功能基本能满足老板需求

)

　　小明供职的一家小型互联网创业公司一直在阿里云上运行应用程序。应用采用通用分布式Nginx+App架构，为用户提供电子商务数据统计的webservice服务。除了偶尔出现的错误和性能问题外，到目前为止，该应用程序运行良好。

　　

　　最近，小明的老板给小明分配了一个任务，希望对应用服务进行监控，提高应用的运行质量。老板需要三样东西：

　　以应用服务监控为出发点，我们可以

　　提供历史查询功能，可以统计任意时间任意服务的任意返回值的调用次数。未来可以将公司的各种定制化业务监控快速扩展到系统中，例如各个界面的响应时间、用户特征的统计等。

　　“解决方案要尽可能的快速和经济，监控平台要搭建在阿里云上，数据不要放在第三方云上，主要是为公网流量和未来大的成本做准备数据分析，”老板最后提到。到达。

　　技术选项

　　小明接到任务后，就开始挑选技术。摆在他面前似乎可行的选择有三个，传统的OLAP风格的处理、搜索引擎、实时计算。

　　

　　在调查了现状和众多技术后，他发现，

　　由于公司业务规模较大，白天高峰期的平均QPS已经上百，业务还在快速增长。因此，将每秒数百次调用直接存储在数据库中然后实时查询是绝对不适合的，成本太高。并且不适合扩展。阿里云提供搜索引擎服务，错误统计功能基本可以满足老板的需求。但有两个不确定性。一方面，搜索引擎的价格和存储成本高（搜索引擎需要引入索引存储），各种聚合查询的查询响应时间，如接口响应时间统计等无法保证。另一方面，考虑到实时警报，API需要不断地为各种类型的调用轮询错误的调用次数，性能和成本都不太确定。基于实时计算架构，所有在线日志可以通过服务、返回值错误类型、时间等维度在内存中实时聚合计算，然后持久化存储。一方面，实时计算效率高，聚合结果大小相比原创数据会大大减小，因此持久化成本低，可以保证实时性；另一方面，告警策略可以在内存中实时验证，使得告警的性能开销足够小。所有在线日志都可以通过服务实时汇总计算在内存中，返回值错误类型、时间等维度，然后持久化存储。一方面，实时计算效率高，聚合结果大小相比原创数据会大大减小，因此持久化成本低，可以保证实时性；另一方面，告警策略可以在内存中实时验证，使得告警的性能开销足够小。所有在线日志都可以通过服务实时汇总计算在内存中，返回值错误类型、时间等维度，然后持久化存储。一方面，实时计算效率高，聚合结果大小相比原创数据会大大减小，因此持久化成本低，可以保证实时性；另一方面，告警策略可以在内存中实时验证，使得告警的性能开销足够小。所以持久化成本低，保证实时性；另一方面，告警策略可以在内存中实时验证，使得告警的性能开销足够小。所以持久化成本低，保证实时性；另一方面，告警策略可以在内存中实时验证，使得告警的性能开销足够小。

　　综上所述，基于实时计算的架构似乎最能满足当前公司的需求。做出决定后，小明开始思考进一步的架构设计。

　　架构设计

　　在确定了基于实时计算的技术后，小明开始设计架构。通过参考各种技术网站，他发现要构建一个可靠的网站监控解决方案，以下组件是必不可少的。

　　

　　幸运的是，对于前三个组件，阿里云提供了一些现成的产品组件。小明不需要手动搭建，所以入门门槛不高。

　　跟老板申请了预算后，小明开始开各种产品进行开发和测试。任务预计在一个月内完成，

　　漫长的发展历程

　　打开过程很简单。用了不到半天的时间，就拿到了kafka、storm、hbase的租户集群。可惜，俗话说，80%的开发时间都花在了最后20%的坑上。这个项目已经有一个多月了，但功能还没有完成 70%。小明在自己的技术博客上默默记录了以下几个坑。

　　集成故障排除成本

　　需要集成的组件包括数据通道、实时计算层、后台存储，并在代码中集成推送数据逻辑和告警查询逻辑。每个环节稍有错误就会导致整个环节阻塞，调试成本非常高。

　　日志清理

　　在开发过程中，为了获取相关应用，调整日志的推送逻辑，需要在每条Nginx日志的内容发生变化后，在各个服务器上改变API的推送逻辑。更改过程繁琐且容易出错。

　　持久表设计

　　除了为监控项做合适的表数据库设计，尽量避免索引热点，还需要考虑由于真实数据的不稳定性，在重复计算数据结果时如何保证数据库写入的幂等性。 -时间计算层。这对于表结构设计很重要。不小的挑战。

　　延迟数据合并

　　如果由于应用原因导致 Nginx 日志数据延迟，如何保证延迟 1 小时到达的数据能够被实时计算引擎准确计算，并将结果合并到之前的结果中。

　　报警

　　对于所有的结果，需要设置一个定时任务，每分钟遍历一次数据。例如，对于任何返回 500 次调用错误且比例超过 5% 的服务，所有服务都需要做出多个调用结果来遍历查询。如何在不忽略所有服务错误检查的情况下确保高效查询也是一个很大的挑战。

　　报警精度

　　有时由于日志延迟，最后一分钟部分服务器的正常日志还没有采集完整，导致暂时有超过5%的服务出现局部500调用错误。是否需要报告类似的错误？如果向*敏*感*词*报案，可能会被误报。如果不向*敏*感*词*报案，可能会错过。如何处理？

　　如何计算UV、TopN

　　以紫外线为例。如果要跨任意时间尺度查询UV，传统方法还需要将单位时间（如分钟级别）的完整IP访问信息存储在数据库中。这对于存储利用率来说显然是不可接受的。有没有更优化的解决方案？

　　错误场景的诊断方法

　　对于各种返回值为500的调用错误，业务方希望在出现500错误时，可以根据时间和调用服务维度查询到详细的调用参数等细节。该场景类似于日志搜索。对于类似的新增需求，似乎无法直接实现实时聚合计算和存储。需要寻找另一种方式来处理日志。

　　上述问题不包括上一段所示的各种问题。

　　转眼间，两个月就过去了。工程还没有完成一半，小明很着急。

　　另一种新的思维方式

　　晚上，小明请师兄老丹做串烧。小明端着一点酒，将自己最近的烦恼从头到尾都说了一遍。

　　老丹听了拍了拍自己的大腿：“小明，你是奥特。其实阿里云上有一个云产品叫实时业务监控，简称ARMS，基本上你遇到的问题在ARMS上都已经提供了. 一站式解决方案，您只需要快速访问。

　　“哦，对吧？我们很多业务监控逻辑都是基于Nginx日志定制的，ARMS有访问Nginx日志的能力，允许我定制业务监控能力？” 小明问道。

　　“当然。ARMS不仅提供了监控Nginx的任务模板，还有自己的告警和监控报表，并且全程开放定制能力。如果你想添加自己的业务监控逻辑，或者删除或修改通用的监控逻辑你不要，可以直接在它的平台上定制。” 老丹回答。

　　

　　“听起来不错，除了举报和报警，公司的下游业务平台也能用吗？”

　　“是的，ARMS提供API，下游系统可以直接连接数据API，和直接在云端读取数据库没什么区别。”

　　“听起来不错，看来我的项目有救了，我去看看。”

　　实现基于Nginx的网站监控场景1.ARMS Nginx监控方案概述及准备

　　目前，监控领域流行的数据处理方式有很多，如搜索引擎、时序数据库、实时计算，甚至大数据的离线计算等。

　　ARMS采用实时计算+列式存储。该方案的优点是数据实时性高，对于固定的数据查询接口，查询效率非常块状。在Nginx的监控解决方案中，其架构大致如下图，蓝色部分为开箱即用ARMS集成的Nginx监控黑盒。

　　

　　由于ARMS分析的是针对Nginx的access.log日志，所以对Nginx日志有一定的要求，用户需要在nginx.config中配置打印内容，包括：“$upstream_response_time”“$request_time”等表示请求信息所消耗时间的日志。例如：

　　 log_format main '$remote_addr - $remote_user [$time_local] $status ''"$request" $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"''"$upstream_response_time" "$request_time" "$ user_cookie_id"' ;

　　在这种情况下，打印的日志大致如下表所示。

　　58.211.119.29 144288 - [16/Mar/2017:21:47:07 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 594 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.144" "0.144" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z"58.211.119.29 148219 - [16/Mar/2017:21:47:08 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 583 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.148" "0.148" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z"

　　完成以上日志配置自定义后，就可以开始在ARMS上进行配置了。以下页面从三个部分描述配置概述：ARMS 数据集、警报和交互式仪表板。关于如何将数据源添加到 ARMS 的详细信息，请参阅文档，此处不再赘述。

　　2. 基于ARMS的Nginx监控数据集的实现

　　在Nginx监控模板中，用户数据分为两类，一类是指标，相当于数据仓库中的Measure；另一个是维度，相当于数据仓库中的Dimension。

　　对于 Nginx 监控，最常见的指标有以下几类：

　　页面的PV、UV

　　页面响应时间

　　页面流量

　　对于 Nginx 监控，最常见的维度如下：

　　对于ARMS的数据集设计，其实是用户感兴趣的Nginx监控结果各个维度的排列组合。

　　下图是数据集配置的示例。数据集配置了URL和Status两个维度（支持从URL下钻到Status的查询方式），统计PV和UV两个指标。这样用户就可以依次向下钻取页面路径和返回值，查询PV和UV的情况。

　　

　　下图是另一个数据集配置的示例。数据集配置与上例相同的两个维度，但顺序相反：状态和URL（支持从状态下钻到URL的查询方式），分别统计两个指标：PV、平均响应时间、最大值响应时间。其中，平均通话时间是一个综合指标，它是由整体通话时间/PV间接推导出来的。

　　

　　3. 基于ARMS实现Nginx监控报警

　　常见的 Nginx 告警如下：

　　下面的例子结合以上三个特点来介绍一个例子，说明如何在ARMS中定义一个“一分钟内任意URL调用500次，返回率超过10%”的报警定义，如下图。

　　

　　4. 基于ARMS的Nginx监控大盘配置

　　监控市场一般有以下用途：

　　对于 Nginx 监控，ARMS 可以根据相似的用户维度、页面维度、IP 维度，甚至地理维度来展示不同的数据。显示用户的整体UV，

　　以V为例，假设对应的数据集为“全站UV PV”，配置如下：

　　

　　最终综合各种UV、PV、响应时间等统计的交互式大图如下：

　　

　　5. 快速入门

　　以上各种 Nginx 监控场景，目前 ARMS 上成熟的业务模板都支持。用户只需在ARMS首页点击“新建标准模板监控”，选择Nginx高级模板即可。