page contents

关于增加微服务监控及自动处理机制

  • 时间:3个月前
  • 浏览:205次

  应用监控的重要性不言而喻,除了监控报警,还需要有无人值守的情况下的自动恢复,这样才能把影响降到最低。

  我编写的监控脚本原理很简单,就是每一个应用自制一个url,通过周期性请求这个url,通过判断返回的状态来确定服务是否还在线,否则自动重启服务。

  针对通常的jbossspring boot框架下的war服务,这种机制屡试不爽,但是微服务下jar就行不通了。

  起初,我设置的判断返回状态的条件如下,正常情况下返回200,如果应用使用了重定向的机制则会返回302,如果服务直接挂掉或者卡死,返回的状态都是000。

if [ ${justWeb}x != "200"x ] && [ ${justWeb}x != "302"x ] ; then

  正常的理解是如果返回404,肯定是有问题,但要放在具体的场景下,404只是代表请求的url不存在对于的文件,而服务仍是通畅的,之前我为了确保请求的url返回200状态,并且为了降低每次请求的带宽占用,十几个应用专门写了一个只有几B字节的文件,现在来看完全没必要。

  我的原则还是老人老办法,新人新办法,所以原来的已经写了的就保持现状,新的应用监控则不会再走老路,只需要将条件做如下调整

if [ ${justWeb}x != "200"x ] && [ ${justWeb}x != "302"x ] && [ ${justWeb}x != "404"x ]; then

  就既满足传统jboss和war服务又满足jar服务了。

  关于增加微服务监控及自动处理机制 运维 1

在修改脚本的时候出现了一个小插曲,就是在传的参数为微服务的时候脚本报错:

关于增加微服务监控及自动处理机制 运维 2

对应的232行代码如下:

关于增加微服务监控及自动处理机制 运维 3

为什么传统服务不报错,而微服务报错了呢?

同样的写法,其它地方不报错,说明语法没问题,看来问题应该出在变量urlPath上,此处有个赋值的动作,可以看到参数传24的时候该变量的值为空,所以用一个空值作比较的时候就会报错,上面的条件相当于[=='email',[找不到匹配对儿,所以就报错了

关于增加微服务监控及自动处理机制 运维 4


将上述条件改成,再次执行,错误消失。

if  [ ${urlPath}x == "email"x ]; then


另外,根据以往的监控记录,发现大部分情况是因为请求没有及时得到响应,产生的原因可能是多方面的,有可能是网络问题或者是服务器资源问题,这本身是带有自愈的机制,所以一遇到未及时响应就重启服务有时候可能是不必要的,所以在脚本中增加了探测次数,即如果第一次未及时响应,10s后在请求一次,如果还没有响应,则重启服务。

留言反馈

Copyright ©刘相涛 powered by zblog 加入我们| 网站地图| 业务合作
歌曲 - 歌手
0:00