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

Question

有谁知道如何检测远程应用程序是否失败/崩溃？ 我的意思是当它变得不可用时 - 在这种情况下，您通常会在标题栏中看到“未响应” - 但关键是应用程序仍在运行； 因此，仅仅发现进程不再运行是不够的。

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

Answer 1

很难知道应用程序是否已崩溃或实际上正在执行一些有用的操作。

考虑一下：

 while(true);

处理器（非常）繁忙。 如果这是在单独的线程中完成的，它甚至可能会做出响应。 然而，这确实是不受欢迎的行为，因为该应用程序不再工作了。

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

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

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

Answer 2

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

Answer 3

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

几种简单的“代理”方法由于其简单性而表面上很有吸引力，但从根本上并没有衡量重要的方面。

也许最常见的是“进程是否处于活动状态”和“单独的心跳广播线程”，可能是因为它很简单：

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

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

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

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

您不仅验证程序是否存在，而且验证其操作越多，您的检查就越有用。 离内部状态越远，您就会检查更多的系统内容，如果您在盒子上运行监控进程，您可能只会检查本地环回，在盒子外运行会验证更多的网络堆栈，包括经常被遗忘的方面，例如 DNS 。

这不可避免地使检查变得更加困难，因为您本质上考虑的是特定任务而不是通用解决方案，因此所带来的好处应该会产生足够的好处，以便在许多情况下认真考虑这种方法。