C检测远程应用程序故障

在确定一个程序的“活跃性”时,重要的是要以一种有用的方式来衡量这个方面的定义。

一些简单的“代理”方法由于其简单性而表面上具有吸引力,但从根本上来说并不衡量重要方面。

也许最常见的是“is the process live”和“separate heartbeat broadcast thread”,可能是因为这样做很简单:

bool keepSending = true; // set this to false to shut down the thread
var hb = new Thread(() => 
    {
         while (true)
             SendHeartbeatMessage();   
    }).Start();

但是,这两个都有一个严重的缺陷,如果应用程序中的实际工作线程被锁定(比如进入无限循环或死锁),那么您将继续愉快地发送OK消息。对于基于流程的监控,您将继续看到流程“活动”,尽管它不再执行真正的任务。
您可以通过在主线程上对进度测试进行分层,从而在许多方面改进线程1(显著增加了复杂性和线程问题的可能性),但这采用了错误的解决方案,并试图将其推向正确的解决方案。

最好是让程序执行的任务成为活动性检查的一部分。可能是在每个子任务完成后直接从主线程检测信号(具有一个阈值以确保不会太频繁发生),或者只是查看输出(如果存在),并确保输入产生输出。

最好还是在内部(在程序内)和外部(尤其是在程序有外部消费者/用户的情况下)验证这一点。如果您有Web服务器:尝试使用它,如果您的应用程序是基于事件循环的系统:触发它必须响应的事件(并验证输出是否正确)。无论做了什么,都要考虑你是否希望验证 有用的 正确的行为正在发生,而不仅仅是任何活动。

你越能证实程序的存在 行动 你的支票越有用。您将检查更多的系统,从内部状态越远,如果您在框上运行您的监视器进程,您只能检查本地环回,从框外运行验证更多的网络堆栈,包括经常被遗忘的方面,如dns。

不可避免地,这会使检查变得更加困难,因为您本质上考虑的是一个特定的任务,而不是一个通用的解决方案,因此从中获得的好处应该足以使这种方法在许多情况下得到认真考虑。

很难知道一个应用程序是崩溃了,还是真的在做一些有用的事情。

考虑一下:

 while(true);

处理器很忙。如果这是在一个单独的线程中完成的,它甚至可能会做出响应。然而,这确实是不必要的行为,因为应用程序不再工作了。

解决这一问题的最佳方法是定期(在软件的某些点上)添加某些计数器并广播这些计数器。一个看门狗应用程序可以监听这些广播,如果它们没有到达或者不再有意义(计数器不加起来),那么您可以终止该进程并重新启动它。

广播可以通过多种方式进行。最简单的方法是将计数器写入一个文件(确保在写入文件时锁定该文件,这样在读取过程中不会在完全同时读取文件时得到半损坏的文件)

更高级的方法是使用命名管道,或者使用套接字。在这种情况下,UDP套接字非常容易设置和使用。不要担心“packetloss”,因为在本地网络上,这几乎从未发生过。

您可以使用轮询机制并定期询问远程应用程序的状态。