现在系统监控的工作处于过渡期，即对于Oracle的还是保留了gridcontrol的监控和报警，同时也保留了zabbix的报警，在发生问题的时候想看看哪个能监控的更到位一些，是否稳定等等，其实这个还真不好说，监控的好与不好都在于使用的情况，标准也不一样，不过从今天这个案例来看，系统级的监控还是zabbix要灵活一些。
首先说明一下情况，一般的系统session数都在1000左右，在定义zabbix监控项的时候还是认为能够限定一下系统级的进程数，所以就给了一个较大的阀值2000,认为还是做一个系统级的监控为好。所以系统在早晨业务低峰期出现这种问题，还是有些奇怪的。
查看session使用情况。
STATUS CNT
目前数据库使用的session数大于在700左右，这和报警中的2000多相差甚远。
这个时候有些怀疑是否被报警误导了，但是zabbix好的一点就是可以灵活的定制图形。可以看到在凌晨开始进程数据开始逐渐增长，到早晨5点多刚好超过了阀值，而且还在不断增长。
所以既然数据层面发现不了问题，那么只能想到就是系统级了。
通过这个发现确实进程数不少，简单看了下进程的情况，发现进程主要都集中在下面三个部分。
# ps -ef|grep sendmail |wc -l
# ps -ef|grep postdrop |wc -l
# ps -ef|grep CROND|wc -l
等过了会，没有做任何操作，屏幕里就开始输出资源紧张了，看来问题还是有些严重了。/dev/sda3 262144 262144 0 100% /var