对于网页（HTTP）监控任务，监控宝对于每一次检查都记录了详细的HTTP响应时间，你可以点击监控任务的最后检查状态，直接进入最后一次检查的结果快照。

通过以下的展示，我们可以看到详细的HTTP响应时间。

可以看到，在这一系列时间中，DNS域名解析所消耗的时间实际上取决于DNS服务器的性能以及用户到DNS服务器的网络状况，除此之外，DNS记录还可能会缓存在互联网接入服务商的各级DNS服务器上，这取决于DNS记录的TTL值。

建立连接的时间体现了Web服务器能否快速的接入用户的请求。通常情况下，当Web服务器的同时连接数达到预设限制时，Web服务器可能会对新的请求拒绝接入，而对于Apache这样的多进程模型，当进程数不断增多时，由于上下文切换的时间开销也随之增加，所以建立连接的平均时间也逐渐开始延长。

接下来的服务器计算时间，很容易理解，对于静态文件的访问，这部分时间主要用于文件的定位，如果是较小的文件，那么还会包括文件读取时间，而如果是较大的文件，通常Web服务器会使用sendfile系统调用来直接传送文件内容到网络设备，所以读取文件的时间并没有算入这里的服务器计算时间，而是归入内容下载时间。

对于动态内容的访问，这里的服务器计算时间具有非常重要的参考价值，要减少这部分时间并不那么容易，你可以使用缓存等策略，更加详细的优化方法我们会在以后深入介绍。

最后的内容下载时间，从根本上来说，取决于监控宝和站点服务器两端的带宽，所以它并不代表用户的真正下载时间，但是却相对依赖于站点服务器的带宽使用情况，你可以根据快照结果中的下载速度，并结合用户接入互联网的带宽来进行估算。

值得一提的是，监控宝会在未来提供真实统计用户加载页面的功能，它将帮助你了解来自各地域用户的真实网络状况以及页面加载时间。

当监控任务开始自动运行后，我们便会看到每日的报告，不同的监控类型在报告的内容上会有一定的差异，但是都会有一个统一的概述部分，这里列出了这一天的常规监控信息，如下图，它们并不难理解，其中我们比较关注的是%可用性，平均响应时间，以及故障次数等。

接下来，我们会看到独立的可用性统计和饼图。下图中的结果非常棒，100%的可用性意味这个监控任务该天始终可用。

了解了可用性之后，你会关心这一天的响应时间变化情况，接下来的柱状图会反映这一点，它会列出每小时的平均响应时间，这里可以看到在中午14点和晚上21点的时候，出现了两个响应时间的峰值，如果每天的报告都有这样的形状，那么便可以说明一定的问题。

我们还可以看到响应时间级别的统计，下图告诉我们几乎所有的响应都在500ms内完成，这会让你满意吗？当然，得看监控的是什么，如果是一个动态程序，500ms或许表现不错，但如果是一张图片，这一定不是好现象。

通过报告，我们了解了一天的站点性能，未来，监控宝还会添加更多丰富的报告形式，以及周报告和月报告功能。

在监控网页的时候，你还可以充分的使用其它HTTP特性，监控宝完全支持这么做。在你创建或修改监控任务的时候，你可以指定诸如提交方式、提交内容、Cookies，以及HTTP自定义头信息等，它们可以让你监控更多更复杂的Web应用，比如你可以通过Post提交方式来监控一个用户注册提交程序，当然，你需要在这个提交程序中针对监控请求进行特定的返回，再通过匹配内容来判断是否可用。

通过Cookies和HTTP自定义头信息，你可以完成更多的工作，比如模拟用户登录状态，以及模拟浏览器请求等。

下图是个简单的例子，我们在监控新浪网首页的监控任务中进行了这些设置，这里它们没有任何的实际意义，仅仅是一个例子。

这样一来，我们可以在检查结果快照中，看到HTTP请求头信息，正是我们设置的内容。

通常情况下，监控任务拥有设定的检查频率，比如5分钟。但是，有时候你需要在站点更新后立即查看检查结果，你可以点击“立即检查”。

这时候，提示信息告诉你任务即将启动。

几秒后，你可以刷新任务列表，通过最后检查时间，你可以了解该任务是否已经完成最新的检查。

对于基于HTTP的网页监控任务，通常是根据HTTP相应状态码来判断是否可用，但是，在一些特殊的情况下，即便返回状态码为200 OK，也有可能不符合你的预期，比如，返回的页面出现局部错误，或者返回的页面存在服务端程序计算错误等。

这里举个简单的例子，我们来监控新浪网首页，并且希望只有当返回的内容中包含“科技”时，才算该URL可用。可以看到，在新浪首页的导航栏中有“科技”两个词，代表科技频道的入口。

下面我们创建监控任务，在匹配内容中输入了“科技”，同时匹配方式为“包含匹配内容”。

监控任务创建成功后，第一次检查顺利通过，可以看到检查状态为200 OK，也就是说监控宝认为这个URL是可用的。

那么，加入我们换一个不存在的匹配内容，会发生什么结果呢？我们来试试修改匹配内容为“监控宝”。

保存任务后，随后的检查立即发现了不包含匹配内容，并将该监控任务标记为失败状态。

当然，虽然不包含匹配内容，但是检查快照中的详细数据仍然是有一定参考价值的。

在任务检查历史中，可以更加直观的看到，故障持续的时间，并且可以查看每次检查的快照。

对于任何监控任务，你都可以为它设置通知方式。

你可以在所有预设的通知方式中勾选，包括Email和手机号码，然后提交即可。

对于每个通知方式，你都可以进行全局设置，控制它们是否接受性能报告、是否接受故障通知以及是否接受故障恢复通知等。

当然，你还可以查看每个通知方式的通知历史，它会列出所有通过这个通知方式发送的故障通知以及故障恢复通知等。

为站点中的多个URL创建监控任务非常重要，这可以帮助你了解这些代表了不同业务的服务究竟性能如何，以及可用性如何，当它们因为种种原因无法访问的时候，你便可以收到故障通知邮件和手机短信。

你的站点可能包含了无数的URL，但是我们不需要监控每一个URL，只需要挑选一些有代表性的即可，这其中当然包括站点首页，其它的URL比如频道首页、文章展示页、用户主页等。

为一个URL创建监控任务非常简单，首先在任务列表页面点击“创建监控任务”。

然后选择“网页和网页(HTTP)”类型，进入下一步。

接下来，我们需要填写任务名称和URL，这两部分是必填的，其它部分这里暂不介绍，对于大多数情况，你都不需要考虑它们。这里举个例子，我们来监控豆瓣网的首页，填写如下：

同样，我们还要监控站点中的其它URL，比如豆瓣小组首页，同样也可以填写如下：

同时我们还需要选择监控频率，你可以选择5分钟，这意味着监控宝会每5分钟对指定的URL进行一次检查。

OK，监控任务创建成功，这时候你可以为它设置通知方式，这里我们暂时不介绍它。

回到任务列表，可以看到刚刚设置的豆瓣首页监控任务已经有了结果，如下：

当然，以上监控任务创建成功后，接下来还有更多的好戏，你可以设置故障通知方式、查看检查历史、查看故障通知历史、查看报告等，这些功能我们在随后会介绍。

这里只是一个简单的例子，目的在于告诉你如何创建一个基本的监控任务。你也许有一个问题，我们究竟需要监控站点中哪些类型的URL呢？如何通过它们来分析站点的性能呢？这些话题我们会在随后的日志中深入探讨。