Question

有没有人知道检测远程应用程序是否出现故障/崩溃的方法？我的意思是当它变得无法使用时 - 在这种情况下你通常会在标题栏中看到“Not Responding” - 但关键是应用程序仍在运行;因此，仅仅找到不再运行的过程是不够的。

WMI不支持在远程计算机上使用System.Diagnostics.Process.Responding ..它们似乎没有其他WMI属性，我可以在Win32_Process中查询此类信息。

Answer 1

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

Answer 2

很难知道应用程序是否已崩溃或实际上正在做一些有用的事情。

考虑一下：

 while(true);

处理器（非常）忙碌。如果在单独的线程中完成，它甚至可能会响应。但是，由于应用程序不再起作用，这实际上是不受欢迎的行为。

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

广播可以通过多种方式完成。最简单的方法是将计数器写入文件（确保文件在写入时被锁定，因此读取过程在同一时间读取文件时不会得到半文件）

更高级的方法是使用命名管道或使用套接字。在这种情况下，UDP套接字很容易设置和使用。不要担心“数据包丢失”，因为在本地网络上这几乎不会发生

Answer 3

在确定一个程序的“活跃度”时，重要的是以有用的方式衡量它所存在的定义。

一些简单的“代理”方法由于其简单性而在表面上很吸引人，但从根本上来说并不能衡量重要方面。

也许最常见的是“过程是否活着”和“单独的心跳广播线程”可能是因为它很简单：

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

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

最好的是使活动检查的程序部分执行任务。也许在每个子任务完成后直接从主线程心跳（用一个阈值来确保它不会经常发生）或者只是查看输出（如果它存在）并确保输入产生输出。

最好还是在内部（在程序内）和外部（特别是如果有程序的外部使用者/用户）验证这一点。如果您有一个Web服务器：尝试使用它，如果您的应用程序是基于事件循环的系统：触发它必须响应的事件（并验证输出是否正确）。无论做什么，请始终考虑您希望验证有用的并且正在发生正确的行为，而不仅仅是任何活动。

您验证的不仅仅是程序的存在，而是操作，您的检查将更有用。如果你在盒子上运行你的监视器进程，你可能只检查本地环回，你可以检查更多的系统，从盒子里运行验证更多的网络堆栈，包括经常被遗忘的方面，如DNS

这不可避免地会使检查变得更难，因为你本身就是在考虑一个特定的任务，而不是一般的解决方案，从中获得的红利应该产生足够的好处，在许多情况下要认真考虑这种方法。

C＃检测远程应用程序故障

3 个答案: