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

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

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

　　针对通常的jboss和spring 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服务了。

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

对应的232行代码如下：

为什么传统服务不报错，而微服务报错了呢？

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

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

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

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