Ocata異常問題一覽

1.

異常：某個服務重新開機後，前一段時間正常運作，之後突然異常挂掉，沒有日志輸出。檢測配置檔案，沒有異常，繼續重新開機依舊會挂掉。

檢查思路：服務異常，一看服務狀态，二看相關日志，三看配置檔案内容，四看配置檔案的權限。

解決方案：此類問題，多是控制該服務的配置檔案的權限問題，修改權限之後，異常解決。

2.

異常：某個服務突然異常，檢視其相關日志，發現一直報，rabbitmq逾時問題。

檢查思路：服務異常，一看服務狀态，二看相關日志，三看配置檔案内容，四看配置檔案的權限。

解決方案：rabbitmq逾時問題一般是由于時間不同步導緻的，檢查時間是否同步，然後檢視rabbitmq叢集狀态，必要時候重新開機rabbitmq和http服務。

3.

異常：l3中出現大量消息逾時錯誤，對網絡的操作各種異常

檢查思路：l3 angent日志出現大量的逾時錯誤，使用異常2的解決方案依舊解決不了，再嘗試下面的操作。

解決方案：

先檢視日志，

-- ::  TRACE neutron.agent.l3.agent     message = self.waiters.get(msg_id, timeout=timeout)
-- ::  TRACE neutron.agent.l3.agent   File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line , in get
-- ::  TRACE neutron.agent.l3.agent     'to message ID %s' % msg_id)
-- ::  TRACE neutron.agent.l3.agent MessagingTimeout: Timed out waiting for a reply to message ID d4baae114cee4f6d831c5eec3c5f0de3
-- ::  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.

注：延時是解決各種問題的大招，使用的時候要慎重，不然傷敵一千自損八百。