监视在http url托pipe的Web服务

最近我给了我一些相当的思考，并得出结论：某种forms的轮询是确定系统是否运行的唯一可靠的方法。 思考一下，我觉得有必要考虑一下，如何跟踪一位独居老人的幸福，这个老人的生活在一定的距离之外。

我可以想到三个select：

1. 请求你的亲属在需要帮助时给你打电话。 例如，如果他们跌倒，不能起床。
2. 请问你的亲戚在某个特定时间每天给你打电话，比如说下午7点。 如果你在晚上7:30之前没有收到消息，你可以试着打电话给他们，或者请附近的人停下来检查一下。
3. 定期给他们打电话，说一天一次，并检查他们是否正常。

选项2和3都是轮询的变体。 唯一的区别是谁发起请求; 但是两个选项都可以。 选项1是一个事件驱动的通知。 这是最有效率的通知，因为亲属会得到即时的帮助。 但是，如果他们遭受了严重的摔倒，他们自己也不会发出警报，而且在任何人注意的情况下都可能会有几天的时间。

基于此，我认为最好的select是在可能的情况下使用事件驱动的通知，但使用某种forms的轮询作为可靠的回退 。 无论使用哪种轮询方法，在轮询机制本身出现故障时都必须显而易见。 如果您用于轮询Web服务的系统已经closures，而您还没有意识到，那就不太好了。

在我负责的系统中，我们使用事件驱动的通知和轮询的混合方式，其中包括许多网页和Web服务。 每当系统发生错误或其他值得注意的事件时，电子邮件都会发送到我的收件箱。 但是我们并不是依靠这个来告诉我们所有的问题。 如果我们这样做，并且出现错误报告过程或networking连接问题，我们将永远无法得知。 为了涵盖这些types的问题，我们使用轮询。

我们决定编写我们自己的监控解决scheme，每隔几秒轮询所有关键服务。 如果在预期的超时期限内没有收到任何回应，或者回复到达，但并非如预期的那样，系统会通知我们的员工。 系统会发送电子邮件给关键人员，并通过其“ 信息散热器 ”/“ 大可视图表 ”types的显示器传达所有系统的当前状态。

以下是我们在办公室的信息散热器之一，它提供了我们关键服务的可用性和性能始终存在的指标：

显示屏位于我们办公室的显着位置，以确保我们知道是否不在监控。

上个月，我们发布了名为ServiceMon的系统，作为GPL许可下的开源软件。

ServiceMon使用一个非常简单的脚本进行configuration。 以下是一个如何监控网页的例子：

http-get "http://www.google.com" must-contain "<title>Google</title>" 

您也可以使用此方法来监视无状态，基于REST的服务。 这里有一个例子

如果您需要监视基于SOAP的Web服务，则需要创build一个简单的插件。 我为CodeProject写的这篇文章有一个最后部分解释了什么是涉及的。

理想情况下，系统将从头开始devise，并希望通过安全控制的方法（可能需要限制内部使用）公开状态和诊断信息。

我希望这有助于你的情况，我真的很想听听你最终使用什么选项。

有关ServiceMon的更多信息，请访问该项目的主页