linux url监控,URL页面监控最佳实践

原作者：肖劲青

对于我们提供服务的应用来说，特别是Web应用，光有端口监控是远远不够的，因此端口还活着并不能代表应用还活着，我们的服务是否还能正常提供、业 务逻辑是否正常等等，都不能由端口还活着来标示，因此我们会通过URL页面监控的方式来进一步监 控 应用可用和业务逻辑可用。

一般我们进行URL页 面监控有以下四种方式：

1、静态页面监控，在应用系统中制作一个静态页面， 一般如：ok.html，监控系统定时去通过HTTP方 式去访问该页面，如果返回正常，则表示该服务正常；

2、动态页面监控，在动态页面中，特别是在业务逻辑 处理完了之后，通过动态程序输出一个关键字，监控系统定时去Check该URL返回的页面内容，如果包含关键字，则表示该服务正常；

3、依赖资源聚合监控，在一个应用中，专门编写一个 页面来进行应用依赖资源的监控，在这个页面中，系统会主动发出一些请求，如DB、Search、外部接口等，将每个请求的返回及响应时间记录下来，由这个页面程序判断，这些依赖资源是否服务正 常，然后将收集到的数据在这个页面中输出，包含一些特定的代表正常或者不正常的字符串，这样监控系统定时去Check该URL的时候，只需要判断页面中是否包含约定的关键字，就能判断系统是否正常，如果不正常，可以通过页面中聚 合的一些数据来判断是哪些依赖资源出问题；

4、权限页面监控，在我们的应用系统中，很多页面都 需要需要用户登录之后才能访问的，这样大大增加了监控的难度，目前监控中心可以CaseByCase的 方式对应用中核心页面进行登录验证监控，但如果登录过程还需要输入验证码什么的，可能会更加困难，欢迎大家能对这类的监控方式提出建议。

第一种静态页面监控，相对端口监控来说更贴近应用，但作用基本一样，只能判断我们的web服务是好的，应用好坏是无从得知，因此建议各个应用都应该多以2/3/4三种监控方式为主，目前采取第二种方式，在动态页面的业务逻辑最后输出关键字，只要程序能走到输出关键字的时候，说明整体业务逻辑代码都可以正常执行完，而考虑第三种方式，每个应用中会专门编写一个页面来实现页面监控，会把应用依赖的资源都进行测试并保证可用性。