一次驚心動魄的問題排查

最新 07-25

預計閱讀時間：9分鐘

周末之前，經歷了一次系統應急處理，可謂驚險。簡單回顧一下，梳理排查思路，算是總結，也是學習。由於涉及些隱私問題，所以屏蔽了一些信息，只闡述技術問題。

應用邏輯並不很複雜，需要訪問遠端資料庫，進行一些數據交互的操作，從應用端日誌看，出現問題的時候，現象就是卡在某一步，不動了，hang的狀態，具體來講，就是卡在資料庫操作，比如SELECT語句，正常來講，毫秒級就能返回，但當前幾秒、幾十秒、甚至幾十分鐘，都沒有響應。選擇重啟應用，偶爾能起作用，但隨著時間推進，效果不很明顯。

由於很久沒有更新過應用，軟硬體環境，同樣許久未變更，突然出現這現象，第一感覺，就是懷疑資料庫層面(Oracle)，例如SQL語句執行計劃的突變，或者數據量累積起來，沒有清除策略，導致到達一個臨界點，影響CBO的判斷。

排查一：應用層面是否有問題

應用已經許久未更新了，包括軟硬體環境，而且從應用層面，幾乎將所有異常，都記錄於日誌當中了，換句話說，只要是應用問題，日誌都會記錄。但出現問題時，應用未有任何的報錯。

trace了出現問題的應用進程，也並未出現任何異常。

因此初步判斷，不是應用層面的問題。

排查二：資料庫層面是否有問題

我們團隊的DBA-albert久經沙場了(P.S. 推薦一下，albert的博客http://travelskydba.com/)，第一步就是讓對端DBA用如下SQL，檢索當前資料庫的等待事件，如果是資料庫層面的問題，操作慢，就一定在等待著什麼，

但從實際來看，沒有任何異常的等待，資料庫層面都比較正常。

此時，另一個現象，就是我從應用伺服器，sqlplus幾十秒才能登陸，執行應用使用的語句，幾十秒未返回，其中sqlplus執行cancel出現過，

又讓對端DBA做了如下操作：

1. 本地sqlplus登陸。

> 速度很快。

2. 本地通過監聽登陸資料庫。

> 速度很快。

3. 本地執行SQL語句

> 速度很快。

因此初步判斷，不是資料庫層面的問題。

排查三：網路層面是否有問題

排查網路問題，常用的方法，可能就是如下這些了，

1. ping

2. telnet

3. tnsping

4. traceroute(Linux)

前三個很好理解，第四個指令，其實在排查網路問題時，非常實用。

traceroute最早是由Van Jacobson在1988寫出的小程序。可以讓我們看到IP數據報從一台主機傳到另一台主機所經過的路由及RTT(往返時間)。通過traceroute我們可以知道信息從你的計算機到互聯網另一端的主機是走的什麼路徑。當然每次數據包由某一同樣的出發點(source)到達某一同樣的目的地(destination)走的路徑可能會不一樣，但基本上來說大部分時候所走的路由是相同的。linux系統中，我們稱之為traceroute，在MS Windows中為tracert。 traceroute通過發送小的數據包到目的設備直到其返回，來測量其需要多長時間。一條路徑上的每個設備traceroute要測3次。輸出結果中包括每次測試的時間(ms)和設備的名稱(如有的話)及其IP地址。

從工作原理上，traceroute程序的設計是利用ICMP及IP header的TTL(Time To Live)欄位(field)。首先，traceroute送出一個TTL是1的IP datagram(其實，每次送出的為3個40位元組的包，包括源地址，目的地址和包發出的時間標籤)到目的地，當路徑上的第一個路由器(router)收到這個datagram時，它將TTL減1。此時，TTL變為0了，所以該路由器會將此datagram丟掉，並送回一個[ICMP time exceeded]消息(包括發IP包的源地址，IP包的所有內容及路由器的IP地址)，traceroute收到這個消息後，便知道這個路由器存在於這個路徑上，接著traceroute再送出另一個TTL是2的datagram，發現第2個路由器...... traceroute每次將送出的datagram的TTL加1來發現另一個路由器，這個重複的動作一直持續到某個datagram抵達目的地。當datagram到達目的地後，該主機並不會送回ICMP time exceeded消息，因為它已是目的地了，那麼traceroute如何得知目的地到達了呢？

traceroute在送出UDP datagrams到目的地時，它所選擇送達的port number是一個一般應用程序都不會用的號碼(30000以上)，所以當此UDP datagram到達目的地後該主機會送回一個[ICMP port unreachable]的消息，而當traceroute收到這個消息時，便知道目的地已經到達了。所以traceroute在Server端也是沒有所謂的Daemon程式。traceroute提取發ICMP TTL到期消息設備的IP地址並作域名解析。每次，traceroute都列印出一系列數據,包括所經過的路由設備的域名及IP地址，三個包每次來回所花時間。

traceroute常用的參數如下，

-n：可以不必進行主機的名稱解析，單純使用IP，速度較快；

-U：使用UDP的port 33434來進行檢測，這是默認的檢測協議；

-I：使用ICMP的方式來進行檢測；

-T：使用TCP來進行檢測，一般使用port 80測試；

-w timeout：若對方主機在幾秒內沒有回應就聲明不通，默認是5秒

-p port：若不想使用UDP與TCP的默認埠號來檢測，可在此改變埠號；

-i device：當自己的主機有多個網路介面時，可在此指明使用的介面；

-g gateway：寬鬆的源站選路。指定路線中的路由；

出現問題的時候，ping和telnet正常，traceroute有時會有延遲，tnsping偶爾連接較長。

此時，對端檢查，到我們的網路有丟包現象，還學到一點，就是單向有問題，意味著雙向會有問題，所以基本定位，和網路相關。

最終確認，就是網路光纖的問題，更換之後，一切恢復正常。當然不是簡單的兩點A-B網路，其中比較複雜，因此某些監控，是無法真正覆蓋，或者聯動。