【测试环境】
【 OB 】
【 4.2.1】
【问题描述】
目前已知当某节点故障导致observer注册不进去rs的时候会自动隔离，
如果遇到ob的服务进程还在，但是ob服务内部处理时会因为某些硬件故障hang住，这种情况有办法自动隔离故障节点么
是否有探针，能自动探活各项硬件指标，探活失败自动kill上面的进程
OceanBase设计为一个Share-Nothing的架构，但是他有RS节点，Root Service和所有ObServer之间维持租约，当ObServer出现故障时，主Root Service能够检测到并执行故障恢复操作。你说的这种情况RS节点就能识别，会自动隔离掉。
【当ObServer出现故障时】 这个应该是指的进程故障 导致注册的时候有延迟所以RS才能检查到吧，如果进程没有问题但是底层硬件有问题，这个情况是能探测吗
Root Service 根据心跳数据包可以获得节点如下的工作状态：
- 节点心跳数据包存在，心跳数据包中的节点磁盘状态正常。此种状态下，Root Service 认为节点处于正常工作状态。
- 节点心跳数据包存在，心跳数据包中的节点磁盘状态异常。此种状态下，Root Service 认为 observer 的进程还在，但节点磁盘故障。此种状态下，Root Service 会尝试将该节点上的全部 Leader 副本切走。
- 节点心跳数据包不存在，节点心跳数据包的丢失时间还比较短，节点心跳状态为 lease_time，此种状态下，Root Service 仅将节点的工作状态设置为 inactive，不做其他处理。
- 节点心跳数据包不存在，节点心跳数据包丢失时间超过 server_permanent_offline_time，节点的心跳状态为 permanent_offline，此种情况下，Root Service 会对该节点上的数据副本进行处理，将该节点上包含的数据副本从 Paxos 成员组中删除，并在其他可用节点上补充数据，已保证数据副本 Paxos 成员组完整。
看起来是考虑到了ob进程和磁盘状态，会有这些情况之外的异常情况吗
其实从机器角度来看的话，大体可以分为：网络、cpu、磁盘、内存这几个吧，
- 网络、磁盘这个是直接有考虑进去的；
- cpu轻点的故障就是cpu高，表现是卡顿，心跳就能识别，严重的，这个节点可能就down掉了，心跳也可感知；
- 内存的话，内存高可能会被机器kill掉，内存坏了的话本身机器也就用不了了。
综上，RS在心跳检测这块基本上是拿捏了各种机器故障情况的
感谢！