我正在为一个kdb+/q系统搭建监控，系统大约有100个进程。

我在考虑如下方案：

• 每个进程检查自己的健康指标
• 每个进程向中心监控发送异步心跳信息
• 心跳包含的指标，例如时间戳、内存和.z.W队列大小
• 如果心跳过时，监控会发送同步探测以确认进程是否已死亡

这在q 中是否是一个合理的模式？

更具体地说：

1. 基于推送的异步心跳是否比监控端轮询更可取？
2. 使用同步探测来确认一个进程是否死亡，是正确的做法吗？
3. .z.W在生产环境中用于监控IPC压力有用吗？

示例架构：

workers --async heartbeat--> monitor
monitor --sync probe--> worker (仅在超时时)

我想知道这在kdb+/q中是否地道，或者是否有更好的做法。

解决方案

一般来说，进程向中心监控发送异步心跳会更好。进程在启动时应向监控注册，监控应尽可能多地捕获并存储关于每个进程的信息（如果使用原生kdb，做法类似这里所示：https://code.kx.com/q/kb/using-dotz/#tracking-clients-and-servers）

在没有收到心跳的情况下，使用同步调用去联系某个进程并不可取——那样只会让监控也陷入僵局。要么是出问题的进程已宕机（在这种情况下，监控可以通过.z.pc处理程序及其存储的客户端映射被动地确认），要么是出问题的进程太忙，无法发送心跳，在这种情况下其实也没有必要去核对。

在给定进程中对sum each .z.W进行跟踪，是判断该进程是否存在慢消费的一个好方法。为了让这些信息有用，该进程本身应该知道谁连接到它（使用上面类似的“跟踪客户端”功能）。