CRM系统常见故障监控.docVIP

常见故障监控方法 ——浅谈CRM受理服务拨测 CRM2.2在2012年7月份，在XX省完成了所有本地网的割接上线，自那时起，做为负责服务保障的我，就在头顶上悬了一把剑，首先让我们看看这把剑有多锋利。 一，运营的困难 服务节点太多：上线之初，CRM2.2受理共有前台服务 200个，后台服务100个（经过调整和XX市并网，现在前台服务182个，后台服务91个）；这些服务如果靠人工来拨测，首先是工作量大，200个服务检查完，需求一个小时左右；并且意义不大，因为服务的状态是动态的，刚刚检查完的下一秒，服务可能就变成异常。 影响面大：CRM2.2是电信的核心业务功能，如果某个本地网的服务出现异常，就会导致大面积故障，影响客户的感知。 其它系统监控的压力：电信另一个厂家的拨测产品对CRM2.2的服务也有监控，但问题是那个监控结果不准；当时服务台常常把它的拨测结果，不加验证，直接贴到QQ群里，客户从上到下都很关注。我们必须被动受接收这些异常点，逐个验证，并公布验证结果。 被困难唬住就不是我们，生活不是强奸，我更不会躺在那任它蹂躏。我们的目标很明确，准确快速地发现异常的服务，给处理赢得时间，绝对不能等用户来踢屁股了，才去检查处理异常点。下一步我们来分析系统的部署架构。 二，部署架构 1，部署模式：CRM2.2的服务分为前台服务和后台服务，中间用nginx连接。前台服务是war包，部署在weblogic，后台部署在tuxedo。 考虑到容灾性及内网CRM和外网CRM的不同要求，部署方式如下： 内网CRM按本地网部署：每四个本地网的受理服务部署在两台机器上，每个本地网部署8个前台服务，对应4个后台服务。以两台机器（四个本地网）的服务部署方式为例，如图1： 图1 外网CRM按组部署，每组占两个机器，部署16个前台服务，对应8个后台服务。以两台机器（一个分组）的服务部署方式为例，如图2 图2 2，用户访问路径 用户首先访问SSO服务映射出来的F5地址，F5按负载均衡和容灾备份的原则，选择其中一个SSO服务，如果密码验证通过，就取得令牌完成登录。登录后，用户的浏览器就带着取到的令牌，按用户的要求，转到CRM受理服务的F5，F5同样按负载均衡和容灾备份的原则，选择受理服务节点，转到受理页面。 以下是本地网营业网访问CRM的路径图： 图3 三，问题分析 需要突破的难点： 取到令牌；因为没有令牌，直接探测受理服务是不通的，所以我们必须拿到令牌，再带着令牌逐个访问受理服务。 绕过F5；由于F5有负载均衡和容灾备份的原则，直接通过F5拨测结果，只能算过抽样拨测，不能做到全覆盖，无法满足服务节点全覆盖的要求，所以必须绕过F5，对所有服务节点进行遍历拨测。 四，解决方法 1,探测SSO SSO是访问CRM2.2受理服务的大门，必须把SSO一起纳入监控范围。所以第一步要实现对SSO服务的监控，模拟用户登录CRM的过程，以http协议的方式，用固定的用户名密码，对所有18个SSO服务（本地网12个，代理商6个）逐个拨测，代码如下（短信发送对象是本人手机号，以“#”隐去了后5位））： #checksso.sh while : do #latn cat ssourl.txt|awk -F| {print $1,$2,$3}|while read ip_port kpi_code node_id do res=`curl -v http://$ip_port/portal/sso/servlet/LogonServlet -d EMPEE_ACCT=crmuserEMPEE_PWD=password` s1=用户名 ssostr=`([ $res = ${res/$s1} ] echo no) || echo ok` if [ ${ssostr} = no ] ; then #发现问题，直接发送短信到手机号 wget http://XXX.XX.12.45:9999/ssss.php?phs=189196#####\content=${kpi_code}:SSO error fi done sleep 600 done 以上用shell脚本的方式，实现模拟用户登录认证的过程。 SSO地址有多个，为了处理灵活和方便，把sso的服务地址和端口号作为变量抽取出来，放在文件“ssourl.txt”中，供程序循环读取。 2,受理服务探测 继续采用步骤一的方法，把受