注册中心Consul异常排查

因为访问tsf-consul需要经过接入层consul-access。所以一般问题定位都是先到Consul-access，然后再定位底层的Consul集群

/data/tsf/consul-access是consul-access二进制所在的目录，该目录下的logfile是日志目录。

1）先检查consul-access进程是否在，ps auxf | grep consul-access。

一般来说，服务注册或者分布式配置出现异常，有几种情况。

1）数据库连接不上，这个时候tail -f consul-access.INFO 是可以看到相应db的报错信息的

2）token鉴权失败，日志里一般打印get customer err:xxxx。然后java程序的控制台会返回Invalid user token

3）参数传递异常，最常见的是没有传递token。这个时候日志里会出现[HTTPServer] customer data is missing这种日志。对应java程序控制台会看到Invalid Request这种错误返回

1）首先要检查底层的Consul集群是否正常，登录到tsf-consul的安装机器

2）检查进程是否存在ps auxf | grep consul

3）检查Consul集群是否ok。curl http://{ip:port}/v1/agent/members?pretty 查看Consul集群的节点是否都是在线的，主要是看其中一行 "Status": 1，1代表该节点正常。

其中端口，如果是按照部署手册默认建议的端口，服务集群端口是8060，配置集群是8070，鉴权集群是8090。

如果是服务相关的业务出现异常，比如服务注册发现，服务消费等。那么可以通过curl http://ip:8060/v1/agent/members?pretty查看相关的信息。

类似的，分布式配置的，那么把请求端口写为8070。鉴权的业务出现异常，把端口改为8090

2）假设服务注册请求出现异常是因为连接不上底层的Consul集群，那么会出现下面的日志

xxxx can't acquire consul cluster 或者是 xxx has no any servers

3）这种情况要么是数据库有异常，要么是consul-access与consul通信出现异常。需要更进一步检查。

select * from consul_server, consul_cluster where consul_cluster.id = consul_cluster_id;

查看输出，看status列是不是都为1;查看data_type列，看1，2，3是否都存在。如果发现不存在，或者有status不为1，那就有可能是tsf-consul出现了异常，或者部署没有正常。

1）Consul-access

curl http://{consul-access ip}/v1/tsf/debug/start 打开调试日志的开关

打开后，consul-access.INFO将会输出很多调试日志，这个时候，就可以通过再次操作业务，来查看具体的日志输出。

相应关闭的方法：

curl http://{consul-access ip:port}/v1/tsf/debug/stop

2）tsf-consul

默认情况下，tsf-consul只会打印info级别的日志，向动态查看底层consul集群的日志输出，比如接受了什么请求，集群间数据同步，节点关系维护等信息。可以通过一个monitor的接口来完成

接口会一直输出当前consul节点的日志，如果想停止，直接ctrl+c

3.2.注册中心Consul异常排查