Ocata异常问题一览

1.
异常：某个服务重启后，前一段时间正常运行，之后突然异常挂掉，没有日志输出。检测配置文件，没有异常，继续重启依旧会挂掉。

检查思路：服务异常，一看服务状态，二看相关日志，三看配置文件内容，四看配置文件的权限。

解决方案：此类问题，多是控制该服务的配置文件的权限问题，修改权限之后，异常解决。

2.
异常：某个服务突然异常，查看其相关日志，发现一直报，rabbitmq超时问题。

检查思路：服务异常，一看服务状态，二看相关日志，三看配置文件内容，四看配置文件的权限。

解决方案：rabbitmq超时问题一般是由于时间不同步导致的，检查时间是否同步，然后查看rabbitmq集群状态，必要时候重启rabbitmq和http服务。

3.
异常：l3中出现大量消息超时错误，对网络的操作各种异常

检查思路：l3 angent日志出现大量的超时错误，使用异常2的解决方案依旧解决不了，再尝试下面的操作。

解决方案：
先查看日志，

2016-02-25 05:54:59.886 15110 TRACE neutron.agent.l3.agent     message = self.waiters.get(msg_id, timeout=timeout)
2016-02-25 05:54:59.886 15110 TRACE neutron.agent.l3.agent   File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 149, in get
2016-02-25 05:54:59.886 15110 TRACE neutron.agent.l3.agent     'to message ID %s' % msg_id)
2016-02-25 05:54:59.886 15110 TRACE neutron.agent.l3.agent MessagingTimeout: Timed out waiting for a reply to message ID d4baae114cee4f6d831c5eec3c5f0de3
2016-02-25 05:54:59.886 15110 TRACE neutron.agent.l3.agent

所有超时都指向同步路由的操作。
而且同步失败时，rabbit中的队列q-l3-plugin中有大量未应答消息积压，该队列为同步路由时使用，路由同步时会使用消息队列传送所有路由的属性详情，消息量很大
1）测试是否由于消息太大导致，编写测试代码，尝试连续1000次发送该消息，并未出现丢失消息的情况，
2）尝试减少路由器数量，短时内情况有所改善，但是随时间增加，消息积压依然有更加严重的趋势
3）最终跟踪neutron代码，发现消息队列出现Timeout的原因是：
neutron在同步路由信息时，会从neutron-server获取所有router的信息，这个过程会比较长（130s左右，和网络资源的多少有关系），而 在/etc/neutron/neutron.conf中会有一个配置项“rpc_response_timeout”，它用来配置RPC的超时时间，默认为60s,所以导致超时异常.解决方法为设置rpc_response_timeout=180.

注：延时是解决各种问题的大招，使用的时候要慎重，不然伤敌一千自损八百。