在Oracle RAC的运维工作中，节点被意外驱逐或者无故重启是让人非常头疼的问题。翻看集群告警日志时，经常会出现cssdagent和cssdmonitor相关的报错信息，比如“cssdagent failed to launch cssd”或者“cssdmonitor detected cssdagent death”。很多DBA遇到这类信息时第一反应是重启集群，但如果不知道这两个进程在整个Grid Infrastructure体系中的角色，排查就容易走偏方向。本文将从OHASD框架讲起，详细剖析这两个守护进程的职责、相互关系以及常见故障的处理思路。
一、cssdagent与cssdmonitor在GI中的位置
要理解这两个进程，首先要从Oracle 11gR2开始引入的OHASD（Oracle High Availability Services Daemon）说起。从11.2版本开始，Grid Infrastructure重新设计了集群的启动架构，最顶层是ohasd进程，它负责管理一组agent进程，而cssdagent和cssdmonitor正是ohasd直接管理的两个关键agent。
cssdagent的全称可以理解为CSS Daemon Agent，它的核心职责是拉起并监控ocssd.bin（即CSSD守护进程）。CSSD是RAC集群的心脏，负责节点间的网络心跳、磁盘心跳以及节点成员资格的判定。这么重要的进程，Oracle自然不允许它出现无人看管的状态，于是cssdagent就承担了“保姆”的角色：当CSSD进程异常退出时，cssdagent会尝试重新拉起它，如果拉起失败，就会触发节点重启来保证集群数据的一致性。
cssdmonitor则是站在更高一层的监督者。它并不直接管理CSSD，而是负责监控cssdagent本身是否健康。这就形成了一条非常清晰的监控链：ohasd管理cssdagent，cssdagent管理cssd，cssdmonitor则在旁边盯着cssdagent有没有偷懒或者死亡。一旦cssdmonitor发现cssdagent异常退出，就会判定为“agent守护机制失效”，直接触发节点的 fencing操作，也就是我们常说的节点驱逐加重启。
二、进程监控链与心跳机制详解
打开一个运行中的RAC节点，通过ps -ef | grep css可以看到这三个进程的启动路径都在Grid Infrastructure的home目录下。它们的父子关系可以通过ps -eo pid,ppid,cmd来确认，正常情况下你会看到cssdagent和cssdmonitor的父进程都是ohasd，而ocssd.bin的父进程是cssdagent。
# 查看集群相关进程的父子关系 ps -eo pid,ppid,user,cmd | egrep "ohasd|cssdagent|cssdmonitor|ocssd" | grep -v grep # 查看ohasd托管的agent状态 crsctl stat res -t -init
这条监控链的另一个关键设计是心跳超时机制。CSSD进程会与cssdagent之间保持周期性的心跳交互，如果CSSD在规定时间内没有响应，cssdagent会认为CSSD已经hang死。注意这里有个重要区别：进程退出和进程hang是两种不同的故障，退出时cssdagent可以尝试重启，而hang住时重启进程反而可能带来数据一致性问题，所以cssdagent在确认CSSD无响应后会请求节点重启。
cssdmonitor这边也有类似的设计，它通过root用户运行，拥有系统级别的权限。当cssdagent死亡时，cssdmonitor会立即接管并触发节点重启。这种双重保护的设计思想是：任何一个监控环节失效，都有另一个进程兜底，确保不会出现CSSD失去监管却没有人知道的危险状态。因为在RAC环境中，一个失去成员资格判定能力的节点如果继续访问共享存储，可能直接导致整个数据库的损坏。
三、常见故障场景与排查思路
实际运维中，与这两个进程相关的故障主要集中在几个场景。第一种是cssdagent无法启动cssd，典型报错是“cssdagent failed to launch the process”，常见原因包括GRID用户的ulimit配置不足、网格home目录权限被改动、或者系统资源耗尽。排查时可以先查看$GRID_HOME/log/节点名/agent/ohasd/oraagent_grid/目录下的日志，再结合操作系统的messages日志确认。
# 检查grid用户的资源限制 su - grid -c "ulimit -a" # 查看ohasd agent日志中与cssd相关的记录 cat $GRID_HOME/log/`hostname -s`/agent/ohasd/oraagent_grid/oraagent_grid.log | grep -i css # 查看ocssd日志中的心跳与成员变更记录 cat $GRID_HOME/log/`hostname -s`/cssd/ocssd.log | tail -200
第二种场景是节点被cssdmonitor强制重启，日志中会出现“cssdmonitor detected a hang or death of cssdagent”之类的信息。这种情况往往不是进程本身的问题，而是系统层面出了状况，比如CPU被大量占用导致进程得不到调度、swap严重不足、或者内核参数设置不当。特别要注意miscount参数与磁盘心跳IO延迟的配合，当磁盘心跳IO缓慢时，CSSD的vote disk交互会超时，进而引发连锁反应。
第三种是网络心跳丢失导致的驱逐。虽然根因在私网，但日志里最终表现出来的往往是cssdagent报告CSSD死亡。此时应该重点排查私网丢包情况，可以通过ping长包测试、检查交换机端口统计以及OCR中记录的集群网络配置。如果确认私网质量不佳，可以考虑启用HAIP或者调整revertimeout相关参数，但在调整任何参数之前，务必理解其含义并用srvctl和crsctl验证配置。
四、总结与运维建议
cssdagent与cssdmonitor虽然只是两个不起眼的agent进程，但它们构成了RAC集群最底层的生死判定机制。理解它们的工作原理，关键在于抓住“分层监控、逐级兜底”这条主线：ohasd看着agent，agent看着cssd，monitor再看着agent，任何一环失效都以节点重启为最终手段来保护共享数据。
日常运维中建议做好几点：一是定期归档和分析alert日志与ocssd日志，建立基线，这样故障发生时才能快速判断异常程度；二是变更操作系统参数或打补丁前，先确认对GI进程的影响，尤其是ulimit、selinux和防火墙策略；三是遇到节点驱逐时不要急于重启，先把GI日志、OS日志完整收集下来，确认驱逐发起方是被驱逐方，才能准确定位根因。把这些细节做扎实，处理RAC节点层面的故障就会从容很多。
Oracle RACcssdagentcssdmonitor修改时间：2026-09-06 07:32:37